This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
1. Requirements22.214.171.124 Center Directors, or designees, shall establish, document, execute, and maintain software processes.
1.1 NotesNPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
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.
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 - 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 ( SCAMPISM) activity (see the CMMI® 157). 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.
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 staff members held accountable to 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 SEI‘s Capability Maturity Model Integration for Development (CMMI-Dev), Version 1.3. 157 The CMMI®-Dev describes the applicability of its processes for developing software work products.
- NPR 7123.1, 041which 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." 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
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.
- CMMI Development Team (2010). "CMMI for Development, Version 1.3: Improving processes for developing better products and services,"CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.
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 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. 572
JPL addressed some of these in its software development process procedures:
- Adopt a risk-based approach to software engineering.
- Involve software engineers in the early system-level project decisions that determine flight system characteristics.
- Provide projects with the requisite software development infrastructure prior to project commencement.
- Develop simulations of instruments and other custom hardware that interfaces with FSW at the earliest point at which their behavior is understood.
- 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.
- Define a suite of flight system architectures that are each capable of supporting a commonly flown category of (Center) mission.
- 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.
- Use objective measures to monitor FSW development progress and to determine the adequacy of software verification activities.
- Manage FSW development using an integrated system.