Production start
(milestone C)
Development start
(milestone B)
Technology
development
Integration
Demonstration
Production
Engineering and management
development
Knowledge
point
Knowledge
point
Knowledge
point
Technologies
and resources
match
Design performs
as expected
Production can
meet cost,
schedule, and
requirements
quality targets
312
Engineering Systems Integration
FIgure 6.7
United States Department of Defense acquisition cycle and decision knowledge points.
task is to link end-to-end functionalities, but this time through the first
demonstrated system thread (first demonstrated). Should there be com
pletely parallel threads without any interactions, the system design and
architecture is that of a system of systems and a different integration plan
is necessary.
During the systems integration process, beginning with the most important system-level thread, the critical objects that must provide linkages
between the subsystem functions are built and tested. Should an object that
is required to demonstrate a critical function not be available, the adjacent
objects that contribute to either of the two adjacent functions should be dem
onstrated. For every object there are always two adjacent objects from which
to integrate and demonstrate functionality.
A systems integration model is a means of structuring the integration
work to better measure the progress of integration. It is quite likely that the
integration model that works for one set of objects and constraints will need
to be tailored for a different set of objects and constraints. It may be that one
model does not deal with all sensitivities that characterize a systems integration effort. This is not unlike the differences in systems engineering process
models. The systems engineering process models strive to first elicit a complete, deliverable set of requirements that can be accomplished within the
constraints of time, budget, and skills; second, provide the structure to manage development work so that it conforms and is totally responsive to this
“legitimate” set of requirements; and third, deliver a product or service that
respects the integrity of the budget, schedule, and needed performances.
Within the management paradigm the work is presumed to be both tractable
and reliably similar in nature throughout the development work. However,
systems engineering is predominantly iterative for the bulk of its use, while
systems integration is predominantly recursive. Yet, the dominant view of
integration today retains its iterative actions—that of fix what needs to be
fixed, then work with the next object to make both of them work (fixing
(milestone C)
Development start
(milestone B)
Technology
development
Integration
Demonstration
Production
Engineering and management
development
Knowledge
point
Knowledge
point
Knowledge
point
Technologies
and resources
match
Design performs
as expected
Production can
meet cost,
schedule, and
requirements
quality targets
312
Engineering Systems Integration
FIgure 6.7
United States Department of Defense acquisition cycle and decision knowledge points.
task is to link end-to-end functionalities, but this time through the first
demonstrated system thread (first demonstrated). Should there be com
pletely parallel threads without any interactions, the system design and
architecture is that of a system of systems and a different integration plan
is necessary.
During the systems integration process, beginning with the most important system-level thread, the critical objects that must provide linkages
between the subsystem functions are built and tested. Should an object that
is required to demonstrate a critical function not be available, the adjacent
objects that contribute to either of the two adjacent functions should be dem
onstrated. For every object there are always two adjacent objects from which
to integrate and demonstrate functionality.
A systems integration model is a means of structuring the integration
work to better measure the progress of integration. It is quite likely that the
integration model that works for one set of objects and constraints will need
to be tailored for a different set of objects and constraints. It may be that one
model does not deal with all sensitivities that characterize a systems integration effort. This is not unlike the differences in systems engineering process
models. The systems engineering process models strive to first elicit a complete, deliverable set of requirements that can be accomplished within the
constraints of time, budget, and skills; second, provide the structure to manage development work so that it conforms and is totally responsive to this
“legitimate” set of requirements; and third, deliver a product or service that
respects the integrity of the budget, schedule, and needed performances.
Within the management paradigm the work is presumed to be both tractable
and reliably similar in nature throughout the development work. However,
systems engineering is predominantly iterative for the bulk of its use, while
systems integration is predominantly recursive. Yet, the dominant view of
integration today retains its iterative actions—that of fix what needs to be
fixed, then work with the next object to make both of them work (fixing