bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

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


{alias:SWE-029} {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.4.2

The

project

shall

plan

the

software

validation

activities,

methods,

environments,

and

criteria

for

the

project.

h2.

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

(Chapter 5 [of NPR

7150.2,

Chapter 5) \[detailed in [SWE-102|SWE-102] in this handbook\]. h2. 1.2 Applicability Across Classes Class D non-Safety Critical and Class G are labeled with

NASA Software Engineering Requirements, section 5.1.1]) [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

an

approved

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=1|dnsc=p|esc=1|ensc=0|f=1|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Planning is appropriate for any activity that is to be repeated, that needs to be verified before use, and that requires thought before implementation. Planning the validation activity allows the project team to put more thought into tasks, methods, environments, and related criteria before they are implemented. The identification of validation resources such as validation environments allow them to be developed before they are needed. 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 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. {div3} {div3:id=tabs-3} h1. 3. Guidance Validation includes establishing roles, responsibility, and authority to plan, perform, analyze, and report validation activities.     This is often necessary when some or all of the software development is performed under contract.     It is also important when the validation environment is a service performed by another organization (e.g., high-fidelity simulators or system integration labs). The basic validation process is shown below with the steps addressed by this requirement highlighted: !SWE-029_Validation_Process.jpg|border=0! Validation activities are not performed in an ad hoc manner, but are 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 covers the validation activities that will occur at various times in the development life cycle 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 the behavior of software components under both nominal and exception scenarios.  For example, a peer review or inspection could trace the execution path through the code under representative scenarios. * 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 reviews the plan and validation results at various life cycle reviews, particularly whenever changes occur throughout the duration of the project. Any identified issues are captured in problem reports / change requests / action items and resolved before the requirements are used as the basis for development activities. Validation is often on the critical path to project completion. Validation activities, therefore, need to be planned and tracked in order to realistically assess progress toward completion. The validation plan will address more than just validation of software requirements. It includes a schedule, stakeholder involvement, and planned reviews, if they 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|SWE-102]) * Identification of work products to be validated ([SWE-102|SWE-102]) * Identification of where validation records and corrective actions will be captured ([SWE-102|SWE-102]) The Scope and Approach sections of the plan 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 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|SWE-055]\-Requirements Validation) * {term:COTS}, {term:GOTS}, {term:MOTS}affects on the project and associated validation planning ([SWE-027|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|SWE-073] \- Platform or High-Fidelity Simulations) * Models, simulations, and/or analysis tools and associated validation planning ([SWE-070|SWE-070] \- Models, Simulations, Tools, [SWE-135|SWE-135] \- Static Analysis, [SWE-136|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|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|SWE-031] \- Validation Results) * Identifying validation activities, as applicable, to occur during the various life cycle 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 needs to 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|SWE-031]* | Validation results | | *[SWE-055|SWE-055]* | Requirements validation | | *[SWE-102|SWE-102]* | Software development/management plan | {div3} {div3:id=tabs-4} h1. 4. Small Projects There is currently no guidance specific to small projects for this requirement. {div3} {div3:id=tabs-5} h1. 5. Resources {refstable} {toolstable} {div3} {div3:id=tabs-6} h1. 6. Lessons Learned There are currently no Lessons Learned identified for this requirement.{div3} {tabclose}

 


applicable
f1
gp
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnscp
dsc1
ensc0



Div
idtabs-2

2. Rationale

Planning is appropriate for any activity that is to be repeated, that needs to be verified before use, and that requires thought before implementation. Planning the validation activity allows the project team to put more thought into tasks, methods, environments, and related criteria before they are implemented. The identification of validation resources such as validation environments allow them to be developed before they are needed. 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 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.


Div
idtabs-3

3. Guidance

Validation includes establishing roles, responsibility, and authority to plan, perform, analyze, and report validation activities. This is often necessary when some or all of the software development is performed under contract. It is also important when the validation environment is a service performed by another organization (e.g., high-fidelity simulators or system integration labs).

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

Image Added

                             Figure 3.1. Validation Process With Planning Steps Highlighted

Validation activities are not performed in an ad hoc manner, but are 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 covers the validation activities that will occur at various times in the development life cycle 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 the behavior of software components under both nominal and exception scenarios. For example, a peer review or inspection could trace the execution path through the code under representative scenarios.
  • 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 reviews the plan and validation results at various life cycle reviews, particularly whenever changes occur throughout the duration of the project. Any identified issues are captured in problem reports/change requests/action items and resolved before the requirements are used as the basis for development activities.

Validation is often on the critical path to project completion. Validation activities, therefore, need to be planned and tracked in order to realistically assess progress toward completion. The validation plan will address more than just validation of software requirements. It includes a schedule, stakeholder involvement, and planned reviews, if they 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 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 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 (Commercial Off the Shelf), GOTS (Government Off the Shelf), MOTS (Modified Off the Shelf) 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 life cycle 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 needs to be part of the plan's review team to ensure the plan meets all assurance requirements.

Additional guidance related to validation planning may be found in the following related requirements in this Handbook:


SWE-031

Validation Results

SWE-055

Requirements Validation

SWE-102

Software Development/Management Plan



Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.