Difference between revisions of "System Verification"

From SEBoK
Jump to navigation Jump to search
Line 137: Line 137:
 
'''Table 4. Verification and Validation Techniques.'''
 
'''Table 4. Verification and Validation Techniques.'''
  
====Validation/ Traceability Matrix====
+
====Validation/Traceability Matrix====
 
 
The [[System Definition]] KA introduced the Traceability Matrix. It may also be extended and used to record data such as the Verification and Validation Actions list, the selected Verification / validation Technique to verify / validate the implementation of every engineering element (in particular Stakeholder and System Requirement), the expected results, the obtained results when the Verification and Validation Action has been performed. The use of such a matrix enables the development team to ensure that the selected Stakeholder and System Requirements have been verified, or to evaluate the percentage of Verification and Validation Actions completed.
 
 
 
  
 +
The [[System Definition]] Knowledge Area introduced the traceability matrix. It may also be extended and used to record data, such as the verification and validation actions list, the selected verification/validation technique to verify/validate the implementation of every engineering element (in particular stakeholder and System requirements), the expected results, and the obtained results when the verification and validation action has been performed. The use of such a matrix enables the development team to ensure that the selected stakeholder and system requirements have been verified or to evaluate the percentage of verification and validation actions completed.
  
 
==Practical Considerations==
 
==Practical Considerations==

Revision as of 08:56, 14 September 2011

verification is a set of actions used to check the correctness of any element such as a system element, a system, a document, a service, a task, a requirement, etc. validation is a set of actions used to check the compliance of these elements to their purpose.

Overview

The verification process is performed on an iterative basis on every produced engineering element throughout the life cycle.

The validation process generally occurs at the end of a set of life cycle tasks or activities and at least at the end of every milestone of a development project. The validation process applied onto the system when completely integrated is often called final validation (see Figure 1 in System Integration).

  • The purpose of verification is to show that the element meets the requirements.
  • The purpose of validation is to show that the requirements were correct.

Validation is used to ensure that “one is working the right problem” whereas verification is used to ensure that “one has solved the problem right” (Martin 1997).

Multiple definitions are shown in the glossary entry for verification and validation (V&V).

Principles

Concept of Verification and Validation Action

The verification and validation action is sketched in Figure 1:

SEBoKv05 KA-SystRealiz Definition & performance of V&V Action.png

Figure 1. Definition and Performance of a Verification and Validation Action (Faisandier 2011).

  • What to verify and validate? – Any engineering element can be verified and validated using a specific reference for comparison: stakeholder requirement, system requirement, function, system element, document, etc. Examples are provided in Table 1 below:
SEBoKv05 KA-SystRealiz V&V Examples.png

Table 1. Examples of Verified and Validated Items.

Integration, Verification, Validation, Final Validation, Operational Validation

Verification activities begin during development (definition and realization) and continue into deployment and use.


Once the system elements have been realized, they begin integration into the complete system, and this integration includes verification and validation activities as stated in System Integration. These activities are done in parallel, thus reducing the tasks at final validation.


System validation concerns the global system (product, service, or enterprise) seen as a whole and is based on the totality of the requirements (system requirements, stakeholder requirements). Three methods are used:

  1. The V&V results are aggregated from the application of the verification process and the validation process to every definition element and to every integration element.
  2. Final validation is performed for the complete integrated system in an industrial environment (as close as possible to the operational environment).
  3. Operational validation is performed on the complete system in its operational environment (context of use - higher level of system).


Operational Validation relates to the operational mission of the system and shows if the system is ready for use or for production.


Verification and validation occur at each stage of the development of a system, as shown in Figure 2:

Verification and Validation Level by Level

Figure 2. Verification and Validation Level per Level (Faisandier & Roussel, 2011).

Verification Actions and Validation Actions Inside and Across Levels

Inside each level of system decomposition, V&V actions are performed during system definition and system realization as represented in Figure 3 for the upper levels and in Figure 4 for lower levels. The stakeholder requirements definition and the operational validation make the link between two levels of the system decomposition.

Verification and Validation Actions in Upper Levels of System Decomposition

Figure 3. Verification and Validation Actions in Upper Levels of System Decomposition (Faisandier 2011).


The system elements requirements and the end product's operational validation make the link between the two lower levels of the decomposition, see Figure 4 below:

Verification and Validation Actions in Lower Levels of System Decomposition

Figure 4. Verification and Validation Actions in Lower Levels of System Decomposition (Faisandier 2011).

Process Approach

Introduction

Several approaches exist for defining the verification and validation Processes. INCOSE defines two main steps: plan and perform the verification Actions (INCOSE 2010).

NASA has a slightly more detailed approach that includes five main steps: prepare verification, perform verification, analyze outcomes, produce report, and capture work products (NASA 2007, 102).

Any approach may be used, provided that it is appropriate to the scope of the system, the constraints of the project, includes the activities listed above in some way, and is appropriately coordinated with other activities (including system definition, system realization, and extension to the rest of the life cycle).

Verification Process

Major activities and tasks performed during this process include:

  1. Establish a verification strategy drafted in a verification and validation plan (glossary) (this activity is carried out concurrently to system definition activities) obtained by the following tasks:
    1. Identify the verification scope by listing as exhaustively as possible the characteristics or properties that should be checked. The number of verification and validation actions can be very high.
    2. Identify the constraints according to their origin (e.g., technical feasibility, management constraints as cost, time, availability of verification and validation means or qualified personnel, contractual constraints as criticality of the mission) that potentially limit the verification and validation actions.
    3. Define the appropriate verification and validation techniques to be applied, such as inspection, analysis, simulation, peer-review, testing, etc. depending on the best step of the project to perform every verification and validation action according to constraints.
    4. Trade off of what should be verified (scope) taking into account all the constraints or limits and deduce what can be verified. The selection of verification and validation actions should be made according to the type of system, objectives of the project, importance of the requirement, acceptable risks, and constraints.
    5. Develop the verification and validation strategy by defining the most appropriate verification technique for every verification and validation action, defining the necessary verification and validation means (tools, test-benches, personnel, location, facilities) according to the selected verification technique, scheduling the verification and validation actions execution in the project steps or milestones, and defining the configuration of the elements submitted to verification and validation actions (mainly about testing on physical elements).
  2. Performance of the verification and validation actions includes the following tasks:
    1. Detail each verification and validation action, in particular the expected results, the verification technique to be applied, and the corresponding means (equipment, resources, and qualified personnel).
    2. Acquire the verification and validation means used during the system definition steps (qualified personnel, modeling tools, mocks-up, simulators, facilities). Then acquire the verification and validation means during the integration step (qualified personnel, verification and validation tools, measuring equipments, facilities, verification and validation Procedures, etc.).
    3. Carry out the verification and validation procedures at the right time, in the expected environment, with the expected means, tools, and techniques.
    4. Capture and record the results obtained when performing the verification and validation actions using verification and validation procedures and means.
  3. Analyze obtained results and compare them to the expected results, record the status as compliant or not, generate verification reports and potential issue/trouble reports, and change requests on the design as necessary.
  4. Controlling the process includes the following tasks:
    1. Update the verification and validation plan according to the progress of the project. In particular, the planned verification and validation actions can be redefined because of unexpected events (addition, deletion, or modification of actions).
    2. Coordinate the verification activities with the project manager for schedule, acquisition of means, and review of personnel and resources, as well as with the designers for issues/trouble/non-conformance reports and with configuration managers for versions of physical elements, design baselines, etc.

Validation Process

Major activities and tasks performed during this process include:

  1. Establish a validation strategy in a verification and validation plan (this activity is carried out concurrently to system definition activities) including the following tasks:
    1. Identify the validation scope that is represented by the system and/or stakeholder requirements; normally, every requirement should be checked as the number of verification and validation actions can be high.
    2. Identify the constraints according to their origin: (same as verification process above).
    3. Define the appropriate verification/validation techniques to be applied: (same as verification process above).
    4. Trade off of what should be validated (scope): (same as verification process above).
    5. Optimize the verification and validation strategy: (same as verification process above).
  2. Performance of the verification and validation actions includes the following tasks: (same as verification process above).
  3. Analyze obtained results and compare them to the expected results. Decide about the acceptability of the conformance/compliance, record the decision and the status as compliant or not, generate validation reports and potential issue/trouble reports, and change requests on the system or stakeholder requirements as necessary.
  4. Control the process includes the following tasks: (same as verification process above).

Artifacts and Ontology Elements

These processes may create several artifacts such as:

  1. Verification and validation plan (contains in particular the verification and validation strategy with objectives, constraints, the list of the selected verification and validation Actions, etc.)
  2. Verification and validation matrix (contains for each verification and validation action, the submitted element, the applied technique/method, the step of execution, the system block concerned, the expected result, the obtained result, etc.)
  3. Verification and validation procedures (describe the verification and validation actions to be performed, the verification and validation tools needed, the verification and validation configuration, resources, personnel, schedule, etc.)
  4. Verification and validation reports
  5. Verification and validation tools
  6. Verified and validated element (system, system element, etc.)
  7. Issue / Non Conformance / Trouble Reports
  8. Change requests on requirement, product, service, enterprise


These processes handle the ontology elements of Table 3.


Main Ontology Elements as Handled within Verification and Validation

Table 3. Main Ontology Elements As Handled Within Verification and Validation.


The main relationships between ontology elements are presented in Figure 5.

Verification and Validation Elements Relationships with other Engineering Elements

Figure 5. Verification and Validation Elements Relationships with other Engineering Elements (Faisandier 2011).


Note: "Design Reference" is a generic term; instances depend of the type of submitted engineering elements, for example: specified requirements, description of design characteristics or properties, drafting rules, standards, regulations, etc.

Methods and Techniques

Verification and Validation techniques

There are several verification and validation techniques/methods to check that an element or a system complies to its system's and/or stakeholder's requirements. These techniques are common to verification and validation. The purposes are different; verification is used to detect faults/defects, whereas validation is used to prove the satisfaction of a system's and/or stakeholder's requirements. Table 4 below provides synthetic descriptions of some techniques.

Verification Techniques and Types of System

Table 4. Verification and Validation Techniques.

Validation/Traceability Matrix

The System Definition Knowledge Area introduced the traceability matrix. It may also be extended and used to record data, such as the verification and validation actions list, the selected verification/validation technique to verify/validate the implementation of every engineering element (in particular stakeholder and System requirements), the expected results, and the obtained results when the verification and validation action has been performed. The use of such a matrix enables the development team to ensure that the selected stakeholder and system requirements have been verified or to evaluate the percentage of verification and validation actions completed.

Practical Considerations

Major pitfalls encountered with System Verification and Validation are presented in Table 6.

Major Pitfalls with System Verification and Validation

Table 6 – Major pitfalls with System Verification and Validation

Major proven practices encountered with System Verification and Validation are presented in Table 7.

Proven Practices with System Verification and Validation

Table 7 – Proven practices with System Verification and Validation.

A good survey with examples of famous failures is found in (Bahill and Henderson 2005).

References

Citations

Bahill, A.T. and S.J. Henderson. 2005. "Requirements Development, Verification, and Validation Exhibited in Famous Failures." Systems Engineering 8(1): 1-14.

Buede, D.M. 2009. The Engineering Design of Systems: Models and Methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

INCOSE. 2011. INCOSE Systems Engineering Handbook. Version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008 (E).

NASA. 2007. Systems Engineering Handbook. Washington, DC, USA: National Aeronautics and Space Administration (NASA), December 2007. NASA/SP-2007-6105.

Primary References

INCOSE. 2011. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).

NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), December 2007. NASA/SP-2007-6105.

Additional References

Bahill, A.T. and S.J. Henderson. 2005. "Requirements Development, Verification, and Validation Exhibited in Famous Failures." Systems Engineering 8(1): 1-14.

Buede, D.M. 2009. The Engineering Design of Systems: Models and Methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.

ECSS. 2009. Systems Engineering General Requirements. Noordwijk, Netherlands: Requirements and Standards Division, European Cooperation for Space Standardization (ECSS), 6 March 2009. ECSS-E-ST-10C.

SAE International. 1996. Certification Considerations for Highly-Integrated or Complex Aircraft Systems. Warrendale, PA, USA: SAE International, ARP475.

SEI. 2007. "Measurement and Analysis Process Area" in Capability Maturity Model Integrated (CMMI) for Development, version 1.2. Pittsburg, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).


Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Dholwell 19:34, 6 September 2011 (UTC) core edit