CMMi - Validation (VAL)



Validation (VAL)
Process Areas
The CMMi easy button concept and disclaimer

Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.

The concept of The CMMi easy button is to be able to
jump start SQA software professionals in establishing an
effective Software process Improvement (SPI) framework that is based on CMMi theories and best practices.

CMMI, CMM, and Capability Maturity Model are registered
in the U.S. Patent and Trademark Office.
CMM Integration, SCAMPI, and IDEAL are service marks of
Carnegie Mellon University.
Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR)
Integrated Project Management +IPPD (IPM+IPPD) Measurement and Analysis (MA) Organizational Innovation and Deployment (OID)
Organizational Process Definition +IPPD (OPD+IPPD) Organizational Process Focus (OPF) Organizational Process Performance (OPP)
Organizational Training (OT) Product Integration (PI) Project Monitoring and Control (PMC)
Project Planning (PP) Process and Product Quality Assurance (PPQA) Quantitative Project Management (QPM)
Requirements Development (RD) Requirements Management (REQM) Risk Management (RSKM)
Supplier Agreement Management (SAM) Technical Solution (TS) Validation (VAL)
. Verification (VER) .
Validation (VAL) purpose and introductory notes
Specific Goals and Practices
Specific Goal 1 (SG 1) Prepare for Validation (SP 1.*)
SP 1.1 Select Products for Validation SP 1.2 Establish the Validation Environment SP 1.3 Establish Validation Procedures and Criteria .
Specific Goal 2 (SG 2) Satisfy Supplier Agreements (SP 2.*)
SP 2.1 Perform Validation SP 2.2 Analyze Validation Results . .
Generic Goals and Practices
Generic Goal 1 (GG 1) Achieve Specific Goals, Generic Practices (GP 1.*)
GP 1.1 Perform Specific Practices . . .
Generic Goal 2 (GG 2) Institutionalize a Managed Process, Generic Practices (GP 2.*)
GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility
GP 2.5 Train People GP 2.6 Manage Configurations GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management . .
Generic Goal 3 (GG 3) Institutionalize a Defined Process, Generic Practices (GP 3.*)
GP 3.1 Establish a Defined Process GP 3.2 Collect Improvement Information . .
Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process, Generic Practices (GP 4.*)
GP 4.1 Establish Quantitative Objectives for the Process GP 4.2 Stabilize Subprocess Performance . .
Generic Goal 5 (GG 5) Institutionalize an Optimizing Process, Generic Practices (GP 5.*)
GP 5.1 Ensure Continuous Process Improvement GP 5.2 Correct Root Causes of Problems . .

Validation in CMMi is a Software Quality Control (SQC) process that addresses the question:-

Are we building the correct product?

This question can be asked at any time during the SDLC but the essence of the question is, when this software product is placed in its proper environment does it fulfill the goals and needs of the end user, as expressed in the requirements.

Contrast this with Verification another SQC process that makes sure a given work product (which could be a design specification or software component) is written to a given standard or meets a particular specification.

For further information on Validation and the roles played by SQA and SQC with regard to this process area see Clarification of the definitions of SQA and SQC .



Validation (VAL)



An Engineering Process Area at Maturity Level 3

Purpose


The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Introductory Notes
Validation activities can be applied to all aspects of the product in any of its intended environments, such as operation, training, manufacturing, maintenance, and support services. The methods employed to accomplish validation can be applied to work products as well as to the product and product components. (Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.) The work products (e.g., requirements, designs, and prototypes) should be selected on the basis of which are the best predictors of how well the product and product component will satisfy user needs and thus validation is performed early and incrementally throughout the product lifecycle.

The validation environment should represent the intended environment for the product and product components as well as represent the intended environment suitable for validation activities with work products.

Validation demonstrates that the product, as provided, will fulfill its intended use; whereas, verification addresses whether the work product properly reflects the specified requirements. In other words, verification ensures that “you built it right”; whereas, validation ensures that “you built the right thing.” Validation activities use approaches similar to verification (e.g., test, analysis, inspection, demonstration, or simulation). Often, the end users and other relevant stakeholders are involved in the validation activities. Both validation and verification activities often run concurrently and may use portions of the same environment.

Refer to the Verification process area for more information about verification activities.

Whenever possible, validation should be accomplished using the product or product component operating in its intended environment. The entire environment can be used or only part of it. However, validation issues can be discovered early in the life of the project using work products by involving relevant stakeholders. Validation activities for services can be applied to work products such as proposals, service catalogs, statements of work, and service records.

When validation issues are identified, they are referred to the processes associated with the Requirements Development, Technical Solution, or Project Monitoring and Control process areas for resolution.



The specific practices of this process area build on each other in the following way:
  • The Select Products for Validation specific practice enables the identification of the product or product component to be validated and the methods to be used to perform the validation.
  • The Establish the Validation Environment specific practice enables the determination of the environment that will be used to carry out the validation.
  • The Establish Validation Procedures and Criteria specific practice enables the development of validation procedures and criteria that are aligned with the characteristics of selected products, customer constraints on validation, methods, and the validation environment.
  • The Perform Validation specific practice enables the performance of validation according to the methods, procedures, and criteria.
Related Process Areas.

Refer to the Requirements Development process area for more information about requirements validation.

Refer to the Technical Solution process area for more information about transforming requirements into product specifications and for corrective action when validation issues are identified that affect the product or product component design.

Refer to the Verification process area for more information about verifying that the product or product component meets its requirements.

Specific Practices by Goal

SG 1 Prepare for Validation

Preparation for validation is conducted.

Preparation activities include selecting products and product components for validation and establishing and maintaining the validation environment, procedures, and criteria. The items selected for validation may include only the product or it may include appropriate levels of the product components that are used to build the product. Any product or product component may be subject to validation, including replacement, maintenance, and training products, to name a few.

The environment required to validate the product or product component is prepared. The environment may be purchased or may be specified, designed, and built. The environments used for product integration and verification may be considered in collaboration with the validation environment to reduce cost and improve efficiency or productivity.

SP 1.1 Select Products for Validation

Select products and product components to be validated and the validation methods that will be used for each.

Products and product components are selected for validation on the basis of their relationship to user needs. For each product component, the scope of the validation (e.g., operational behavior, maintenance, training, and user interface) should be determined.

Examples of products and product components that can be validated include the following:
  • Product and product component requirements and designs
  • Product and product components (e.g., system, hardware units, software, and service documentation)
  • User interfaces
  • User manuals
  • Training materials
  • Process documentation
The requirements and constraints for performing validation are collected. Then, validation methods are selected based on their ability to demonstrate that user needs are satisfied. The validation methods not only define the approach to product validation, but also drive the needs for the facilities, equipment, and environments. This may result in the generation of lower level product component requirements that are handled by the requirements development processes. Derived requirements, such as interface requirements to test sets and test equipment, can be generated. These requirements are also passed to the requirements development processes to ensure that the product or product components can be validated in an environment that supports the methods.

Validation methods should be selected early in the life of the project so that they are clearly understood and agreed to by the relevant stakeholders.

The validation methods address the development, maintenance, support, and training for the product or product component as appropriate.

Examples of validation methods include the following:
  • Discussions with the users, perhaps in the context of a formal review
  • Prototype demonstrations
  • Functional demonstrations (e.g., system, hardware units, software, service documentation, and user interfaces)
  • Pilots of training materials
  • Analyses of product and product components (e.g., simulations, modeling, and user analyses)
For Hardware Engineering

Hardware validation activities include modeling to validate form, fit, and function of mechanical designs; thermal modeling; maintainability and reliability analysis; timeline demonstrations; and electrical design simulations of electronic or mechanical product components.

Typical Work Products
  • Lists of products and product components selected for validation
  • Validation methods for each product or product component
  • Requirements for performing validation for each product or product component
  • Validation constraints for each product or product component
Subpractice 1: Identify the key principles, features, and phases for product or product component validation throughout the life of the project.

Subpractice 2: Determine which categories of user needs (operational, maintenance, training, or support) are to be validated.

The product or product component must be maintainable and supportable in its intended operational environment. This specific practice also addresses the actual maintenance, training, and support services that may be delivered along with the product.

An example of evaluation of maintenance concepts in the operational environment is a demonstration that maintenance tools are operating with the actual product.

Subpractice 3: Select the product and product components to be validated.

Subpractice 4: Select the evaluation methods for product or product component validation.

Subpractice 5: Review the validation selection, constraints, and methods with relevant stakeholders.

SP 1.2 Establish the Validation Environment

Establish and maintain the environment needed to support validation.

The requirements for the validation environment are driven by the product or product components selected, by the type of the work products (e.g., design, prototype, and final version), and by the methods of validation. These may yield requirements for the purchase or development of equipment, software, or other resources. These requirements are provided to the requirements development processes for development. The validation environment may include the reuse of existing resources. In this case, arrangements for the use of these resources must be made. Examples of the type of elements in a validation environment include the following:
  • Test tools interfaced with the product being validated (e.g., scope, electronic devices, and probes)
  • Temporary embedded test software
  • Recording tools for dump or further analysis and replay
  • Simulated subsystems or components (by software, electronics, or mechanics)
  • Simulated interfaced systems (e.g., a dummy warship for testing a naval radar)
  • Real interfaced systems (e.g., aircraft for testing a radar with trajectory tracking facilities)
  • Facilities and customer-supplied products
  • The skilled people to operate or use all the preceding elements
  • Dedicated computing or network test environment (e.g., pseudo-operational telecommunications-network testbed or facility with actual trunks, switches, and systems established for realistic integration and validation trials)
Early selection of the products or product components to be validated, the work products to be used in the validation, and the validation methods is needed to ensure that the validation environment will be available when necessary.

The validation environment should be carefully controlled to provide for replication, analysis of results, and revalidation of problem areas.

Typical Work Products
  • Validation environment
Subpractice 1: Identify validation environment requirements.

Subpractice 2: Identify customer-supplied products.

Subpractice 3: Identify reuse items.

Subpractice 4: Identify test equipment and tools.

Subpractice 5: Identify validation resources that are available for reuse and modification.

Subpractice 6: Plan the availability of resources in detail.

SP 1.3 Establish Validation Procedures and Criteria

Establish and maintain procedures and criteria for validation.

Validation procedures and criteria are defined to ensure that the product or product component will fulfill its intended use when placed in its intended environment. Acceptance test cases and procedures may meet the need for validation procedures.

The validation procedures and criteria include test and evaluation of maintenance, training, and support services.

Examples of sources for validation criteria include the following:
  • Product and product component requirements
  • Standards
  • Customer acceptance criteria
  • Environmental performance
  • Thresholds of performance deviation
Typical Work Products
  • Validation procedures
  • Validation criteria
  • Test and evaluation procedures for maintenance, training, and support
Subpractice 1: Review the product requirements to ensure that issues affecting validation of the product or product component are identified and resolved.

Subpractice 2: Document the environment, operational scenario, procedures, inputs, outputs, and criteria for the validation of the selected product or product component.

Subpractice 3: Assess the design as it matures in the context of the validation environment to identify validation issues.

SG 2 Validate Product or Product Components

The product or product components are validated to ensure that they are suitable for use in their intended operating environment.

The validation methods, procedures, and criteria are used to validate the selected products and product components and any associated maintenance, training, and support services using the appropriate validation environment. Validation activities are performed throughout the product lifecycle.

SP 2.1 Perform Validation

Perform validation on the selected products and product components.

To be acceptable to users, a product or product component must perform as expected in its intended operational environment.

Validation activities are performed and the resulting data are collected according to the established methods, procedures, and criteria.

The as-run validation procedures should be documented and the deviations occurring during the execution should be noted, as appropriate.

Typical Work Products
  • Validation reports
  • Validation results
  • Validation cross-reference matrix
  • As-run procedures log
  • Operational demonstrations
SP 2.2 Analyze Validation Results

Analyze the results of the validation activities.

The data resulting from validation tests, inspections, demonstrations, or evaluations are analyzed against the defined validation criteria. Analysis reports indicate whether the needs were met; in the case of deficiencies, these reports document the degree of success or failure and categorize probable cause of failure. The collected test, inspection, or review results are compared with established evaluation criteria to determine whether to proceed or to address requirements or design issues in the requirements development or technical solution processes.

Analysis reports or as-run validation documentation may also indicate that bad test results are due to a validation procedure problem or a validation environment problem.

Typical Work Products
  • Validation deficiency reports
  • Validation issues
  • Procedure change request
Subpractice 1: Compare actual results to expected results.

Subpractice 2: Based on the established validation criteria, identify products and product components that do not perform suitably in their intended operating environments, or identify problems with the methods, criteria, and/or environment.

Subpractice 3: Analyze the validation data for defects.

Subpractice 4: Record the results of the analysis and identify issues.

Subpractice 5: Use validation results to compare actual measurements and performance to intended use or operational need.

Generic Practices by Goal

GG 1 Achieve Specific Goals

The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.

GP 1.1 Perform Specific Practices

Perform the specific practices of the validation process to develop work products and provide services to achieve the specific goals of the process area.

GG 2 Institutionalize a Managed Process

The process is institutionalized as a managed process.

GP 2.1 Establish an Organizational Policy

Establish and maintain an organizational policy for planning and performing the validation process.

Elaboration:

This policy establishes organizational expectations for selecting products and product components for validation; for selecting validation methods; and for establishing and maintaining validation procedures, criteria, and environments that ensure the products and product components satisfy user needs in their intended operating environment.

GP 2.2 Plan the Process

Establish and maintain the plan for performing the validation process.

Elaboration:

This plan for performing the validation process can be included in (or referenced by) the project plan, which is described in the Project Planning process area.

GP 2.3 Provide Resources

Provide adequate resources for performing the validation process, developing the work products, and providing the services of the process.

Elaboration:

Special facilities may be required for validating the product or product components. When necessary, the facilities required for validation are developed or purchased.

Examples of other resources provided include the following tools:
  • Test-management tools
  • Test-case generators
  • Test-coverage analyzers
  • Simulators
  • Load, stress, and performance tools
GP 2.4 Assign Responsibility

Assign responsibility and authority for performing the process, developing the work products, and providing the services of the validation process.

GP 2.5 Train People

Train the people performing or supporting the validation process as needed.

Elaboration:

Examples of training topics include the following:
  • Application domain
  • Validation principles, standards, and methods
  • Intended-use environment
GP 2.6 Manage Configurations

Place designated work products of the validation process under appropriate levels of control.

Elaboration:

Examples of work products placed under control include the following:
  • Lists of products and product components selected for validation
  • Validation methods, procedures, and criteria
  • Validation reports
GP 2.7 Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of the validation process as planned.

Elaboration:

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process.

Examples of activities for stakeholder involvement include the following:
  • Selecting the products and product components to be validated
  • Establishing the validation methods, procedures, and criteria
  • Reviewing results of product and product component validation and resolving issues
  • Resolving issues with the customers or end users
Issues with the customers or end users are resolved particularly when there are significant deviations from their baseline needs for the following:
  • Waivers on the contract or agreement (what, when, and for which products)
  • Additional in-depth studies, trials, tests, or evaluations
  • Possible changes in the contracts or agreements
GP 2.8 Monitor and Control the Process

Monitor and control the validation process against the plan for performing the process and take appropriate corrective action.

Elaboration:

Examples of measures and work products used in monitoring and controlling include the following:
  • Number of validation activities completed (planned versus actual)
  • Validation problem report trends (e.g., number written and number closed)
  • Validation problem report aging (i.e., how long each problem report has been open)
  • Schedule for a specific validation activity
GP 2.9 Objectively Evaluate Adherence

Objectively evaluate adherence of the validation process against its process description, standards, and procedures, and address noncompliance.

Elaboration:



Examples of activities reviewed include the following:
  • Selecting the products and product components to be validated
  • Establishing and maintaining validation methods, procedures, and criteria
  • Validating products or product components
Examples of work products reviewed include the following:
  • Validation methods, procedures, and criteria
GP 2.10 Review Status with Higher Level Management

Review the activities, status, and results of the validation process with higher level management and resolve issues.

GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

GP 3.1 Establish a Defined Process

Establish and maintain the description of a defined validation process.

GP 3.2 Collect Improvement Information

Collect work products, measures, measurement results, and improvement information derived from planning and performing the validation process to support the future use and improvement of the organization’s processes and process assets.

Elaboration:

Examples of work products, measures, measurement results, and improvement information include the following:
  • Product component prototype
  • Percent of time the validation environment is available
  • Number of product defects found through validation per development phase
  • Validation analysis report
GG 4 Institutionalize a Quantitatively Managed Process

The process is institutionalized as a quantitatively managed process.

GP 4.1 Establish Quantitative Objectives for the Process

Establish and maintain quantitative objectives for the validation process, which address quality and process performance, based on customer needs and business objectives.

GP 4.2 Stabilize Subprocess Performance

Stabilize the performance of one or more subprocesses to determine the ability of the validation process to achieve the established quantitative quality and process-performance objectives.

GG 5 Institutionalize an Optimizing Process

The process is institutionalized as an optimizing process.

GP 5.1 Ensure Continuous Process Improvement

Ensure continuous improvement of the validation process in fulfilling the relevant business objectives of the organization.

GP 5.2 Correct Root Causes of Problems

Identify and correct the root causes of defects and other problems in the validation process.


Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi and Software Quality Assurance. No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-