1. Requirements

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

1.1 Notes

This includes any software assurance personnel assigned to the project.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

This requirement is to ensure that project personnel receives the 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. The development and use of a controlled training plan ensure 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 analyzes the software-specific skills and expertise needed to develop these work products and to support the software activities on a project. Not all the skills required to accomplish a software project are "software" skills. The software engineering staff may require training in other domains to facilitate the support of a project.

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 5.08 - SDP-SMP - Software Development - Management Plan). The training information is also included in a Center training plan (see SWE-101 and 5.15 - Train - Software Training Plan) 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.
• Software assurance 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 coursework, 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 (APPEL) ⁴⁹⁰, a Center's Software Engineering Process Group (SEPG), STEP- NASA’s university for safety and mission assurance, the team member's engineering organization, and the Center's Training Office. These organizations often maintain web-based curricula and schedules of training classes. The 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 are monitored and recorded. Just as the type and nature of training opportunities vary among Centers and projects, so do 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 5.08 - SDP-SMP - Software Development - Management Plan).

Good practice suggests that these scheduled training activities, their completion, and the impacts of 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.

The software team members often need supporting discipline capabilities beyond software engineering expertise (e.g., project management, scheduling).  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 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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 were 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. 1. 1. 1. Undetected mis-modeling of spacecraft velocity changes.
         2. Navigation Team unfamiliar with spacecraft.
         3. The trajectory correction maneuver number 5 was not performed.
         4. The system engineering process did not adequately address the transition from development to operations.
         5. Inadequate communications between project elements.
         6. Inadequate operations Navigation Team staffing.
         7. Inadequate training.
         8. The verification and validation process did not adequately address ground software

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that any project-specific software training has been planned, tracked, and completed for project personnel, including software assurance and software safety personnel.

7.2 Software Assurance Products

• The required software training completion records for SA personnel on a project.

  
  

  Objective Evidence

  • Evidence showing confirmation of the required project training activities for the personnel supporting the software development activities.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• Percent of the required training completed for each of the project SA personnel.
• % of project personnel that has completed project specific training against the planned training schedule.

7.4 Guidance

Step 1 - Confirm that any project-specific software training has been planned, tracked, and completed for project personnel, including SA personnel.

Determine if any project-specific software training is required or needed for project personnel, including SA personnel.

Confirm that the identified project-specific software training has been planned, tracked, and completed for project personnel, including SA personnel.

Software Management/Development Plan typically has a section identifying the training required for the project. If the project has decided to adopt Agile Software Development, it’s important to identify such training for software assurance, software developers, and software managers. Training in the particular Agile methodology being used, such as SCRUM, may be needed and a trained Certified Scrum Master to lead the team is necessary as well. For projects who are developing flight software using cFE and cFS, cFE and cFS training are important. Other types of training may include training on software development environment tools such as Integrated Development Environment, Configuration Management, Project Management, Confluence, build tools, static analysis tools, and JIRA. Additionally, software process training may be needed to understand the software processes being used by the project as well as how those processes support software development.  Some project personnel may also need training on real-time operating systems being used by the project or other embedded COTS software being used by the project.

Step 2 Develop and maintain software training records for SA personnel on a project, including basic software assurance training.

Maintain or have access to data showing the software training records for SA personnel on a project, including basic software assurance training. You can use Saturn data and STEP training data for this activity.  

Personnel performing software assurance on a project also need training on the specific details of the project itself. The project is to provide an orientation session for all project personnel, including software assurance, to ensure that they understand the basic details of the project including the concepts of operations and the requirements from the perspective of the system and of the software.

In addition, to project-specific training, there is a professional development program called SMA Technical Excellence Program (STEP) designed for the SMA Workforce, which includes software assurance personnel. STEP has four distinct Levels, each requiring an increased amount of time, effort, and dedication. Participants must complete Level 1 before proceeding to Levels 2-4; however, courses are available à la carte. SA Personnel will need to declare SA as his/her discipline for Levels 2-4. The courses in the SA curriculum are pushed onto his/her SATERN (the NASA Learning Management System) required training list. This is where the SA Personnel will online courses and where the training records are maintained. Any project personnel who will be doing software assurance tasks need to be trained on the software assurance (and safety assurance, if applicable) requirements and processes.

The SA courses in Level 2 are the following: 

It’s recommended for SA personnel supporting projects to have taken these or equivalent courses. This training may not be included in the Software Management/Development Plan but it should be specified in the Software Assurance Plan.

The recommended benchmark for training is 40 training hours.