21
Importance of Integration
guess-and-try-again approach to integration is time-consuming and dollarexpensive. Consequently, integration as an afterthought is time-consuming
and dollar-expensive (McKenna et al. 2006). The issue of forethought is
completely masked by the predominant influence of interfaces between
objects as the central focus for integration. Much of the planning that is
done for integration is concerned with the interfaces between objects. Early
in the development stage, much attention (and therefore tasks and documentation) is placed on linking the subsystems with various connections
across an interface. Interfaces are managed to be consistent with the
planned interactions between objects, each iteration adding more detail
and refining the actions of the transfers of data. The expectation of the
engineers is that by moving data through objects, subfunctions and therefore system-level functions are enabled to satisfy the performance requirements. While planning for interfaces is indeed a necessary and essential
process, it should neither mask nor undermine the importance and enactments of forethought.
Principle 6: The Principle of Planning
Integration planning is predicated on pattern scheduling (lowest impact on budget),
network scheduling (determinable impact on budget), and ad hoc scheduling (undetermined impact on budget).
Integration planning requires knowledge of the completion dates for
developing objects. But knowing which tasks are to be completed is not the
key for planning. Rather, the problem for planning for integration is in identifying how long the tasks will take to complete. Systems engineering management planning works within the systems engineering process models to
lay out the tasks (break down the tasks) into a structure (referred to as the
work breakdown structure or WBS). The key issue is in determining the
type and amount of resources, the delays due to factors internal and external to completing the task, and the overall impact(s) of missing a scheduled
milestone or delivery.
Task durations should be assessed only based on inputs from engineers,
systems engineers, and management specialists who have direct and applicable experience with integration planning. Still, the theory of planning for
integration rests principally on one of two fundamental premises: integration planning predicated on the scheduled needs for the optimum sequencing of objects or ad hoc by the dictates of what is completed. Planning for
integration involves knowing what technological problems need to be
resolved, recognizing the skills and resources that are available to prepare
objects for integration, and protecting the project team from disruptions
that have significant impact(s) on the progression toward milestones. In
this regard, integration can be thought of as having explanatory variables
for propitious aggregation, starting with the systems design and architecture baselines.
Importance of Integration
guess-and-try-again approach to integration is time-consuming and dollarexpensive. Consequently, integration as an afterthought is time-consuming
and dollar-expensive (McKenna et al. 2006). The issue of forethought is
completely masked by the predominant influence of interfaces between
objects as the central focus for integration. Much of the planning that is
done for integration is concerned with the interfaces between objects. Early
in the development stage, much attention (and therefore tasks and documentation) is placed on linking the subsystems with various connections
across an interface. Interfaces are managed to be consistent with the
planned interactions between objects, each iteration adding more detail
and refining the actions of the transfers of data. The expectation of the
engineers is that by moving data through objects, subfunctions and therefore system-level functions are enabled to satisfy the performance requirements. While planning for interfaces is indeed a necessary and essential
process, it should neither mask nor undermine the importance and enactments of forethought.
Principle 6: The Principle of Planning
Integration planning is predicated on pattern scheduling (lowest impact on budget),
network scheduling (determinable impact on budget), and ad hoc scheduling (undetermined impact on budget).
Integration planning requires knowledge of the completion dates for
developing objects. But knowing which tasks are to be completed is not the
key for planning. Rather, the problem for planning for integration is in identifying how long the tasks will take to complete. Systems engineering management planning works within the systems engineering process models to
lay out the tasks (break down the tasks) into a structure (referred to as the
work breakdown structure or WBS). The key issue is in determining the
type and amount of resources, the delays due to factors internal and external to completing the task, and the overall impact(s) of missing a scheduled
milestone or delivery.
Task durations should be assessed only based on inputs from engineers,
systems engineers, and management specialists who have direct and applicable experience with integration planning. Still, the theory of planning for
integration rests principally on one of two fundamental premises: integration planning predicated on the scheduled needs for the optimum sequencing of objects or ad hoc by the dictates of what is completed. Planning for
integration involves knowing what technological problems need to be
resolved, recognizing the skills and resources that are available to prepare
objects for integration, and protecting the project team from disruptions
that have significant impact(s) on the progression toward milestones. In
this regard, integration can be thought of as having explanatory variables
for propitious aggregation, starting with the systems design and architecture baselines.