bannerc
SWE-005 - Software Processes

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

Click here to view the history of this requirement: SWE-005 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.

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

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?

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

  • The Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook, 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 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, 041 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." 372
  • 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." 224

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


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


Unable to render {include} The included page could not be found.

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 572: The NASA Software Engineering Improvement Initiative (NSEII) (see SWE-002 and Topic 7.1) 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.

6.2 Other Lessons Learned

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


  • No labels