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:
- Requirements specification (requirements analysis).
- Software design.
- Coding (implementation).
- Integration (implementation).
- Testing (verification).
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:
Software Development/Management Plan
Software Maintenance Plan