bannerb

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Include Page
2B-Page Warning
2B-Page Warning

Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Div
idtabs-1

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 Applicability Across Classes

Applicable b
a1
b1
csc1
c1
d0
dsc1
e0
f1
g1
h0


Div
idtabs-2

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. 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.

Div
idtabs-3

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 and 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.

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 SDP-SMP). The training information is also included in a Center training plan (see SWE-101 and STP - Software Test 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 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)

Swerefn
refnum289
, the Academy of Program/Project and Engineering Leadership (APPEL)
Swerefn
refnum491
, a Center's Software Engineering Process Group (SEPG), STEP- NASA’s university for safety and mission assurance, 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 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 SDP-SMP).

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.

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:

Div
idtabs-4

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.

Div
idtabs-5

5. Resources

refstable

toolstable

Div
idtabs-6

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
    Swerefn
    refnum513