257
Integration in Systems Engineering Context
would seem to be: some problems need to be solved now, some later, and
some not at all. Not all problems have an urgency to find a solution. For
example, military systems that take 10 years or more to build do not represent an urgent need. Instead, such a development schedule suggests that
new technologies are being inculcated through the design into the envisioned product or service. If the lifecycle of a new technology is estimated to
be less than the time it takes to design and build the system with today’s
technology, and the system is needed for at least another lifecycle of the proposed new technology, then the system should be built. The system design
should begin with the lowest-risk technologies and over time be upgraded so
that additional capability can be included as new technology is introduced
and proven. The result would be a planned upgrade using new technologies,
maturation of which results in the system have a potentially longer use in
operations. Longer use, however, does not automatically signify that the
newest technology reaches the operational environment first. Rather, the
technology makes it to the field when it is ready. Once the new technology is
proven and fielded, the existing systems (with the “older technology”) can be
upgraded to improve performance(s) across the family of systems that use
the new technology. Contrast this upgrade scheme with waiting longer to
field the first unit and losing out on the increased performance for a number
of years. But it is much more than merely losing out on some years of
enhanced performance during the formative years for the product. It is also
the missed opportunity to develop the supply chain, logistics, maintenance,
support, and training that is often more expensive to set up and sustain.
Early fielding provides many benefits (both in improved capability and costs
of operations). Moreover, the total cost of development for a limited series
production is significantly less than an extended development period. If
greater production is the intent of the acquisition, then once the production
prototypes are built (i.e., the limited series production units), manufacturing
engineering can present a more mature manufacturing item for scaled-up
production.
Defining the problem in systems engineering is akin to forming a question
that needs to be answered for integration. Integration relies on bringing
together objects that satisfy the metaphoric question: What does it take to
satisfy the needs of a specified group of stakeholders? From an integration
perspective, the needs of stakeholders must be considered both from the limited perspectives of the desired parts and from the whole. This implies that
the stakeholder requirements for physical, functional, and behavioral objects
must also be reflective of the lifecycle issues that will confront and pace the
whole. The question domain that describes the distinctive nature of product
or service features desired by the customer(s) can then be posed and answered
through integration. Does the integration of two physical objects result in the
required functionality and the resultant behaviors? Does the test that is
planned for a physical object represent the questions that eventually must be
answered if the unit fails. Of course, a functional requirement being met is
Integration in Systems Engineering Context
would seem to be: some problems need to be solved now, some later, and
some not at all. Not all problems have an urgency to find a solution. For
example, military systems that take 10 years or more to build do not represent an urgent need. Instead, such a development schedule suggests that
new technologies are being inculcated through the design into the envisioned product or service. If the lifecycle of a new technology is estimated to
be less than the time it takes to design and build the system with today’s
technology, and the system is needed for at least another lifecycle of the proposed new technology, then the system should be built. The system design
should begin with the lowest-risk technologies and over time be upgraded so
that additional capability can be included as new technology is introduced
and proven. The result would be a planned upgrade using new technologies,
maturation of which results in the system have a potentially longer use in
operations. Longer use, however, does not automatically signify that the
newest technology reaches the operational environment first. Rather, the
technology makes it to the field when it is ready. Once the new technology is
proven and fielded, the existing systems (with the “older technology”) can be
upgraded to improve performance(s) across the family of systems that use
the new technology. Contrast this upgrade scheme with waiting longer to
field the first unit and losing out on the increased performance for a number
of years. But it is much more than merely losing out on some years of
enhanced performance during the formative years for the product. It is also
the missed opportunity to develop the supply chain, logistics, maintenance,
support, and training that is often more expensive to set up and sustain.
Early fielding provides many benefits (both in improved capability and costs
of operations). Moreover, the total cost of development for a limited series
production is significantly less than an extended development period. If
greater production is the intent of the acquisition, then once the production
prototypes are built (i.e., the limited series production units), manufacturing
engineering can present a more mature manufacturing item for scaled-up
production.
Defining the problem in systems engineering is akin to forming a question
that needs to be answered for integration. Integration relies on bringing
together objects that satisfy the metaphoric question: What does it take to
satisfy the needs of a specified group of stakeholders? From an integration
perspective, the needs of stakeholders must be considered both from the limited perspectives of the desired parts and from the whole. This implies that
the stakeholder requirements for physical, functional, and behavioral objects
must also be reflective of the lifecycle issues that will confront and pace the
whole. The question domain that describes the distinctive nature of product
or service features desired by the customer(s) can then be posed and answered
through integration. Does the integration of two physical objects result in the
required functionality and the resultant behaviors? Does the test that is
planned for a physical object represent the questions that eventually must be
answered if the unit fails. Of course, a functional requirement being met is