311
Systems Integration Management
the development aspects (schedule constraints, resources, facilities, labor);
the results of the development aspects (system design, preliminary design,
detailed design, architecture, descriptions of physical objects, interfaces
between physical objects, descriptions of product or service functionalities),
and testing plans (early-to-late stages). The iterative nature of systems engineering transforms a set of initial requirements into design, architecture,
and then development. Throughout these steps, the requirements continue
to be refined, the design becomes more detailed, and the architecture
matures. By the time the development effort is readying for integration, the
system functionalities, the functional decomposition, and the allocation to
physical objects should be substantially completed. By the end of the detailed
design phase, the integration plan should be thought of as the baseline from
which refinements will be added during development.
Integration strategies come under various names from do it all at once “big
bang” or dividing the integration process into stages (Tahan and Ben-Asher
2005 citing Sommerville 2001) for incremental integration; or do it when you
can, or do it top down and bottoms up, or do it according to some other rationale. Perhaps the reason why there are so many choices is that no one strategy seems to have proven very effective given the factors that confound
integration (e.g., unknown impacts of boundaries) (i.e., complexity). The
notion of iterative integration often means that one or both the components undergoing integration will need to be changed. A failed integration
activity means just that, one or both components need to be changed.
Whether the changes are to be localized or are pervasive throughout an
object, the iterative notion of integration means failure. This is in sharp contrast to systems engineering that relies heavily for its success in dealing
with unknowns through iteration.
Building an integration plan requires a strategy and a model for integration. The strategy is at once the path we undertake to develop and build pairs
of objects that will provide the requisite functionalities. When these objects
are linked through interfaces with proper inputs and outputs of EMMI, the
resultant functions form the end-to-end chains (or threads) that demonstrate
the system-level functions. A systems integration strategy usually involves
planning for codevelopment of objects, orchestrated first at the component
level, and then at the subsystem level. The strategy aims to match the needs
of user’s requirement for functionality with the priorities the user ascribes
based on the minimally acceptable set of functions that demonstrate the
basic elements of the product or service. To be clear, this is not the “wish” list
of the user, nor is it what the user needs. The first objects to be integrated are
only those that are necessary and sufficient to show end-to-end viability of a
major system-level function. Integration activities focus on this one thread,
not all threads in parallel (Figure 6.7).
Once the main system thread is completed and demonstrated, parallel
threads, interacting threads, and subsidiary threads that add additional
functionality are then worked on in a similar manner. Again, the integration
Systems Integration Management
the development aspects (schedule constraints, resources, facilities, labor);
the results of the development aspects (system design, preliminary design,
detailed design, architecture, descriptions of physical objects, interfaces
between physical objects, descriptions of product or service functionalities),
and testing plans (early-to-late stages). The iterative nature of systems engineering transforms a set of initial requirements into design, architecture,
and then development. Throughout these steps, the requirements continue
to be refined, the design becomes more detailed, and the architecture
matures. By the time the development effort is readying for integration, the
system functionalities, the functional decomposition, and the allocation to
physical objects should be substantially completed. By the end of the detailed
design phase, the integration plan should be thought of as the baseline from
which refinements will be added during development.
Integration strategies come under various names from do it all at once “big
bang” or dividing the integration process into stages (Tahan and Ben-Asher
2005 citing Sommerville 2001) for incremental integration; or do it when you
can, or do it top down and bottoms up, or do it according to some other rationale. Perhaps the reason why there are so many choices is that no one strategy seems to have proven very effective given the factors that confound
integration (e.g., unknown impacts of boundaries) (i.e., complexity). The
notion of iterative integration often means that one or both the components undergoing integration will need to be changed. A failed integration
activity means just that, one or both components need to be changed.
Whether the changes are to be localized or are pervasive throughout an
object, the iterative notion of integration means failure. This is in sharp contrast to systems engineering that relies heavily for its success in dealing
with unknowns through iteration.
Building an integration plan requires a strategy and a model for integration. The strategy is at once the path we undertake to develop and build pairs
of objects that will provide the requisite functionalities. When these objects
are linked through interfaces with proper inputs and outputs of EMMI, the
resultant functions form the end-to-end chains (or threads) that demonstrate
the system-level functions. A systems integration strategy usually involves
planning for codevelopment of objects, orchestrated first at the component
level, and then at the subsystem level. The strategy aims to match the needs
of user’s requirement for functionality with the priorities the user ascribes
based on the minimally acceptable set of functions that demonstrate the
basic elements of the product or service. To be clear, this is not the “wish” list
of the user, nor is it what the user needs. The first objects to be integrated are
only those that are necessary and sufficient to show end-to-end viability of a
major system-level function. Integration activities focus on this one thread,
not all threads in parallel (Figure 6.7).
Once the main system thread is completed and demonstrated, parallel
threads, interacting threads, and subsidiary threads that add additional
functionality are then worked on in a similar manner. Again, the integration