UNDER CONSTRUCTION
This activity describes the institutional responsibilities for maintaining and advancing organizational capability in software engineering practices to effectively meet the scientific and technological objectives of the Agency. Chapter 2 of NPR7150.2 defines the roles and responsibilities of key officials in software engineering management, the software development and management processes, and the software life cycle management processes. Specific software classification applicability, if any, for the requirements in Chapter 2 are contained in the requirement wording. The requirements in Chapter 2 are not part of the Requirements Mapping Matrix in Appendix C. Approval of any tailoring of requirements designated in Chapter 2 can be done by the appropriate organization per the defined roles and responsibilities. Some of these SWEs have applicability in other activities for projects and are noted in those activities as relevant. 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. 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. All NASA software development needs to follow some level of defined software processes. Project Managers determines: Software Assurance monitors and tracks processes. Resources available to the Project Manager include the Process Asset Libraries from the Centers where the Center level processes are recorded for reuse. a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by: (1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D. b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s). 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. a. Project/program name and Work Breakdown Structure (WBS) number. (1) The name of the software development organization. a. Software development tracking data. a. Planned and actual effort and cost. Sharing and reuse of software can reduce the overall cost of software. It is critical that software that is shared or reused be properly licensed and attributed to the originators of the software. a. A NASA civil servant to a NASA civil servant: (1) Verify the requesting NASA civil servant has requested and completed an Acknowledgment (as set forth in the note following paragraph 3.10.2e). b. A NASA civil servant to a NASA contractor: (1) Verify a NASA civil servant (e.g., a Contracting Officer (CO) or Contracting Officer Representative (COR)) has confirmed the NASA contractor requires such software for the performance of Government work under their NASA contract and that such performance of work will be a Government purpose. Center Intellectual Property Counsel should be consulted for any questions regarding what is or is not a Government purpose. c. A NASA civil servant to any NASA grantees, Cooperative Agreement Recipients or any other agreement partners or to any other entity under U.S. Government Agency Release, Open source Release, Public Release, U.S. Release, Foreign Release: (1) If the release is to any NASA grantees, Cooperative Agreement Recipients, or any other agreement (e.g., Space Act Agreement) partners or to any other entity under U.S. Government Agency Release, an Open source Release, a Public Release, a U.S. Release, or a Foreign Release, the software release is completed in accordance with the external release requirements of NPR 2210.1, Release of NASA Software – Revalidated w/change 1. a. Keep a list of all contributors to the software product. b. Ensure that the software product contains appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express or implied, and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors. 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. 
View this section on the website
See edit history of this section
Post feedback on this section
13.00 NASA Institutional Requirements
13.01. Activity Overview and History
Institutional Requirements are grouped into several sub-activities. History of Improvement Efforts
13.01.1 Related SWEs
13.01.2 Related Work Products
13.01.3 Related Topics
13.01.4 Related SPAN Links
13.02. Appraisals, Assessments, and Benchmarking
Frequency Of This Activity
13.02.1 Related SWEs
13.02.2 Related Work Products
13.02.2.1 Related Process Asset Templates
13.02.3 Related Topics
13.02.4 Related SPAN Links
13.03. Processes
Frequency Of This Activity
13.03.1 Related SWEs
(2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
(3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
(4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
(5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
(6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
(7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
(8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.13.03.2 Related Work Products
13.03.2.1 Related Process Asset Templates
13.03.3 Related Topics
13.03.4 Related SPAN Links
13.04. Measurement and Metrics
Frequency Of This Activity
13.04.1 Related SWEs
b. Software name(s) and WBS number(s).
c. Software size estimate (report in Kilo/Thousand Source Lines of Code (KSLOCs)).
d. The phase of development or operations.
e. Software Class or list of the software classes being used on the project.
f. Software safety-critical status.
g. For each Computer Software Configuration Item (CSCI)/Major System containing Class A, B, or C software, provide:
(2) Title or brief description of the CSCI/Major System.
(3) The estimated total KSLOCs, the CSCI/Major System, represents.
(4) The primary programming languages used.
(5) The life cycle methodology on the software project.
(6) Name of responsible software assurance organization(s).
b. Software functionality achieved data.
c. Software quality data.
d. Software development effort and cost data.
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.13.04.2 Related Work Products
13.04.2.1 Related Process Asset Templates
13.04.3 Related Topics
13.04.4 Related SPAN Links
13.05. Software Sharing and Reuse
13.05.1 Related SWEs
(2) Provide the software to the requesting NASA civil servant.
(2) Verify a NASA civil servant (e.g., a CO or COR) has confirmed an appropriate Government Furnished Software clause (e.g., 1852.227-88, “Government-furnished computer software and related technical data”) is in the subject contract (or, if not, that such clause is first added); or the contractor may also obtain access to the software in accordance with the external release requirements of NPR 2210.1, Release of NASA Software.
(3) Verify NASA contractor is not a foreign person (as defined by 22 CFR §120.16).
(4) Verify there is a requesting NASA Civil servant (e.g., a CO or COR), and the requesting NASA civil servant has executed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
(5) After items (1), (2), (3), and (4) are complete, provide the software to the requesting NASA civil servant. The requesting NASA civil servant is responsible for furnishing the software to the contractor pursuant to the subject contract’s terms.13.05.2 Related Work Products
13.05.2.1 Related Process Asset Templates
13.05.3 Related Topics
13.05.4 Related SPAN Links
13.06. Training
Frequency Of This Activity
13.06.1 Related SWEs
13.06.2 Related Work Products
13.06.2.1 Related Process Asset Templates
13.06.3 Related Topics
13.06.4 Related SPAN Links
