1. Requirements

2.1.5.3 Center Director, or designee, shall establish, document, execute, and maintain software processes per the requirements in this directive.

1.1 Notes

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

1.2 History

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.

See also SWE-002 - Software Engineering Initiative for the requirement on the Software Engineering Initiative. 

See also Topic 7.01 - History and Overview of the Software Process Improvement (SPI) Effort for additional details on the SPI Initiative. 

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. 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's requirements. Engineering management and or the project lead software engineer have 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.

3.1 Software Engineering Process Group (SEPG) and Process Asset Library (PAL)

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.

3.2 Standard Processes

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. 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 CMMI Institute's CMMI method. The degree to which they follow the CMMI method can be assessed in an external appraisal activity (see the CMMI). To the extent appropriate and useful, Class D and Class E software development will also benefit from the use of these CMMI-aligned Center processes. See also SWE-032 - CMMI Levels for Class A and B Software. 

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.

The challenge for organizations is to examine every area of their organization and identify the processes that are in place. Ask:

• Does the right process or procedure exist?
• Is the process effective? How do you know?
• Do staff members know the outcome of the procedure?
• Does everyone know the “why” of the process?
• How and when is the process evaluated?
• Does everyone know how they fit into the process and what to do?
• Are the staff members held accountable for the process?
• What is the process to fix an ineffective process?

See also SWE-036 - Software Process Determination, SWE-013 - Software Plans.

See also SWE-003 - Center Improvement Plans for the NPR 7150.2 requirement on Center Improvement Plans. 

3.3 Resources for Developing and Maintaining Processes

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

• The processes and best practices are described in the Capability Maturity Model Integration for Development (CMMI-Dev). The CMMI^®-Dev describes the applicability of its processes for developing software work products.

• NPR 7123.1, ⁰⁴¹ which establishes a core set of common Agency-level technical processes and requirements needed to define, develop, realize, and integrate the quality of the system's 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, "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." ²²⁴

3.4 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.5 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

Small projects do need to establish, document, execute, and maintain software processes per the requirements in this directive. Smaller projects may reuse processes previously developed or use processes developed by the organization or Center. Existing processes may be tailored to meet the project risks level.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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 - Software Engineering Initiative 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. 1. 1. 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 interface 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.

6.2 Other Lessons Learned

• No other Lessons Learned have currently been identified for this requirement.