Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Wiki Markup
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}


h1. 1. Requirements

2.5.5 The project shall determine which software processes, activities, and tasks are required for the project.

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 F is labeled with "X (not OTS)". This means that this requirement does not apply to off-the-shelf software for these 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.


h1. 2. Rationale

Projects evaluate the environment (e.g., organization, funding, size, personnel) in which they plan to develop software. From this evaluation, they choose an appropriate set of processes, tasks and activities to develop software which meets their needs. The Center Process Asset Library (PAL) may contain processes tailored to different development environments. The planning down to the activity and task levels will assure that only the appropriate processes are selected from the ones available to the project. A further evaluation of these processes will determine the level of software resources that the project team needs to include in the planning documentation and funding requests.

h1. 3. Guidance

The formulation phase in the life cycle includes the selection and execution of planning activities that are necessary for the successful initiation of a project. During this phase of the project the project team defines customer needs, system level requirements, make-versus-buy strategies, overall project and software management plans, a work breakdown structure (WBS), software safety assessments, and primary project deliverables and work products.

The project develops planning documents to account for the above and for use in managing the software development efforts. The core set of software plans includes a Software Development or Management Plan (see [SWE-102|SWE-102]), Configuration Management Plan (see [SWE-103|SWE-103]), Test Plan (see [SWE-104|SWE-104]), Maintenance Plan (see [SWE-105|SWE-105]), and Assurance Plan (see [SWE-106|SWE-106]). The planning may be recorded in a single document or in standalone documents, depending on project size and requirements.

{panel}The selections of the processes to support and execute the above planning and definition activities typically are based on an analysis of the desired software work products and their characteristics, and on a determination of which activities and tasks are needed to produce these work products. The selected processes must meet the requirements of the NPR 7150.2 that are applicable to the project.{panel}

Projects may find it helpful to review the following sources of listed processes when planning their project implementation:

* [Agency and Center PALs|] that can be used to locate and select processes and activities that are applicable to software development activities.
* The processes and best practices described in the Software Engineering Institute's (SEI) [Capability Maturity Model Integration for Development (CMMI®-Dev), Version 1.3 ^1^|]. The CMMI®-Dev describes the applicability of its processes areas for developing software work products.
* [NPR 7123.1A|], which establishes a core set of common Agency-level technical processes and requirements needed to define, develop, realize, and integrate the quality of the systems products created and acquired for NASA. The set of common processes in the NPR may be supplemented or tailored to achieve specific project requirements. ^2^
* [AS9100C|], which provides a process-based quality management system for aerospace applications. "The application of a system of processes within an organization...can be referred to as the 'process approach'. An advantage of the process approach is the ongoing control that it provides over the linkage between the individual processes within the system of processes, as well as over their combination and interaction." ^3^

The processes that are selected and/or tailored to be applicable to the project will be accomplished through the execution of the activities and tasks that compose the process. Specifically, NPR7123.1 describes an activity as a set of tasks that describe the technical effort needed to accomplish a process and to help generate the expected outcomes. Software processes are generally reviewed during the software development life cycle, and revised and modified as needed. The appropriate planning and scheduling of these tasks and activities enable the successful execution of the planned processes. The successful placement of the applicable and tailored processes, activities, and tasks on the project development schedule will complete the determination process.

Additional guidance related to Software Process Determination may be found in the following related requirements in this handbook:

| [SWE-005|SWE-005] | Software Processes |
| [SWE-013|SWE-013] | Software Plans |
| [SWE-016|SWE-016] | Software Schedule |
| [SWE-019|SWE-019] | Software Life cycle |
| [SWE-027|SWE-027] | Use of COTS, GOTS, MOTS |
| [SWE-032|SWE-032] | CMMI Levels |
| [SWE-098|SWE-098] | Agency PAL |
| [SWE-102|SWE-102] | Software Development/ Management Plan |
| [SWE-103|SWE-103] | Software Configuration Management Plan |
| [SWE-104|SWE-104] | Software Test Plan |
| [SWE-105|SWE-105] | Software Maintenance Plan |
| [SWE-106|SWE-106] | Software Assurance Plan |
| [SWE-130|SWE-130] | Develop Software Safety Plan |

h1. 4. Small Projects

Small projects may want to use a standard set of processes that have been tailored for their development environment, and type of project. These processes may have been developed by people in the same organization that may have done similar developments.

h1. 5. Resources

# ["CMMI® for Development, Version 1.3"|], CMU/SEI-2010-TR-033, Software Engineering Institute, 2010
# [NASA Systems Engineering Processes and Requirements|] with Change 1, NPR 7123.1A, 2009
# SAE AS9100C, ["Quality Management Systems -- Requirements for Aviation, Space and Defense Organizations"|],available through the [NASA Technical Standards|] website
# [NASA Systems Engineering Handbook| SP-2007-6105 Rev 1 Final 31Dec2007.pdf], NASA/SP-2007-6105 Rev1, 2007
# [NASA Space Flight Program and Project Management Requirements|], NPR 7120.5D (NM-7120.81), 2009
# [Systems and software engineering \---Content of systems and software lifecycle process information products (Documentation)|], ISO/IEC 15289:2006(E)\],available through the [NASA Technical Standards|] website
# [EI32-OI-001 Software Development Process description Document|], NASA Marshall Spaceflight Center, 2010.
# [Agency and Center PALs|]
# [NASA MSFC Standard Processes|], available through the Agency PAL website


h2. 6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

*Public Lessons Learned Entry: 2218 - Flight Software Engineering Lessons*

The engineering of flight software is a major consideration in establishing JPL project total cost and schedule because every mission requires a significant amount of new software to implement new spacecraft functionality. Constraints to the development and testing of software concurrent to engineering the rest of the flight system has led to flight software errors, including the loss of some missions. The findings of several JPL studies and flight mishap investigations suggest a number of recommendations for mitigating software engineering risk.

For additional information see the following: []