SYSTEMS, PROJECTS, AND MANAGEMENT
1.4 THE SYSTEMS APPROACH
management emphasizes “the learning organization” and proposes methods of assuring that such learning occurs [1.16]. Learning from one’s own as well as another’s errors is a basic rationale for this as well as other books.
January10,200813:23CharCount=
Requirements Project
plan
Functional design of alternatives
Analysis of alternatives
Preferred system architecture
Evaluation criteria Iteration
Iteration
Iteration No
No Yes
Yes Satisfies requirements
?
Analysis of alternatives
Trade-off studies
Preferred subsystem
designs
Subsystems/
builds Subsystem/
build integration
Subsystem/
build test
System test and evaluation
Cost- effective physical system Satisfies
requirements
?
Subsystem design
• Hardware
• Software
• Human
• Hardware
• Software
• Human
1 2
7
8
3 4
9 10
5
6
11
12
13
14 15 16
17
Architecture design
Subsystem design
System construction
Figure 1.1. Overview of the systems approach.
18
functions are to be implemented in hardware, software, and human components. Several such designs are configured, each representing a feasible alternative. Often, these alternatives span concepts that range from low cost to high performance.
Box 4: Analysis of Alternatives.Each of the alternatives is analyzed in terms of cost, performance, and satisfaction of requirements. By interacting back and forth between the postulation of alternatives and their analyses, it is ultimately possible to determine the quantitative and qualitative attributes of the various viable alternatives. At the system level, two to four alternatives might be considered desirable.
Box 5: Evaluation Criteria.The analysis of alternatives could not be carried out without the clear identification of criteria against which the alter- natives are evaluated. These criteria are derived from the requirements and may include such features as interoperability, growth potential, and societal risk as well as the detailed performance items listed in the requirements document. A formal evaluation framework is normally necessary in order to carry out the evaluation.
Box 6: Preferred System Architecture.This step is a selection of the system- level architecture that is most cost-effective. It represents a choice among the competing alternatives. Many projects go astray because they leap to a preferred architecture without the explicit consideration of alterna- tives. As an example, this may constitute the selection of time-division multiplexing as preferred over a frequency-division multiplexing ap- proach for a communications system. System architecture is a very important part of the systems approach and the system engineering and design process and is discussed again in Chapter 9.
Box 7: Satisfies Requirements? We make this step explicit in order to emphasize the significance of assuring that the preferred system archi- tecture meets all the designated requirements. If even one mandatory requirement is not completely met, then it is necessary to loop back and consider additional alternatives. If all the key requirements are satis- fied, then and only then can the project team move on to the matter of subsystem design.
Box 8: Subsystem Design. By knowing the preferred architecture at the system level, it is then possible to move into detailed subsystem design.
These subsystems involve the interplay among hardware, software, and human elements. Subsystems are naturally divided into subordinate el- ements, which can be called builds, configuration items (CIs), compo- nents, or other names that can be mutually understood.
Box 9: Analysis of Alternatives. Following a process similar to that uti- lized to develop a preferred architecture, alternatives are set forth and analyzed at the subsystem level of design. This is critical because there are numerous ways to implement a given function. Issues of timing and sizing are usually important here.
Box 10: Trade-Off Studies.A variety of trade-offs are generally considered in trying to optimize at the subsystem level. These may be power–
weight–space–performance trades, attempting to find the proper balance of attributes. An iteration loop is shown explicitly to account for the possible need to postulate additional alternative subsystem designs.
Box 11: Preferred Subsystem Designs.Preferred subsystem designs flow from the previous steps, representing near-optimal choices with all rele- vant factors explicitly considered in the trade-off studies. At this stage of the process, one is still at the design level and the system has not, as yet, been built. There are some exceptions to this, as with the notion of rapid prototyping of subsystems in order to prove certain critical high-risk parts of a system.
Box 12: Satisfies Requirements?We again wish to make explicit the check- ing of the preferred subsystem designs to assure that all requirements have been met. If not, an iteration loop is shown that means we are “back to the drawing board.” If so, we move on to the physical building of the system.
Box 13: Subsystems/Builds. The physical construction of the subsystems is now in order, occurring for the hardware, software, and human com- ponents, and in consonance with the subsystem designs. Builds is used here as a generic name for configuration items, components, subsub- systems, and so on. The physical construction proceeds through the various levels of indenture defined in the design process.
Box 14: Subsystem/Build Integration.After a given build (or CI) has been constructed, it must be integrated with all interoperating builds (or CIs).
This is performed at all subordinate levels of the system.
Box 15: Subsystem/Build Test.Physical testing takes place as builds (CIs) are integrated to assure that they work together, are compatible, and perform as required. If integrated builds fail these tests, the process is iterated until the test leads to success. Clearly, all test plans and procedures must be based on the original or derivative requirements.
Many people have suggested, especially with respect to software, that a
“build a little, test a little” orientation is most likely to lead to success.
Box 16: System Test and Evaluation. A final system-level test and eval- uation (T&E) step confirms that the system meets both development and operational requirements. This can be a long and protracted step, especially for systems that are to operate in a hostile field environment such as aboard a ship or aircraft. It represents an end-to-end check of the full system and a final verification that all requirements have been met.
Box 17: Cost-Effective Physical System.The result of all the previous steps, and many implicit substeps, is a cost-effective physical system.
Although these steps represent most of the elements of the systems ap- proach, there are several that are implicit and therefore are examined in later
chapters. However, this overview explains the key aspects of such an ap- proach. It is intended to lead to a system that meets all requirements and is cost-effective and robust. These terms are examined in the chapters dealing with systems engineering management.
The Project Manager and Chief Systems Engineer are clearly key players in assuring that the systems approach is carried out with discipline and good sense. We now more formally explore their roles and responsibilities in a corporate setting.