|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)|
|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 .
An Engineering Process Area at Maturity Level 3
The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.
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:
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:
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:
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
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:
The validation environment should be carefully controlled to provide for replication, analysis of results, and revalidation of problem areas.
Typical Work Products
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:
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
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
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.
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.
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.
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:
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.
Examples of training topics include the following:
Place designated work products of the validation process under appropriate levels of control.
Examples of work products placed under control include the following:
Identify and involve the relevant stakeholders of the validation process as planned.
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:
Monitor and control the validation process against the plan for performing the process and take appropriate corrective action.
Examples of measures and work products used in monitoring and controlling include the following:
Objectively evaluate adherence of the validation process against its process description, standards, and procedures, and address noncompliance.
Examples of activities reviewed include the following:
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.
Examples of work products, measures, measurement results, and improvement information include the following:
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:-