bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{alias:SWE-019}
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}

{div3:id=tabs-1}

h1. 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).

h2. {color:#003366}{*}1.1 Notes{*}{color}

NPR 7150.2 does not include any notes for this requirement.

h2. 1.2 Applicability Across Classes

Class D and not Safety Critical is 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"

Class G is 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.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=p|esc=1|ensc=0|f=*|g=p|h=0}
{div3}
{div3:id=tabs-2}

h1. 2. Rationale

The software development community over the years has recognized the need for rationally managing the activities involved in software development. Boehm{^}1^ in 1988 and Scacchi{^}2^ 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|http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4475826]^3^ 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.5D|http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005D_/NM_7120-81_.pdf]^4^) 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 to 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.3|https://nasa7150.onconfluence.com/display/7150/7.3+-+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.
{div3}
{div3:id=tabs-3}



h1. 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.
\\

*{+}NASA Program and Project Life Cycles{+}*

The NASA life cycle for Space Flight project management from [NPR 7120.5D|http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005D_/NM_7120-81_.pdf]^4^ 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 [NASA Systems Engineering Processes and Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7123&s=1A]^5^ 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.
 
               
                    !
!Fig 3.1a.png|border=1!
!


                    Figure 3.1a Phases in a NASA program life cycle

                  !SWE019 Fig3b.jpg|border=1!

                   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|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_0007_&page_name=Chapter1&search_term=7120]. NASA's Research and Technology Projects follows a less rigorous life cycle described in [NPR 7120.8|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_0008_&page_name=ChangeHistory&search_term=7120]. 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. 
\\

                    !Fig 3.2.png|border=1!


                       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 Critical Design Review.  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|https://nasa7150.onconfluence.com/display/7150/SWE-013]and [SWE-102|https://nasa7150.onconfluence.com/display/7150/SWE-102]), the Software Requirements Specification (see [SWE-049|https://nasa7150.onconfluence.com/display/7150/SWE-049] and [SWE-109|https://nasa7150.onconfluence.com/display/7150/SWE-109]), and the Requirements Traceability Matrix (see [SWE-052|https://nasa7150.onconfluence.com/display/7150/SWE-052]).  The project should specify Key Decision Points when selecting the type of approved software lifecycle (see paragraph 3.3) to be used on the project. The NPR 7123.1A document and the NASA/SP-2007\- 6105 [NASA Systems Engineering Handbook|http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf]^6^ 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 Lifecycle (SDLC)|http://condor.depaul.edu/~jpetlick/extra/394/Session2.ppt] ^7^.


*•  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)
# Maintenance

                       !Fig 3.3a.png|border=1,width=429,height=304!

                    Figure 3.3a Schematic of Standard Waterfall Model

The standard waterfall model performs well for work products with clearly understood requirements{^}8^. 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.^9^


*•  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.

                   !Fig 3.3b.jpg|border=1!

                    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). 

                   !Fig 3.3c.png|border=1,width=536,height=476!

                    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."^10^  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-053|https://nasa7150.onconfluence.com/display/7150/SWE-053] and [SWE-055|https://nasa7150.onconfluence.com/display/7150/SWE-055]).


Additional guidance related to the software development life cycle may be found in the following related requirements in this handbook:
| [SWE-102|https://nasa7150.onconfluence.com/display/7150/SWE-102] | Software Development / Management Plan |
| [SWE-105|https://nasa7150.onconfluence.com/display/7150/SWE-105] | Software Maintenance Plan |
\\
{div3}
{div3:id=tabs-4}

h1. 4. Small Projects

Smaller projects should 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.
{div3}
{div3:id=tabs-5}

h1. 5. Resources

# Boehm, B., [A Spiral Model of Software Development and Enhancement|http://www.computer.org/portal/web/csdl/doi/10.1109/2.59]. _IEEE Computer_. *21*(5). Pp 61-72. 1988.
# Scacchi, W., [Process Models in Software Engineering, Encyclopedia for Software Engineering|http://www.ics.uci.edu/%7Ewscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf], 2{^}nd^ Edition, John Wiley and Sons, Inc, New York, 2001.
# IEEE Std 12207, [Systems and software engineering --- Software life cycle Processes|http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4475826], 2008
# [NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005D_/NM_7120-81_.pdf], NPR 7120.5D (NM-7120.81), 2009
# NASA Research and Technology Program and Project Management Requirements, NPR 7120.8, 2008
# NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements, NPR 7120.7, 2008
# [NASA Systems Engineering Processes and Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7123&s=1A] with Change 1, NPR 7123.1A, 2009
# [NASA Systems Engineering Handbook|http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf], NASA/SP-2007-6105 Rev1, 2007
# Petlick, J. Software Development Lifecycle (SDLC). DePaul University, Chicago, IL. Available from [http://condor.depaul.edu/~jpetlick/extra/394/Session2.ppt|http://condor.depaul.edu/~jpetlick/extra/394/Session2.ppt], (Accessed August 31, 2011).
# Royce, W., [Managing the Development of Large Software Systems|http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]. Proceedings of IEEE WESCON 26 (August): 1-9. 1970
# Kuhl, J., [Project Lifecycle Models: How they Differ and When to Use Them|http://www.business-esolutions.com/islm.htm], Business eSolutions, 2002 (accessed online July 22, 2011).
# Fowler, M., [The New Methodology|http://martinfowler.com/articles/newMethodology.html], 2005 (accessed online July 22, 2011).



h2. 5.1 Tools

{panel}
Tools relative to this SWE may be found in the table above. If no tools are listed, none have been currently identified for this SWE. You may wish to reference table xyz in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all\- inclusive, nor is it an endorsement of any particular tool. *Check with your Center to see what tools are available to facilitate compliance with this requirement.* {panel}
{div3}
{div3:id=tabs-6}

h2. 6. Lessons Learned

There are currently no lessons learned identified for this requirement.
{div3}
{tabclose}