bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Old Version 3

changes.mady.by.user [DISABLED] Gauntner, Dan (GRC-DPS0)

Saved on

compared with

New Version Current

changes.mady.by.user Haigh, Fred Douglas. (HQ-KA000)[PEROT]

Saved on

Key

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


{alias:SWE-025} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Wiki Markup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

1. Requirements

2.2.14

The

project

shall

ensure

that

corrective

actions

are

taken,

recorded,

and

managed

to

closure

when

actual

results

and

performance

deviate

from

the

software

plans.

h2. {color:#003366}{*}

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2

does not include any notes for this requirement. h2.

, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2

Applicability

Across

Classes

Classes

D

and

E

and

Safety

Critical

are

labeled

with

"SO."

.

This

means

that

this

requirement

applies

to

the

safety-critical

aspects

of

the

software.

Class

G

is

labeled

with

"P

(Center).

 

" This

means

that

an

approved

center

Center-defined

process

which

meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=*|dnsc=0|esc=*|ensc=0|f=1|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale The use of a good corrective action plan and related tools (usually referred to as a "PRACA" Problem Reporting and Corrective Action System) makes sure that the software development and assurance teams understand, act upon, and closes issues and deviations to prevent reoccurrence.  Proper documentation helps the teams to track the activity, know when it is complete, and when it is eligible to be closed.  It also provides measurement data input for project metric evaluations and the development of lessons learned information. {div3} {div3:id=tabs-3} h1. 3. Guidance The planning and requirements documentation developed during the early phases of the project (see [SWE-013|https://nasa7150.onconfluence.com/display/7150/SWE-013], [SWE-102|https://nasa7150.onconfluence.com/display/7150/SWE-102], and [SWE-109|https://nasa7150.onconfluence.com/display/7150/SWE-109]) guides development of software work products. The project management team and the software development lead work together to construct a work plan that is logical and achievable in the allotted time. During early project phases key performance factors, schedules and milestones are composed. As scheduled work is performed it is important for the results to be reviewed to assure conformance with these plans and to assess if the expected performance has been achieved (see [SWE-024|https://nasa7150.onconfluence.com/display/7150/SWE-024]). Occasionally these reviews surface a significant deviation between the actual and expected results of an activity. Some deviations are a normal part of project development activity and are resolved through the normal course of scheduled activity. These deviations are typically tracked informally until the developers establish a product baseline, after which deviations/problems are formally tracked (usually in the PRACA system) which requires evaluation, disposition and assurance oversight of the problem.  The Software Development Plan or the Software Configuration Management Plan typically defines the level of the deviations that are required to be recorded and tracked in the formal tracking systems.   Typically a Center has an approved process for problem reporting and corrective action (PRACA) activities. This requirement does not mandate a particular approach or tool as long as the following key elements of a corrective action activity are employed. During the course of the software development activity, once a deviation is found that meets the criteria for formal reporting, the software development team should clearly state the issue, its area of applicability across the software development activity, and the spectrum of relevant stakeholders it involves. As this information is obtained the issue is documented in the approved process tool or data repository and an analysis is conducted of the deviation. The results of the analysis should provide a clear understanding of the deviation and a proposed course of action to further investigate and resolve the deviation as necessary. [SWE-113|https://nasa7150.onconfluence.com/display/7150/SWE-113] provides specific details for the information needed for documenting a problem report. The proposed course of action may be reviewed by project management and other relevant stakeholders to assure resources are available for the activity (see [SWE-026|https://nasa7150.onconfluence.com/display/7150/SWE-026]). It may be necessary to update planning documentation and development schedules to account for the corrective action activity (see [SWE-080|https://nasa7150.onconfluence.com/display/7150/SWE-080]).Once a corrective action activity has been approved and initiated, its progress is reviewed on a regular basis for progress and its use of planned resources.  This information is used to assess whether the action itself is on course or deviating from the expected result. An important element of the corrective action activity is the proper closeout of the action. After the activity has concluded, or when the deviation has been narrowed to within acceptable limits, the closeout is recorded and may include the following information: * Description of the issue/deviation * Proposed corrective action, with acceptable limits * Actual results/impacts from the effort * Listing of required changes to requirements, schedules, resources, if any, to accommodate the result * Signature(s)/concurrence by all relevant stakeholders Once the documentation has been completed, it should be entered into a suitable repository or configuration management system. {div3} {div3:id=tabs-4} h1. 4. Small Projects This requirement applies to all projects. {div3} {div3:id=tabs-5} h1. 5. Resources 1.    [NASA Systems Engineering Processes and Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7123&s=1A] with Change 1, NPR 7123.1A, 2009 2.    [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130], NASA STD 8739.8, 2005 3.    [NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005D_/NM_7120-81_.pdf], NPR 7120.5D (NM-7120.81), 2009. 4.    [NASA Software Formal Inspection Standard|https://standards.nasa.gov/documents/detail/3314883], NASA-STD-2202-93, 1993 h2. 5.1 Tools {panel}Tools relative to this SWE may be found in the table above. If no tools are listed, none have been currently identified for this SWE. You may wish to reference table xyz 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{*}*.* {panel} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned Probable Scenario for Mars Polar Lander Mission Loss (1998) Description: Neither the MPL software requirements specification nor the software, subsystem or system test plans required verification of immunity to transient signals. MPL touchdown sensors generated known transient signals at leg deployment. Full leg deployment test was not repeated after wiring corrections. Tests should be re-run after test deficiencies are corrected or hardware or software is revised unless clear rationale exists for not doing so. Hardware operational characteristics, including transients and spurious signals must be reflected in software requirements and verified by test.. [http://www.nasa.gov/offices/oce/llis/0938.html|http://www.nasa.gov/offices/oce/llis/0938.html] Problem Reporting and Corrective Action System This Lesson Learned is based on Reliability Practice No. PD-ED-1255; from NASA Technical Memorandum 4322A, NASA Reliability Preferred Practices for Design and Test. [http://www.nasa.gov/offices/oce/llis/0738.html] {div3} {tabclose}


applicable
f1
gp
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc*
cnsc1
dnsc0
dsc*
ensc0


 Div
idtabs-2
2. Rationale
The use of a good corrective action plan and related tools (usually referred to as a "PRACA" (Problem Reporting and Corrective Action System) ensures that the software development and assurance teams understand, act upon, and close issues and discrepancies to prevent reoccurrence. Proper documentation helps the teams to track the activity, know when it is complete, and when it is eligible to be closed.  It also provides measurement data input for project metric evaluations and the development of lessons learned information.

 Div
idtabs-3
3. Guidance
The planning and requirements documentation developed during the early phases of the project (see SWE-013, SWE-102, and SWE-109) guides development of software work products. The project management team and the software development lead work together to construct a work plan that is logical and achievable in the allotted time. During early project phases key performance factors, schedules and milestones are composed. As scheduled work is performed, it is important for the results to be reviewed to assure conformance with these plans and to assess if the expected performance has been achieved (see SWE-024). During these reviews (both formal and informal), project results are compared to plans. Tools, such as excel-based checklists, planning and tracking tools (such as Omniplan and Primavera), and/or formal configuration management systems/change control tools, are used to identify, resolve, and track to closure discrepancies and other shortfalls to project performance.

 Panel
It is important to understand that the activities of "identification," "recording," and "tracking to closure" are techniques that the software development engineering team uses to address and satisfy NPR 7150.2, NASA Software Engineering Requirements, requirements related to many areas in the project, such as life cycle planning (SWE-018 and SWE-024), verification and validation (V&V) activities (SWE-030 and SWE-031), requirements development and management (SWE-054), configuration management systems (SWE-080), and the preparation of documentation to measure and record these activities (SWE-091, SWE-102, SWE-109, SWE-113, and SWE-117). NPR 7150.2 uses these terms repetitively, but users of this Handbook are expected to use them and interpret them in the context of the SWE guidance being read.
Occasionally these reviews surface a significant discrepancy between the actual and expected results of an activity. Some discrepancies are a normal part of project development activity and are resolved through the normal course of scheduled activity. These discrepancies are typically tracked informally until the developers establish a product baseline, after which discrepancies/problems are formally tracked (usually in the PRACA system) which requires evaluation, disposition and assurance oversight of the problem. The Software Development Plan or the Software Configuration Management Plan typically defines the level of the discrepancies that are required to be recorded and tracked in the formal tracking systems. Typically a Center has an approved process for problem reporting and corrective action (PRACA) activities. This requirement does not mandate a particular approach or tool as long the key elements of a corrective action activity that are described in the following paragraph are employed.
During the course of the software development activity, once a discrepancy is found that meets the criteria for formal reporting, the software development team clearly states the issue, its area of applicability across the software development activity, and the spectrum of relevant stakeholders it involves. As this information is obtained, the issue is documented in the approved process tool or data repository and an analysis is conducted of the discrepancy. The results of a properly completed analysis provide a clear understanding of the discrepancy and a proposed course of action to further investigate and resolve the discrepancy as necessary. SWE-113 provides specific details for the information needed for documenting a problem report.
The proposed course of action may be reviewed by project management and other relevant stakeholders to assure resources are available for the activity (see SWE-026). It may be necessary to update planning documentation and development schedules to account for the corrective action activity (see SWE-080). Once a corrective action activity has been approved and initiated, its progress is reviewed on a regular basis for progress and its use of planned resources. This information is used to assess whether the action itself is on course or deviating from the expected result.
An important element of the corrective action activity is the proper closeout of the action. After the activity has concluded, or when the discrepancy has been narrowed to within acceptable limits, the closeout is recorded and may include the following information:

  • Description of the issue/discrepancy.
  • Proposed corrective action, with acceptable limits.
  • Actual results/impacts from the effort.
  • Listing of required changes to requirements, schedules, resources, if any, to accommodate the result.
  • Signature(s)/concurrence by all relevant stakeholders.
Once the documentation has been completed, it can be entered into a suitable repository or configuration management system.

 Div
idtabs-4
4. Small Projects
This requirement applies to all projects regardless of size.

 Div
idtabs-5
5. Resources

refstable
toolstable

 Div
idtabs-6
6. Lessons Learned
 The NASA Lessons Learned database contains the following lessons learned related to corrective actions:
  1. Probable Scenario for Mars Polar Lander (MPL) Mission Loss (1998), Lesson No. 0938: "Description: Neither the MPL software requirements specification nor the software, subsystem or system test plans required verification of immunity to transient signals. MPL touchdown sensors generated known transient signals at leg deployment. Full leg deployment test was not repeated after wiring corrections. Tests should be re-run after test deficiencies are corrected or hardware or software is revised unless clear rationale exists for not doing so. Hardware operational characteristics, including transients and spurious signals must be reflected in software requirements and verified by test."
    sweref
    529
    529
  2. Problem Reporting and Corrective Action System, Lesson No. 0738. "This Lesson Learned is based on Reliability Practice No. PD-ED-1255; from NASA Technical Memorandum 4322A, NASA Reliability Preferred Practices for Design and Test."
    sweref
    520
    520





    
    






    
	

    
    
    



    




    
    

    
    
    






        



        

    

    



										
								
		        

		    



		
						
 











Page Editor: Tim Crumbley 

NASA Official: Tim Crumbley






NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer

 NASA Privacy Statement

______________________________________________________________________________