This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
See edit history of this section
Post feedback on this section
3.3.3 The project manager shall select and document a software development life cycle or model that includes phase transition criteria for each life-cycle phase.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
NASA programs and projects are managed to life cycles, the division of the program’s and project’s activities over the full lifetime of the program or project, based on the expected maturity of program and project information and products as they move through defined phases in the life cycle. At the top level, this work is divided into two phases, Formulation and Implementation, each of which is divided into sub phases. As part of checks and balances, programs and projects must be given formal approval at specific points to progress through their life cycle. This approval is based on periodic evaluation.
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, agile 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 SDP-SMP) 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 - Entrance and Exit Criteria discusses appropriate entrance and exit criteria for these reviews. Additional information is available in the NPR 7123.1, NASA Systems Engineering Processes and Requirements 041.
The software development community over the years has recognized the need for rationally managing the activities involved in software development. Boehm 134 in 1988 and Scacchi 314 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,” 224 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 082) 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.
Formal review milestones, informal reviews, software requirements reviews (SRR), preliminary design reviews (PDR), critical design reviews (CDR), test readiness reviews (TRR), customer acceptance or approval reviews are 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 - Entrance and Exit Criteria) 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.
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 082, 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.1 041 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 264." 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 269." 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 lifecycle, 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 System Requirements Review (SRR), includes an intermediate Software Preliminary Design Review (PDR), and concludes with a software design being baselined at the Software Critical Design Review (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 SDP-SMP), the Software Requirements Specification (see SRS), 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.1 and NASA/SP-2007-6105, “NASA Systems Engineering Handbook 273, 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) 298.
• 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 273. 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 298.
• The Standard Incremental Life Cycle
This life-cycle model determines user needs, develops all the system 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 re-plan 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. "Agile software development is an iterative, incremental approach to developing and releasing software. Agile principles include commitment to timely and ongoing software deliveries, changing requirements, simplicity in approach, and sustainable development cycles. The Agile method also promotes self-organizing, self-empowered, self-monitoring teams and individuals who work collaboratively with face-to-face communication. Agile development practices include frequent releases, ongoing testing, customer and stakeholder participation throughout the development process, co-ownership of code and pair-programming. A range of agile methodologies have emerged. All embrace the general principles of agile development but can differ in focus and level of formality." 015
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-024 and SWE-053).
Additional guidance related to the software development life cycle may be found in topic 7.18 - Documentation Guidance in this Handbook.
4. Small Projects
Smaller projects may consider less formal approaches to the life-cycle model concept.
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.