1. Requirements

1.2.4 Each Center shall establish, document, execute, and maintain software processes.

1.1 Notes

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

1.2 Applicability Across Classes

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

2. Rationale

Software engineering is a core capability and a key enabling technology necessary for the support of NASA's missions. Ensuring the quality, safety, and reliability of NASA software is of paramount importance in achieving mission success. Additionally, the exponential growth in the scope, complexity, and importance of software within NASA systems experienced over the years is expected to continue, challenging our ability to manage it effectively. The Software processes define a set of technical and management frameworks for applying methods, tools, and people to the task of developing software products. Software processes:

• Ensure that NASA has the best available software engineering practices and techniques applied to its projects.
• Enable seamless multi-Center software development for NASA projects.
• Ensure quick and effective mobility of assignments for software engineering personnel.
• Establish a common understanding of the software engineering discipline.
• Maintain and improve NASA's software engineering capability, tools, principles/rules, and Capability Maturity Model Integration (CMMI) rating with reduced Center and project effort and cost.
• Reduce the risk in critical software development activities by use of a common set of software principles/rules.
• Enable a more affordable approach for NASA software development.

3. Guidance

All NASA software development needs to follow some level of defined software processes. The processes used in a software development activity can be derived from a set of common processes defined at the Agency level, Center level or organizational level. Class E software that is not safety critical and Class H software, labeled with "P (Center)," can be developed with a simplified software development process per a Center's direction (See SWE-140). A Center's software processes can be defined at the appropriate level that is needed by the software engineers on the project and per the direction of the Center requirements. Engineering management and or the project lead software engineer has the responsibility to develop, train, maintain, and execute all software process development steps and to ensure that all software being developed follows the organization's defined software development processes.

Many, if not all, Centers started a Software Engineering Process Group (SEPG) and chartered and tasked it with the development of their organization's software processes. These products are typically documented and maintained current in a suitable repository. Centers typically use a software process asset library (PAL) as a repository for the storage and maintenance of their software development processes. PALs typically align with overall Center business management systems and process and procedure libraries.

The number and type of standard processes to be developed or implemented are left to the Center to determine, but, if developed properly, they are sufficient to progress through the phases of the software development life cycle, while satisfying the entrance and exit criteria (see Topic 7.09 - Entrance and Exit Criteria ) for reviews and life cycle phase transitions (see SWE-019 ). These standard processes interpret and reflect the application of the requirements in NPR 7150.2. They include activities that incorporate best practices for developing quality software and software systems.

For organizations developing Class A, B, and C software (Class C software as defined by the Center requirements), the Center processes benefit by aligning with the processes contained in the Software Engineering Institute's (SEI) CMMI method. The degree to which they follow the CMMI method can be assessed in a Standard CMMI Appraisal Method for Process Improvement (SCAMPI ) activity (see the CMMI ¹⁵⁷). To the extent appropriate and useful, Class D and Class E software development will also benefit by the use of these CMMI-aligned Center processes.

This requirement does not mandate a single process for a given set of activities at a Center. When several software development organizations exist at a Center, they may establish and maintain processes that vary across the organizations. The important point for these organizations is that the processes they use must be developed, documented, and followed consistently throughout the software development activity. How this is done is up to the specific organization or the Center. Centers that utilize different processes in different organizations must assure that all the process versions satisfy and are consistent with the requirements in NPR 7150.2.

SEPGs may find it helpful to consult the following sources when developing new processes, or maintaining and improving existing processes:

• The Agency PAL ²⁶⁶ and the Center PALs 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. ¹⁵⁷ The CMMI-Dev describes the applicability of its processes 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.

• 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." ³⁷²

• The IEEE STD 12207, which "establishes a common framework for software life cycle processes, with well defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance, and disposal of software products." ²²⁴

Additional guidance related to software process establishment may be found in the following related requirements in this Handbook:

4. Small Projects

Smaller projects with limited resources may reuse processes previously developed and placed in Center PALs. Existing processes may be tailored to meet critical project aspects. Documentation and maintenance of process documents may be assigned to the SEPG or large projects for major support.

5. Resources

5.1 Tools

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

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

Flight Software Engineering Lessons. Lesson Number 2218: The NASA Software Engineering Improvement Initiative (NSEII) (see SWE-002 and 7.01 - History and Overview of the Software Process Improvement (SPI) Effort) includes software process improvement activities. The NASA Jet Propulsion Lab (JPL) reviewed many of its software development projects and identified a number of steps to mitigate the risk from defects in its flight software development (FSW) process. ⁵⁷²
JPL addressed some of these in its software development process procedures:

1. Adopt a risk-based approach to software engineering.
2. Involve software engineers in the early system-level project decisions that determine flight system characteristics.
3. Provide projects with the requisite software development infrastructure prior to project commencement.
4. Develop simulations of instruments and other custom hardware that interfaces with FSW at the earliest point at which their behavior is understood.
5. Before coding begins, prepare an FSW architecture specification for use in developing the conceptual architecture, realizing the architecture as a high-level integrated flight system design, and managing subsequent changes.
6. Define a suite of flight system architectures that are each capable of supporting a commonly flown category of (Center) mission.
7. Development of a complete and consistent set of engineering requirements requires a robust systems engineering process that defines performance and resource utilization requirements, traces requirements to higher- and lower-level requirements, ensures review of requirements by key stakeholders and by parties independent of the engineering of the requirements, and assesses the requirements using a checklist of questions that address quality concerns.
8. Use objective measures to monitor FSW development progress and to determine the adequacy of software verification activities.
9. Manage FSW development using an integrated system.