bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 59 Next »

Error formatting macro: alias: java.lang.NullPointerException
SWE-029 - Validation Planning
Unknown macro: {div3}

1. Requirements

2.4.2 The project shall plan the software validation activities, methods, environments, and criteria for the project.

1.1 Notes

Software validation is a software engineering activity that shows confirmation that the software product, as provided (or as it will be provided), fulfills its intended use in its intended environment. In other words, validation ensures that "you built the right thing." Examples of validation methods include but are not limited to: formal reviews, prototype demonstrations, functional demonstrations, software testing, software peer reviews/inspections of software product component, behavior in a simulated environment, acceptance testing against mathematical models, analyses, and operational environment demonstrations. Refer to the software plan requirements for software validation planning and incorporation (NPR 7150.2, Chapter 5) [detailed in [SWE-102] in this handbook].

1.2 Applicability Across Classes

Class D non-Safety Critical and Class G are labeled with "P(Center)". This means that local requirements or procedures describe validation planning sufficiently to meet the intent of this requirement.

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

    P(C)

   

   

   

    P(C)

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

Unknown macro: {div3}

2. Rationale

Planning should be applied to any activity that is to be repeated, that needs to be verified before use, and that requires thought before implementation. Planning the requirements validation activity allows the project team to put more thought into tasks, methods, environments, and related criteria before they are implemented. Planning also allows a current project to improve based on lessons learned from previous projects, including using more appropriate or efficient techniques and ensuring the completeness of all steps in the process.

Having a plan also allows the requirements validation activity to be reviewed, improved, and verified before it is implemented to ensure the outcome will meet the expectations and goals of the validation activity. Planning also helps to ensure the validation activity is cost-efficient and timely.

Unknown macro: {div3}

3. Guidance

The basic validation process is shown below with the steps addressed by this requirement highlighted:

Validation activities should not be performed in an ad hoc manner, but should be planned and captured in a validation plan document. The validation plan is typically part of a verification and validation (V&V) plan, a software V&V plan (SVVP), or is included in the Software Management / Development Plan (SMP/SDP).

The plan should cover the validation activities that will occur at various times in the development lifecycle including:

  • During requirements development, validation is accomplished by bringing in the customer and outside people for a review of the requirements, e.g., focus groups, requirements reviews, etc.
  • During design, validation occurs when the customers have a chance to view prototypes of the product or pieces of the product, e.g., focus groups, user groups, etc.
  • During implementation, validation occurs when team members review requirements, design, and code during peer reviews/inspections.
  • Prior to delivery, validation occurs when customers see the completed product function in a nearly operational environment, e.g., acceptance testing, operational demonstrations, etc.
  • During product use, validation occurs when the product is used in the operational environment in the way the customer expects it to be used.

The project team should review the plan and validation results at various lifecycle reviews, particularly whenever requirements change throughout the duration of the project. Any identified issues should be captured in problem reports / change requests / action items and resolved before the requirements are used as the basis for development activities.

The validation plan will address more than just validation of software requirements. It should include a schedule, especially if stakeholder reviews are required to complete the validation activities and gain agreement that the requirements are a correct and acceptable description of the system or software to be implemented. Other elements to include in the overall plan:

  • Scope
  • Approach
  • Resources
  • Specific tasks and activities
  • Validation methods and criteria ([SWE-102])
  • Identification of work products to be validated ([SWE-102])
  • Identification of where validation records and corrective actions will be captured ([SWE-102])

The Scope and Approach sections of the plan should identify the project and define the purpose and goals of the plan including responsibilities, assumptions, and a summary of the efforts described in the plan.

Resources include personnel, environments such as simulators, facilities, tools, etc. and should include any skills and/or training necessary for those resources to carry out the validation activities.

When developing the validation plan, consider the following for inclusion:

  • Identifying the key functions and/or components that require validation (based on criticality, safety, security, etc.)
  • Identifying the validation methods, techniques, tests to carry out the validation activities for components as well as the system as a whole (see [SWE-055]-Requirements Validation)
  • COTS, GOTS, MOTS affects on the project and associated validation planning ([SWE-027] - Use of Commercial, Government, and Legacy Software)
  • Identifying criteria by which success will be measured for each validation activity
  • Establishing the target environment (which could be a high fidelity simulation) for validating the software or system, including validation of tools used in those environments (see [SWE-073] - Platform or High-Fidelity Simulations)
  • Models, simulations, and/or analysis tools and associated validation planning ([SWE-070] - Models, Simulations, Tools, [SWE-135] - Static Analysis, [SWE-136] - Validation of Software Development Tools)
  • Identifying how the results will be documented and reported, when and to whom they will be reported ([SWE-031]- Validation Results)
  • Issue resolution (capture and tracking to closure) for issues or findings identified during validation activities (could be as simple as using the project configuration management process) (see [SWE-031] - Validation Results)
  • Identifying validation activities, as applicable, to occur during the various lifecycle phases
  • Re-validation plans to accommodate changes as the system is developed
  • Method for obtaining customer approval of the validation plan, if applicable

If not part of the team developing the validation plan, Software Assurance should be part of the plan's review team to ensure the plan meets all assurance requirements.

See also related requirements in this handbook:

?[SWE-031]

Validation results

[SWE-055]

Requirements validation

[SWE-102]

Software development/management plan

Unknown macro: {div3}

4. Small Projects

There is currently no guidance specific to small projects for this requirement.

Unknown macro: {div3}

5. Resources

  1. Software Management Plan / Product Plan (SMP/PP) For Class A, B & C Software (Verification and Validation section), 580-TM-033-02, GSFC
  2. IEEE Computer Society, "IEEE Standard for Software Verification and Validation", Chapter 7, IEEE STD 1012-2004, 2004.  This link requires an account on the NASA START (AGCY NTSS) system (http://standards.nasa.gov).  Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards.
  3. IEEE Computer Society, "IEEE Guide for Software Verification and Validation Plans", IEEE STD 1059-1993, 1993.  This link requires an account on the NASA START (AGCY NTSS) system (http://standards.nasa.gov).  Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards.
  4. How to Develop A Software Validation Plan, O'Keeffe, August 2010
  5. FSW Testbed Validation Description, 582-2008-006, Version 1, GSFC, 2008
  6. The CMMi easy button presentation of CMMi – Validation (VAL), Software Quality Assurance.org
  7. Reference Information for the Software Verification and Validation Process, NIST Special Publication 500-234, 1996
  8. Software Verification and Validation Plan (SVVP) Template (based on IEEE standards), Texas State University Computer Science Department, 2001

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table 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.

Tool nameTypeOwner/SourceLinkDescriptionUser

Simics 4.4

COTS

Wind River

http://www.windriver.com/products/simics/ ...

"Wind River Simics is a full system simulator used by software developers to simulate any target hardware from a single processor to large, complex, and connected electronic systems. This simulation enables the target software (board support package, firmware, real-time operating system, middleware, and application) to run on a virtual platform the same way it does on the physical hardware."

IV&V Centers ?, JSC

Unknown macro: {div3}

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.

  • No labels