![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL | | |||||
2.1.1 The NASA Office of the Chief Engineer (OCE)
2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices. [SWE-002]
2.1.1.2 The NASA OCE shall periodically benchmark each Center's software engineering capability against requirements in this directive. [SWE-004]
Note: 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.
2.1.1.3 The NASA OCE shall periodically review the project requirements mapping matrices. [SWE-152]
2.1.1.4 The NASA OCE shall authorize appraisals against selected requirements in this NPR to check compliance. [SWE-129]
2.1.1.5 The NASA OCE and Center training organizations shall provide training to advance software engineering practices. [SWE-100]
2.1.1.6 The NASA OCE shall maintain an Agency-wide process asset library of applicable best practices. [SWE-098]
2.1.2 Chief, Safety and Mission Assurance (SMA)
2.1.2.1 The Chief, SMA manages Agency software assurance policy and oversees its implementation, and is the Technical Authority for any requirements which may impact safety.
2.1.2.2 The NASA Chief, SMA will lead and maintain a NASA Software Assurance Initiative to advance software assurance practices.
2.1.2.3 The NASA Chief, SMA will periodically benchmark each Center's software assurance capabilities against the NASA Software Assurance Standard.
2.1.2.4 The NASA Chief, SMA will periodically review the project’s requirements mapping matrices.
2.1.2.5 The NASA Chief, SMA will authorize appraisals against selected requirements in this NPR to check compliance.
2.1.2.6 The NASA Chief, SMA will provide for software assurance training.
2.1.2.7 The NASA Chief, SMA will make the final decision on all proposed tailoring of SWE-141, the Independent Verification and Validation (IV&V) requirement.
2.1.2.8 The NASA Chief, SMA provides policy direction, functional oversight, and assessment for all Agency safety, reliability, maintainability, and quality engineering and assurance activities.
2.1.3 Chief, Office of Chief Information Officer (OCIO)
2.1.3.1 The NASA OCIO Senior Agency Information Security Officer (SAISO) (or designee) will conduct security assessments and appraisals on selected requirements in this NPR to check compliance.
2.1.3.2 The NASA OCIO SAISO (or designee) will participate in any software development reviews, as needed.
2.1.4 Chief Health and Medical Officer (CHMO)
2.1.4.1 The CHMO is the Technical Authority for any requirements which impacts health and medical.
2.1.4.2 The CHMO has approval authority of tailoring of software with health and medical implications. This approval may be delegated to the CHMO designated Center HMTA.
2.1.5 Center Director
2.1.5.1 In this directive, the phrase "the Center Directors shall..." means that the roles and responsibilities of the Center Directors may be further delegated within the organization consistent with the scope and scale of the system.
2.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-003]
Note: The recommended practices and guidelines for the content of a Center Software Engineering Improvement Plan are defined in NASA-HDBK-2203. Each Center has a current Center Software Engineering Improvement Plan on file in the NASA Chief Engineer’s office.
2.1.5.3 Center Director, or designee, shall establish, document, execute, and maintain software processes per the requirements in this directive. [SWE-005]
2.1.5.4 Center Director, or designee, shall comply with the requirements in this directive that are marked with an ”X” in Appendix C. [SWE-140]
Note: The responsibilities for approving changes in the requirements for a project is listed for each requirement in the requirement mapping matrix. When the requirement and software class are marked with an “X,” the projects will record the risk and rationale for any requirement that is not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix. Project relief from the applicable cybersecurity requirements, section 3.11, Software Cybersecurity, has to include an agreement from the Center CIO or designee. The NASA Agency CIO, or Center CIO designee, has institutional authority on all Class F software projects.
2.1.5.5 The designated Center Engineering Technical Authority(s) or Institutional Authority(s) for requirements in this NPR shall be NASA civil servants (or JPL/Contractor employees). [SWE-122]
Note: Refer to Appendix C (column titled “Authority”) for requirements and their associated Technical or Institutional Authority. NASA Headquarters will designate the technical authority for SWE-032 and SWE-141.
2.1.5.6 Serving as technical and institutional authorities for requirements in this directive, Center Director, or designee, shall: [SWE-126]
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.
(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 Center CIO and CISO (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.
Note: To effectively assess projects’ requirements mapping matrices, the designated Center Engineering Technical and Institutional Authorities for this NPR are recognized NASA software engineering experts or utilize recognized NASA software engineering experts in their decision processes. NASA-HDBK-2203 contains valuable information on each requirement, links to relevant NASA Lessons Learned, and guidance on tailoring. Center organizations or branches may also share frequently used tailoring and related common processes.
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).
Note: The Requirements Mapping Matrix documents the requirements that the project plans to meet, “not applicable” requirements, and any tailoring approved by designated Authorities with associated justification. If a project wants to tailor a requirement marked as Headquarters Technical Authority, then the project is required to get NASA Headquarters approval (e.g., OCE, OSMA, OCIO, or OCHMO) on a tailored request or a software Requirements Mapping Matrix.
2.1.5.7 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 or OSMA. [SWE-095]
2.1.5.8 Center Director, or designee, shall maintain a reliable list of their Center’s programs and projects containing Class A, B, C, and D software. The list should include: [SWE-006]
a. Project/program name and Work Breakdown Structure (WBS) number.
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:
(1) The name of the software development organization.
(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).
2.1.5.9 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: [SWE-091]
a. Software development tracking data.
b. Software functionality achieved data.
c. Software quality data.
d. Software development effort and cost data.
2.1.5.10 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-092]
2.1.5.11 Center Director, or designee, will maintain and implement software training to advance its in-house software engineering capabilities. [SWE-101]
2.1.5.12 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: [SWE-142]
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.
2.1.5.13 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. [SWE-144]
2.1.5.14 The designated Engineering Technical Authority(s) shall define the content requirements for software documents or records. [SWE-153].
Note: The recommended practices and guidelines for the content of different types of software activities (whether stand-alone or condensed into one or more project level or software documents or electronic files) are defined in NASA-HDBK-2203. The Center defined content should address prescribed content, format, maintenance instructions, and submittal requirements for all software related records. The designated Technical Authority for software approves the required software content for projects within their scope of authority. Electronic submission of data deliverables is preferred. “Software records should be in accordance with NPR 7120.5, NPD 2810.1, NPR 2800.1 and NPR 2810.1.”
2.1.5.15 The Center Director or designee shall ensure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third party owners prior to providing the software for internal NASA software sharing or reuse. [SWE-215]
2.1.5.16 The Center Director or designee shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements. [SWE-216]
2.1.5.17 The Center Director or designee (e.g., the Civil Servant Technical Point of Contact for the software product) shall perform the following actions: [SWE-217]
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.
2.1.5.18 The Center Director or designee (e.g., the Civil Servant Technical Point of Contact for the software product) shall perform the following actions for each type of internal NASA software transfer or reuse: [SWE-214]
a. A NASA civil servant to a NASA civil servant:
i. Verify the requesting NASA civil servant has executed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
ii. Provide the software to the requesting NASA civil servant.
b. A NASA civil servant to a NASA contractor:
i. 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.
ii. 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.
iii. Verify NASA contractor is not a foreign person (as defined by 22 CFR §120.16).
iv. 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).
v. After items i., ii., iii., and iv. 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.
c. A NASA civil servant to a foreign person or foreign entity:
i. If foreign persons or entities need access to any software in the NASA Internal Sharing and Reuse Software Inventory, they must obtain such access to the software in accordance with the external release requirements of NPR 2210.1.
2.1.6 Center SMA
2.1.6.1 The Center SMA Director will assure the project completes thorough hazard analyses which include software.
Note: The project manager is responsible for assuring Software Safety Hazard Analyses is performed on their project. The PM is responsible for the development of the project’s software hazard analyses and its independent review. Any differences in software safety's independent software safety critical determinations will be worked through the Engineering Technical Authority and the SMA Technical Authority.
2.1.6.2 The Center SMA Director, will review the project’s IV&V provider’s IV&V Project Execution Plan (IPEP) to ensure it meets NASA IV&V criteria.
2.1.6.3 The Center SMA Director will support the project to ensure that acquired, developed, and maintained software, as required by SWE-032, is developed by an organization with a non-expired CMMI-DEV rating as measured by a CMMI Institute Certified Lead Appraiser.
2.1.6.4 The Center SMA Director will support the Center organizations in obtaining and maintaining the NASA organization’s CMMI-DEV ratings. 2.1.6.5 The Center SMA Director, or designee, will ensure that the project’s Requirements Mapping Matrix implementation approach does not impact SMA on the project.
2.1.6.6 The Center SMA Director will ensure that any disagreements between software engineering or the project office and software assurance are identified, reported, tracked, and if not resolved, elevated.
2.1.6.7 In this document, the phrase “the Center SMA Director will…” means that the roles and responsibilities of the Center SMA Directors may be further delegated within the organization consistent with the scope and scale of the system. The Center SMA Director designates SMA Technical Authorities for programs, facilities, and projects, providing direction, functional oversight, and assessment for all Agency safety, reliability, maintainability, and quality engineering and assurance activities, including Software Assurance.
2.1.6.8 The designated SMA Technical Authority(s) will review, ensure, and concur on SW products and processes throughout the project acquisition, development, delivery, operations, and maintenance.
2.2.1 Software requirements tailoring is the process used to seek relief from NPR requirements consistent with program or project objectives, acceptable risk, and constraints. To accommodate the wide variety of software systems and subsystems, application of these requirements to specific software development efforts may be tailored where justified and approved. To effectively maintain control over the application of requirements in this directive and to ensure proposed variants from specific requirements are appropriately mitigated, NASA established Technical Authority governance. Tailoring from requirements in this directive are governed by the following requirements, as well as those established in NPD 1000.3, NPR 2800.1, NPR 2810.1, NPR 7120.5, NPR 7120.7, NPR 7120.8, and NPR 8715.3 for all of the Agency’s investment areas. The Technical and Institutional Authority for each requirement in this NPR is documented in the "Authority" column of Appendix C. The OSMA has co-approval on any tailoring decided at the Headquarters level that involves software. The Office of the Chief Medical Officer (OCHMO) has co-approval on any tailoring decided that involves software with health and medical implications. The Center CIO, or designee, has co-approval on any tailoring of the cybersecurity requirements in section 3.11. For tailoring involving human safety risk, the actual risk taker(s) (or official spokesperson[s] and appropriate supervisory chain) must formally agree to assume the risk. The responsible program, project, or operations manager must formally accept the risk. Tailoring decided at the Center level are to consult the Center Engineering Technical Authority, Center SMA Technical Authority, Center Health and Medical Technical Authority, and the NASA CIO’s Center IT Authority designee as defined in the requirements mapping matrix.
2.2.2 This directive establishes a baseline set of requirements to reduce software engineering risks on NASA projects and programs. Appendix C defines the default applicability of the requirements based on software classification. Each project has unique circumstances, and tailoring can be employed to modify the requirements set appropriate for the software engineering effort. Tailoring of requirements is based on key characteristics of the software engineering effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, a program, an organization, or other collection of similar software development efforts in accordance with NPR 7120.5, Section 3.5.5.
2.2.3 In this directive, the phrase "the project manager shall..." means the roles and responsibilities of the project manager may be further delegated within the organization to the scope and scale of the system.
2.2.4 Requirements in this directive are invoked by software classifications as defined in Appendix C:
a. “X” – Indicates an invoked requirement by this directive consistent with software classification (ref. SWE-139).
b. Blank – Optional/Not invoked by this directive.
2.2.5 The approval of the Authority designated in Appendix C is required for all tailoring of requirements designated as “X.” The implementation approach used to meet each requirement is typically determined by the appropriate software engineering management in conjunction with the project.
Note: The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that justifies supporting acceptance. The organization submitting the tailoring request informs the next higher level of involved management in a timely manner of the tailoring request. The dispositioning organization reviews the request with the other organizations that could be impacted or have a potential risk (i.e., to safety, quality, cybersecurity, health) with the proposed changes; and obtains the concurrence of those organizations.
2.2.6 Requests for software requirements relief at either the Center or Headquarters Technical Authority level (i.e., partial or complete relief) may be submitted in the streamlined form of a Requirements Mapping Matrix. The required signatures from engineering, Center CIO, and SMA authorities are to be obtained. A required signature from designated Center CIO is required for relief of cybersecurity requirements. If the Requirements Mapping Matrix is completed and approved in accordance with NPR 7120.5’s direction on Authority and this directive, it meets the requirements for requesting tailoring.
2.2.7 The engineering, CIO, and SMA authorities shall review and agree with any tailored NPR 7150.2 requirements per the requirements mapping matrix authority column. [SWE-150]
2.2.8 If a system or subsystem development evolves to meet a higher or lower software classification as defined in Appendix D, then the project manager shall update their plan to fulfill the applicable requirements per the Requirements Mapping Matrix in Appendix C and any approved changes and initiate adjustments to applicable supplier contracts to fulfill the modified requirements. [SWE-021]
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |