Technical
This topic contains technical questions and answers about CMMI models.
Contents:
- What is bidirectional traceability?
- In Organizational Process Performance (OPP), why are process performance baselines and process performance models important?
- Where in a CMMI model is senior management commitment obtained?
- Where is system testing covered in CMMI for Development?
- Where are CM and QA plans covered in CMMI models?
- Is an independent quality assurance group required?
- Does Validation apply to intermediate work products?
- When does Validation (VAL) occur in the product development lifecycle?
- What is the difference between Verification and Validation?
- Can cross-PA processes satisfy generic practice 3.2, Collect Improvement Information?
- What does generic practice 2.2, Plan the Process, require and how does it relate to planning and strategy specific practices?
- When using a CMMI model for process improvement, is the use of functional analysis problematic for an object oriented approach?
- Where in CMMI are documented procedures addressed?
What is bidirectional traceability?
In the Requirements Management (REQM) process area, specific practice 1.4 states, "Maintain bidirectional traceability among the requirements and work products." Bidirectional traceability is the ability to trace both forward and backward (i.e., from requirements to end products and from end product back to requirements).
Typically, traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, bidirectional traceability is achieved from the source requirements to lower-level requirements and selected work products and verifications and then back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements and selected work products can be traced to a valid source.
return to top
In Organizational Process Performance (OPP), why are process performance baselines and process performance models important?
Process performance baselines and models (OPP specific practice1.4, "Establish and maintain the organization's process-performance baselines." and specific practice 1.5, "Establish and maintain the process-performance models for the organization's set of standard processes.") summarize the historical performance of selected processes (or subprocesses). Process performance baselines are often represented as statistical summaries (e.g., mean and variation) of how a process or subprocess has performed across the organization (appropriately normalized, e.g., for work product or task size). Process performance models are often represented as predictive models (e.g. Regression, Correlation, Analysis of Variance, Chi-Square Analysis, Logistic Regression, Discrete Event, and Monte Carlo simulation modeling) that indicate the statistical relationship among measures of selected process or work product attributes from different lifecycle phases.
Both process performance models and baselines are used in project planning to assess the impact of including certain processes and subprocesses in the project's defined process (QPM specific practice 1.2, "Select the subprocesses that compose the project's defined process based on historical stability and capability data." and specific practice 1.3, "Select the subprocesses of the project's defined process that will be statistically managed.") on the achievement of the project's quality and process performance objectives.
Process performance models are used during project execution to estimate and predict the value of process performance measures in later lifecycle phases of the project from other measures now available. They are used both at the beginning of the project and regularly thereafter to determine whether the project is on track (QPM specific practice 1.4, "Monitor the project to determine whether the project's objectives for quality and process performance will be satisfied, and identify corrective action as appropriate.") to achieve its quality and process performance objectives (QPM specific practice 1.1, "Establish and maintain the project's quality and process-performance objectives.").
Process performance baselines and models are important to achieving CL and ML 4 because they, together with quantitative objectives for quality and process performance and statistical management of selected subprocesses, are important to quantitatively managing project performance.
Process performance baselines and models support the OID process area in terms of identifying and understanding innovative approaches and the relationship to the current organizational performance.
return to topWhere in a CMMI model is senior management commitment obtained?
Senior management review is covered in generic practice 2.10, "Review the activities, status, and results of the process with higher level management and resolve issues." The first section within Part Two of the model provides a description of the generic practice that says
return to topThe purpose of this generic practice is to provide higher level management with the appropriate visibility into the process.
Where is system testing covered in CMMI for Development?
Examples of system testing are provided in SP 1.1 of the Verification process area and SP 1.1 of the Validation process area. However, system testing is not a term used in CMMI, since the terms "system" and "testing" can be interpreted in many ways.
The term "system" was not used in CMMI because of its multiple interpretations across disciplines. Instead of "system," the term "product" and "product component" were used for consistency and clarity. The terms "verification" or "validation" were used instead of "testing" since (1) testing can be either part of verification or validation, and (2) testing is only one method used for verification or validation.
So, to find information on system testing, look instead for "product verification," "product validation," "product component verification," or "product component validation."
return to topWhere are CM and QA plans covered in CMMI models?
Configuration management and quality assurance plans are not explicitly addressed in CMMI specific practices. Instead, generic practice 2.2, "Establish and maintain the plan for performing the process," covers the activities expected in a configuration management and quality assurance plan. These may be separate plans, or part of a more inclusive plan that meets organizational needs.
return to topIs an independent quality assurance group required?
Independence is not required; however, objectivity is required. For a more detailed explanation, see the Introductory Notes of the Process and Product Quality Assurance process area.
return to topDoes Validation apply to intermediate work products?
The Validation process area applies to both the finished product and intermediate work products.
The focus of validation is whether the product or product component, as provided (or as it will be provided), will fulfill its intended use in its operational environment. In many cases, validation of product components will occur on intermediate work products early in the lifecycle to ensure that the product meets its intended use. In rare cases acceptance testing may be an adequate implementation of this process. Also see the When does Validation (VAL) occur in the product development lifecycle? FAQ for more information.
return to topWhen does Validation (VAL) occur in the product development lifecycle?
The focus of validation is whether the product or product component, as provided (or as it will be provided), will fulfill its intended use in its operational environment. In many cases, the validation of product components will occur on intermediate work products early in the lifecycle to ensure that the product meets its intended use.
The following are examples of validation on products and work products throughout the product lifecycle:
- Validation begins early in the lifecycle with validation of requirements in specific goal 3 of Requirements Development.
- Prototypes are often developed and used to test design concepts and to confirm with end users that the product works as expected.
- Acceptance testing is used near the end of the lifecycle to ensure the product meets its intended use.
- Independent verification and validation (IV&V) also is employed near the end of the lifecycle to ensure the product meets its intended use in its intended environment. This environment may be simulated if the actual environment is not available.
In rare cases, acceptance testing may be an adequate implementation of this process area because, as stated above, there are usually a series of validation activities that will occur to ensure that the product works as intended.
return to topWhat is the difference between Verification and Validation?
Verification ensures that you are building a product according to its requirements, specifications, and standards. For Verification, you should ask the following questions:
- Are you meeting the specified requirements?
- Are you building the product right?
Validation ensures that your product will be usable once it is in its intended environment. For Validation, you should ask the following questions:
- Are you meeting the operational need?
- Does this product meet its intended use in the intended environment?
- Are you building the right product?
These concepts were separated into two process areas to stress both concepts. Both are applicable throughout the product development lifecycle and can be addressed using the same test or activity. The difference between the two can be seen in the purpose of the test or activity. When prototypes are developed to ensure that specific requirements can be addressed, it is an example of a verification practice. When end users are asked to evaluate prototypes to ensure that the product will meet their needs, it is an example of a validation practice.
return to topCan cross-PA processes satisfy generic practice 3.2, Collect Improvement Information?
Yes. Generic practice 3.2, "Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization's processes and process assets." can be performed using a single process that collects artifacts and information from multiple process areas. A separate collection process for each process area is not required. A "cross-PA" approach is consistent with the intent of generic practice 3.2 and is a good example of an effective and efficient approach to its implementation.
return to topWhat does generic practice 2.2, Plan the Process, require and how does it relate to planning and strategy specific practices?
Every process area has a generic practice (GP 2.2) that addresses planning. Generic practice 2.2, "Establish and maintain the plan for performing the process," addresses the planning of the overall process for a particular process area. The purpose of this generic practice is to determine what is needed to perform the process and achieve the established objectives, prepare a plan for performing the process, prepare a process description, and get agreement on the plan from relevant stakeholders.
In some process areas (Causal Analysis and Resolution, Integrated Project Management, Organizational Innovation and Deployment, Organizational Process Focus, Organizational Training, and Risk Management), there are specific practices that cover plan or strategy development. Where there are such specific practices, GP 2.2 addresses overall planning for the entire process area, whereas the specific practices address more detailed and focused planning. In these same process areas, the elaboration that accompanies GP 2.2 explains the differences between the generic practice and the specific practice.
return to topWhen using a CMMI model for process improvement, is the use of functional analysis problematic for an object oriented approach?
The term "functional analysis" was used in CMMI to be universally applicable, and there is no intention to exclude an object oriented approach. In Requirements Development, specific practice 3.2, it says
The definition of functionality, also referred to as "functional analysis," is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
return to topFunctional analysis is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called "services" or "methods." The definition of functions, their logical groupings, and their association with requirements is referred to as a functional architecture.
Where in CMMI are documented procedures addressed?
The concept of a documented procedure is handled in CMMI models by the generic goals that state that you perform a process according to a managed or defined process. The generic practices associated with these generic goals include documenting the processes and procedures that you use (e.g., see GP 2.2, subpractice 2).
Although the term "according to a documented procedure" is not explicitly used in CMMI models, the phrase "establish and maintain" is used. This phrase represents a meaning that includes not only establishing and maintaining, but also documenting and using.
For example, "Establish and maintain an organizational policy for planning and performing the organizational process focus process" means that you must formulate a policy, document it, maintain it, and use it.
return to topIf you have a question that is not answered within this FAQ, check the CMMI FAQ Main Page or send email to an SEI person at cmmi-comments@sei.cmu.edu. You will receive a response within 48 hours.