1. Requirements

2.2.5 The project shall plan, track, and ensure project specific software training for project personnel.

1.1 Notes

This requirement is intended to address skills needed to support the software activities on a project. Not all skills required to accomplish a software project are "software" skills. The software engineering staff may require training in other domains to facilitate support of a project.

1.2 Applicability Across Classes

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

2. Rationale

This requirement is to ensure that project personnel receive necessary training in project selected software tools, programming languages, techniques, and methodologies to develop quality work products.  Furthermore, the system under development typically has aspects that need to be thoroughly understood by software personnel. There are a wide variety of tools and techniques available to support the software engineering activity. The development and use of a controlled training plan ensures that the skills and expertise required by a project are available when they are needed.

3. Guidance

Preparation for the development of software training plans begins in the Formulation phase of a project. As the initial efforts occur to define the requirements and performance characteristics for the software work products, the Project Team makes an analysis of the software-specific skills and expertise needed to develop these work products. The Project Team uses surveys and interviews with task managers and team leaders to identify existing capabilities and shortfalls in expertise. The analysis also includes reviews of histories and lessons learned on past projects and software activities. Information developed from the analysis is documented in the Software Development or Management Plan (see SWE-102). The training information is also included in a Center training plan (see SWE-101 and SWE-107) to avoid duplicate requests for training among the Center's projects.

Key software-specific training areas to consider during the analysis include:

• Architecture and design development and assessment.
• Process methods.
• Requirements development.
• Configuration management.
• Development languages and environments.
• Target processing systems.
• Verification and validation skills.

Once the analysis of the needed skills and expertise is completed, the project reviews the integrated set of training needs with training organizations and their course providers to identify the available training opportunities. These may include formal course work, self-study events, or on-the-job development opportunities. Specific organizations within NASA to contact about the needed training include the Office of the Chief Engineer (OCE) ²⁸⁹, the Academy of Program/Project and Engineering Leadership (APPL) ²⁶⁵, a Center's Software Engineering Process Group (SEPG) ³¹⁸, the team member's own engineering organization, and the Center's Training Office. These organizations often maintain web-based curricula and schedules of training classes.  The NASA

System for Administration, Training and Educational Resources for NASA (SATERN) website provides a convenient and controlled tool for scheduling, registering, and monitoring training. See the tools table resource for the website.

This review will also identify any issues with the availability of specific types of training.  When deficiencies are identified, they are presented to the organizations providing the training.  If training deficiencies persist, the project will need to develop work-around plans, which may include procuring or developing training that is focused on the shortfalls in specific knowledge or skills. 

Once training plans have been developed for individuals and teams, the scheduling, attendance, and completion of these activities is monitored and recorded. Just as the type and nature of training opportunities varies among Centers and projects, so to the methods for tracking and recording training vary. These usually align with Center training and records retention processes that are currently in effect at each Center. If no training is needed to execute the software development activity then the requirement is satisfied by stating this fact in the Software Development Plan training section (see SWE-102).

Good practice suggests that these scheduled training activities, their completion, and the impacts to the project and software activities be evaluated. Surveys, collections of lessons learned, solicitations for best practices, and evaluations of improvements in project performance are all sources of inputs for judging the effectiveness of the training. Remedial training or additional training can be scheduled, as needed, based on a review of the results.

As indicated in the later half of the note of section 1.1, the software team members often need supporting discipline capabilities beyond software engineering expertise (e.g., project management, scheduling, earned value management).  The Center training departments plan, schedule and provide all appropriate training in these supporting disciplines to the people who need it.

Additional guidance related to software training may be found in the following related requirements in this Handbook:

4. Small Projects

Small projects can consider using a pre-existing training plan if the project is similar to previous projects. Organizations that are responsible for developing numerous, similar small projects can develop an umbrella training plan that covers these projects.

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

Mars Climate Orbiter Mishap Investigation Board - Phase I Report: The MCO Mishap Investigation Board (MIB) has determined that the root cause for the loss of the MCO spacecraft was the failure to use metric units in the coding of a ground software file, "Small Forces," used in trajectory models. Specifically, thruster performance data in English units instead of metric units was used in the software application code titled SM_FORCES (small forces). A file called Angular Momentum Desaturation (AMD) contained the output data from the SM_FORCES software. The data in the AMD file was required to be in metric units per existing software interface documentation, and the trajectory modelers assumed the data was provided in metric units per the requirements.

Root Cause: Failure to use metric units in the coding of a ground software file, "Small Forces," used in trajectory models.

Contributing causes include:

1. Undetected mismodeling of spacecraft velocity changes.
2. Navigation Team unfamiliar with spacecraft.
3. Trajectory correction maneuver number 5 not performed.
4. System engineering process did not adequately address transition from development to operations.
5. Inadequate communications between project elements.
6. Inadequate operations Navigation Team staffing.
7. Inadequate training.
8. Verification and validation process did not adequately address ground software. ⁵¹³