Monday, June 6, 2011
We now turn to the next step for systems engineers after the first system design concept is defined. This next step is the subject of chapter 8.
8 Selecting the Preferred Design
8.0 Review and Introduction
Selecting the preferred design involves several types of systems analysis tasks including: trade studies, risk assessment, cost modeling, performance analysis/modeling and simulation. Before describing some of these processes it is helpful to review several points from chapters 5 and 6. Trade studies, assessment and analysis are involved in each of the three major steps in the systems engineering process. Referring back to the systems engineering process described in Figure 6-4 shows that iteration takes place not just between each of the major steps of requirements analysis, functional analysis and design synthesis but also between each of these steps and the systems analysis processes of trade studies, modeling and simulation included under technical management. Figure 5-1 illustrates how these systems analysis tasks support the decisions involved in flowing down requirements. Chapter 6 discussed how functional analysis is involved in the flow down of requirements and how systems analysis supports allocating requirements to functions. Chapter 6 also discussed the value in considering many design alternatives at each stage of design synthesis but particularly during concept design. The preferred process for considering design alternatives is to arrive at a baseline design and then conduct trade studies of alternative designs. It is systems analysis processes that aid in selecting the preferred design from the alternatives studied. This chapter describes methods for conducting trade studies, provides an overview of modeling and simulation and introduces some additional diagrams that are useful in describing design concepts.[J1]
8.1 Baseline Concept Management
Project leaders must strive for a balance between forcing decisions too early so that promising alternatives are not considered and leaving too many decisions until just before major design reviews so that the design details are unclear. The standard process for achieving this balance is forcing a design baseline as soon as possible and then conducting trade studies of alternatives to the baseline. This facilitates having a controlled process for making decisions to adopt changes to the baseline and it enables all team members to have the same view of the baseline design at any time.
As soon as the top level function and physical diagrams, the system level specification document and the ICD are complete declare this documentation to be the baseline design. It’s ok that many assemblies or even subsystems are immature; just use the team’s best guesses, but do include as much detail as is available. The baseline design documentation should be maintained where it is available to all team members but no changes to the documentation are allowed without a formal decision process being executed.
As the design progresses and trade studies are performed use the baseline as the starting point and the reference for trades and design decisions. If analysis or trade studies suggest the baseline should change and the project leadership, including the lead systems engineer, agrees then the change is made and the lead systems engineer should notify all key engineering participants that a design change to the baseline has been made. Then the baseline documentation should be updated.
Following this simple baseline management process ensures the whole team is working from the same design data base at any time and it facilitates a controlled design decision process.