1. Requirements

6.3.1 The designated Center Engineering Technical Authority(s) for this NPR shall comply with NASA Headquarters' Office of the Chief Engineer's direction on roles and responsibilities for Engineering Technical Authority.

1.1 Notes

Top-level direction on Engineering Technical Authority for all of the Agency's investment areas (including activities performed under NPR 7120.7 and NPR 7120.8) is documented in NPR 7120.5 and elaborated for software in this NPR.

1.2 Applicability Across Classes

2. Rationale

The NASA Headquarters Office of the Chief Engineer (OCE) is responsible for providing Agency-wide direction for the implementation of the roles and responsibilities of the Engineering Technical Authority (ETA). Understanding of the Technical Authority (TA) process is necessary to assure NASA programs and projects are managed consistently across enterprises and Centers. An individual Center can assist in developing consistent implementation by recording and disseminating its approach for complying with the TA direction in the local ETA Implementation Plan.

3. Guidance

NPR 7120.5, NASA Space Flight Program and Project Management Requirements,  ⁰⁸² describes the generic roles and responsibilities for the ETA (Engineering Technical Authority).  Because this document is written for general Agency-wide use, its content tends to be generally stated and avoids providing an elaboration of Center-specific instructions and explanations. To assure these roles and responsibilities are recognized at the Center level, NPR 7120.5 calls for the Center ETA to develop a plan for local TA implementation. This requires the Center ETA Implementation Plan to contain specific direction for complying with the Headquarters' OCE (Office of the Chief Engineer) lists of roles and responsibilities. The development of a Center-centric implementation plan and subsequent updates needs to proceed with conversation and involvement with the Headquarters' OCE, as well as with consideration for the Center's mission.

The software development team is expected to familiarize itself with the content of the Center implementation plan, which typically discusses the following:

• How the delegation of software ETA is officially documented at the Center level, e.g., in an approved TA Plan, Center Director Letter, Center Software Directive.
• How approval of deviations and waivers will proceed. ²⁶²
• The need to convene and support reviews.
• The method for identifying Center best practices.
• How review resources will be provided.

A Center may have one software TA or multiple TAs. Collaborative discussions and planning between or among these TAs regarding best practice implementation of the responsibilities from a software perspective will support consistent and fair decisions.

The software TA typically assists in developing compliance methods to SWE-124 based on the Center's ETA Implementation Plan. Typical activities might include software TA training, negotiations with the Center ETA regarding specific software discipline areas of responsibility, and discussions and planning sessions with software managers, working groups, and line management. 

Expending sufficient effort and planning up front to develop precise descriptions and processes for exercising TA will help negate nebulous and multiple applications across Center projects. This information will be important for future training of new software TA personnel, as well as for lessons learned activities.

Updates to the ETA Implementation Plan include any modifications or additional adaptations of the roles and responsibilities received from the Headquarters' OCE.

Additional guidance related to TA compliance may be found in the following related requirements in this Handbook:

4. Small Projects

Projects are not responsible for this requirement.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

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

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

Common Review Methods for Engineering Products. Lesson Number 0667: This lesson learned can have implications for the need of common roles and responsibilities for software TAs. Headquarters-specified roles and responsibilities for TAs typically generate practices that "provide a common framework for planning, conducting, documenting, and evaluating ... process". One such example is the performance of technical reviews to evaluate waiver requests or to validate engineering designs that are based on a common, consistent approach that has been proven to lead to reliable and quality products.

The lack of a common approach inhibited the ability to perform a substantive review.  The lesson (in "Impact of Non-Practice") states, "Lacking clear standards for project and task review, and failing to conduct detailed technical reviews (DTRs) beforehand, design reviews have a tendency to emphasize formality and "packaging" at the expense of substantive assessment of content and depth of analysis." ⁵¹⁶