1. Purpose

NPR 7150.2, NASA Software Engineering Requirements, ⁰³⁹ is applicable to all NASA software development activities, including single and multi-Center projects, and contracted development efforts. This topic provides suggestions to the software lead for levying the Agency-level requirements contained in NPR 7150.2 to contracts. It also helps NASA's lead Centers determine the NPR requirements that are appropriate for each Center participating in multi-Center projects. This topic supplements the NPR by providing some brief examples for levying the requirements, or their intent, to software development activities.

1.1 Introduction

Many of NASA's original software development activities were project specific and were created with the particular project's needs in mind. New software development was required because software adaptation and reuse seldom occurred. Usually, software development occurred at a Center or at a contractor site. While multi-Center software development did occur, NASA had minimal available resources for assuring the effective management and implementation of compliance with the specified requirements. This situation changed dramatically with the development of NPD 2820.1, NASA Software Policy, and the first issuance of NPR 7150.2. The need for Center development processes to be consistent with NPR 7150.2 also increased as NASA began greater use of multi-Center teams.

NPR 7150.2 addresses these needs by imposing requirements on various software development activities and tasks used by NASA to acquire, develop, assure, and maintain software for its programs. NPR 7150.2 provides procedural requirements to the responsible NASA project managers and contracting officers for NASA contracts. The NPR applies to the Jet Propulsion Laboratory, contractors, grant recipients, or other parties to agreements only to the extent specified or referenced in the appropriate contracts, grants, or agreements.The NPR is made applicable to contractors through contract clauses, specifications, or statements of work in conformance with the NASA Federal Acquisition Regulation (FAR) Supplement. ²⁵⁹

This topic discusses examples for the application and flowdown of the requirements to contractors and/or other parties as described above. Other approaches for flowing down NPR 7150.2 can be employed, as long as compliance with the applicable requirements is shown. (See section 2.6, Software Contract Requirements, of NPR 7150.2 ⁰³⁹and SWE-027 for specific additional guidance on software acquisition.)

2. Requirements and Flowdown to Contracts

Contractors and subcontractors develop in-house policies and procedures to provide quality software products and to fulfill the requirements passed down to them contractually. Correct application of the NASA acquisition process typically results in the specification of the applicable technical standards and requirements documents in the contract statement of work for software development activities that are performed by a prime contractor. Contractor and subcontractor policies and procedures are typically designed to satisfy different customers in an effective and efficient manner. Because many contract organizations have software development capabilities that match or even exceed those of NASA, the resulting list of included requirements is often subject to negotiation and modification as a part of the software acquisition process. NPR 7150.2 provides software acquisition guidance (see Topic 7.03 - Acquisition Guidance and SWE-048), but it does not specify the exact manner for levying its requirements to the contract. (The further flowdown of requirements to subcontractors is managed by the prime contractor.)

The final agreed-to requirements may be levied on the contract in a number of different ways. The important point is that, whatever approach is chosen, the effectiveness of the final list of applied requirements is to be equivalent to or better than the intent of the NPR.

This can be assured when the software development team assesses the final set of requirements and the selected processes for equivalency and compliance with the intent of the NPR.

The following paragraphs illustrate some scenarios of levying the NPR requirements on a contracted software development effort. These are just some example methods; other methods may be utilized.

Scenario 1

The developing Center makes NPR 7150.2 requirements a direct part of the contract statement of work. NASA's intent is that the performing contract organization will use the requirements statements of the NPR according to the wording and assistance notes to develop its software. Deviations from NPR 7150.2 or the use of equivalent substitutions can be explicitly specified or referenced in the contract statement of work (see SWE-120).

The following paragraphs provide scenarios and examples of contract language that can be used and adjusted as needed for applying NPR 7150.2 requirements:

1. The contractor shall develop and maintain software and firmware in accordance with NPR 7150.2, NASA Software Engineering Requirements, ⁰³⁹ for the appropriate software classes, and NASA-STD-8739.8, Software Assurance Standard, ²⁷⁸ (chapters 6 and 7).
2. SWE-xxx and SWE-yyy of NPR 7150.2 are not applicable to this contract. (This release from specific NPR 7150.2 requirement can also be accomplished by the acquirer including a requirements compliance matrix in the statement of work that only lists the applicable software requirements to be fulfilled by the supplier. Note that several NPR 7150.2 requirements are uniquely applicable to NASA Headquarters or Centers and are not appropriate to flowdown to commercial suppliers, i.e., SWE-002, SWE-003, SWE-004, SWE-005, SWE-006, SWE-095, SWE-096, SWE-098, SWE-100, SWE-101, SWE-107, SWE-108, SWE-122, SWE-124, SWE-126, SWE-127, SWE-128, SWE-129. The acquirer may wish to perform some requirements in-house rather than contracting them out to the supplier, e.g., SWE-055, SWE-073.)
3. The contractor may substitute its in-house software development processes if the government accepts that they have been shown to be equivalent to or better than the intent of the requirements in NPR 7150.2.
4. For IT applications other than mission-specific flight and non-flight software, the contractor shall use commercial off-the-shelf and existing government off-the-shelf products where cost effective to NASA. All IT applications, other than mission-specific flight and non-flight software, shall comply with NASA requirements as outlined in NPR 7150.2 for the appropriate software classes, limited to Classes E, F, and G, and NPR 2830.1, NASA Enterprise Architecture (EA) Procedures. ⁰³⁵

Scenario 2

The developing Center flows down the requirements of NPR 7150.2 into its Center-level or project-level procedures and requirements documents, which, in turn, are applied to the contract statement of work. Center-level or project-level directives are developed by NASA Centers to document their local software policies, requirements, and procedures. These directives are responsive to the requirements that are hierarchically above them, while addressing the specific application areas and the Center's mission within the Agency. Prior assessments and independent reviews provide assurance that the Center or project processes and requirements documents are equivalent to or better than the intent of NPR 7150.2. The responsible Center then assures compliance with the requirements of the NPR by assuring compliance with the Center or project documents levied on the contractor. This approach, while taking more time for Center personnel to prepare, may be more efficient for the performing contractor, since the levied documents are tailored to the Center or project needs and to the project at hand.

The following paragraphs provide examples of contract language that can be used and adjusted as needed when Center-defined documents are used to capture and flowdown some or all of the NPR 7150.2 requirements:

1. The contractor shall use the following document for the development of all software document deliverables:
   • CXP-02009, Constellation Software Classification Matrix (use as guidance in interpreting flight software classification definitions in NPR 7150.2).
2. For IT applications, other than mission-specific software, the contractor shall:
   • Where cost effective to NASA, use commercial off-the-shelf  and existing government off-the-shelf products.
   • Ensure compatibility with existing NASA applications and systems.
   • Comply with NASA requirements for NPR 7150.2 for the appropriate software classes, limited to Classes E, F, and G.
3. The developing Center levies equivalent internal documents that have been shown to be compliant with the minimum acceptable requirements of NPR 7150.2, even though one-to-one traceability is not possible. These internal documents are formed by giving consideration for what makes sense and for what the project wants. This scenario and scenario 1 are similar but not identical. Whereas the previous scenario above flows NPR requirements through its Center procedures down to the contractor, this scenario uses a unique set of requirements statements that produce the same end effect but through the application of a set of different or unique procedural steps.
   • The following Figure 2.1 provides an example of how equivalent but unique Center processes and requirements may evolve for application to the contract statement of work. This example approach can be used and adjusted as needed for applying NPR 7120.5 ⁰⁸² requirements.

                         Figure 2.1 Example Approach for Flowdown of Center Processes and Requirements to Contract Statement of Work

3. Requirements Flowdown to Multi-Center Teams

The previous two scenarios for contracted efforts can also be adapted to supporting Center activities in a multi-Center approach. When dealing with support Centers in a multi-Center development activity, the lead Center usually develops the approach for establishing the governing standards and requirements documents to be used during the software development activity. Lead Centers and supporting Centers have the additional task of determining which Center's software development processes will be used during the project. Consider using the following steps:

          a. Describe and document the implementation approach for the project, including the acquisition strategy, e.g., all in-house, NASA Centers, and contractors.

          b. Describe and document how participating NASA Centers' implementation policies and practices will be utilized in the execution of the project. (Note: for tightly coupled projects, the project manager and the Center Chief Engineer(s) or designees participate in the establishment of the engineering best practices to be used.)

          c. Come to agreement on a common/shared compliance matrix against NPR 7150.2, which is to be maintained by the lead Center. This matrix typically notes which Center has primary responsibility for each applicable requirement and the extent (if any) of support provided by another Center(s). When a Center is assigned a subset of the overall software system, consider if a stand-alone compliance matrix is more effective.

          d. Document the agreements for the use of the policies and procedures.

          e. Document the approach for ensuring that interfaces do not increase risk to mission success. (Also, see SWE-086.)

When the lead Center develops a project, it needs to evaluate each SWE to see which ones are applicable to the project. In a multi-Center project, the lead Center needs to decide which SWE it will 'keep' for its own execution and which will be jointly or uniquely performed by supporting Centers. More likely than not, this division of assignments will be based on project needs, Center and or contractor expertise, and level of importance of the task. (The items that are assigned to the contracted statement of work remain the responsibility of the contracting Center to show compliance.)

4. Flowdown Considerations

4.1 Assessment of Compliance

There are two approaches for assuring the successful implementation of NPR 7150.2 on a contract. The first is government verification of the contractor activities through the use of the "insight" (surveillance mode requiring the monitoring of customer-identified metrics and contracted milestones) process (see SWE-039). In this approach, the government uses a series of meetings, inspections, and evaluations to ascertain that the contractor is satisfying the approved requirements and processes in the contracted statement of work. The second approach concerns the development of software when a tiered set of contractors (prime/subcontractor) develop the software. In this latter approach, the government and the prime may share responsibility for verifying the subcontractor's performance. The prime may use "oversight" (surveillance process that implies a more active supervision of a contractor's processes and decision making) and its own verification processes to assure that the subcontractor is meeting the flowdown of NPR requirements. The government, in turn, will use insight and possibly independent verification (see SWE-131) that the software is being developed using the required processes.

4.2 Safety Considerations

NPR 8715.3C, NASA General Safety Program Requirements, chapter 2, ²⁶⁷ discusses safety and risk management requirements for NASA contracts. Responsibilities of the project/program manager, Contracting Officer, and Safety and Mission Assurance personnel are described in various chapters.

          According to NPR 8715.3, the following items can be considered for inclusion in any contract:

• Safety requirements.
• Mission success requirements.
• Risk management requirements.
• Submission and evaluation of safety and risk management documentation from the contractor, such as corporate safety policies, project safety plans, and risk management plans.
• Reporting of mishaps, close calls, and lessons learned.
• Surveillance by NASA. Performance-based contracts still have a requirement for surveillance!
• Subcontracting: require that the safety requirements are passed on to subcontractors!

The contract also clearly states what analyses or special tests will be performed for safety and mission assurance, who will do them, and who will see the results. In a performance-based contract, usually the contractor performs all functions, including analyses. In other cases, some of the analyses may be handled from the NASA side. Regardless, the tests and analyses are to be spelled out and the responsible party identified. (See SWE-023 and SWE-133.)

4.3 Multi-Center Considerations

When executing their portions of a multi-Center project, supporting Centers receive governing requirements and processes from the lead Center through one of the example approaches described earlier. Since each Center has its own set of software development processes and procedures, it may occasionally run into a difference of opinion as to which Center's approach will be used. While discussions and negotiations can clear up the majority of issues, a few may remain that require additional help to resolve. Several of these 'helps' are discussed briefly below:

a. Technical Authority: The NASA governance model prescribes a management structure that employs checks and balances between key organizations to ensure that decisions have the benefit of different points of view and are not made in isolation. (See NPD 1000.0A, NASA Governance and Strategic Management Handbook ²⁶¹.) NASA has established the technical authority process (see SWE-122) as part of its system of checks and balances to provide independent oversight of programs and projects in support of safety and mission success.

Occasionally, a disagreement may arise regarding the implementation of Center designated requirements. In the event negotiations do not solve the disagreement, the technical authority process may be used to assure that the appropriate viewpoints are heard at the appropriate levels of management.

b. Deviations and Waivers: Whenever the requirements specified in a multi-Center software development project come under dispute, the deviation and waiver process may be used to arrive at an agreed-to amended set of requirements. (See SWE-120 and SWE-126.)

c. Reviews: Occasionally, the choice of chair person and method for conducting reviews will result in a disagreement between Center and contractor and/or lead Center and supporting Center procedural documents. The clear flowdown and agreement on requirements and process documents ahead of time can negate these types of issues. (See SWE-018).

4.4 CMMI Rating Considerations

When a project acquires either Class A or Class B software, at a minimum, personnel from an organization that has a non-expired Capability Maturity Model Integration Maturity Level (ML)3 or ML2 rating, respectively, in the Supplier Agreement Management (SAM) process area are required to support the acquiring organization during the acquisition planning process in the software area. This ensures that the project is supported by a smart buyer who is knowledgeable of best software practices associated with CMMI resident within the supplier's engineering capability. This SAM-only alternative allows a Center or prime contractor who might only procure small amounts of Class A and Class B software and who may not have a full CMMI ML2 or ML3 rating to acquire this type of software and to participate in a project that requires its use.

5. Allocation of SWEs to Performing Organizations

Appendix D of NPR 7150.2 indicates the office or organization that is responsible for each SWE's execution. It shows that 109 of the 132 SWEs are to be executed by projects. The content of these requirements needs to be evaluated by the project and assigned to the development team (lead Center, supporting Center, contractor) as indicated by the analysis. The results and rationale for the assignments can be documented as needed.

For instance, the project is responsible for developing software plans (SWE-013), developing a life cycle or model (SWE-019), and performing the classification of software (SWE-020). These are typically performed by the lead Center. Training (SWE-017), scheduling (SWE-016), and reviews (SWE-018) can be assigned to supporting Centers and contractors for the execution of their portions of the software plan.

Some SWEs are not the direct responsibility of projects but require inputs from projects or Center staff. For example, the Office of the Chief Engineer and the Chief of Safety and Mission Assurance are responsible for conducting software inventory activities for classes of software development under their respective areas of responsibility. Although not responsible for executing SWE-006, Centers do need to support the development of data for the software inventory.

6. Resources

SWEs and Topics Related to this Handbook Topic:

6.1 Tools