Purpose:

Demonstrate that an acquired product r service fulfills its intended use when placed in its intended environment.

Objective:

Establishes organizational expectations to ensure that the products or services received from the supplier will fulfill the relevant stakeholders’ needs.

Description:

Validation demonstrates that the acquired product or service, as provided, fulfills its intended use. In other words, validation ensures that the acquired product or service meets stakeholders’ needs and customer requirements.

Validation activities are performed early (concept/explorations phases) and incrementally throughout the project lifecycle (including the transition to operations and sustainment). These activities can be applied to all aspects of the product and its components in any of their intended environments, such as operations, training, manufacturing, maintenance, and support services. (Throughout the process, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.)

The product or product components that are selected to be validated by the acquirer vary depending on project attributes. Methods used to conduct validation also can be applied to selected acquirer work products (e.g., customer requirements) and supplier deliverables (e.g., prototypes, simulations, demonstrations). Method selection is based on which methods
best predict how well the acquired product or service will satisfy stakeholder needs.

Whenever possible, validation should be conducted using the product or product component operating in its intended environment. Either the entire environment or part of it can be used.

When validation issues are identified, these issues are referred to processes associated with the Acquisition Requirements Development or Project Monitoring and Control process for resolution.

The specific practices of this process area build on each other in the following way:

• • The Select Products for Validation enables the identification of the product or product component to be validated and methods to be used to perform the validation.
  • Establishing the Validation Environment enables the determination of the environment to be used to carry out the validation.
  • The Establish Validation Procedures and Criteria 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 validation to be conducted according to methods, procedures, and criteria. The Analyze Validation Results specific practice enables the analysis of validation results against criteria.

Entrance Criteria:

• <?>

Exit Criteria:

• 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
• Validation environment
• Validation procedures
• Validation criteria
• Test and evaluation procedures for maintenance, training, and support
• Validation reports
• Validation results
• Validation cross reference matrix
• As-run procedures log
• Operational demonstrations
• Validation deficiency reports
• Validation issues
• Procedure change request

Process and Procedures:

• Prepare for Validation
• Validate Selected Products and Product Components

Tailoring Guidelines:

• None

Process Verification Record(s)

• Selecting the products and product components to be validated
  • Stored By: Quality Assurance Lead
• Establishing and maintaining validation methods, procedures, and criteria
  • Stored By: Quality Assurance Lead
• Validating products or product components
  • Stored By: Quality Assurance Lead
• Validation methods
  • Stored By: Quality Assurance Lead
• Validation procedures
  • Stored By: Quality Assurance Lead
• Validation criteria
  • Stored By: Quality Assurance Lead

Measure(s):

• Number of validation activities completed (planned versus actual)
  • Maintained By: Project Manager
  • Submitted By: Quality Assurance Lead
  • Frequency of Submission: Weekly

• Validation problem reports trends (e.g., number written, number closed)
  • Maintained By: Project Manager
  • Submitted By: Quality Assurance Lead
  • Frequency of Submission: Weekly
• Validation problem report aging (i.e., how long each problem report has been open)
  • Maintained By: Project Manager
  • Submitted By: Quality Assurance Lead
  • Frequency of Submission: Weekly

• Schedule for a specific validation activity
  • Maintained By: Project Manager
  • Submitted By: Quality Assurance Lead
  • Frequency of Submission: Weekly

References:

• CMMI^® for Development, Version 1.3, Software Engineering Process Management Program, November 2010
• CMMI^® for Acquisition, Version 1.3, Software Engineering Process Management Program, November 2010
• CMMI^® for Services, Version 1.3, Software Engineering Process Management Program, November 2010