2. Rationale

The CMMI® requirement is a qualifying requirement for NASA.  The requirement is included to ensure that NASA projects are supported by software development organization(s) having the necessary skills and processes in place to produce reliable products within cost and schedule estimates. 

3. Guidance

The Capability Maturity Model (CMM®) and the CMMI®-DEV is an internationally used framework for process improvement in development organizations. It is an organized collection of best practices and proven processes areas. Practices cover topics that include eliciting and managing requirements, decision making, measuring performance, planning work, handling risks, and more. Using these practices, NASA can improve NASA software projects’ chances of mission success.

This requirement provides NASA with a methodology to:

• Measure software development organizations against an industry-wide set of best practices that address software development and maintenance activities applied to products and services.
• Measure and compare the maturity of an organization’s product development and acquisition processes with industry state of the practice.
• Measure and ensure compliance with the intent of the NPR 7150.2 process related requirements using an industry standard approach. 
• Assess internal and external software development organizations processes.
• Identify potential risk areas within a given organization’s software development processes.

Benefits of using CMMI® include:

• Reducing risk of software failure - Increasing mission safety.
• Improving the accuracy of schedule and cost estimates by requiring the use of historical data and repeatable methods.
• Helping NASA become a smarter buyer of contracted out software.
• Increasing quality by finding and removing more defects earlier.
• Improving the potential for reuse of tools and products across multiple projects.
• Increasing ability to meet the challenges of evolving software technology.
• Improving software development planning across the Agency.
• Improving NASA contractor community with respect to software engineering. 
• Lowering the software development cost.
• Improving employee morale.
• Improving customer satisfaction.
• Improving NASA and contractor community knowledge and skills.
• Providing NASA a solid foundation and structure for developing software in a disciplined manner.

CMMI® ratings can cover a team, a work group, a project, a division, or an entire organization. When evaluating software suppliers, it’s important to make sure that the specific organization doing the software work on the project has the cited rating (as some parts of a company may be rated while others are not).

Many of the requirements in NPR 7150.2 are consistent with the established process areas in the CMMI®-DEV framework. The CMMI®-DEV rating as well as consistent NPR 7150.2 requirements are both needed to ensure that organizations have demonstrated the capability to perform key software engineering processes and have a binding agreement to continue to execute key software engineering processes during the development of NASA’s most critical software systems. 

This requirement applies to software in Classes A and B.  It is recommended that projects check the status of the software development or maintenance organization's CMMI® rating at each major project life cycle review to ensure continued compliance and to identify potential risk areas in the software processes. A "check" can easily be done via the CMMI® Institute's Published Appraisals website ³²⁷.

General Software Acquisition Guidance:

The content of the supplier agreement is critical to the acquisition of any software, including software embedded in a delivered system. In addition to the CMMI® Maturity Level requirements placed on the supplier by SWE-032, the supplier agreement must also specify compliance with the software contract requirements identified in NPR 7150.2. The creation and negotiation of any supplier agreement involving software needs to include representatives from the Center's software engineering and software assurance organizations to ensure that the software requirements are represented in the acquisition agreement(s). The agreements clearly identify the following aspects of the acquisition:

• Technical requirements on the software.
• Definition and documentation of all software deliverables.
• Required access to intermediate and final software work products throughout the development life cycle.
• Compliance and permissible exceptions to NPR 7150.2 and any applicable Center software engineering requirements.
• Software development status reporting including: implementation progress, technical issues, and risks.
• Definition of acceptance criteria for software and software work products.
• Non-technical software requirements including: licensing, ownership, use of third party or Open Source Software, and maintenance agreements.

Representatives from the Center's software engineering and assurance organizations must evaluate all software-related contract deliverables prior to acceptance by the Project. The deliverables must be evaluated for:

• Compliance with acceptance criteria.
• Completeness.
• Accuracy.

Class A software – if you acquire, develop or maintain Class A software the organization performing the functions is required to have a non-expired CMMI®-DEV Level 3 or higher rating. 

Class A software acquisition guidance –

To ensure that the solicitation, contract, and delivered products meet the requirements of this NPR, the Project's acquisition team must be supported by representatives from a software engineering and software assurance organization that is either rated at CMMI®-DEV Maturity Level 3 or higher or rated at CMMI®-DEV Capability Level 3 in at least the process areas of Supplier Agreement Management and Process and Product Quality Assurance. This support may be in the form of direct involvement in the development of supplier agreements or review and approval of these agreements. The support must also include review and approval of any software-related contract deliverables. The extent of the CMMI®-DEV Level 3 rated organization's support required for a Class A acquisition can be determined by the Center's Engineering Technical Authority responsible for the project.

Identification of the appropriate personnel from an organization that has been rated at a CMMI®-DEV Level 3 or higher to support the Project acquisition team is the responsibility of the designated Center Engineering Technical Authority and Center Management. The Center Engineering Technical Authority has the responsibilities for ensuring that the appropriate and required NASA Software Engineering requirements are included in an acquisition.

For those cases in which a Center or project desires a general exclusion from the NASA Software Engineering requirement(s) in this NPR or desires to generically apply specific alternate requirements that do not meet or exceed the requirements of this NPR, the requester can submit a waiver for those exclusions or alternate requirements in the form of a streamlined compliance matrix for approval by the designated Technical Authorities with appropriate justification (see SWE-145).

Class A software development or maintenance guidance - The software organizations that directly develop or maintain Class A software are required to have a valid CMMI®-DEV Level 3 or higher rating for the organization performing the activities.  Support contracts supporting NASA in-house software development organizations can be included in the NASA organizational assessments.  Project contractors and subcontractors performing Class A software development are required to have their own CMMI®-DEV Level 3 rating.  It is important for NASA and primes to pass this requirement down in contracts to ensure all subcontractors have the necessary CMMI®-DEV rating.

The CMMI®-DEV Level 3 rating is to be maintained throughout the project’s development or maintenance period.  NASA requests organizations’ CMMI® ratings be posted on the CMMI Institute website ³²⁷. The CMMI® Institute vets the validity of the CMMI® appraisals on this list and assures the rating hasn’t expired (as of this writing CMMI® ratings are valid for a 3 year period). In rare instances (rating earned in a classified environment) an organization may have a current CMMI®-DEV rating, but it doesn’t appear on the CMMI® Institute website. In these cases the supplier’s claim can be directly checked with the CMMI® Institute.

Class B software (except Class B software on NASA Class D payloads) - CMMI®-DEV Maturity Level 2 Rating or higher for software, or CMMI®-DEV Capability Level 2 Rating or higher for software in the following process areas:

a. Requirements Management.
b. Configuration Management.
c. Process and Product Quality Assurance.
d. Measurement and Analysis.
e. Project Planning.
f. Project Monitoring and Control.
g. Supplier Agreement Management (if applicable).

Class B software acquisition guidance -

To ensure that the solicitation, contract, and delivered products meet the requirements of this NPR, the Project's acquisition team must be supported by representatives from a software engineering and software assurance organization that is either rated at CMMI®-DEV Maturity Level 2 or higher or rated at CMMI®-DEV Capability Level 2 in at least the process areas of Supplier Agreement Management and Process and Product Quality Assurance. This support may be in the form of direct involvement in the development of supplier agreements or review and approval of these agreements. The support must also include review and approval of any software-related contract deliverables.

The Center Engineering Technical Authority responsible for the project determines the extent of the CMMI®-DEV Level 2 rated organization's support required (see description in previous paragraph) for a Class B acquisition. Identification of the appropriate personnel from an organization that has been rated at a CMMI®-DEV Level 2 or higher to support the Project acquisition team is the responsibility of the designated Center Engineering Technical Authority and Center Management. The Center Engineering Technical Authority has the responsibilities for ensuring that the appropriate and required NASA Software Engineering requirements are included in an acquisition.

For those cases in which a Center or project desires a general exclusion from the NASA Software Engineering requirement(s) in this NPR or desires to generically apply specific alternate requirements that do not meet or exceed the requirements of this NPR, the requester can submit a waiver in the form of a streamlined compliance matrix for those exclusions or alternate requirements for approval by the designated Technical Authorities with appropriate justification (see SWE-145).

Class B software development or maintenance guidance - The software organizations that directly develop or maintain Class B software are required to have a valid CMMI®-DEV Level 2 or higher rating (via a Continuous or Staged representation) for the organization performing the activities.  Support contracts supporting NASA in-house software development organizations can be included in the NASA organizational assessments.  Project contractors and subcontractor performing Class B software development are required to have their own CMMI®-DEV Level 2 or higher rating.  The CMMI®-DEV Level 2 maintains an active rating during the development or maintenance period.  The rating is to be posted on the CMMI® Institute website ³²⁷.

Guidance on the exception for Class B software development and maintenance - If this option is used, the project is responsible for funding the evaluation and for addressing any all risks that are identified during the evaluation.  A Standard CMMI Appraisal Method for Process Improvement (SCAMPI^SM) B or SCAMPI^SM C appraisal across the listed process areas in this requirement is one method for conducting this evaluation. The Center Engineering Technical Authority is responsible for maintaining all records associated with the evaluation for the life of the project.  The decision on participators in the evaluation process is determined by the responsible Center Engineering Technical Authority on the project.  Recommended guidance is that the “qualified evaluator” should have demonstrated experience on a SCAMPI^SM A appraisal or training, such as CMMI® Practitioner Level 2 training. Completion of an introduction to CMMI® training course should not be the only criteria used in the selection.

Guidance on Class B software on NASA Class D payloads (as defined in NPR 8705.4) and Class C software - While not required, it is highly recommended that providers have a Certified CMMI® Lead Appraiser conduct periodic informal evaluations (e.g., SCAMPI^SM B or SCAMPI^SM C appraisals) against process areas chosen by the project and project engineering based on the risk associated with the project.  The project determines if an assessment is needed, identifies the required areas for the assessment, and communicates this information to the provider. A sample assessment process, “Process for Evaluation in Lieu of CMMI® Appraisal,” can be found in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.  

4. Small Projects

National Defense Industrial Association (NDIA) CMMI® Working Group conducted a study on the use of CMMI®-DEV within Small Businesses in 2010 ¹⁵⁸. One of the counter-intuitive findings was that the "Perceptions that CMMI® is too burdensome for small businesses is not supported by data on CMMI®-DEV adoption". Significant numbers of organizations in the 1-20 employees range adopted and achieved CMMI® Level ratings.

Small projects are expected to take advantage of Agency, Center, and/or organizational assets. 

5. Resources

6. Lessons Learned

 A documented lesson from the NASA Lessons Learned database notes the following:

Acquisition Philosophy and Mechanism. Lesson Number 1414: "Since the procurement's goal is to minimize the time from start to finish, part of its philosophy is to instill efficiency into the Contractor-Government roles and relationships. Thus, it becomes paramount during the selection process to ensure that the Contractor's processes, procedures, and tools are adequate (as based on some established criteria such as ISO 9001 and/or CMMI) to allow the Government to take a 'hands-off' approach during implementation. Also, any criteria to be used to verify/validate and or assess the Contractor's work after contract award must be consistent and compatible with the performance criteria levied on the Contractor." ⁵⁵³
Additional CMM/CMMI Lessons Learned by NASA associated with implementing and maintaining this requirement are:

• Preparing for an appraisal helps you get the measurable process improvement.
• CMMI process helped Centers establish a baseline of where they are.
• Organizations develop an extensive set of "tools" (i.e., templates, spreadsheets) to help projects with CMMI practices and artifacts.
• Use of toolset helped projects reach compliance much faster.
• Use of organizations tools help support small project development efforts.
• Software Engineers that have participated in the CMMI process can be mentors that can help implement project tools and help projects utilize and tailor the software development processes.
• The CMMI process helps establish sponsorship across departments and with the Engineering management.
• Establish a relationship early with the CMMI Lead Appraiser.
• PIID development depends on a good artifact collection process and data management approach.
• The CMMI workshops can be used to review the processes in depth and reinforce the tool sets.
• The CMMI process help establish a method of tracking progress on software development activities.
• The CMMI process improves the project management and software configuration management areas.
• CMMI assessments help identify areas for process and project improvement.
• Projects appreciate systematic and analytical feedback on what they are doing.
• Measurement and analysis is a big challenge in the CMMI process.
• Improved quality and review of management plan early in the life cycle and reuse of the plans for new projects.
• Resource planning and tracking at the individual process level provided little additional benefit to the projects.
• Smaller projects need to have light-weight processes to avoid being smothered (especially for a one person task).

As part of its annual review, the Aerospace Advisory Panel included this finding in the Computer Hardware/Software section of its Annual Report for 2000: "NASA has initiated plans to have its critical systems processes evaluated according to the Capability Maturity Model (CMM) of the Software Engineering Institute and to work toward increasing the CMM level of its critical systems processes." ⁴²²