The National Aeronautics and Space Administration (NASA) uses the con- cept of lifecycle for a program, called a program lifecycle which consists of distinct phases separated by control gates. NASA uses its lifecycle model not only to describe how a program evolves over time, but also to aid manage- ment in program control. The boundaries between phases are defined so that they provide proceed or do not proceed decisions. Decisions to proceed may be qualified by liens that must be removed within a reasonable time. A program that fails to pass a control gate and has enough resources may be allowed to readdress the deficiencies or it may be terminated.
The government operates with a fiscal budget and annual funding lead- ing to implicit funding control gates at the beginning of each fiscal year. While these gates place planning requirements on the project and can make significant replanning necessary, they are not part of an orderly system engineering process; rather, they constitute one of the sources of uncertainty that affect project risks and should be included in project risk considerations. The NASA model can generally be defined to include the following phases:
Prephase A — Advanced Studies
The objective of this phase is to produce a broad spectrum of ideas and alternatives for missions from which new projects or programs can be selected. Major activities and their products in this prephase A are to (1) identify missions consistent with the NASA charter, (2) identify and involve users, and (3) perform preliminary evaluations of possible missions. Typically, this phase consists of loosely structured examinations of new ideas, usually without central control and mostly oriented toward small studies. Also, program or project proposals are prepared that include mission justifi- cation and objectives, possible operations concepts, possible system architec- tures, and cost, schedule, and risk estimates. The phase also produces master plans for existing program areas. The control gate for this phase is informal proposal reviews. Descriptions of projects suggested generally include initial system design and operational concepts, preliminary project organization, schedule, testing and review structure, and documentation requirements.
This phase is of an ongoing nature since technological progress makes possible missions that were previously impossible. Manned trips to the moon and the taking of high-resolution pictures of planets and other objects in the universe illustrate past responses to this kind of opportunity. New opportu- nities will continue to become available as our technological capabilities grow.
Phase A — Conceptual design studies
The objective of this phase is to determine the feasibility and desirability of a suggested new major system in preparation for the seeking of funding. This phase includes major activities such as (1) preparation of mission needs statements, (2) development of preliminary system requirements, (3) identi- fication of alternative operations and logistics concepts, (4) identification of project constraints and system boundaries, (5) consideration of alternative design concepts, and (6) demonstrating that credible, feasible designs exist. System validation plans are initiated in this phase. Also, systems engineering tools and models are acquired, environmental impact studies are initiated, and program implementation plans are prepared. The control gates are con- ceptual design review and prephase B nonadvocate review. This phase is frequently described as a structured version of the previous phase.
Phase B — Concept definition
The objective of this phase is to define the project in enough detail to establish an initial baseline. This phase includes major activities such as
• reaffirmation of the mission needs statement, • preparation of a program initiation agreement,
• preparation of a system engineering management plan, • preparation of a risk management plan,
• initiation of configuration management,
• development of a system-level cost-effectiveness model, • restatement of the mission needs as system requirements, • establishment of the initial requirements traceability matrix,
• selection of a baseline system architecture at some level of resolution and concept of operation,
• identification of science payload,
• definition of internal and external interface requirements, • definition of the work breakdown structure,
• definition of verification approach and policies, • preparation of preliminary manufacturing plans, • identification of government resource requirements, • identification of ground test and facility requirements, • development of statement of work,
• revision and publication of project implementation plans, • initiation of advanced technology development programs.
The control gates include project definition and cost review, program and project requirements review, and safety review.
Tradeoff studies in this phase should precede rather than follow system design decisions. A feasible system design can be defined as a design that can be implemented as designed, and can then accomplish the system’s goal within the constraints imposed by the fiscal and operating environment. To be credible, a design must not depend on the occurrence of unforeseen
breakthroughs in the state of the art. While a credible design may assume likely improvements in the state of the art, it is nonetheless riskier than one that does not.
Phase C — Design and development
This phase has the objective to design a system and its associated sub- systems, including its operations systems, so that it will be able to meet its requirements. This phase has primary tasks and activities that include
• adding subsystem design specifications to the system architecture, • publishing subsystem requirements documents,
• preparation of subsystem verification plans, • preparation of interface documents,
• repetition of the process of successive refinement to get “design-to” and “build-to” specifications and drawings, verification plans, and interface documents at all levels,
• augmentation of documents to reflect the growing maturity of the system,
• monitoring the project progress against project plans,
• development of the system integration plan and the system opera- tions plans,
• documentation of tradeoff studies performed,
• development of the end-to-end information system design and the system deployment approach,
• identification of opportunities for preplanned product improvement, and
• confirmation of science payload selection.
Control gates include system-level preliminary design review, sub- system (and lower level) preliminary design reviews, subsystem (and lower level) critical design reviews, and system-level critical design review.
The purpose of this phase is to unfold system requirements into system and subsystem designs. Several popular approaches can be used in the unfolding process, such as the code-and-fix, the waterfall, requirements- driven design, and/or evolutionary development.
Phase D — Fabrication, integration, test and certification
The purpose of this phase is to build the system designed in the previous phase. Activities include fabrication system of hardware and coding of soft- ware, integration, verification and validation, and certified acceptance of the system.
Phase E — Pre-operations
The purpose of this phase is to prepare the certified system for operations by performing main activities that include the initial training of operating personnel and finalization of the integrated logistics support plan. For flight projects, the focus of activities then shifts to prelaunch integration and
launch. On the other hand, for large flight projects, extended periods of orbit insertion, assembly, and shakedown operations are needed. In some projects, these activities can be treated as minor items permitting combining this phase with either its predecessor or its successor. The control gates are launch readiness reviews, operational readiness reviews, and safety reviews.
Phase F — Operations and disposal
The objective of this phase is to actually meet the initially identified need, and then to dispose of the system in a responsible manner. This phase includes major activities such as (1) training replacement operators, (2) con- ducting the mission, (3) maintaining the operating system, and (4) disposing of the system. The control gates are operational acceptance review, regular system operations reviews, and system upgrade reviews.
Phase F encompasses the problem of dealing with the system when it has completed its mission. The end of life depends on many factors. For example, the disposal of a flight system with short-mission duration, such as a space-lab payload, may require only selection and retrieval of the hard- ware and its return to its owner, whereas a large flight project of long duration disposal may proceed according to long-established plans or may begin as a result of unplanned events, such as accidents. In addition to uncertainty as to when this part of the phase begins, the activities associated with safely deactivating and disposing of a system may be long and complex. As a result, the costs and risks associated with different designs should be considered during the planning process.
2.2.3.3 Technical maturity model
The technical maturity model is another view of the lifecycle of a project. According to this model, the lifecycle considers a program as an interaction between society and engineering. The model concentrates on the engineering aspects of the program and not on the technology development through research. The program must come to fruition by meeting both the needs of the customer and also meeting the technical requirements. Therefore, by keeping distinctions among technical requirements, needs and technology development, the motivations, wants, and desires of the customer are dif- ferentiated from the technology issues during the course of the project.
2.2.4 Black-box method
Historically, engineers have built analytical models to represent natural and manmade systems using empirical tools of observing system attributes of interest (called system output variables) and trying to relate them to some other controllable or uncontrollable input variables. For example, a structural engineer might observe the deflection of a bridge as an output of an input such as a load at middle of its span. By varying the intensity of the load, the deflection changes. Empirical test methods would vary the load incremen- tally and the corresponding deflections are measured, thereby producing a relationship such as
y = f(x) (2.1) where x = input variable, y = output variable, and f = a function that relates input to output. In general, a system might have several input vari- ables that can be represented as a vector X, and several output variables that can be represented by a vector Y. A schematic representation of this model is shown in Figure 2.8. According to this model, the system is viewed as a whole entity without any knowledge on how the input variables are pro- cessed within the system to produce the output variables. This black box view of the system has the advantage of shielding an analyst from the physics governing the system, and providing the analyst with the opportunity to focus on relating the output to the input within some range of interest for the underlying variables. The primary assumptions according to this model are (1) the existence of causal relationships between input and output vari- ables as defined by the function f, and (2) the effects of time, i.e., time-lag or time-prolongation within the system, are accounted for by methods of mea- surement of input and output variables.
For complex engineering systems or natural systems, the numbers of input and output variables might be large with varying levels of importance. In such cases, a system engineer would be faced with the challenge of identifying the most significant variables, and how they should be measured. Establishing a short list of variables might be a most difficult task especially for novel systems. Some knowledge of the physics of the system might help in this task of system identification. Then, the analyst needs to decide on the nature of time-relation between input and output by addressing questions such as
• Is the output instantaneous as a result of the input?
• If the output lags behind the input, what is the lag time? Are the lag times for the input and output related, i.e., exhibiting nonlinear be- havior?
• Does the function f depend on time, number of input applications, or magnitude of input?
• Does the input produce an output, and linger within the system affecting future outputs?
These questions are important for the purpose of defining the model, its applicability range, and validity.
Figure 2.8 Black-box system model.