2.0    Fundamentals of Systems Engineering 
2.1    The Common Technical Processes and the SE Engine
2.2    An Overview of the SE Engine by Project Phase   
2.3    Example of Using the SE Engine
2.4    Distinctions between Product Verification and Product Validation  
2.5    Cost Effectiveness Considerations 
2.6    Human Systems Integration (HSI) in the SE Process 
2.7    Competency Model for Systems Engineers 

The objective of systems engineering is to see that the system is designed, built, and can be operated so that it accomplishes its purpose safely in the most cost-effective way possible considering performance, cost, schedule, and risk. A cost-effective and safe system should provide a particular kind of balance between effectiveness and cost. This causality is an indefinite one because there are usually many designs that meet the cost-effective condition.

Design trade studies, an important part of the systems engineering process, often attempt to find designs that provide the best combination of cost and effectiveness. At times there are alternatives that either reduce costs without reducing effectiveness or increase effectiveness without increasing cost. In such “win-win” cases, the systems engineer’s decision is easy. When the alternatives in a design trade study require trading cost for effectiveness, the decisions become harder.

The Systems Engineer’s Dilemma

At each cost-effective solution:

• To reduce cost at constant risk, performance must be reduced.
• To reduce risk at constant cost, performance must be reduced.
• To reduce cost at constant performance, higher risks must be accepted.
• To reduce risk at constant performance, higher costs must be accepted.

In this context, time in the schedule is often a critical resource, so that schedule behaves like a kind of cost.

Figure 2.5-1 shows that the life cycle costs of a program or project tend to get “locked in” early in design and development. The cost curves clearly show that late identification of and fixes to problems cost considerably more later in the life cycle. Conversely, descopes taken later versus earlier in the project life cycle result in reduced cost savings. This figure, obtained from the Defense Acquisition University, is an example of how these costs are determined by the early concepts and designs. The numbers will vary from project to project, but the general shape of the curves and the message they send will be similar. For example, the figure shows that during design, only about 15% of the costs might be expended, but the design itself will commit about 75% of the life cycle costs. This is because the way the system is designed will determine how expensive it will be to test, manufacture, integrate, operate, and sustain. If these factors have not been considered during design, they pose significant cost risks later in the life cycle. Also note that the cost to change the design increases as you get later in the life cycle. If the project waits until verification to do any type of test or analysis, any problems found will have a significant cost impact to redesign and reverify.

The technical team may have to choose among designs that differ in terms of numerous attributes. A variety of methods have been developed that can be used to help uncover preferences between attributes and to quantify subjective assessments of relative value. When this can be done, trades between attributes can be assessed quantitatively. Often, however, the attributes are incompatible. In the end, decisions need to be made in spite of the given variety of attributes. There are several decision analysis techniques (Section 6.8) that can aid in complex decision analysis. The systems engineer should always keep in mind the information that needs to be available to help the decision-makers choose the most cost-effective option.