See edit history of this section
Post feedback on this section
- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
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
Class A B C D E F Applicable?
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
3.1 Development of Training Plans
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 5.15 - Train - Software Training Plan) to avoid duplicate requests for training among the Center's projects.
3.2 Training Areas
Key software-specific training areas to consider during the analysis include:
- Architecture and design development and assessment.
- Process methods.
- Requirements development.
- Configuration management.
- Development of languages and environments.
- Target processing systems.
- Verification and validation skills.
- Software assurance skills.
3.3 Identify Training Opportunities
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) 289,
- the Academy of Program/Project and Engineering Leadership (APPEL) 490,
- 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 Officer.
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. See also SWE-100 - Software Training Funding, SWE-222 - Software Assurance Training
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.
3.4 Scheduling and Tracking Training
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).
3.5 Evaluation of Training
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 input for judging the effectiveness of the training. Remedial training or additional training can be scheduled, as needed, based on a review of the results.
3.6 Additional Training for Software Team Members
The software team members often need supporting discipline capabilities beyond software engineering expertise (e.g., project management, scheduling). The Center training departments plan schedules and provide all appropriate training in these supporting disciplines to the people who need it.
3.7 Additional Guidance
Additional guidance related to software training may be found in the following related requirements in this Handbook:
Related Links |
---|
3.8 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
SPAN Links |
---|
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
- (SWEREF-041) NPR 7123.1D, Office of the Chief Engineer, Effective Date: July 05, 2023, Expiration Date: July 05, 2028
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-266) This NASA-only resource is available to NASA users at https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal.
- (SWEREF-289) NESC Academy Software Discipline. Topics include software requirements, design, implementation, architecture, assurance, testing, training, tools, process improvement, best practices, software release, models and simulations, and software research and technology innovation.
- (SWEREF-294) The Safety and Mission Assurance (SMA) Technical Excellence Program (STEP) is a career-oriented, professional development roadmap for SMA professionals.
- (SWEREF-490) Academy of Program/Project and Engineering Leadership (APPEL). Retrieved on September 14, 2015 from http://appel.nasa.gov/about-us/history/.
- (SWEREF-491) Access the APPEL curriculum catalog from this URL.
- (SWEREF-513) Public Lessons Learned Entry: 641.
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
- Mars Climate Orbiter Mishap Investigation Board - Phase I Report 513: 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:
- Undetected mis-modeling of spacecraft velocity changes.
- Navigation Team unfamiliar with spacecraft.
- The trajectory correction maneuver number 5 was not performed.
- The system engineering process did not adequately address the transition from development to operations.
- Inadequate communications between project elements.
- Inadequate operations Navigation Team staffing.
- Inadequate training.
- 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.
2. Confirm that software assurance and software safety personnel have completed the appropriate software assurance and/or software safety training to satisfactorily conduct assurance and safety activities.
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.
7.3 Metrics
- Percent of the required training completed for each of the project SA personnel.
- % of project personnel that have completed project specific training against the planned training schedule.
See also Topic 8.18 - SA Suggested Metrics.
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 is 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) 294designed 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:
Intermediate Software Assurance |
Software Requirements Development, & Analysis |
Introduction to Software Engineering |
Introduction to Model-Based Assurance |
Foundations of Capability, CMMI |
Building Development Excellence, CMMI |
Introducing Agile Software Development |
Introduction to Software Testing |
Software Safety for Practitioners |
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.
7.5 Additional Guidance
Additional guidance related to software training may be found in the following related requirements in this Handbook:
Related Links |
---|
See also SWE-222 - Software Assurance Training for more on funding for SA training.