1. Requirements

2.2.7 The project shall select and document a software development life cycle or model that includes phase transition criteria for each life cycle phase (e.g., formal review milestones, informal reviews, software requirements review (SRR), preliminary design review (PDR), critical design review (CDR), test readiness reviews, customer acceptance or approval reviews).

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Class D and Not Safety Critical and Class G are labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

Class F is labeled with "X (not OTS)".  This means that this requirement does not apply to software that is considered to be "Off the Shelf"

2. Rationale

The software development community over the years has recognized the need for rationally managing the activities involved in software development. Boehm in 1988 and Scacchi in 2001 presented some of the original discussion for process models for software development. The IEEE STD 12207, Systems and software engineering — Software life cycle processes, document states that "Models may be used to represent the entire life from concept to disposal or to represent the portion of the life corresponding to the current project." Following in this vein, NASA requires the use of life cycle models for its program and project activities (see NPR 7120.5) and has adapted them to software work product development. The use of a software life cycle model assures that process steps are organized, logically progressive, and repeatable. While the choice of the life cycle model is left up to the software development team, the selected model and the rationale for its selection need to be documented and stored in an appropriate repository. The ready availability of the model helps guide the software development process, provides for an integrated timeline of activities, and provides a framework for the selection and scheduling of the phase transition criteria.

The requirements statement gives examples of the phase transition criteria that can be used for the software development activities. The transition criteria for the software work development can be selected from these examples, or others that apply to the project. Still other examples may be suggested through an examination of the Entrance and Exit Criteria (see Topic 7.9) for each of the major program/project formal reviews. Once agreed to by the project team and the software development team, these criteria, when satisfied, provide a common basis of agreement that the software work products are viable and sufficiently developed to proceed.  Materials presented at major reviews serve as evidence in determining if the transition criteria are satisfied.

3. Guidance

NPR 7150.2 makes no recommendation for a specific software development life cycle model.  Each has its strengths and weaknesses, and no one model is best for every situation.  Whether using the spiral model, the iterative model, waterfall, or any other development life cycle model, the software lead takes into consideration demands upon software engineering from the life cycles at the project and systems levels. The selection of the specific software development life cycle includes consideration for the appropriate phase transition criteria to be used. The Software Development Plan (see SWE-102) can be used to document the chosen life cycle and the selected phase transition criteria. Often the transition criteria include or involve major design reviews such as a PDR or CDR. Topic 7.9 discusses appropriate Entrance and Exit criteria for these reviews. Additional information is available in the NPR 7123.1A, NASA Systems Engineering Processes and Requirements.

NASA Program and Project Life Cycles

The NASA life cycle for Space Flight project management from NPR 7120.5, NASA Space Flight Program and Project Management Requirements, is depicted in Figure 3.1a.  The life cycle includes two major common phases (Formulation and Implementation) that are divided into seven specific life cycle phases, Pre-Phase A thru Phase F, for the NASA project life cycle, as seen in Figure 3.1b. See NPR 7123.1A for details on these project life cycle phases. Each phase is typically marked by a Key Decision Point (KDP), which usually is associated with a prescribed major design review.  A KDP is an event (sometimes called a "gate") wherein the decision authority determines the readiness of a program/project to progress to the next phase of the life cycle. The satisfaction of phase transition criteria is key to the determination of readiness. NPR 7120.5 also provides additional detail about the NASA project life cycle, associated reviews, and KDP's.

                   Figure 3.1a Phases in a NASA program life cycle

                   Figure 3.1b Phases in a NASA project life cycle

The terms "Key Decision Point (KDP)" and "Gate" are nominally equivalent.  The term "transition criteria" may signify an event which, when satisfied, allows a KDP or gate to be "passed" through.

The NASA life cycle for Information Technology and Institutional Infrastructure projects follow a similar model as described in NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements. NASA's Research and Technology Projects follow a less rigorous life cycle described in NPR 7120.8, NASA Research and Technology Program and Project Management Requirements. The selection of the software development life-cycle needs to take into consideration the phases and schedule at the systems and project management levels to ensure software products are delivered in a timely manner.

The Generic Software Life Cycle

A generic life cycle model for software development, which is aligned to the NASA project life cycle, is shown in Figure 3.2.  Concepts and Requirements are part of the common Formulation phase, while Design, Code & Test, and Release & Maintenance are part of the Implementation phase. 

                   Figure 3.2 Phases of a generic software development life cycle

Once customer needs and concepts are defined, requirements development and management begins in the Formulation part of the software development life cycle and extends into the late Implementation phases for final builds. Software design begins after the Software Requirements Review, includes an intermediate Software Preliminary Design Review, and concludes with a software design being baselined at the Software CDR.  Initial and final coding, unit and integration testing, and software documentation, acceptance, and delivery dominate the Implementation period. Typical work products resulting from the requirements phase include the Software Management Plan (see SWE-013 and SWE-102), the Software Requirements Specification (see SWE-049 and SWE-109), and the Requirements Traceability Matrix (see SWE-052). The project specifies KDPs when selecting the type of approved software life cycle (see paragraph 3.3 of NPR 7120.8) to be used on the project. NPR 7123.1A and NASA/SP-2007-6105, NASA Systems Engineering Handbook, provide detailed information on life cycle phase content, reviews, entrance and success criteria, and the types of KDP's to be used.  The software development team can use these descriptions as a basis to develop the required phase transition criteria for the software development activities.

Types of Software Life Cycles

The project must select and document the life cycle(s) to be used for software development activities. A particular project may require a variety of software development activities. As a result, several types of software development life cycle models may be used during the course of a project to accomplish the various components of the software. The following are examples of software development life cycle models. For more information on the strengths and weaknesses of many of the following example software development life cycles, see Petlick, J., Software Development Life Cycle (SDLC).

•  The Standard Waterfall Life Cycle
This strategy consists of performing the applicable processes sequentially during a development. Typically, they are:

1. Requirements specification (requirements analysis).
2. Software design.
3. Coding (implementation).
4. Integration (implementation).
5. Testing (verification).
6. Maintenance.

                   Figure 3.3a Schematic of Standard Waterfall Model

The standard waterfall model performs well for work products with clearly understood requirements. In the model, after each phase is finished, the project proceeds to the next one. Reviews may occur before moving to the next phase.  These reviews allow for the possibility of changes (which in turn may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete. The phase transition criteria may be referred to as a "gate" that the project must pass through to move to the next phase. The waterfall concept discourages revisiting and revising any prior phase once it is complete. In projects that are less well-defined, modified waterfall models may be more appropriate.

•  The Standard Incremental Life Cycle
This life cycle model determines user needs, develops all the systems level requirements, and then performs the rest of the development process in a series of builds. Each successive build adds on to the capabilities encoded in the prior cycle, until the software work product is complete.  Typically, high risk or major functions are developed in early builds.

                   Figure 3.3b Schematic of Standard Incremental Life Cycle Model

Each build has its own set of requirements, design, code, test, and integration activities.  The Incremental life cycle requires that the full system design be completed early and that module interfaces be well-defined.  This life cycle works best when most requirements are known early, but allows those requirements to evolve over time. 

•  The Evolutionary (iterative)  Life Cycle
This life cycle model utilizes the concept of software partial release, capability evolution, new release, and so forth until the mature software work product is obtained. Each evolutionary cycle includes all or most of the life cycle phases in the waterfall model. This life cycle process is typically characterized by the idea that not all of the system requirements are known at the start of the development process. The evolutionary life cycle is typically used when requirements are not well known and are subject to change.

•  The Standard Spiral Life Cycle
A key characteristic of a spiral model is the use of risk management at regular and repetitive stages in the development cycle. The spiral model is actually a series of maturing prototypes with each prototype building on the previous prototype. Each prototype is developed in four phases: planning (determine objectives for the current spiral), risk analysis, engineering (design, development, or test), and evaluation (review and replan the next spiral). 

                   Figure 3.3c Schematic of Standard Spiral Model

The spiral model can be visualized as a process passing through some number of iterations, with a four quadrant diagram being used to represent the four phases. Software is produced in the engineering phase.  Testing, when it begins, also occurs in the engineering phase of the life cycle model. In the visualization, the angular component of the spiral represents progress, while the radial component represents time and/or cost. The software development process using the spiral approach will pass iteratively through each of these phases until the work product is complete with all requirements and stakeholders being satisfied. 

The spiral life cycle is typically used when requirements are not well understood or are extremely complex and prototype software can be used to help flush out firmer requirements. 

•  The agile development method
While not technically a life cycle model, the agile development method is sometimes used by developers who want a formal methodology without the formality of a repetitive cycle.  Like many of the previous models, agile software development uses iterative development as a basis, but it does this with a lighter and more developer-oriented focus. "The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says the key part of documentation is source code." Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. Agile life cycles are typically used in small scale and/or time critical software work product development activities. They work better when utilized by experienced software development teams.

Tailoring of Life Cycles

Individual projects developing software may benefit by tailoring the basic elements, the key decision points, the major review events, and/or the major work products that are to be developed in each phase of the chosen life cycle. The software development lead determines the appropriate life cycle, along with any modifications, that aligns its efforts with the needs of the overall project. The reviews and work products that arise from a tailored life cycle need to be integrated with the overall project life cycle to maintain schedule consistency. The decision to use a tailored software development life cycle does not affect the requirements specified for the software work products. Any needed modifications or inconsistencies caused by the decision to use a modified life cycle model must be managed by the corrective action and change control processes (see SWE-025 and SWE-053).

Additional guidance related to the software development life cycle may be found in the following related requirements in this Handbook:

4. Small Projects

Smaller projects may consider less formal approaches to the life cycle model concept. The agile approach, which relies on testing and feedback, may be more suitable to a smaller project.

5. Resources

6. Lessons Learned

 No Lessons Learned have currently been identified for this requirement.