bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)


SWE-122 - Technical Authority Appointment

1. Requirements

6.2.1 The designated Engineering Technical Authority(s) for requirements in this NPR, which can be waived at the Center level, shall be approved by the Center Director.

1.1 Notes

The designated Engineering Technical Authority(s) for this NPR is a recognized NASA software engineering expert. Typically, Center Directors designate an Engineering Technical Authority for software from their engineering organization for software classes A through E, from the NASA Headquarters' Office of the Chief Information Officer (CIO) for Class F, and from their Center CIO organization for classes G through H. The designation of Engineering Technical Authority(s) is documented in the Center Technical Authority Implementation Plan. Please refer to Appendix D (last column) for requirements that can be waived at the Center level.

1.2 Applicability Across Classes

While the applicability noted below duplicates the applicability from Appendix D of NPR 7150.2, the Office of the Chief Engineer (OCE) has indicated that this is an inadvertent error for Classes F, G, and H.  Expect this SWE-122 to apply to all classes and safety criticalities, possibly through an administrative change to NPR 7150.2.

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

   

   

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

2. Rationale

The Center Director is delegated Technical Authority (TA) from the NASA Chief Engineer. With this delegation, the Center Director selects and approves a software TA who is 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 a TA who is responsible for approval of deviations and/or waivers.  These actions cover requirements developed and approved at the Center, as well as those that are assigned to the Center, as listed in Appendix D of NPR 7150.2, NASA Software Engineering Requirements.

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

A list of viable software TA candidates may be prepared and made available to the Center Director. This will ensure a timely selection and start of the TA for the Center's projects. The list typically contains only the names of individuals who are known for their expertise in the software engineering technical area and for their ability to work well within engineering and project teams. This expertise is usually demonstrated by successful involvement with projects that are typical of the Center's mission.  It is essential that the TA candidate thoroughly understands Center-level software development requirements, as well as Agency-level software requirements, including NPR 7150.2, NASA STD 8739.8, NASA Software Assurance Standard 278, and NASA STD 8719.13, Software Safety Standard 271.

Typically, the software TA is chosen from the Center's engineering organization(s). However, the Center Director (or designee) is empowered by NPR 7150.2 to select 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 organization and project-specific documentation repositories.

4. Small Projects

Projects are not responsible for this requirement.

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

6. Lessons Learned

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

Orbital Space Plane Centralized Technical Management. Lesson Number 1499: 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 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." 558

1 Comment

  1. Anonymous

    “The designated Engineering Technical Authority(s) for this NPR is a recognized NASA software engineering expert.” The guidance is too restrictive for Technical Authority. Chief Engineers are the Technical Authority for programs/projects for both software and hardware. While some of them may not be NASA “recognized” software experts, they do call upon the experts for advice and technical input in performing their functions. Recommend to revise or to remove this guidance.