315
Systems Integration Management
review tests and test results for patterns during development (as opposed to
integration), the intent is to pass the test so the focus is on “fixing the problem” with the object. The expectation during systems engineering development is to uncover, face, and fix problems. Consequently, the thinking during
systems engineering development is to loop back and fix problems. Should
an object pass its tests during development the task is to then either move on
to another object (repeating what was done on yet another object) or carry
forward with the same object and bring another object together with it for
another test. This bringing together of objects is (by definition) integration.
But bringing together objects that result in a failed test again focuses attention on the problem that must be solved to pass the test. Iteratively, the test
provides insight into the problem. Systems engineering is focused on iterative activities to pass tests.
The iterative nature of systems engineering is built into the structure of
analyzing the results of the testing of an object. The purpose of analyzing
patterns to perform retrospective analysis is focused on improving the
chances of the object to successfully complete its prescribed tests. The view
that passing the tests is needed to give confidence to the design and implementation of the object is predicted on the belief that tests accurately demonstrate some measure of meaningful progress toward project goals. The
difficulty arises when those beliefs translate into some measure that is quantifiable in terms of schedule or rate of expenditure (i.e., earned value). If only
one object is tested, then no function is enabled (as it takes two objects to
comprise a function).
For acquisition, decision makers rely on events to help determine the status of a project (or program). The acquisition cycle and knowledge points
(specifically for the U.S. Department of Defense (GAO 2011)) to aid with
decisions to continue with development work are indicated as technology
development, integration, demonstration, and production. Figure 6.8 illustrates these knowledge points in terms of a sequence of phases.
These are top-level categories that subsume a myriad of decision points.
Various versions of acquisition cycles and decision points are routine for
government and industry, some formalized while others are ad hoc.*
Regardless of the manner or formality, management review of development
work for new products and services is a key aspect of most projects. In the
case of the U.S. Department of Defense, technology development means
achieving a sufficient level of technology maturity by the start of system
development, coupled with the project’s resources matching its expected
needs. These two factors have been shown by the U.S. Government
Accountability Office to be key determinants of a project’s success. The first
decision point involves work under the auspices of the system engineering
* The systems engineering process models have many decision points, separated both by
stage of development and by milestones that signify that a step is completed and the next
step can begin.
Systems Integration Management
review tests and test results for patterns during development (as opposed to
integration), the intent is to pass the test so the focus is on “fixing the problem” with the object. The expectation during systems engineering development is to uncover, face, and fix problems. Consequently, the thinking during
systems engineering development is to loop back and fix problems. Should
an object pass its tests during development the task is to then either move on
to another object (repeating what was done on yet another object) or carry
forward with the same object and bring another object together with it for
another test. This bringing together of objects is (by definition) integration.
But bringing together objects that result in a failed test again focuses attention on the problem that must be solved to pass the test. Iteratively, the test
provides insight into the problem. Systems engineering is focused on iterative activities to pass tests.
The iterative nature of systems engineering is built into the structure of
analyzing the results of the testing of an object. The purpose of analyzing
patterns to perform retrospective analysis is focused on improving the
chances of the object to successfully complete its prescribed tests. The view
that passing the tests is needed to give confidence to the design and implementation of the object is predicted on the belief that tests accurately demonstrate some measure of meaningful progress toward project goals. The
difficulty arises when those beliefs translate into some measure that is quantifiable in terms of schedule or rate of expenditure (i.e., earned value). If only
one object is tested, then no function is enabled (as it takes two objects to
comprise a function).
For acquisition, decision makers rely on events to help determine the status of a project (or program). The acquisition cycle and knowledge points
(specifically for the U.S. Department of Defense (GAO 2011)) to aid with
decisions to continue with development work are indicated as technology
development, integration, demonstration, and production. Figure 6.8 illustrates these knowledge points in terms of a sequence of phases.
These are top-level categories that subsume a myriad of decision points.
Various versions of acquisition cycles and decision points are routine for
government and industry, some formalized while others are ad hoc.*
Regardless of the manner or formality, management review of development
work for new products and services is a key aspect of most projects. In the
case of the U.S. Department of Defense, technology development means
achieving a sufficient level of technology maturity by the start of system
development, coupled with the project’s resources matching its expected
needs. These two factors have been shown by the U.S. Government
Accountability Office to be key determinants of a project’s success. The first
decision point involves work under the auspices of the system engineering
* The systems engineering process models have many decision points, separated both by
stage of development and by milestones that signify that a step is completed and the next
step can begin.