bannerd


UNDER CONSTRUCTION

A.13 NASA Institutional Requirements

13.01. Activity Overview and History

Institutional Requirements are grouped into several sub-activities. 

Each of the sub-activities are performed by the Agency or Centers, not by the projects.

Projects benefit from the outputs from these sub-activities. 


History of Improvement Efforts

13.01.1 Related SWEs

  • SWE-002 - Software Engineering Initiative2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices. 
  • SWE-003 - Center Improvement Plans2.1.5.2 Center Director, or designee, shall maintain, staff, and implement a plan to continually advance the Center’s in-house software engineering capability and monitor the software engineering capability of NASA's contractors.
  • SWE-005 - Software Processes - 2.1.5.3 Center Director, or designee, shall establish, document, execute, and maintain software processes per the requirements in this directive.
  • SWE-095 - Report Engineering Discipline Status2.1.5.5 The Center Director, or designee, shall report on the status of the Center’s software engineering discipline, as applied to its projects, upon request by the OCE, OSMA, or OCHMO.  
  • SWE-208 - Advancing Software Assurance and Software Safety Practices - 2.1.2.2 The NASA Chief, SMA shall lead and maintain a NASA Software Assurance and Software Safety Initiative to advance software assurance and software safety practices.

13.01.2 Related Work Products

  • Software Engineering Handbook - SWEHB

13.01.3 Related Topics



Editors only

A.00.2 - History of Improvement Efforts

None of these SWEs and topics reference one another. 

Analysis of SWEs and SM
SWE or Topic

Related SWEs 

Related SM

7.01 - History and Overview of the Software Process Improvement (SPI) Effort

A.13.01 NASA Institutional Requirements and History

Analysis of SWEs and SM

A.13.01 History of Improvement Efforts

  • Need to consider of any  Topics or other Supplementary Materials are needed. 
  • No Work Products are mentioned in the SWEs
SWE or Topic

Related SWEs 

Related SM

Related Activity






7.01 - History and Overview of the Software Process Improvement (SPI) Effort


13.02. Appraisals, Assessments, and Benchmarking

NPR 71150.2 is largely based on the industry-wide best practices documented in the CMMI. The CMMI Appraisal is a tool for assessing how closely is following the best practices of the CMMI. 

Some projects are required to use the CMMI Appraisal process administered by an independent CMMI Lead Appraiser to show how closely they follow the CMMI. Other projects are appraised by OCE or OSMA to check on how closely they are following NPR 7150.2. The SWEs listed here describe the benchmarking, appraisal, QAAR audits, and other assessments tools.  

Frequency Of This Activity

13.02.1 Related SWEs

  • SWE-004 - OCE Benchmarking2.1.1.2 The NASA OCE shall periodically benchmark each Center's software engineering capability against requirements in this directive. 
  • SWE-032 - CMMI Levels for Class A and B Software - 3.9.2 The project manager shall acquire, develop, and maintain software from an organization with a non-expired CMMI-DEV rating as measured by a CMMI Institute Certified Lead Appraiser as follows:
      1. For Class A software: CMMI-DEV Maturity Level 3 Rating or higher for software.
      2. For Class B software (except Class B software on NASA Class D payloads, as defined in NPR 8705.4): CMMI-DEV Maturity Level 2 Rating or higher for software.
  • SWE-129 - OCE NPR Appraisals2.1.1.4 The NASA OCE shall authorize appraisals against selected requirements in this NPR to check compliance. 
  • SWE-221 - OSMA NPR Appraisals - 2.1.2.5 The NASA Chief, SMA shall authorize appraisals against selected requirements in this NPR to check compliance.
  • SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities - 2.1.2.3 The NASA Chief, SMA shall periodically benchmark each Center’s software assurance and software safety capabilities against the NASA-STD-8739.8, NASA Software Assurance and Software Safety Standard.

13.02.2 Related Work Products

13.02.2.1 Related Process Asset Templates

13.02.3 Related Topics


13.03. Processes

All NASA software development needs to follow some level of defined software processes. Project Managers determines:

  • what processes they are going to use in carrying out the work of the project,
  • customer needs,
  • system-level requirements,
  • make-versus-buy strategies,
  • overall project and software management plans,
  • a work breakdown structure (WBS),
  • software safety assessments, and
  • primary project deliverables and work products, including, but not limited to, software documents and electronic products.

Resources available to the Project Manager include the Process Asset Libraries from the Centers where the Center level processes are recorded for reuse. 

Frequency Of This Activity

13.03.1 Related SWEs

  • SWE-005 - Software Processes - 2.1.5.3 Center Director, or designee, shall establish, document, execute, and maintain software processes per the requirements in this directive.
  • SWE-036 - Software Process Determination - 3.1.6 The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables.
  • SWE-098 - Agency Process Asset Library2.1.1.6 The NASA OCE shall maintain an Agency-wide process asset library of applicable best practices and process templates for all size projects.  
  • SWE-144 - Software Engineering Process Assets2.1.5.11 Each Center Director, or designee, shall contribute applicable software engineering process assets in use at his/her Centers to the Agency-wide process asset library. 

13.03.2 Related Work Products

  • D. Topics - See section "5.xx Document Contents"

13.03.2.1 Related Process Asset Templates

13.03.3 Related Topics

  • 7.08 - Maturity of Life Cycle Products at Milestone ReviewsThis chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
  • 7.09 - Entrance and Exit CriteriaThis guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.


13.04. Measurement and Metrics

Software measurement programs are established to meet measurement objectives and goals at multiple levels. The data gained from these measurement programs are used in the management of projects, to assuring safety and quality, and in improving overall software engineering practices. Software measurement repositories help manage this data and provide the insight needed on projects.  Measurement repositories should be established for collecting, storing, analyzing, and reporting measurement data based on the requirements of the projects and Center. The repository enables the Center to assess its current software status and the engineering capabilities of providers for future work. Once these software measurement systems are established, the software measures and analysis results that emanate from them enable Center-wide assessments of the abilities and skills in the workforce, and opportunities for improving software development.

What gets measured, gets managed. Software measurement programs are established to meet objectives at multiple levels and structured to satisfy particular organization, project, program, and Mission Directorate needs. The data gained from these measurement programs assist in managing projects, assuring quality, and improving overall software engineering practices.  

 Establishing, maintaining, and using a cost repository enables projects and programs to develop credible software cost estimates. 

NASA software measurement programs are designed to provide specific information necessary to manage software products, projects, and services.  For these programs to be current and accurate, certain center measurements (such as size and effort estimates, milestones, and characteristics) are provided to the Center repository at the end of the major project milestones. Defined software measurements are used to make effective management decisions by Center Management. Historical measurement data can also be used to improve aspects of future projects such as cost estimation.

Frequency Of This Activity

13.04.1 Related SWEs

  • SWE-091 - Establish and Maintain Measurement Repository - 2.1.5.7 For Class A, B, and C software projects, the Center Director, or designee, shall establish and maintain a software measurement repository for software project measurements containing at a minimum: 

    a. Software development tracking data.
    b. Software functionality achieved data.
    c. Software quality data.
    d. Software development effort and cost data.

  • SWE-092 - Using Measurement Data2.1.5.8 For Class A, B, and C software projects, the Center Director, or designee, shall utilize software measurement data for monitoring software engineering capability, improving software quality, and to track the status of software engineering improvement activities. 
  • SWE-142 - Software Cost Repositories2.1.5.10 For Class A, B, and C software projects, each Center Director, or designee, shall establish and maintain software cost repository(ies) that contains at least the following measures: 

    a. Planned and actual effort and cost.
    b. Planned and actual schedule dates for major milestones.
    c. Both planned and actual values for key cost parameters that typically include software size, requirements count, defects counts for maintenance or sustaining engineering projects, and cost model inputs.
    d. Project descriptors or metadata that typically includes software class, software domain/type, and requirements volatility.

  • SWE-174 - Software Planning Parameters - 3.2.3 The project manager shall submit software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of major milestones.
  • SWE-095 - Report Engineering Discipline Status2.1.5.5 The Center Director, or designee, shall report on the status of the Center’s software engineering discipline, as applied to its projects, upon request by the OCE, OSMA, or OCHMO.  

13.04.2 Related Work Products

13.04.2.1 Related Process Asset Templates

13.04.3 Related Topics

  • 7.08 - Maturity of Life Cycle Products at Milestone ReviewsThis chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
  • 8.18 - SA Suggested Metrics - This topic contains the complete list of software assurance/safety metrics that are suggested for use with the SA tasks in NASA-STD-8739.8.

13.05. Training

NASA software development activities in support of projects often require a balanced blend of software engineering development expertise and knowledge. If the software is contracted out, the development activities also require knowledge of NASA's acquisition practices and regulations. The Office of the Chief Engineer(OCE) and the Centers have committed to support these objectives by providing sufficient funding in support of the training.  In some instances, funding for training may be provided by multiple organizations if the training is beneficial to the communities they represent.

NASA software assurance and software safety activities in support of projects often require a balanced blend of software engineering development expertise, software assurance expertise, software safety expertise, and knowledge. If the software is contracted out, the development activities also require knowledge of NASA's acquisition practices and regulations. The Office of Safety and Mission Assurance and the Centers have committed to support these objectives by providing sufficient funding in support of the training.  In some instances, funding for training may be provided by multiple organizations if the training is beneficial to the communities they represent.

Frequency Of This Activity

13.05.1 Related SWEs

13.05.2 Related Work Products

13.05.2.1 Related Process Asset Templates

13.05.3 Related Topics

  • No labels