NASA Procedures and Guidelines
This Document is Obsolete and Is No Longer Used. Check the NODIS Library to access the current version: http://nodis3.gsfc.nasa.gov
NPR 7150.2A Eff. Date: November 19, 2009 Cancellation Date: August 20, 2020	NASA Software Engineering Requirements
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL |

Chapter 1: Introduction

1.1 Overview

1.1.1 This NPR imposes requirements on procedures, design considerations, activities, and tasks used to acquire, develop, assure, and maintain software created and acquired by or for NASA programs. This NPR is designed to be a minimum set of requirements to protect the Agency's investment in software engineering products and to fulfill its responsibility to the citizens of the United States of America.

1.1.2 The requirements in this NPR have been extracted from industry standards and proven NASA experience in software engineering. Centers and software developers will find that many of the requirements are satisfied through programs, procedures, and processes that are in place.

1.1.3 The Agency makes significant investments in software engineering to support the Agency's investment areas: Space Flight, Research and Technology, Information Technology, and Institutional Infrastructure. NASA ensures that programs, projects, systems, and subsystems that use software follow a standard set of requirements. One of the goals of this NPR is to bring the Agency's engineering community together to optimize resources and talents across Center boundaries. For engineers to effectively communicate and work seamlessly among Centers, a common framework of generic requirements is needed. This NPR fulfills this need for the Agency within the discipline of software engineering.

1.1.4 This NPR makes no recommendation for a specific software life-cycle model. Each has its strengths and weaknesses, and no one model is best for every situation. Projects can evaluate the potential life-cycle models and select one that best matches the project's requirements and supports the products that are being produced. Standards or organizational policy may dictate a particular life-cycle model.

1.1.5 The NASA Headquarters Office of the Chief Engineer is committed to instituting and updating these requirements to meet the Agency's current and future challenges in software engineering. Successful experiences will be codified in updated versions of this NPR after experience has been gained through its use within the NASA software community, the collection of lessons learned from projects, and the implementation records of Engineering Technical Authority.

1.2 Organizational Capabilities and Improvement

Software engineering is a core capability and a key enabling technology necessary for the support of NASA's Mission Directorates. Ensuring the quality, safety, and reliability of NASA software is of paramount importance in achieving mission success. This chapter describes the requirements to help NASA maintain and advance organizational capability in software engineering practices to effectively meet scientific and technological objectives of the Agency.

1.2.1 The NASA Headquarters Office of the Chief Engineer shall lead, maintain, and fund a NASA Software Engineering Initiative to advance software engineering practices. [SWE-002]

1.2.2 Each Center shall maintain, staff, and implement a plan to continually advance its in-house software engineering capability and monitor the software engineering capability of NASA's contractors, as per NASA's Software Engineering Initiative Improvement Plan. [SWE-003]

Note: The requirement for the content of each Center Software Engineering Improvement Plan is defined in Chapter 5. Each Center has a current Center Software Engineering Improvement Plan on file in the NASA Headquarters' Office of the Chief Engineer.

1.2.3 The NASA Headquarters' Chief Engineer shall periodically benchmark each Center's software engineering capability against its Center Software Engineering Improvement Plan. [SWE-004]

Note: Center Software Engineering Improvement Plans are documented per Center Software Engineering Improvement Plan requirements. Capability Maturity Model^® Integration (CMMI^®) for Development (CMMI-DEV) appraisals are the preferred benchmarks for objectively measuring progress toward software engineering process improvement at NASA Centers.

1.2.4 Each Center shall establish, document, execute, and maintain software processes. [SWE-005]

1.2.5 To support compliance with NASA policy and facilitate the application of resources to mitigate risk, the NASA Headquarters' Chief Engineer, in coordination with the Chief, Safety and Mission Assurance, shall maintain a reliable list of the Agency's programs and projects containing software. [SWE-006]

1.3 Hierarchy of NASA Software-Related Documents

This paragraph helps the reader understand the flow down of requirements with respect to software created and acquired by or for NASA. Figure 1-1 shows the software engineering perspective of the relationship between relevant documents. The shaded documents in the figure show documents that primarily address software engineering policy and requirements. The text that follows the figure provides a brief description of each type of document, listed according to its position in the figure.

FIGURE 1-1 Relationships of Governing Software Documents

1.3.1 Higher Agency-Level Requirements

NPD 1000.0, Strategic Management and Governance Handbook, is the highest ranking NASA directive. NPD 1000.0 sets forth the principles by which NASA will strategically manage the Agency, describes the means for doing so, and identifies the specific requirements that drive NASA's strategic planning process, leading to products such as the Strategic Plan and the Annual Performance and Accountability Report. NPD 1000.3 defines the basic roles and responsibilities necessary to conduct the mission and business of NASA. It is the official repository for defining NASA's organizational architecture. NPD 1000.5 provides the overall policy framework of NASA's disciplined, comprehensive strategic acquisition process with appropriate references to other key processes and directives. This acquisition process complies with NASA obligations as a Federal agency and is tailored to each of NASA's major areas of investment to ensure the efficient, effective use of the resources entrusted to the Agency. In the event of a conflict among the top-level directives, the information provided in the highest ranking directive takes precedence. In the event of conflict among the top-level directives and one or more lower-level NPDs and/or NPRs, the information provided in the top-level directive(s) takes precedence. These policies may include very high-level requirements relevant to software and information technology that are elaborated in lower-level policies and procedural requirements.

1.3.2 Agency-Level Software Policies and Requirements

NASA Policy Directive (NPD) 7120.4, NASA Engineering and Program/Project Management Policy, is an overarching document that establishes top-level policies for all software created and acquired by or for NASA. This policy covers software created, acquired, or maintained by or for NASA, including COTS, GOTS, and MOTS software, and open source, embedded, reused, and legacy/heritage software. NPR 7150.2, NASA Software Engineering Requirements, supports the implementation of the NPD 7120.4, NASA Engineering and Program/Project Management Policy. NPR 7150.2 establishes the NASA Software Classifications definitions and provides the minimal set of requirements established by the Agency for software acquisition, development, maintenance, retirement, operations, and management. NPR 7150.2 provides a set of software engineering requirements in generic terms to be applied throughout NASA and its contractor community. Additional Agency-level project management requirements (NPR 7120.5, NASA Space Flight Program and Project Management Requirements, NPR 7120.6, Lessons Learned Process, NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements, and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements), information technology requirements (NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements) and system engineering requirements (NPR 7123, NASA Systems Engineering Processes and Requirements) exist that influence and affect the software development activities on a project. In the event of a conflict between an NPD and an NPR, the information provided in the NPD takes precedence.

1.3.3 Agency-Level Multi-Center and Product Line Requirements (non-software specific)

These NPDs and NPRs elaborate, tailor, and in some cases add requirements to the ones above to address the needs of major multi-Center projects, specific product lines, and specific focus areas. Examples of representative NPRs in this category are NPR 8705.2, Human-Rating Requirements for Space Systems, NPR 8715.3, NASA General Safety Program Requirements, and NPR 8735.2, Management of Government Quality Assurance Functions for NASA Contracts.

1.3.4 NASA and Industry Software Standards and Guidebooks

NASA Preferred Industry Software Standards and Guidebooks and NASA Software-Related Standards and Guidebooks are required when invoked by an NPD, NPR, Center-Level Directive, contract clause, specification, or statement of work.

1.3.5 Center-Level Directives (related to software)

Center-Level Directives are developed by NASA Centers to document their local software policies, requirements, and procedures. These directives are responsive to the requirements above them while addressing the specific application areas and the Center's mission within the Agency. In the event of a conflict between an NPD or an NPR with a Center-Level Directive, the information provided in the NPD or NPR takes precedence.

1.3.6 Government In-house Development

Government in-house software development policies and procedures are developed to provide quality software products that fulfill the requirements passed down by the project. Government in-house software development policies and procedures are typically designed to meet the needs of the supported projects in an effective and efficient manner.

1.3.7 Contractor and Subcontractor Development

Contractors and subcontractors develop in-house policies and procedures to provide quality software products and to fulfill the requirements passed down through a contract by a customer. Contractor and subcontractor policies and procedures are typically designed to satisfy different customers in an effective and efficient manner.

DISTRIBUTION:
NODIS