See edit history of this section
Post feedback on this section
1. Requirements
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).
1.1 Notes
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.
1.2 History
2. Rationale
Waiving or tailoring NASA Procedure requirements for Software Engineering is an inherently Government function.
3. Guidance
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. The TA process (see NPR 7120.5, NASA Space Flight Program and Project Management Requirements, Chapter 3.3) 082 provides for the selection of individuals at different levels of responsibility who contribute an independent view of matters within their respective areas of expertise. These individuals are responsible for assuring that changes to and waivers of technical requirements are submitted to and acted on by the appropriate level in the TA process. The involvement of the TA in program/project activities as a member of the program's/project's control, change, and internal review boards will ensure that any views from the TA will be available to the program/project in a timely manner. 082
The Center Director is delegated Technical Authority (TA) from the NASA Chief Engineer. With this delegation, the Center Director selects and approves software TA(s) who are knowledgeable of the software development policies, requirements, and practices that are applicable to a given project. This is important because the Center Director, who is ultimately responsible for all projects at the Center, is appointing TA(s) who are responsible for approval of deviations and/or waivers.
It is essential that the project TA(s) thoroughly understands the Agency-level, Center-level, Project-level software development requirements, including NPR 7150.2, NASA STD 8739.8 278, NASA Software Assurance and Software Safety Standard.
The Center Director (or designee) is empowered by NPR 7150.2 to select civil servant individual(s) from the Office of the Chief Information Officer (CIO) at Headquarters for class F software or from the Center's CIO office, if that makes the most sense, for classes G and H software. This ability to choose will assure the software TA is familiar with the software development policies, requirements, and practices associated with a particular class of software.
Because of the extent and variety of projects at a Center, it may be beneficial to assign multiple software TAs, each having responsibility for a unique portion of the software being developed or acquired in support of the Center's mission. The appointment of software TAs may be documented in appointment letters from the Engineering Technical Authority (or designee), in the Center implementation plans, in project plans, and in the organization and project-specific documentation repositories.
4. Small Projects
No additional guidance is available for small projects.
5. Resources
5.1 Resources
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-257) NPD 7120.4E, NASA Office of the Chief Engineer, Effective Date: June 26, 2017, Expiration Date: June 26, 2022
- (SWEREF-261) NPD 1000.0C, NASA Governance and Strategic Management Handbook, Effective Date: January 29, 2020, Expiration Date: January 29, 2025
- (SWEREF-262) NASA Headquarters NASA Office of the Chief Engineer engineering deviations and waivers website.
- (SWEREF-271) NASA STD 8719.13 (Rev C ) , Document Date: 2013-05-07
- (SWEREF-278) NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
- (SWEREF-558) Public Lessons Learned Entry: 1499.
5.2 Tools
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
6.1 NASA Lessons Learned
A documented lesson from the NASA Lessons Learned database notes the following:
- Orbital Space Plane Centralized Technical Management. Lesson Number 1499 558: The Orbital Space Plane project cited the need to make early appointments so that project implementation is strengthened early in phase A of a project's life cycle. Many examples from project histories indicate that Phase A's decisions strongly impact the future cost of projects. The recommendation (in "Lesson(s) Learned") is "to quickly/clearly charter and mobilize a strong centralized technical authority with responsibility to make binding technical decisions across all elements...and across program boundaries" to avoid weakening "the program's Phase A technical implementation."
6.2 Other Lessons Learned
No other Lessons Learned have currently been identified for this requirement.