Software Testing

Organizational Process Definition: Institutionalize a Defined Process

2007-12-10T11:53:00.000-08:00

The process is institutionalized as a defined process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the organizational process definition process.
Elaboration:
This policy establishes organizational expectations for establishing and maintaining a set of standard processes for use by the organization and making organizational process assets available across the organization.

Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined organizational process definition process.
GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the organizational process definition process.

Elaboration:
Typically, this plan for performing the organizational process definition process is a part of the organization’s process-improvement plan.

GP 2.3 (AB 3) Provide Resources
Provide adequate resources for performing the organizational process definition process, developing the work products, and providing the services of the process.

Elaboration:
A process group typically manages the organizational process definition activities. This group is typically staffed by a core of professionals whose primary responsibility is coordinating organizational process
improvement. This group is supported by process owners and people with expertise in various disciplines such as the following:
· Project management
· The appropriate engineering disciplines
· Configuration management
· Quality assurance
Examples of other resources provided include the following tools:
· Database management systems
· Process modeling tools
· Web page builders and browsers

GP 2.4 (AB 4) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational process definition process.

GP 2.5 (AB 5) Train People
Train the people performing or supporting the organizational process definition process as needed. Elaboration:
Examples of training topics include the following:
· CMMI and other process and process-improvement reference models
· Planning, managing, and monitoring processes
· Process modeling and definition
· Developing a tailorable standard process

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the organizational process definition process under appropriate levels of configuration management.

Elaboration:
Examples of work products placed under configuration management include the following:
· Organization’s set of standard processes
· Descriptions of the life-cycle models
· Tailoring guidelines for the organization’s set of standard processes
· Definitions of the common set of product and process measures
· Organization’s measurement data
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the organizational process definition process as planned.
Elaboration:
Examples of activities for stakeholder involvement include the following:
· Reviewing the organization’s set of standard processes
· Reviewing the organization’s life-cycle models
· Resolving issues on the tailoring guidelines
· Assessing the definitions of the common set of process and product measures
GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the organizational process definition process against the plan for performing the process and take appropriate corrective action.

Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Percentage of projects using the process architectures and process elements of the organization's set of standard processes
· Defect density of each process element of the organization’s set of standard processes
GP 3.2 (DI 4) Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational process definition process to support the future use and improvement of the organization’s processes and process assets.
Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the organizational process definition process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Establishing organizational process assets
Examples of work products reviewed include the following:
· Organization’s set of standard processes
· Descriptions of the life-cycle models
· Tailoring guidelines for the organization’s set of standard processes
· Organization’s measurement data

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the organizational process definition process with higher level management and resolve issues.

Organizational Process Focus: Specific Practice By Goal SP1.5

2007-12-10T11:49:00.000-08:00

Establish the Organization’s Process Asset Library
Establish and maintain the organization's process asset library.
Examples of items to be stored in the organization’s process asset library include the following:
· Organizational policies
· Defined process descriptions
· Procedures (e.g., estimating procedure)
· Development plans
· Quality assurance plans
· Training materials
· Process aids (e.g., checklists)
· Lessons-learned reports

Typical Work Products
1. Design of the organization’s process asset library
2. Organization's process asset library
3. Selected items to be included in the organization’s process asset library
4. Catalog of items in the organization’s process asset library

Subpractices
1. Design and implement the organization’s process asset library,including the library structure and support environment.
2. Specify the criteria for including items in the library.
The items are selected based primarily on their relationship to the organization's set of standard processes.
3. Specify the procedures for storing and retrieving items.
4. Enter the selected items into the library and catalog them for easy reference and retrieval.
5. Make the items available for use by the projects.
6. Periodically review the use of each item and use the results to maintain the library contents.
7. Revise the organization’s process asset library as necessary.

Examples of when the library may need to be revised include the following:
· New items are added
· Items are retired
· Current versions of items are changed

Organizational Process Focus: Specific Practice By Goal SP1.4

2007-12-01T11:28:00.000-08:00

Establish the Organization’s Measurement Repository
Establish and maintain the organization’s measurement repository.
The repository contains both product and process measures that are related to the organization's set of standard processes. It also contains or refers to the information needed to understand and interpret the
measures and assess them for reasonableness and applicability. For example, the definitions of the measures are used to compare similar measures from different processes.

Typical Work Products
1. Definition of the common set of product and process measures for the organization's set of standard processes
2. Design of the organization’s measurement repository
3. Organization's measurement repository (i.e., the repository structure and support environment)
4. Organization’s measurement data

Subpractices
1. Determine the organization's needs for storing, retrieving, and analyzing measurements.
2. Define a common set of process and product measures for the organization's set of standard processes.
The measures in the common set are selected based on the organization's set of standard processes. The common set of measures may vary for different standard processes.
Operational definitions for the measures specify the procedures for collecting valid data and the point in the process where the data will be collected.
Examples of classes of commonly used measures include the following:
· Estimates of work product size (e.g., pages)
· Estimates of effort and cost (e.g., person hours)
· Actual measures of size, effort, and cost
· Quality measures (e.g., number of defects found, severity of defects)
· Peer review coverage
· Test coverage
· Reliability measures (e.g., mean time to failure)
3. Design and implement the measurement repository.
4. Specify the procedures for storing, updating, and retrieving measures.
5. Conduct peer reviews on the definitions of the common set of measures and the procedures for storing and retrieving measures.
6. Enter the specified measures into the repository.
7. Make the contents of the measurement repository available for use by the organization and projects as appropriate.
8. Revise the measurement repository, common set of measures, and procedures as the organization’s needs change.
Examples of when the common set of measures may need to be revised include the following:
· New processes are added
· Processes are revised and new product or process measures are needed
· Finer granularity of data is required
· Greater visibility into the process is required
· Measures are retired

Organizational Process Focus: Specific Practice By Goal SP1.3

2007-11-30T11:09:00.000-08:00

Establish Tailoring Criteria and Guidelines
Establish and maintain the tailoring criteria and guidelines for the organization's set of standard processes.

For Integrated Product and Process Development
In creating the tailoring criteria and guidelines, include considerations for concurrent development and operating with integrated teams. For example, how one tailors the manufacturing process will be different depending on whether it is done serially after the product has been developed or in
parallel with the development of the product, as in IPPD. Processes, such as resource allocation, will also be tailored differently if the project is operating with integrated teams.

The tailoring criteria and guidelines describe the following:
· How the organization's set of standard processes and organizational process assets are used to create the defined processes
· Mandatory requirements that must be satisfied by the defined processes (e.g., the subset of the organizational process assets that are essential for any defined process)
· Options that can be exercised and criteria for selecting among the options
· Procedures that must be followed in performing and documenting process tailoring
Examples of reasons for tailoring include the following:
· Adapting the process for a new product line or host environment
· Customizing the process for a specific application or class of applications (e.g.,initial development, maintenance, or creation of prototypes)
· Elaborating the process description so that the resulting defined process can be performed
Flexibility in tailoring and defining processes is balanced with ensuring appropriate consistency in the processes across the organization.
Flexibility is needed to address contextual variables such as the domain; nature of the customer; cost, schedule, and quality tradeoffs;technical difficulty of the work; and experience of the people
implementing the process. Consistency across the organization is needed so that organizational standards, objectives, and strategies are appropriately addressed, and process data and lessons learned can be
shared.
Tailoring criteria and guidelines may allow for using a standard process “as is,” with no tailoring.

Typical Work Products
1. Tailoring guidelines for the organization's set of standard processes
Subpractices
1. Specify the selection criteria and procedures for tailoring the organization's set of standard processes.

Examples of criteria and procedures include the following:
· Criteria for selecting life-cycle models from those approved by the organization
· Criteria for selecting process elements from the organization's set of standard processes
· Procedures for tailoring the selected life-cycle models and process elements to accommodate specific process characteristics and needs
Examples of tailoring actions include the following:
· Modifying a life-cycle model
· Combining elements of different life-cycle models
· Modifying process elements
· Replacing process elements
· Reordering process elements
2. Specify the standards for documenting the defined processes.
3. Specify the procedures for submitting and obtaining approval of waivers from the requirements of the organization's set of standard processes.
4. Document the tailoring guidelines for the organization's set of standard processes.
5. Conduct peer reviews on the tailoring guidelines.
6. Revise the tailoring guidelines as necessary.

Organizational Process Focus: Specific Practice By Goal SP1.2

2007-11-28T22:53:00.000-08:00

Establish Life-Cycle Model Descriptions
Establish and maintain descriptions of the life-cycle models approved for use in the organization.
Life-cycle models may be developed for a variety of customers or in a variety of situations, since one life-cycle model may not be appropriate for all situations. The organization may identify more than one life-cycle
model for use. Typically, the organization needs both product and project life-cycle models, for the types of products that it produces and for defining the phases of the project.
Product life-cycle models partition the product life cycle into phases for which activities and requirements can be defined to promote a complete solution, from initiating development of the product to its ultimate
disposal.

Typical Work Products
1. Descriptions of life-cycle models
Subpractices
1. Select life-cycle models based on the needs of projects and the organization.
For example, in the case of a development project, project life-cycle models include the following:
· Waterfall
· Spiral
· Evolutionary
· Incremental
· Iterative
Examples of project characteristics that could affect the project life-cycle models include the following:
· Size of the project
· Experience and familiarity of project staff in implementing the process
· Constraints such as cycle time and acceptable defect levels
2. Document the descriptions of the life-cycle models.
The life-cycle models may be documented as part of the organization's standard process descriptions or they may be documented separately.
3. Conduct peer reviews on the life-cycle models.
. Revise the descriptions of the life-cycle models as necessary.

Organizational Process Focus: Specific Practice By Goal SP1.1

2007-11-28T21:38:00.000-08:00

Establish Standard Processes
Establish and maintain the organization's set of standard processes.

For Integrated Product and Process Development
In an IPPD environment, the organization’s shared vision is included in the organizational process assets.
Standard processes may be defined at multiple levels in an enterprise and they may be related in a hierarchical manner. For example, an enterprise may have a set of standard processes that is tailored by
individual organizations (e.g., a division or site) in the enterprise to establish their set of standard processes. The set of standard processes may also be tailored for each of the organization’s business areas or product lines. Thus “the organization's set of standard processes” can refer to the standard processes established at the organization level and standard processes that may be established at lower levels, although some organizations may only have a single level of standard processes.

Multiple standard processes may be needed to address the needs of different application domains, life-cycle models, methodologies, and tools. The organization's set of standard processes contains process elements (e.g., a work product size-estimating element) that may be interconnected according to one or more process architectures that describe the relationships among these process elements. Processes may be composed of other processes or process elements.

The organization's set of standard processes typically includes technical, management, administrative, support, and organizational processes.
The organization’s set of standard processes should collectively cover all processes needed by the organization and projects, including those processes addressed by the process areas at Maturity Level 2.

Typical Work Products
1. Organization's set of standard processes
Subpractices
1. Decompose each standard process into constituent process elements to the detail needed to understand and describe the process.
Each process element covers a bounded and closely related set of activities. The descriptions of the process elements may be templates to be filled in, fragments to be completed, abstractions to be refined, or complete descriptions to be tailored or used unmodified. These elements are described in sufficient detail such that the process, when fully defined, can be consistently performed by appropriately trained and skilled people.
Examples of process elements include the following:
· Template for generating work product size estimates
· Description of work product design methodology
· Tailorable peer review methodology
· Template for conduct of management reviews
2. Specify the critical attributes of each process element.
Examples of critical attributes include the following:
· Process roles
· Applicable process and product standards
· Applicable procedures, methods, tools, and resources
· Process performance objectives
· Entry criteria
· Inputs
· Product and process measures to be collected and used
· Verification points (e.g., peer reviews)
· Outputs
· Interfaces
· Exit criteria
3. Specify the relationships of the process elements.
Examples of relationships include the following:
· Ordering of the process elements
· Interfaces among the process elements
· Interfaces with external processes
· Interdependencies among the process elements
The rules for describing the relationships among process elements are referred to as “process architecture.” The process architecture covers the essential requirements and guidelines. The detailed specifications of these relationships are covered in the descriptions of the defined processes that are tailored from the organization's set of standard processes.
4. Ensure that the organization's set of standard processes adheres to applicable policies; process standards and models; and product standards.
Adherence to applicable process standards and models is typically demonstrated by developing a mapping from the organization’s set of standard processes to the relevant process standards and models. In addition, this mapping will be a useful input to future appraisals.
5. Ensure that the organization’s set of standard processes satisfies the process needs and objectives of the organization.
6. Ensure that there is appropriate integration among the processes that are included in the organization’s set of standard processes.
7. Document the organization's set of standard processes.
8. Conduct peer reviews on the organization's set of standard processes.
9. Revise the organization's set of standard processes as necessary.

Organizational Process Definition: CMMI Maturity Level 3

2007-11-28T21:26:00.000-08:00

Consistent performance across the company is enabled through organizational process and also provides a basis for cumulative, long-term benefits to the organization. A coolection of items maintained by the organization are in organization's process asset library to be used by people and projects of the organization.
This collection of items includes descriptions of processes and process elements, descriptions of life-cycle models, process tailoring guidelines, process-related documentation, and data. The organization’s process asset library supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across the organization.
The organization's set of standard processes is tailored by projects to create their defined processes. The other organizational process assets are used to support tailoring as well as the implementation of the
defined processes.
A standard process is composed of other processes or process elements. A process element is the fundamental (e.g., atomic) unit of process definition and describes the activities and tasks to consistently
perform work. Process architecture provides rules for connecting the process elements of a standard process. The organization's set of standard processes may include multiple process architectures.

The organizational process assets may be organized in many ways, depending on the implementation of the Organizational Process Definition process area. Examples include the following:
· Descriptions of life-cycle models may be documented as part of the organization's set of standard processes, or they may be documented separately.
· The organization's set of standard processes may be stored in the organization's process asset library, or they may be stored separately.
· A single repository may contain both the measurements and the process-related documentation, or they may be stored separately.

Specific and Generic Goals:
SG 1 Establish Organizational Process Assets
A set of organizational process assets is established and maintained.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

SG 1 Establish Organizational Process Assets
SP 1.1 Establish Standard Processes
SP 1.2 Establish Life-Cycle Model Descriptions
SP 1.3 Establish Tailoring Criteria and Guidelines
SP 1.4 Establish the Organization’s Measurement Repository
SP 1.5 Establish the Organization’s Process Asset Library

GG 3 Institutionalize a Defined Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 3.1 (AB 1) Establish a Defined Process
GP 2.2 (AB 2) Plan the Process
GP 2.3 (AB 3) Provide Resources
GP 2.4 (AB 4) Assign Responsibility
GP 2.5 (AB 5) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 3.2 (DI 4) Collect Improvement Information
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

Organizational Process Focus: Institutionalize A Defined Process

2007-11-23T00:04:00.000-08:00

The process is institutionalized as a defined process.
Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the organizational process focus process.
Elaboration:
This policy establishes organizational expectations for determining process-improvement opportunities for the processes being used and for planning and implementing process-improvement activities across the organization.

Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined organizational process focus process.

GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the organizational process focus process.
Elaboration:
The plan for performing the organizational process focus process,which is often called “the process-improvement plan,” differs from the process action plans described in specific practices in this process
area. The plan called for in this generic practice addresses the comprehensive planning for all of the specific practices in this process area, from the establishment of organizational process needs all the way through to the incorporation of process-related experiences into the organizational process assets.

GP 2.3 (AB 3) Provide Resources
Provide adequate resources for performing the organizational process focus process, developing the work products, and providing the services of the process.

Elaboration:
Examples of resources provided include the following tools:
· Database management systems
· Process-improvement tools
· Web page builders and browsers
· Groupware
· Quality-improvement tools (e.g., quality-improvement tools, cause-and-effect diagrams, affinity diagrams, Pareto charts)

GP 2.4 (AB 4) Assign Responsibility
Assign responsibility and authority for performing the process,developing the work products, and providing the services of the organizational process focus process.
Elaboration:
Two groups are typically established and assigned responsibility for process improvement:
(1) a management steering committee for process improvement to provide senior-management sponsorship;
(2) a process group to facilitate and manage the process-improvement activities.

GP 2.5 (AB 5) Train People
Train the people performing or supporting the organizational process focus process as needed.

Elaboration:
Examples of training topics include the following:
· CMMI and other process and process-improvement reference models
· Planning and managing process improvement
· Tools, methods, and analysis techniques
· Process modeling
· Facilitation techniques
· Change management

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the organizational process management.

Elaboration:
Examples of work products placed under configuration management include the following:
· Process-improvement proposals
· Organization’s approved process action plans
· Training materials for deploying organizational process assets
· Plans for the organization’s process appraisals

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the organizational process focus process as planned.
Elaboration:
Examples of activities for stakeholder involvement include the following:
· Coordinating and collaborating on process-improvement activities with process owners, those that are or will be performing the process, and support organizations (e.g., training staff and quality assurance representatives)
· Establishing the organizational process needs and objectives
· Appraising the organization’s processes
· Implementing process action plans
· Coordinating and collaborating on the execution of pilots to test selected improvements
· Deploying organizational process assets and changes to organizational process assets
· Communicating the plans, status, activities, and results related to the implementation of process-improvement activities

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the organizational process focus process against the plan for performing the process and take appropriate corrective action.

Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Number of process-improvement proposals submitted, accepted, or implemented
· CMMI maturity level or capability level

GP 3.2 (DI 4) Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the organizational process focus process to support the future use and improvement of the organization’s processes and process assets.

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the organizational process focus process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Determining process-improvement opportunities
· Planning and coordinating process-improvement activities
Examples of work products reviewed include the following:
· Process-improvement plans
· Process action plans
· Plans for the organization’s process appraisals

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the organizational process focus process with higher level management and resolve issues.

Elaboration:
These reviews are typically in the form of a briefing presented to the management steering committee by the process group and the process action teams.
Examples of presentation topics include the following:
· Status of improvements being developed by process action teams
· Results of pilots
· Results of deployments
· Schedule status for achieving significant milestones (e.g., readiness for an appraisal, or progress towards achieving a targeted organizational maturity level or capability level profile)

Organizational Process Focus: Speciifc Practice By Goal SG2

2007-11-12T23:52:00.000-08:00

Improvements are planned and implemented, organizational process assets are deployed, and process-related experiences are incorporated into the organizational process assets. Successful implementation of improvements requires participation in the process definition and improvement activities by process owners, those performing the process, and support organizations.

SP 2.1 Establish Process Action Plans
Establish and maintain process action plans to address improvements to the organization's processes and process assets.
Establishing and maintaining process action plans typically involves the following roles:
· Management steering committees to set strategies and oversee process-improvement activities
· Process group staff to facilitate and manage the process improvement activities
· Process action teams to define and implement the improvement
· Process owners to manage the deployment
· Practitioners to perform the process
This involvement helps to obtain buy-in on the process improvements and increases the likelihood of effective deployment.

Process action plans are detailed implementation plans. These plans differ from the organization’s process-improvement plan in that they are plans targeting specific improvements that have been defined to
address weaknesses usually uncovered by appraisals.

Typical Work Products
1. Organization's approved process action plans
Subpractices
1. Identify strategies, approaches, and actions to address the identified process improvements. New, unproven, and major changes are piloted before they are incorporated into normal use.
2. Establish process action teams to implement the actions.
The teams and people performing the process-improvement actions are called “process action teams.” Process action teams typically include process owners and those who perform the process.
3. Document process action plans. Process action plans typically cover the following:
· Process-improvement infrastructure
· Process-improvement objectives
· Process improvements that will be addressed
· Procedures for planning and tracking process actions
· Strategies for piloting and implementing the process actions
· Responsibility and authority for implementing the process actions
· Resources, schedules, and assignments for implementing the process actions
· Methods for determining the effectiveness of the process actions
· Risks associated with process action plans
4. Review and negotiate process action plans with relevant stakeholders.
5. Review process action plans as necessary.

SP 2.2 Implement Process Action Plans
Implement process action plans across the organization.

Typical Work Products
1. Commitments among the various process action teams
2. Status and results of implementing process action plans
3. Plans for pilots
Subpractices
1. Make process action plans readily available to relevant stakeholders.
2. Negotiate and document commitments among the process action teams and revise their process action plans as necessary.
3. Track progress and commitments against process action plans.
4. Conduct joint reviews with the process action teams and relevant stakeholders to monitor the progress and results of the process actions.
5. Plan pilots needed to test selected process improvements.
6. Review the activities and work products of process action teams.
7. Identify, document, and track to closure issues in implementing process action plans.
8. Ensure that the results of implementing process action plans satisfy the organization’s process-improvement objectives.

SP 2.3 Deploy Organizational Process Assets
Deploy organizational process assets across the organization.
Deployment of organizational process assets or of changes to organizational process assets should be performed in an orderly manner. Some organizational process assets or changes to organizational process assets may not be appropriate for implementation in some parts of the organization (because of customer
requirements or the current lifecycle phase being implemented, for example). It is therefore important that those that are or will be executing the process, as well as other organization functions (such as training and quality assurance) be involved in the deployment as necessary.
Typical Work Products
1. Plans for deploying the organizational process assets and changes to organizational process assets
2. Training materials for deploying the organizational process assets and changes to organizational process assets
3. Documentation of changes to the organizational process assets
4. Support materials for deploying the organizational process assets and changes to organizational process assets
Subpractices
1. Deploy organizational process assets and associated methods and tools.
Typical activities performed as a part of this deployment include the following:
· Planning the deployment
· Identifying the organizational process assets that should be adopted by those who will be performing the process
· Ensuring that training is available for the organizational process assets that are being deployed
· Identifying the support resources (e.g., tools) needed to transition the deployed organizational process assets
· Determining the schedule for deploying the organizational process assets
2. Deploy the changes that were made to the organizational process assets.
Typical activities performed as a part of this deployment include the following:
· Planning the deployment
· Determining which changes are appropriate for those that are or will be performing the process
· Determining the time frame for deploying the changes
· Arranging for the associated support needed to successfully transition the changes
3. Document the changes to the organizational process assets.
The documentation of changes is used to understand the relationship of the changes to resulting changes in process performance and results.
4. Provide guidance and consultation on the use of the organizational process assets.

SP 2.4 Incorporate Process-Related Experiences into the Organizational Process Assets
Incorporate process-related work products, measures, and improvement information derived from planning and performing the process into the organizational process assets.
Typical Work Products
1. Process-improvement proposals
2. Process lessons learned
3. Measurements on the organizational process assets
4. Improvement recommendations for the organizational process assets
5. Records of the organization's process-improvement activities
6. Information on the organizational process assets and improvements to them

Subpractices
1. Conduct periodic reviews of the effectiveness and suitability of the organization’s set of standard processes and related organizational process assets relative to the organization’s business objectives.
2. Obtain feedback about the use of the organizational process assets.
3. Derive lessons learned from defining, piloting, implementing, and deploying the organizational process assets.
4. Make lessons learned available to the people in the organization as appropriate.
Actions may have to be taken to ensure that lessons learned are used appropriately.
Examples of inappropriate use of lessons learned include the following:
· Evaluating the performance of people
· Judging process performance or results
Examples of ways to prevent inappropriate use of lessons learned include the following:
· Controlling access to the lessons learned
· Educating people about the appropriate use of lessons learned
5. Analyze the organization's common set of measures.
6. Appraise the processes, methods, and tools in use in the organization and develop recommendations for improving the organizational process assets.
This appraisal typically includes the following:
· Determining which of the processes, methods, and tools are of potential use to other parts of the organization
· Appraising the quality and effectiveness of the organizational process assets
· Identifying candidate improvements to the organizational process assets
· Determining compliance with the organization’s set of standard processes and tailoring guidelines
7. Make the best use of the organization's processes, methods, and tools available to the people in the organization as appropriate.
8. Manage process-improvement proposals.
The activities for managing process-improvement proposals typically include the following:
· Soliciting process-improvement proposals
· Collecting process-improvement proposals
· Reviewing the process-improvement proposals
· Selecting the process-improvement proposals that will be implemented
· Tracking the implementation of the process-improvement proposals
Process-improvement proposals are documented as process change requests or problem reports, as appropriate.
Some process-improvement proposals may be incorporated into the organization’s process action plans.
9. Establish and maintain records of the organization's processimprovement
activities.

Organizational Process Focus: Speciifc Practice By Goal SG1

2007-11-12T23:38:00.000-08:00

SG 1 Determine Process-Improvement Opportunities
Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed.
Strengths, weaknesses, and improvement opportunities may be determined relative to a process standard or model such as a CMMI model or International Organization for Standardization (ISO) standard.
The process improvements should be selected specifically to address the organization's needs.

SP 1.1 Establish Organizational Process Needs
Establish and maintain the description of the process needs and objectives for the organization.
For Integrated Product and Process Development
Integrated processes that emphasize parallel rather than serial development are a cornerstone of IPPD implementation.Product development processes and product-related life-cycle processes, such as the manufacturing process development and the support process development processes, are conducted concurrently. Such integrated processes need to accommodate the information provided by stakeholders
representing all phases of the product life cycle from both business and technical functions. Processes for effective teamwork will also be needed.
Examples of processes for effective teamwork include the following:
· Communications
· Collaborative decision making
· Issue resolution
· Team building
The organization's processes operate in a business context that must be understood. The organization's business objectives, needs, and constraints determine the needs and objectives for the organization’s processes. Typically, the issues related to financial, technological,quality, human resource, and marketing are important process considerations.
The organization's process needs and objectives cover aspects that include the following:
· Characteristics of the processes
· Process performance objectives, such as time to market and product quality
· Process effectiveness
Typical Work Products
1. Organization’s process needs and objectives
Subpractices
1. Identify the policies, standards, and business objectives that are applicable to the organization's processes.
2. Examine relevant process standards and models for best practices.
3. Determine the organization’s process performance objectives.

Process performance objectives may be expressed in quantitative or qualitative terms.
Examples of process performance objectives include the following:
· Cycle time
· Defect removal rates
· Productivity
4. Define the essential characteristics of the organization’s processes.
The essential characteristics of the organization’s processes are determined based on the following:
· Processes currently being used in the organization
· Process and product standards imposed by the organization
· Process and product standards commonly imposed by customers of the organization
Examples of process characteristics include the following:
· Level of detail used to describe the processes
· Process notation used
· Granularity of the processes
5. Document the organization’s process needs and objectives.
6. Revise the organization’s process needs and objectives as needed.

SP 1.2 Appraise the Organization’s Processes
Appraise the processes of the organization periodically and as needed to maintain an understanding of their strengths and weaknesses.
Process appraisals may be performed for the following reasons:
· To identify processes that should be improved
· To confirm progress and make the benefits of process improvement visible
· To satisfy the needs of a customer-supplier relationship
· To motivate and facilitate buy-in
The buy-in gained during a process appraisal can be eroded significantly if it is not followed by an appraisal-based action plan.
Typical Work Products
1. Plans for the organization's process appraisals
2. Appraisal findings that address strengths and weaknesses of the organization's processes
3. Improvement recommendations for the organization's processes
Subpractices
1. Obtain sponsorship of the process appraisal from senior management.
Senior-management sponsorship includes the commitment to have the organization's managers and staff participate in the process appraisal and to provide the resources and funding to analyze and communicate the findings of the appraisal.
2. Define the scope of the process appraisal.
Process appraisals may be performed on the entire organization or may be performed on a smaller part of an organization such as a single project or business area.
The scope of the process appraisal addresses the following:
· Definition of the organization (e.g., sites or business areas) that will be covered by the appraisal
· Identification of the project and support functions that will represent the organization in the appraisal
· Processes that will be appraised
3. Determine the method and criteria for process appraisal.
Process appraisals can occur in many forms. Process appraisals should address the needs and objectives of the organization, which may change over time. For example, the appraisal may be based on a process model, such as a CMMI model, or on a national or international standard, such as ISO 9001. The appraisals may also be based on a benchmark comparison with other organizations. The appraisal method may assume a variety of characteristics in terms of time and effort expended, makeup of the appraisal team, and the method and depth of investigation.
4. Plan, schedule, and prepare for the process appraisal.
5. Conduct the process appraisal.
6. Document and deliver the appraisal’s activities and findings.

SP 1.3 Identify the Organization's Process Improvements
Identify improvements to the organization's processes and process assets.
Typical Work Products
1. Analysis of candidate process improvements
2. Identification of improvements for the organization's processes
Subpractices
1. Determine candidate process improvements.
Candidate process improvements are typically determined by doing the following:
· Measure the processes and analyze the measurement results
· Review the processes for effectiveness and suitability
· Review the lessons learned from tailoring the organization’s set of standard processes
· Review the lessons learned from implementing the processes
· Review process-improvement proposals submitted by the organization's managers and staff, and other relevant stakeholders
· Solicit inputs on process improvements from the senior management and leaders in the organization
· Examine the results of process appraisals and other process-related reviews
· Review results of other organization improvement initiatives
2. Prioritize the candidate process improvements.
Criteria for prioritization are as follows:
· Consider the estimated cost and effort to implement the process improvements
· Appraise the expected improvement against the organization's improvement objectives and priorities
· Determine the potential barriers to the process improvements and develop strategies for overcoming these barriers
Examples of techniques to help determine and prioritize the possible improvements to be implemented include the following:
· A gap analysis that compares current conditions in the organization with optimal conditions
· Force-field analysis of potential improvements to identify potential barriers and strategies for overcoming those barriers
· Cause-and-effect analyses to provide information on the potential effects of different improvements that can then be compared
3. Identify and document the process improvements that will be implemented.
4. Revise the list of planned process improvements to keep it current.

Organizational Process Focus: CMMI Maturity Level 3

2007-11-12T23:29:00.000-08:00

Abstract:

Planning and implementing organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets is the main focus of organizational processes.

The organization's processes include the organization's set of standard processes and the defined processes that are tailored from them. The organizational process assets are used to establish, maintain,implement, and improve the defined processes.

Candidate improvements to the organizational process assets are obtained from various sources, including measurement of the processes, lessons learned in implementing the processes, results of process appraisals, results of product evaluation activities, results of benchmarking against other organizations' processes, and
recommendations from other improvement initiatives in the organization.
Process improvement occurs within the context of the organization’s needs and is used to address the organization's objectives. The organization encourages participation in process-improvement activities
by those who will perform the process. The responsibility for facilitating and managing the organization's process-improvement activities, including coordinating the participation of others, is typically assigned to
a process group. The organization provides the long-term commitment and resources required to sponsor this group.

Careful planning is required to ensure that process-improvement efforts across the organization are adequately managed and implemented.
The organization’s planning for process-improvement results in a process-improvement plan. The organization’s process-improvement plan will address appraisal planning, process action planning, pilot
planning, and deployment planning. Appraisal plans describe the appraisal timeline and schedule, the scope of the appraisal, the resources required to perform the appraisal, the reference model against which the appraisal will be performed, and the logistics for the appraisal. Process action plans usually result from appraisals and document how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented. In cases in which it is determined that the improvement described in the process action plan
should be tested on a small group before deploying it across the organization, a pilot plan is generated. Finally, when the improvement is to be deployed, a deployment plan is used. This plan describes when
and how the improvement will be deployed across the organization.

Specific and Generic Goals
SG 1 Determine Process-Improvement Opportunities
Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed.
SG 2 Plan and Implement Process-Improvement Activities
Improvements are planned and implemented, organizational process assets are deployed, and process-related experiences are incorporated into the organizational process assets.
GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

Validation: Institutionalize a Defined Process

2007-11-12T22:44:00.000-08:00

The process is institutionalized as a defined process.
Commitment to Perform
GP 2.1 (CO 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.

Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined validation process.

GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the validation process.
Elaboration:
Typically, this plan for performing the validation process is included in (or referenced by) the project plan, which is described in the Project Planning process area.

GP 2.3 (AB 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 (AB 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 (AB 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

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the validation process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Lists of products and product components selected for validation
· Validation methods, procedures, and criteria
· Validation reports

GP 2.7 (DI 2) 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, services, or manufactured products)
· Additional in-depth studies, trials, tests, or evaluations
· Possible changes in the contracts or agreements

GP 2.8 (DI 3) 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 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)

GP 3.2 (DI 4) 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.

Verifying Implementation
GP 2.9 (VE 1) 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 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the validation process with higher level management and resolve issues.

Validate Product or Product Components: Specific Practices By Goal SG2

2007-11-12T21:14:00.000-08:00

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.

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.
(For users of the continuous representation, this is a capability level 1 specific practice. Validation processes at capability level 1 or 2 may not include procedures and criteria, which are created in the Establish
Validation Procedures and Criteria specific practice at capability level 3. When there are no procedures or criteria established, use the methods established by the Select Products for Validation specific practice to
accomplish capability level 1 performance.)

Typical Work Products
1. Validation reports
2. Validation results
3. Validation cross-reference matrix
4. As-run procedures log
5. Operational demonstrations

SP 2.2 Analyze Validation Results
Analyze the results of the validation activities and identify issues.
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
1. Validation deficiency reports
2. Validation issues
3. Procedure change request
Subpractices
1. Compare actual results to expected results.
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.
3. Analyze the validation data for defects.
4. Record the results of the analysis and identify issues.
5. Use validation results to compare actual measurements and performance to intended use or operational need.

Prepare for Validation: Specific Practices By Goal SG1

2007-11-12T20:46:00.000-08:00

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.
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 technical 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, may 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 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.

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

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.
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 technical 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, may 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 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.

Typical Work Products
1. Lists of products and product components selected for validation
2. Validation methods for each product or product component
3. Requirements for performing validation for each product or product component
4. Validation constraints for each product or product component
Subpractices
1. Identify the key principles, features, and phases for product or product-component validation throughout the life of the project.
· 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 above elements
· Dedicated computing or network test environment (e.g., pseudooperational 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 re-validation of problem areas.

Typical Work Products
1. Validation environment
Subpractices
1. Identify validation environment requirements.
2. Identify customer-supplied products.
3. Identify reuse items.
4. Identify test equipment and tools.
5. Identify validation resources that are available for reuse and modification.
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
1. Validation procedures
2. Validation criteria
3. Test and evaluation procedures for maintenance, training, and support
Subpractices
1. Review the product requirements to ensure that issues affecting validation of the product or product component are identified and resolved.
2. Document the environment, operational scenario, procedures, inputs, outputs, and criteria for the validation of the selected product or product component.
3. Assess the design as it matures in the context of the validation environment to identify validation issues.

Validation: CMMI Maturity Level 3

2007-11-12T20:39:00.000-08:00

Abstract:
Demonstartion of a product or product component fulfills its intended use when placed in its intended environment is the sole purpose of validation.

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. The work products (e.g.,requirements, designs, 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.
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 are involved in the validation activities.Both validation and verification activities often run concurrently and may use portions of the same environment.
Where possible, validation should be accomplished using the product or product component operating in its intended environment. The entire environment may be used or only part of it. However, validation issues can be discovered early in the life of the project using work products.
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.

Specific and Generic Goals
SG 1 Prepare for Validation
Preparation for validation is conducted.
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.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Verification: Specific Practices by Goal SG3

2007-11-12T20:28:00.000-08:00

Verification of Selected Work Products
SP 3.1 Perform Verification
Perform verification on the selected work products. Verifying products and work products incrementally promotes early detection of problems and can result in the early removal of defects. These results of verification save considerable cost of fault isolation and rework associated with troubleshooting problems.
(For users of the continuous representation, this is a capability level 1 specific practice. Verification processes at capability level 1 or 2 may not include procedures and criteria, which are created in the Establish Verification Procedures and Criteria specific practice at capability level
3. When there are no procedures or criteria established, use the methods established by the Select Work Products for Verification specific practice to accomplish capability level 1 performance.)

Typical Work Products
1. Verification results
2. Verification reports
3. Demonstrations
4. As-run procedures log
Subpractices
1. Perform verification of selected work products against their requirements.
2. Record the results of verification activities.
3. Identify action items resulting from verification of work products.
4. Document the “as-run” verification method and the deviations from the available methods and procedures discovered during its performance.

SP 3.2 Analyze Verification Results and Identify Corrective Action
Analyze the results of all verification activities and identify corrective action. Actual results must be compared to established verification criteria to determine acceptability. The results of the analysis are recorded as evidence that verification was conducted.
For each work product, all available verification results are incrementally analyzed and corrective actions are initiated to ensure that the requirements have been met. Since a peer review is one of several verification methods, peer review data should be included in this analysis activity to ensure that the verification results are analyzed sufficiently. Analysis reports or “as-run” method documentation may also indicate that bad verification results are due to method problems, criteria problems, or a verification environment problem.

Typical Work Products
1. Analysis report (such as statistics on performances, causal analysis of nonconformances, comparison of the behavior between the real product and models, and trends)
2. Trouble reports
3. Change requests for the verification methods, criteria, and environment
4. Corrective actions to verification methods, criteria, and/or environment
Subpractices
1. Compare actual results to expected results.
2. Based on the established verification criteria, identify products that have not met their requirements or identify problems with the methods, procedures, criteria, and verification environment.
3. Analyze the verification data on defects.
4. Record all results of the analysis in a report.
5. Use verification results to compare actual measurements and performance to technical performance parameters.
6. Provide information on how defects may be resolved (including verification methods, criteria, and verification environment) and formalize it in a plan.

For Supplier Sourcing
Distribute pertinent verification results to the supplier of the work product.

Verification: Specific Practices by Goal SG2

2007-10-22T04:52:00.000-07:00

Peer reviews are performed on selected work products.
Peer reviews involve a methodical examination of work products by the producers' peers to identify defects for removal and to recommend other changes that are needed.
The peer review is an important and effective engineering method implemented via inspections, structured walkthroughs, or a number of other collegial review methods.Peer reviews are primarily applied to work products developed by the projects, but they can also be applied to other work products such as
documentation and training work products that are typically developed by support groups.

SP 2.1 Prepare for Peer Reviews
Prepare for peer reviews of selected work products.
Preparation activities for peer reviews typically include identifying the staff who will be invited to participate in the peer review of each work product, identifying the key reviewers who must participate in the peer
review, preparing and updating any materials that will be used during the peer reviews (such as checklists and review criteria), and scheduling peer reviews.

Typical Work Products
1. Peer review schedule
2. Peer review checklist
3. Entry and exit criteria for work products
4. Criteria for requiring another peer review
5. Peer review training material
6. Selected work products to be reviewed
Subpractices
1. Determine what type of peer review will be conducted.
Examples of types of peer reviews include the following:
· Inspections
· Structured walkthroughs
· Active reviews
2. Define requirements for collecting data during the peer review.
3. Establish and maintain entry and exit criteria for the peer review.
4. Establish and maintain criteria for requiring another peer review.
5. Establish and maintain checklists to ensure that the work products

Examples of items addressed by the checklists include the following:
· Rules of construction
· Design guidelines
· Completeness
· Correctness
· Maintainability
· Common defect types
The checklists are modified as necessary to address the specific type of work product and peer review. The peers of the checklist developers and potential users review the checklists.
6. Develop a detailed peer review schedule, including the dates for peer review training and for when materials for peer reviews will be available.
7. Ensure that the work product satisfies the peer review entry criteria prior to distribution.
8. Distribute the work product to be reviewed and its related information to the participants early enough to enable participants to adequately prepare for the peer review.
9. Assign roles for the peer review as appropriate.
Examples of roles include the following:
· Leader
· Reader
· Recorder
· Author
10. Prepare for the peer review by reviewing the work product prior to conducting the peer review.

SP 2.2 Conduct Peer Reviews
Conduct peer reviews on selected work products and identify issues resulting from the peer review.
One of the purposes of conducting a peer review is to find and remove defects early. Peer reviews are performed incrementally, as work products are being developed. These reviews are structured and are
not management reviews.
Peer reviews may be performed on key work products of specification, design, test, and implementation activities and specific planning work products.
The focus of the peer review should be on the work product in review, not on the person who produced it.
When issues arise during the peer review, they should be communicated to the primary developer of the work product for correction.
Peer reviews should address the following guidelines: there must be sufficient preparation, the conduct must be managed and controlled, consistent and sufficient data must be recorded (an example is conducting a formal inspection), and action items must be recorded.
Typical Work Products
1. Peer review results
2. Peer review issues
3. Peer review data
Subpractices
1. Perform the assigned roles in the peer review.
2. Identify and document defects and other issues in the work product.
3. Record the results of the peer review, including the action items.
4. Collect peer review data.
5. Identify action items and communicate the issues to relevant stakeholders.
6. Conduct an additional peer review if the defined criteria indicate the need.
7. Ensure that the exit criteria for the peer review are satisfied.

SP 2.3 Analyze Peer Review Data
Analyze data about preparation, conduct, and results of the peer reviews.
Typical Work Products
1. Peer review data
2. Peer review action items
Subpractices
1. Record data related to the preparation, conduct, and results of the peer reviews. Typical data are product name, product size, composition of the peer review team,type of peer review, preparation time per reviewer, length of the review meeting,number of defects found, type and origin of defect, etc. Additional information on the work product being peer reviewed may be collected, such as size,development stage, operating modes examined, and requirements being evaluated.
2. Store the data for future reference and analysis.
3. Protect the data to ensure that peer review data are not used inappropriately.
Examples of inappropriate use of peer review data include using data to evaluate the performance of people and using data for attribution.
4. Analyze the peer review data.

Verification: Specific Practices by Goal SG1

2007-10-19T00:30:00.000-07:00

Abstract:

Verification includes selection, inspection, testing, analyses etc and its methods include inspections, peer reviews, audits, walkthroughs, analyses, simulations etc. Select the work products based on meeting project objectives and requirements.

SG 1 Prepare for Verification
Up-front preparation is necessary to ensure that verification provisions are embedded in product and product-component requirements, designs, developmental plans, and schedules. Verification includes
selection, inspection, testing, analyses, and demonstration of work products.
Methods of verification include, but are not limited to, inspections, peer reviews, audits, walkthroughs, analyses, simulations, testing, and demonstrations.
Preparation also entails the definition of support tools, test equipment and software, simulations, prototypes, and facilities.

SP 1.1 Select Work Products for Verification
Select the work products to be verified and the verification methods that will be used for each.
Work products are selected based on their contribution to meeting project objectives and requirements, and to addressing project risks.
The work products to be verified may include those associated with maintenance, training, and support services. The work product requirements for verification are included with the verification methods.
The verification methods address the technical approach to work product verification and the specific approaches that will be used to verify that specific work products meet their requirements.
For Software Engineering
Examples of verification methods include the following:
· Path coverage testing
· Load, stress, and performance testing
· Decision-table-based testing
· Functional-decomposition-based testing
· Test-case reuse
· Acceptance tests
For Supplier Sourcing
Products supplied from outside of the project should be considered for verification.
Selection of the verification methods typically begins with involvement in the definition of product and product-component requirements to ensure that these requirements are verifiable. Re-verification should be
addressed by the verification methods to ensure that rework performed on work products did not cause unintended defects.

For Integrated Product and Process Development
The verification methods should be developed concurrently and iteratively with the product and product-component designs.

For Supplier Sourcing
Verification methods should be coordinated with suppliers to ensure applicability of the project’s methods to the supplier’s environment.

Typical Work Products
1. Lists of work products selected for verification
2. Verification methods for each selected work product

Subpractices
1. Identify work products for verification.
2. Identify the requirements to be satisfied by each selected work product.
3. Identify the verification methods that are available for use.
4. Define the verification methods to be used for each selected work product.
5. Submit for integration with the project plan the identification of work products to be verified, the requirements to be satisfied, and the methods to be used.

SP 1.2 Establish the Verification Environment
Establish and maintain the environment needed to support verification.
An environment must be established to enable verification to take place. The verification environment may be acquired, developed, reused, modified, or a combination of these, depending on the needs of the project.
For Supplier Sourcing
The verification criteria affecting a supplier should be shared with the supplier to reduce the probability that a work product will fail its verification.
Typical Work Products
1. Verification procedures
2. Verification criteria
Subpractices
1. Generate the set of comprehensive, integrated verification procedures for work products and any commercial off-the-shelf products, as necessary.
2. Develop and refine the verification criteria when necessary.
3. Identify the expected results, any tolerances allowed in observation, and other criteria for satisfying the requirements.
4. Identify any equipment and environmental components needed to support verification.

Verification: CMMI Maturity Level 3

2007-10-19T00:02:00.000-07:00

Abstract:

Preparation, performance and corrective action identification are the key process areas for Verification.
It is an incremental process that begins with verifying requireents, progress through verification of evolving products and verification of compelete product. Peer reviews form a significant part of Verification.

Explanation:
The Verification process area involves the following: verification preparation, verification performance, and identification of corrective action.
Verification includes verification of the product and intermediate work products against all selected requirements, including customer, product, and product-component requirements.
Verification is inherently an incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the
verification of the evolving work products, and culminating in the verification of the completed product.

The specific practices of this process area build upon each other in the following way: the Select Work Products for Verification specific practice enables the identification of the work products to be verified, the
methods to be used to perform the verification, and the requirements to be satisfied by each selected work product. The Establish the Verification Environment specific practice enables the determination of
the environment that will be used to carry out the verification. The Establish Verification Procedures and Criteria specific practice then enables the development of verification procedures and criteria that are
aligned with the selected work products, requirements, methods, and characteristics of the verification environment. The Perform Verification specific practice conducts the verification according to the available
methods, procedures, and criteria.

Verification of work products substantially increases the likelihood that the product will meet the customer, product, and product-component requirements.

The Verification and Validation process areas are similar, but they address different issues. Validation demonstrates that the product, as provided (or as it will be 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.”

Peer reviews are an important part of verification and are a proven mechanism for effective defect removal. An important corollary is to develop a better understanding of the work products and the processes
that produced them so defects can be prevented and process improvement opportunities can be identified.
Peer reviews involve a methodical examination of work products by the producers' peers to identify defects and other changes that are needed.
Examples of peer review methods include the following:
· Inspections
· Structured walkthroughs

Specific and Generic Goals
SG 1 Prepare for Verification
Preparation for verification is conducted.
SG 2 Perform Peer Reviews
Peer reviews are performed on selected work products.
SG 3 Verify Selected Work Products
Selected work products are verified against their specified requirements.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Prepare for Verification
SP 1.1 Select Work Products for Verification
SP 1.2 Establish the Verification Environment
SP 1.3 Establish Verification Procedures and Criteria
SG 2 Perform Peer Reviews
SP 2.1 Prepare for Peer Reviews
SP 2.2 Conduct Peer Reviews
SP 2.3 Analyze Peer Review Data
SG 3 Verify Selected Work Products
SP 3.1 Perform Verification
SP 3.2 Analyze Verification Results and Identify Corrective Action
GG 3 Institutionalize a Defined Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 3.1 (AB 1) Establish a Defined Process
GP 2.2 (AB 2) Plan the Process
GP 2.3 (AB 3) Provide Resources
GP 2.4 (AB 4) Assign Responsibility
GP 2.5 (AB 5) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 3.2 (DI 4) Collect Improvement Information
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

Product Integration : Institutionalize a Defined Process GG3

2007-10-17T03:39:00.000-07:00

The process is institutionalized as a defined process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the product integration process.
Elaboration:
This policy establishes organizational expectations for developing product integration sequences, procedures, and an environment, ensuring interface compatibility among product components,
assembling the product components, and delivering the product and product components.

Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined product integration process.

GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the product integration process.
Elaboration:
This plan for performing the product integration process addresses the comprehensive planning for all of the specific practices in this process area, from the preparation for product integration all the way through to
the delivery of the final product.

GP 2.3 (AB 3) Provide Resources
Provide adequate resources for performing the product integration process, developing the work products, and providing the services of the process.

Elaboration:
Product-component interface coordination may be accomplished with an Interface Control Working Group consisting of people who represent external and internal interfaces. Such groups can be used to elicit needs for interface requirements development.
Special facilities may be required for assembling and delivering the product. When necessary, the facilities required for the activities in the Product Integration process area are developed or purchased.
Examples of other resources provided include the following tools:
· Prototyping tools
· Analysis tools
· Simulation tools
· Interface management tools
· Assembly tools (e.g., compilers, make files, joining tools, jigs and fixtures)

GP 2.4 (AB 4) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the product integration process.

GP 2.5 (AB 5) Train People
Train the people performing or supporting the product integration
process as needed. [GP107]
Elaboration:
Examples of training topics include the following: [PA147.EL105]
· Application domain
· Product integration procedures and criteria
· Organization's facilities for integration and assembly
· Assembly methods
· Packaging standards

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the product integration process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Acceptance documents for the received product components
· Evaluated assembled product and product components
· Product integration sequence
· Product integration procedures and criteria
· Updated interface description or agreement

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the product integration 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:
· Reviewing interface descriptions for completeness
· Establishing the product integration sequence
· Establishing the product integration procedures and criteria
· Assembling and delivering the product and product components
· Communicating the results after evaluation
· Communicating new, effective product integration processes to give affected
people the opportunity to improve their performance

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the product integration process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Product-component integration profile (e.g., product-component assemblies planned and performed, and number of exceptions found)
· Integration evaluation problem report trends (e.g., number written and number closed)
· Integration evaluation problem report aging (i.e., how long each problem report has been open)

GP 3.2 (DI 4) Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the product integration process to support the future use and improvement of the organization’s processes and process assets.

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the product integration process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Establishing and maintaining a product integration sequence
· Ensuring interface compatibility
· Assembling product components and delivering the product

Examples of work products reviewed include the following:
· Product integration sequence
· Product integration procedures and criteria
· Acceptance documents for the received product components
· Assembled product and product components

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the product integration process with higher level management and resolve issues.

Product Integration : Specific Practices by Goal SG3

2007-10-11T03:40:00.000-07:00

Assemble Product Components and Deliver the Product
Verified product components are assembled and the integrated, verified, and validated product is delivered.
Integration of product components proceeds according to the product integration sequence and available procedures. Before integration, each product component should be confirmed to be compliant with its
interface requirements. Product components are assembled into larger, more complex product components. These assembled product components are checked for correct interoperation. This process continues until product integration is complete. If, during this process, problems are identified, the problem should be documented and a corrective action process initiated.
Ensure that the assembly of the product components into larger and more complex product components is conducted according to the product integration sequence and available procedures. The timely receipt of needed product components and the involvement of the right people contribute to the successful integration of the product components that compose the product.

SP 3.1 Confirm Readiness of Product Components for Integration
Confirm, prior to assembly, that each product component required to assemble the product has been properly identified, functions according to its description, and that the product-component interfaces comply with the interface descriptions.
The purpose of this specific practice is to ensure that the properly identified product component that meets its description can actually be assembled according to the product integration sequence and available
procedures. The product components are checked for quantity, obvious damage, and consistency between the product component and interface descriptions.
Those conducting product integration are ultimately responsible for checking to make sure everything is proper with the product components before assembly.
Typical Work Products
1. Acceptance documents for the received product components
2. Delivery receipts
3. Checked packing lists
4. Exception reports
5. Waivers
Subpractices
1. Track the status of all product components as soon as they become available for integration.
2. Ensure that product components are delivered to the product integration environment in accordance with the product integration sequence and available procedures.
3. Confirm the receipt of each properly identified product component.
4. Ensure that each received product component meets its description.
5. Check the configuration status against the expected configuration.
6. Perform pre-check (for example, by a visual inspection and using basic measures) of all the physical interfaces before connecting product components together.

SP 3.2 Assemble Product Components
Assemble product components according to the product integration sequence and available procedures.
(For users of the continuous representation, this is a capability level 1 specific practice. Product integration processes at capability level 1 or 2 may not include procedures and criteria, which are created in the
Establish Product Integration Procedures and Criteria specific practice at capability level 3. When there are no procedures or criteria established, use the sequence established by the Determine Integration
Sequence specific practice to accomplish capability level 1 performance.) The assembly activities of this specific practice and the evaluation activities of the next specific practice are conducted iteratively, from the
initial product components, through the interim assemblies of product components, to the product as a whole.

For Supplier Sourcing
The project should exercise reasonable oversight of these assembly processes. The supplier agreements should specify appropriate oversight for critical components.

Typical Work Products
1. Assembled product or product components
Subpractices
1. Ensure the readiness of the product integration environment.
2. Ensure that the assembly sequence is properly performed.
Record all appropriate information (e.g., configuration status, serial numbers of the product components, types, and calibration date of the meters).
3. Revise the product integration sequence and available procedures as appropriate.

SP 3.3 Evaluate Assembled Product Components
Evaluate assembled product components for interface compatibility. This evaluation involves examining and testing assembled product components for performance, suitability, or readiness using the available procedures and environment. It is performed as appropriate for different stages of assembly of product components as identified in the product integration sequence and available procedures. The product integration sequence and available procedures may define a more refined integration and evaluation sequence than might be envisioned just by examining the product architecture. For example, if
an assembly of product components is composed of four less complex product components, the integration sequence will not necessarily call for the simultaneous integration and evaluation of the four units as one.
Rather, the four less complex units may be integrated progressively, one at a time, with an evaluation after each assembly operation prior to realizing the more complex product component that matched the
specification in the product architecture. Alternatively, the integration sequence and available procedures could have determined that only a final evaluation was the best one to perform.

Typical Work Products
1. Exception reports
2. Interface evaluation reports
3. Product integration summary reports
Subpractices
1. Conduct the evaluation of assembled product components following the product integration sequence and available procedures.
2. Record the evaluation results.
Example results include the following:
· Any adaptation required to the integration procedure
· Any change to the product configuration (spare parts, new release)
· Evaluation procedure deviations

SP 3.4 Package and Deliver the Product or Product Component
Package the assembled product or product component and deliver it to the appropriate customer.
The packaging requirements for some products may be addressed in their specifications and verification criteria. This is especially important when items are stored and transported by the customer. In such cases,
there may be a spectrum of environmental and stress conditions specified for the package. In other circumstances, factors such as the following may become important:
· Economy and ease of transportation (e.g., containerization)
· Accountability (e.g., shrinkwrapping)
· Ease and safety of unpacking (e.g., sharp edges, strength of binding methods, childproofing, environmental friendliness of packing material, weight)
The adjustment required to fit product components together in the factory could be different from the one required to fit product components when installed on the operational site. In that case, the product's logbook for the customer should be used to record such specific parameters.

Typical Work Products
1. Packaged product or product components
2. Delivery documentation
Subpractices
1. Review the requirements, design, product, verification results, and documentation to ensure that issues affecting the packaging and delivery of the product are identified and resolved.
2. Use effective methods to package and deliver the assembled product.

For Software Engineering
Examples of software packaging and delivery methods include the following:
· Magnetic tape
· Diskettes
· Hardcopy documents
· Compact disks
· Other electronic distribution such as the Internet
3. Satisfy the applicable requirements and standards for packaging and delivering the product.

For Software Engineering
Examples of requirements and standards for packaging and delivering the software include the following:
· Type of storage and delivery media
· Custodians of the master and backup copies of the software
· Required documentation
· Copyrights
· License provisions
· Security of the software

For Systems Engineering
Examples of requirements and standards include those for safety, the environment, security, and transportability.
4. Prepare the operational site for installation of the product.
Preparing the operational site may be the responsibility of the customer or end users.
5. Deliver the product and related documentation and confirm receipt.
6. Install the product at the operational site and confirm correct operation.
Installing the product may be the responsibility of the customer or end users. In some circumstances, very little may need to be done to confirm correct operation. In other circumstances, final verification of the integrated product occurs at the operational site.

Product Integration : Specific Practices by Goal SG2

2007-10-01T21:37:00.000-07:00

Ensure Interface Compatibility
The product-component interfaces, both internal and external, are compatible.
Many product integration problems arise from unknown or uncontrolled aspects of both internal and external interfaces. Effective management of product-component interface requirements, specifications, and
designs helps ensure that implemented interfaces will be complete and compatible.

SP 2.1 Review Interface Descriptions for Completeness
Review interface descriptions for coverage and completeness.
The interfaces should include, in addition to product-component interfaces, all the interfaces with the product integration environment.

Typical Work Products
1. Categories of interfaces
2. List of interfaces per category
3. Mapping of the interfaces to the product components and product integration environment
Subpractices
1. Review interface data for completeness and ensure complete coverage of all interfaces.
Consider all the product components and prepare a relationship table. Interfaces are usually classified in three main classes: environmental, physical, and functional. Typical categories for these classes include the following: mechanical, fluid, sound, electrical, climatic, electromagnetic, thermal, message, and the
human-machine or human interface.

For Software Engineering
In the message category for software, interfaces include the following:
· Origination
· Destination
· Stimulus
· Protocols and data characteristics

For Systems Engineering
For mechanical and electronic components, the interface data should include the following:
· Mechanical interfaces (e.g., weight and size, center of gravity, clearance of parts in operation, space required for maintenance, fixed links, mobile links, shocks and vibrations received from the bearing structure)
· Noise interfaces (e.g., noise transmitted by the structure, noise transmitted in the air, acoustics)
· Climatic interfaces (e.g., temperature, humidity, pressure,salinity)
· Thermal interfaces (e.g., heat dissipation, transmission of heat to the bearing structure, air conditioning characteristics)
· Fluid interfaces (e.g., fresh water inlet/outlet, seawater inlet/outlet for a naval/coastal product, air conditioning, compressed air, nitrogen, fuel, lubricating oil, exhaust gas outlet)
· Electrical interfaces (e.g., power supply consumption by network with transients and peak values; non-sensitive control signal for power supply, communications, etc.; sensitive signal [analog links]; disturbing signal [microwave,etc.]; grounding signal to comply with the TEMPEST standard)
· Electromagnetic interfaces (e.g., magnetic field, radio and radar links, optical band link wave guides, coaxial and optical fibers)
· Human-machine interface (e.g., audio or voice synthesis, audio or voice recognition, display [analog dial, TV screen, or liquid crystal display, indicators' light emitting diodes], manual controls [pedal, joystick, ball, keys, push buttons, touch screen])
2. Ensure that product components and interfaces are marked to ensure easy and correct connection to the joining product component.
3. Periodically review the adequacy of interface descriptions.

Once established, the interface descriptions must be periodically reviewed to ensure there is no deviation between the existing descriptions and the products being developed, processed, produced, or bought.

For Supplier Sourcing
The interface descriptions for product components should be reviewed with relevant suppliers to avoid misinterpretations, reduce delays, and prevent the development of interfaces that do not work properly.

SP 2.2 Manage Interfaces
Manage internal and external interface definitions, designs, and changes for products and product components.
Interface requirements drive the development of the interfaces necessary to integrate product components. Managing product and product-component interfaces starts very early in the development of the product. The definitions and designs for interfaces affect not only the product components and external systems, but can also affect the verification and validation environments.
Management of the interfaces includes maintenance of the consistency of the interfaces throughout the life of the product, and resolution of conflict, noncompliance, and change issues.
The interfaces should include, in addition to product-component interfaces, all the interfaces with the environment as well as other environments for verification, validation, operations, and support.
The interface changes are documented, maintained, and readily accessible.

Typical Work Products
1. Table of relationships among the product components and the external environment (e.g., main power supply, fastening product, computer bus system)
2. Table of relationships between the different product components
3. List of agreed-to interfaces defined for each pair of product components, when applicable
4. Reports from the interface control working group meetings
5. Action items for updating interfaces
6. Application program interface (API)
7. Updated interface description or agreement
Subpractices
1. Ensure the compatibility of the interfaces throughout the life of the product.
2. Resolve conflict, noncompliance, and change issues.
3. Maintain a repository for interface data accessible to project participants.
A common accessible repository for interface data provides a mechanism to ensure that everyone knows where the current interface data resides and can access it for use.

Product Integration: Specific Practice by Goal SG1

2007-10-01T03:49:00.000-07:00

SG 1 Prepare for Product Integration
Preparation for product integration is conducted.

Preparing for integration of product components involves establishing and maintaining an integration sequence, the environment for performing the integration, and integration procedures. The specific
practices of the Prepare for Product Integration specific goal build on each other in the following way. The first specific practice determines the sequence for product and product-component integration. The
second determines the environment that will be used to carry out the product and product-component integration. The third develops procedures and criteria for product and product-component integration.
Preparation for integration starts early in the project and the integration sequence is developed concurrently with the practices in the Technical Solution process area.

SP 1.1 Determine Integration Sequence
Determine the product-component integration sequence.
The product components that are integrated may include those that are a part of the product to be delivered along with test equipment, test software, or other integration items such as fixtures. Once you have
analyzed alternative test and assembly integration sequences, select the best integration sequence.
The product integration sequence can provide for incremental assembly and evaluation of product components that provide a problem-free foundation for incorporation of other product components as they
become available, or for prototypes of high-risk product components.
The integration sequence should be harmonized with the selection of solutions and the design of product and product components in the Technical Solution process area.

Typical Work Products
1. Product integration sequence
2. Rationale for selecting or rejecting integration sequences
Subpractices
1. Identify the product components to be integrated.
2. Identify the product integration verifications to be performed using
the definition of the interfaces between the product components.
3. Identify alternative product-component integration sequences.
This can include defining the specific tools and test equipment to support the product integration.
4. Select the best integration sequence.
5. Periodically review the product integration sequence and revise as needed.
Assess the product integration sequence to ensure that variations in production and delivery schedules have not had an adverse impact on the sequence or compromised the factors upon which earlier decisions were made.
6. Record the rationale for decisions made and deferred.

SP 1.2 Establish the Product Integration Environment
Establish and maintain the environment needed to support the integration of the product components.

The environment for product integration can either be acquired or developed. To establish an environment, requirements for the purchase or development of equipment, software, or other resources will need to
be developed. These requirements are gathered when implementing the processes associated with the Requirements Development process area. The product integration environment may include the reuse of
existing organizational resources. The decision to acquire or develop the product integration environment is addressed in the processes associated with the Technical Solution process area.

The environment required at each step of the product integration process may include test equipment, simulators (taking the place of nonavailable product components), pieces of real equipment, and
recording devices.

Typical Work Products
1. Verified environment for product integration
2. Support documentation for the product integration environment
Subpractices
1. Identify the requirements for the product integration environment.
2. Identify verification criteria and procedures for the product integration environment.
3. Decide whether to make or buy the needed product integration environment.
4. Develop an integration environment if a suitable environment cannot be acquired.
For unprecedented, complex projects, the product integration environment can be a major development. As such, it would involve project planning, requirements development, technical solutions, verification, validation, and risk management.
5. Maintain the product integration environment throughout the project.
6. Dispose of those portions of the environment that are no longer useful.

SP 1.3 Establish Product Integration Procedures and Criteria
Establish and maintain procedures and criteria for integration of the product components.
Procedures for the integration of the product components can include such things as the number of incremental iterations to be performed and details of the expected tests and other evaluations to be carried out at each stage.
Criteria can indicate the readiness of a product component for integration or its acceptability.
Procedures and criteria for product integration address the following:
· Level of testing for build components
· Verification of interfaces
· Thresholds of performance deviation
· Derived requirements for the assembly and its external interfaces
· Allowable substitutions of components
· Testing environment parameters
· Limits on cost of testing
· Quality/cost tradeoffs for integration operations
· Probability of proper functioning
· Delivery rate and its variation
· Lead time from order to delivery
· Personnel availability
· Availability of the integration facility/line/environment
Criteria can be defined for how the product components are to be verified and the functions they are expected to have. Criteria can be defined for how the assembled product components and final integrated
product are to be validated and delivered.
Criteria may also constrain the degree of simulation permitted for a product component to pass a test, or may constrain the environment to be used for the integration test.

For Supplier Sourcing
Pertinent parts of the schedule and criteria for assembly should be shared with suppliers of work products to reduce the occurrence of delays and component failure.

Typical Work Products
1. Product integration procedures
2. Product integration criteria
Subpractices
1. Establish and maintain product integration procedures for the product components.
2. Establish and maintain criteria for product-component integration and evaluation.
3. Establish and maintain criteria for validation and delivery of the integrated product.

Product Integration: CMMI Maturity Level 3

2007-10-01T03:39:00.000-07:00

Product Integration
This process area addresses the integration of product components into more complex product components or into complete products. The term “integration” is used in this sense throughout this process area and is
not to be confused with integration of people or activities that may be described elsewhere in the model.
The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration sequence and procedures.

A critical aspect of product integration is the management of internal and external interfaces of the products and product components to ensure compatibility among the interfaces. Attention should be paid to
interface management throughout the project.

Product integration is more than just a one-time assembly of the product components at the conclusion of design and fabrication. Product integration can be conducted incrementally, using an iterative process of assembling product components, evaluating them, and then assembling more product components. This process may begin with analysis and simulations (e.g., threads, rapid prototypes, virtual prototypes, and physical prototypes) and steadily progress through increasingly more realistic incremental functionality until the final product is achieved. In each successive build, prototypes (virtual, rapid,or physical) are constructed, evaluated, improved, and reconstructed based upon knowledge gained in the evaluation process. The degree of virtual vs. physical prototyping required depends on the functionality of the design tools, the complexity of the product, and its associated risk.

There is a high probability that the product, integrated in this manner, will pass product verification and validation. For some products, the last integration phase will occur when the product is deployed at its intended operational site.

Specific and Generic Goals
SG 1 Prepare for Product Integration
Preparation for product integration is conducted.
SG 2 Ensure Interface Compatibility
The product-component interfaces, both internal and external, are compatible.
SG 3 Assemble Product Components and Deliver the Product
Verified product components are assembled and the integrated, verified, and validated product is delivered.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Prepare for Product Integration
SP 1.1 Determine Integration Sequence
SP 1.2 Establish the Product Integration Environment
SP 1.3 Establish Product Integration Procedures and Criteria

SG 2 Ensure Interface Compatibility
SP 2.1 Review Interface Descriptions for Completeness
SP 2.2 Manage Interfaces

SG 3 Assemble Product Components and Deliver the Product
SP 3.1 Confirm Readiness of Product Components for Integration
SP 3.2 Assemble Product Components
SP 3.3 Evaluate Assembled Product Components
SP 3.4 Package and Deliver the Product or Product Component

GG 3 Institutionalize a Defined Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 3.1 (AB 1) Establish a Defined Process
GP 2.2 (AB 2) Plan the Process
GP 2.3 (AB 3) Provide Resources
GP 2.4 (AB 4) Assign Responsibility
GP 2.5 (AB 5) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 3.2 (DI 4) Collect Improvement Information
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

Technichal Solution : Institutionalize a Defined Process GG3

2007-10-01T00:09:00.000-07:00

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the technical solution process.
Elaboration:
This policy establishes organizational expectations for addressing the iterative cycle in which product-component solutions are selected, product and product-component designs are developed, and the
product-component designs are implemented.

Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined technical solution process.

GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the technical solution process.
Elaboration:
Typically, this plan for performing the technical solution process is a part of the project plan as described in the Project Planning process area.

GP 2.3 (AB 3) Provide Resources
Provide adequate resources for performing the technical solution process, developing the work products, and providing the services of the process.
Elaboration:
Special facilities may be required for developing, designing, and implementing solutions to requirements. When necessary, the facilities required for the activities in the Technical Solution process area are
developed or purchased.
Examples of other resources provided include the following tools:
· Design specification tools
· Simulators and modeling tools
· Prototyping tools
· Scenario definition and management tools
· Requirements tracking tools
· Interactive documentation tools

GP 2.4 (AB 4) Assign Responsibility
Assign responsibility and authority for performing the process,developing the work products, and providing the services of the technical solution process.

GP 2.5 (AB 5) Train People
Train the people performing or supporting the technical solution process as needed.
Elaboration:
Examples of training topics include the following:
· Application domain of the product and product components
· Design methods
· Interface design
· Unit testing techniques
· Standards (e.g., product, safety, human factors, environmental)

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the technical solution process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Product, product component, process, service, and interface designs
· Technical data packages
· Interface design documents
· Criteria for design and product-component reuse
· Implemented designs (e.g., software code, fabricated product components)
· User, installation, operation, and maintenance documentation

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the technical solution 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:
· Developing alternative solutions and selection criteria
· Evolving operational concept and scenarios
· Obtaining approval on external interface specifications and design descriptions
· Developing the technical data package
· Assessing the make, buy, or reuse alternatives for product components
· Implementing the design

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the technical solution process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Cost, schedule, and effort expended for rework
· Percentage of requirements addressed in the product or product-component design
· Size and complexity of the product, product components, interfaces, and documentation
· Defect density of technical solutions work products

GP 3.2 (DI 4) Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing
the technical solution process to support the future use and improvement of the organization’s processes and process assets.

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the technical solution process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Selecting product-component solutions
· Developing product and product-component designs
· Implementing product-component designs

Examples of work products reviewed include the following:
· Technical data packages
· Product, product-component, and interface designs
· Implemented designs (e.g., software code, fabricated product components)
· User, installation, operation, and maintenance documentation

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the technical solution process with higher level management and resolve issues.

Technichal Solution : Specific Practices by Goal SG3

2007-09-23T22:27:00.000-07:00

Implement the Product Design
Product components, and associated support documentation, are implemented from their designs.
Product components are implemented from the designs established by the specific practices in the Develop the Design specific goal. The implementation usually includes unit testing of the product components
before sending them to product integration and development of enduser documentation.

SP 3.1 Implement the Design
Implement the designs of the product components.
For Software Engineering
Software code is a typical software product component.
Once the design has been completed, it is implemented as a product component. The characteristics of that implementation depend on the type of product component.
Design implementation at the top level of the product hierarchy involves the specification of each of the product components at the next level of the product hierarchy. This activity includes the allocation, refinement, and verification of each product component. It also involves the coordination between the various product-component development efforts.
Example characteristics of this implementation are as follows:
· Software is coded.
· Data is documented.
· Services are documented.
· Electrical and mechanical parts are fabricated.
· Product-unique manufacturing processes are put into operation.
· Processes are documented.
· Facilities are constructed.
· Materials are produced (e.g., a product-unique material could be a petroleum, oil, or lubricant, or a new alloy).
Typical Work Products
1. Implemented design
Subpractices
1. Use effective methods to implement the product components.

For Software Engineering
Examples of software coding methods include the following:
· Structured programming
· Object-oriented programming
· Automatic code generation
· Software code reuse
· Use of applicable design patterns

For Systems Engineering
Examples of appropriate fabrication methods include the following:
· Casting
· Molding
· Forming
· Joining
· Machining
· Tooling
· Welding
· Extruding
2. Adhere to applicable standards and criteria.

For Software Engineering
Examples of software coding standards include the following:
· Language standards
· Naming conventions for variables
· Acceptable language structures
· Structure and hierarchy of software product components
· Format of code and comments

For Software Engineering
Examples of software coding criteria include the following:
· Modularity
· Clarity
· Simplicity
· Structured (e.g., no GOTOs, one entrance, and one exit)
· Maintainability

For Systems Engineering
Examples of standards include the following:
· Standard Parts Lists
· Standard drawing requirements
· International Organization for Standardization (ISO) T3303 standards for manufactured parts

For Systems Engineering
Examples of criteria include the following:
· Maintainability
· Reliability
· Safety
3. Conduct peer reviews of the selected product components.
4. Perform unit testing of the product component as appropriate.
Note that unit testing is not limited to software. Unit testing involves the testing of individual hardware or software units or groups of related items prior to integration of those items.
5. Revise the product component as necessary.
An example of when the product component may need to be revised is when problems surface during implementation that could not be foreseen during design.

SP 3.2 Develop Product Support Documentation
Develop and maintain the end-use documentation.
This specific practice develops and maintains the documentation that will be used to install, operate, and maintain the product.

Typical Work Products
1. End-user training materials
2. User's manual
3. Operator's manual
4. Maintenance manual
5. Online help

Subpractices
1. Review the requirements, design, product, and test results to ensure that issues affecting the installation, operation, and maintenance documentation are identified and resolved.
2. Use effective methods to develop the installation, operation, and maintenance documentation.
3. Adhere to the applicable documentation standards.
Examples of documentation standards include the following:
· Compatibility with designated word processors
· Acceptable fonts
· Numbering of pages, sections, and paragraphs
· Consistency with a designated style manual
· Use of abbreviations
· Security classification markings
· Internationalization requirements
4. Develop preliminary versions of the installation, operation, and maintenance documentation in early phases of the project life cycle for review by the relevant stakeholders.
5. Conduct peer reviews of the installation, operation, and maintenance documentation.
6. Revise the installation, operation, and maintenance documentation as necessary.
Examples of when documentation may need to be revised include when the following events occur:
· Requirements change
· Design changes are made
· Product changes are made
· Documentation errors are identified
· Workaround fixes are identified

Technichal Solution : Specific Practices by Goal SG2

2007-09-23T21:43:00.000-07:00

Develop the Design
Product or product-component designs are developed.
Product or product-component designs must provide the appropriate content not only for implementation, but also for other phases of the product life cycle such as modification, reprocurement, maintenance,
sustainment, and installation. The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during
development and in subsequent phases of the product life cycle. A complete design description is documented in a technical data package that includes a full range of features and parameters including form, fit, function, interface, manufacturing process characteristics, and other parameters. Established organizational or project design standards (e.g., checklists, templates, object frameworks) form the basis for
achieving a high degree of definition and completeness in design documentation.

For Integrated Product and Process Development
The integrated teams develop the designs of the appropriate product-related life-cycle processes concurrently with the design of the product. These processes may be selected without modification from the organization’s set of standard processes, if appropriate.

SP 2.1 Design the Product or Product Component
Develop a design for the product or product component.
Product design consists of two broad phases that may overlap in execution: preliminary and detailed design. Preliminary design establishes product capabilities and the product architecture, including product partitions, product-component identifications, system states and modes, major intercomponent interfaces, and external product interfaces. Detailed design fully defines the structure and capabilities of the product components.
Architecture definition is driven from a set of architectural requirements developed during the requirements development processes. These requirements express the qualities and performance points that are critical to the success of the product. The architecture defines structural elements and coordination mechanisms that either directly satisfy requirements or support the achievement of the requirements as the details of the product design are established. Architectures may include standards and design rules governing development of product components and their interfaces as well as guidance to aid product developers. Specific practices in the Select Product-Component Solutions specific goal contain more information about using product architectures as a basis for alternative solutions.
Architects postulate and develop a model of the product, making judgments about allocation of requirements to product components including hardware and software. Multiple architectures, supporting alternative solutions, may be developed and analyzed to determine the advantages and disadvantages in the context of the architectural requirements.
Operational concepts and scenarios are used to generate use cases and quality scenarios that are used to refine the architecture. They are also used as a means to evaluate the suitability of the architecture for
its intended purpose during architecture evaluations, which are conducted periodically throughout product design. The Evolve Operational Concepts and Scenarios specific practice gives more information about elaborating operational concepts and scenarios used in architecture evaluation.

For Software Engineering
In addition to tasks identified above, software architecture definition may include:
· Establishing the structural relations of partitions and rules regarding interfaces between elements within partitions, and between partitions
· Identifying major internal interfaces and all external interfaces of software
· Identifying software product components
· Defining software coordination mechanisms
· Establishing infrastructure capabilities and services
· Developing product-component templates or classes and frameworks
· Establishing design rules and authority for making decisions
· Defining a process/thread model
· Defining physical deployment of software to hardware
· Identifying major reuse approaches and sources
During detailed design, the product architecture details are finalized, product components are completely defined, and interfaces are fully characterized. Product-component designs may be optimized for certain
qualities or performance characteristics. Designers may evaluate the use of legacy or COTS products for the product components. As the design matures, the requirements assigned to lower level product components are tracked to ensure those requirements are satisfied.

For Software Engineering
Detailed design is focused on software product-component development.The internal structure of product components is defined, data schema are generated, algorithms are developed, and heuristics are established to provide product-component capabilities that satisfy allocated requirements.

Typical Work Products
1. Product architecture
2. Product-component designs
Subpractices
1. Establish and maintain criteria against which the design can be evaluated.
Examples of attributes, in addition to expected performance, for which design criteria can be established, include the following:
· Modular
· Clear
· Simple
· Maintainable
· Verifiable
· Portable
· Reliable
· Accurate
· Secure
· Scalable
· Usable
2. Identify, develop, or acquire the design methods appropriate for the product.
Effective design methods can embody a wide range of activities, tools, and descriptive techniques. Whether a given method is effective or not depends on the situation. Two companies may have very effective design methods for products in which they specialize, but these methods may not be effective in cooperative
ventures. Highly sophisticated methods are not necessarily effective in the hands of designers that have not been trained in the use of the methods.
Whether or not a method is effective also depends on how much assistance it provides the designer, and the cost effectiveness of that assistance. For example, a multiyear prototyping effort may not be appropriate for a simple product component but might be the right thing to do for an unprecedented, expensive, and complex product development. Rapid prototyping techniques, however, may be highly effective for many product components. Methods that use tools to ensure that a design will encompass all the necessary attributes needed to implement the product-component design can be very effective. For example, a design tool that “knows” the capabilities of the manufacturing processes can allow the variability of the manufacturing process to be accounted for in the design tolerances.
Examples of techniques and methods that facilitate effective design include the following:
· Prototypes
· Structural models
· Object-oriented design
· Essential systems analysis
· Entity relationship models
· Design reuse
· Design patterns
3. Ensure that the design adheres to applicable design standards and criteria.
Examples of design standards include the following (some or all of these standards may be design criteria, particularly in circumstances where the standards have not been established):
· Operator interface standards
· Safety standards
· Production constraints
· Design tolerances
· Parts standards (e.g., production scrap and waste)
4. Ensure that the design adheres to allocated requirements.
Identified COTS product components must be taken into account. For example, putting existing product components into the product architecture might modify the requirements and the requirements allocation.
5. Document the design.

SP 2.2 Establish a Technical Data Package
Establish and maintain a technical data package.A technical data package provides the developer with a comprehensive description of the product or product component as it is developed. Such a package also provides procurement flexibility in a variety of circumstances such as performance-based contracting or build to print. The design is recorded in a technical data package that is created during preliminary design to document the architecture definition. Thistechnical data package is maintained throughout the life of the productto record essential details of the product design. The technical datapackage provides the description of a product or product component(including product-related life-cycle processes if not handled asseparate product components) that supports an acquisition strategy, or the implementation, production, engineering, and logistics support phases of the product life cycle. The description includes the definition of the required design configuration and procedures to ensure adequacy of product or product-component performance. It includes all applicable technical data such as drawings, associated lists,specifications, design descriptions, design databases, standards,performance requirements, quality assurance provisions, and packaging details. The technical data package includes a description ofthe selected alternative solution that was chosen for implementation.
A technical data package should include the following if such information is appropriate for the type of product and product component (for example, material and manufacturing requirements maynot be useful for product components associated with software servicesor processes):
· Product architecture description
· Allocated requirements
· Product-component descriptions
· Product-related life-cycle process descriptions, if not described asseparate product components
· Key product characteristics
· Required physical characteristics and constraints
· Interface requirements
· Materials requirements (bills of material and materialcharacteristics)
· Fabrication and manufacturing requirements (for both the originalequipment manufacturer and field support)
· The verification criteria used to ensure that requirements havebeen achieved
· Conditions of use (environments) and operating/usage scenarios,modes and states for operations, support, training, manufacturing,disposal, and verifications throughout the life of the product· Rationale for decisions and characteristics (requirements,requirement allocations, and design choices)
Because design descriptions can involve a very large amount of data and be crucial to successful product-component development, it is advisable to establish criteria for organizing the data and for selecting
the data content. It is particularly useful to use the product architecture as a means of organizing this data and abstracting views that are clear and relevant to an issue or feature of interest. These views include the
following:
· Customers
· Requirements
· The environment
· Functional
· Logical
· Security
· Data
· States/modes
· Construction
· Management
These views are documented in the technical data package.

Typical Work Products
1. Technical data package
Subpractices
1. Determine the number of levels of design and the appropriate level of documentation for each design level.
Determining the number of levels of product components (e.g., subsystem,hardware configuration item, circuit board, computer software configuration item [CSCI], computer software product component, computer software unit) that require documentation and requirements traceability is important to manage
documentation costs and to support integration and verification plans.
2. Base detailed design descriptions on the allocated product component requirements, architecture, and higher level designs.
3. Document the design in the technical data package.
4. Document the rationale for key (i.e., significant effect on cost, schedule, or technical performance) decisions made or defined.
5. Revise the technical data package as necessary.

SP 2.3 Design Interfaces Using Criteria
Design comprehensive product-component interfaces in terms of established and maintained criteria.
Interface designs include the following:
· Origination
· Destination
· Stimulus and data characteristics for software
· Electrical, mechanical, and functional characteristics for hardware
The criteria for interfaces frequently reflect a comprehensive list of critical parameters that must be defined, or at least investigated, to ascertain their applicability. These parameters are often peculiar to a given type of product (e.g., software, mechanical, electrical) and are often associated with safety, security, durability, and mission-critical characteristics.

Typical Work Products
1. Interface design specifications
2. Interface control documents
3. Interface specification criteria
4. Rationale for selected interface design
Subpractices
1. Define interface criteria.
These criteria can be a part of the organizational process assets.
2. Apply the criteria to the interface design alternatives.
3. Document the selected interface designs and the rationale for the
selection.

SP 2.4 Perform Make, Buy, or Reuse Analyses
Evaluate whether the product components should be developed, purchased, or reused based on established criteria.
The determination of what products or product components will be acquired is frequently referred to as a “make-or-buy analysis.” It is based on an analysis of the needs of the project. This make-or-buy analysis begins early in the project during the first iteration of design, continues during the design process, and is completed with the decision to develop, acquire, or reuse the product
Factors affecting the make-or-buy decision include the following:
· Functions the products or services will provide and how these functions will fit into the project
· Available project resources and skills
· Costs of acquiring versus developing internally
· Critical delivery and integration dates
· Strategic business alliances, including high-level business requirements
· Market research of available products, including COTS products
· Functionality and quality of available products
· Skills and capabilities of potential suppliers
· Impact on core competencies
· Licenses, warranties, responsibilities, and limitations associated with products being acquired
· Product availability
· Proprietary issues
· Risk reduction
Many of these factors are addressed by the project.
The make-or-buy decision can be conducted using a formal evaluation
approach.
As technology evolves, so does the rationale for choosing to develop or purchase a product component. While complex development efforts may favor purchasing an off-the-shelf product component, advances in
productivity and tools may provide an opposing rationale. Off-the-shelf products may have incomplete or inaccurate documentation and may or may not be supported in the future.
Once the decision is made to purchase an off-the-shelf product component, the requirements are used to establish a supplier agreement. There are times when “off the shelf” refers to an existing item that may not be readily available in the marketplace. For example, some types of aircraft and engines are not truly “off the shelf” but can be readily procured. In some cases the use of such non-developed items is in situations where the specifics of the performance and other product characteristics expected need to be within the limits specified.In these cases, the requirements and acceptance criteria may need to be included in the supplier agreement and managed. In other cases, the off-the-shelf product is literally off the shelf (word processing software, for example) and there is no agreement with the supplier that needs to be managed.

Typical Work Products
1. Criteria for design and product-component reuse
2. Make-or-buy analyses
3. Guidelines for choosing COTS product components

Subpractices
1. Develop criteria for the reuse of product-component designs.
2. Analyze designs to determine if product components should be developed, reused, or purchased.
3. When purchased or non-developmental (COTS, government off the shelf, and reuse) items are selected, plan for their maintenance.

For Software Engineering
Consider how the compatibility of future releases of an operating system and a database manager will be handled.

Technichal Solution : Specific Practices by Goal SG1

2007-09-17T00:22:00.000-07:00

This article provides information about selecting product component solutions considering the major areas, limitations, issues etc. The article defines the Technichal Solutions for the product-component solutions based on CMMI standards.

SG 1 Select Product-Component Solutions
Product or product-component solutions are selected from alternative solutions.
Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis.
Architectural features that provide a foundation for product improvement and evolution are considered. Use of commercial off-the-shelf (COTS) product components are considered relative to cost, schedule,
performance, and risk. COTS alternatives may be used with or without modification. Sometimes such items may require modifications to aspects such as interfaces or a customization of some of the features to
better achieve product requirements.
One indicator of a good design process is that the design was chosen after comparing and evaluating it against alternative solutions. Decisions on architecture, custom development versus off the shelf, and product-component modularization are typical of the design choices that are addressed.
Sometimes the search for solutions examines alternative instances of the same requirements with no allocations needed to lower level product components. Such is the case at the bottom of the product architecture. There are also cases where one or more of the solutions are fixed (e.g., a specific solution is directed or available product components, such as COTS, are investigated for use).
In the general case, solutions are defined as a set. That is, when defining the next layer of product components, the solution for each of the product components in the set is established. The alternative
solutions are not only different ways of addressing the same requirements, but they also reflect a different allocation of requirements among the product components comprising the solution set. The objective is to optimize the set as a whole and not the individual pieces.There will be significant interaction with processes associated with the Requirements Development process area to support the provisional allocations to product components until a solution set is selected and final allocations established.
Product-related life-cycle processes are among the product-component solutions that are selected from alternative solutions. Examples of these product-related life-cycle processes are the manufacturing and the
support processes.

SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria
Develop detailed alternative solutions and selection criteria.
For Integrated Product and Process Development
The activity of selecting alternative solutions and issues to be subject to decision analyses and trade studies is accomplished by the involvement of relevant stakeholders. These stakeholders represent both business and technical functions and the concurrent development of the product and the product-related life-cycle processes (e.g., manufacturing,support, training, verification, and disposal). In this way, important issues surface earlier in product development than with traditional serial development and can be addressed before they become costly mistakes.
Detailed alternative solutions are an essential concept of the Technical Solution process area. They provide more accurate and comprehensive information about the solution than nondetailed alternatives. For example, characterization of performance based on design content rather than on simple estimating enables effective assessment and understanding of environment and operating concept impacts. Alternative solutions need to be identified and analyzed to enable the selection of a balanced solution across the life of the product in terms of cost, schedule, and technical performance. These solutions are based on proposed product architectures that address critical product qualities. Specific practices associated with the Develop the Design specific goal provide more information on developing potential product architectures that can be incorporated into alternative solutions for the product.
Alternative solutions span the acceptable range of cost, schedule, and performance. The product-component requirements are received and used along with design issues, constraints, and criteria to develop the
alternative solutions. Selection criteria would typically address costs (e.g., time, people, money), benefits (e.g., performance, capability,effectiveness), and risks (e.g., technical, cost, schedule).Considerations for detailed alternative solutions and selection criteria include the following:
· Cost (development, procurement, support, product life cycle)
· Technical performance
· Complexity of the product component and product-related life-cycle processes
· Robustness to product operating and use conditions, operating modes, environments, and variations in product-related life-cycle processes
· Product expansion and growth
· Technology limitations
· Sensitivity to construction methods and materials
· Risk
· Evolution of requirements and technology
· Disposal
· Capabilities and limitations of end users and operators

The considerations listed above are a basic set; organizations should develop screening criteria to narrow down the list of alternatives that are consistent with their business objectives. Product life-cycle cost, while
being a desirable parameter to minimize, may be outside the control of development organizations. A customer may not be willing to pay for features that cost more in the short term but ultimately decrease cost
over the life of the product. In such cases, customers should at least be advised of any potential for reducing life-cycle costs. The criteria used in selections of final solutions should provide a balanced approach to
costs, benefits, and risks.

Typical Work Products
1. Alternative solution screening criteria
2. Evaluations of new technologies
3. Alternative solutions
4. Selection criteria for final selection
Subpractices
1. Identify screening criteria to select a set of alternative solutions for consideration.
2. Identify technologies currently in use and new product technologies for competitive advantage.

The project should identify technologies applied to current products and processes and monitor the progress of currently used technologies throughout the life of the project. The project should identify, select, evaluate, and invest in new technologies to achieve competitive advantage. Alternative solutions could include
newly developed technologies, but could also include applying mature technologies in different applications or to maintain current methods.
3. Generate alternative solutions.
4. Obtain a complete requirements allocation for each alternative.
5. Develop the criteria for selecting the best alternative solution.
Criteria should be included that address design issues for the life of the product, such as provisions for more easily inserting new technologies or the ability to better exploit commercial products. Examples include criteria related to open design or open architecture concepts for the alternatives being evaluated.
6. Develop timeline scenarios for product operation and user interaction for each alternative solution.

The following specific practice appears in the continuous representation as SP 1.1-1, but is subsumed in the staged representation by SP 1.1, Develop Detailed Alternative Solutions and Selection Criteria. The specific practice is presented here only as informative material.

SP 1.1-1 Develop Alternative Solutions and Selection Criteria
Develop alternative solutions and selection criteria.
Alternatives are based on potential product architectures and span a design space of feasible solutions. The Design Product or Product Component specific practice of the Develop the Design specific goal
contains more information about developing potential product architectures to incorporate into alternative solutions for the product.
As selections are made, the design space may be constricted and other alternatives examined until the most promising (i.e., optimal) solutions that meet requirements and criteria are identified. The selection criteria
identify the key factors that provide a basis for the selection of the solution. These criteria should provide clear discrimination and an indication of success in arriving at a balanced solution across the life of
the product. They typically include measures of cost, schedule, performance, and risk.
The alternative solutions evaluated frequently encompass alternative requirement allocations to different product components. These alternatives may also be structured to evaluate the use of COTS solutions in the product architecture. Processes associated with the Requirements Development process area would then be employed to provide a more complete and robust provisional allocation of requirements to the alternative solutions.
Selection of the best solution establishes the requirements provisionally allocated to that solution as the set of allocated requirements. The circumstances in which it would not be useful to examine alternative
solutions are infrequent in new developments. However, developments of precedented product components are candidates for not examining, or only minimally examining, alternative solutions.

Typical Work Products
1. Alternative solutions
2. Selection criteria
Subpractices
1. Establish and maintain a process or processes for identifying solution alternatives, selection criteria, and design issues.
Selection criteria are influenced by a wide variety of factors driven by the requirements imposed on the project as well as the product life cycle. For example, criteria related to mitigating cost and schedule risks may influence a greater preference for COTS solutions provided such selections do not result in unacceptable risks for the remaining product components to be developed. When using existing items, such as COTS, either with or without modification, criteria dealing with diminishing sources of supply or technological obsolescence should be examined, as well as criteria capturing the benefits of standardization,
maintaining relationships with suppliers, and so forth. The criteria used in selections should provide a balanced approach to costs, benefits, and risks.

2. Identify alternative groupings of requirements that characterize sets of solution alternatives that span the feasible design space.

Effective employment of COTS alternatives can provide special challenges. Knowledgeable designers familiar with candidate COTS alternatives may explore architectural opportunities to exploit potential COTS payoffs.

3. Identify design issues for each solution alternative in each set of alternatives.

4. Characterize design issues and take appropriate action.

Appropriate action could be to characterize the issues as a risk for risk management, adjust the solution alternative to preclude the issues, or reject the solution alternative and replace it with a different alternative.

5. Obtain a complete requirements allocation for each alternative.

6. Document the rationale for each alternative set of solutions.

SP 1.2 Evolve Operational Concepts and Scenarios
Evolve the operational concept, scenarios, and environments to describe the conditions, operating modes, and operating states specific to each product component.
Operational concepts and scenarios are evolved to facilitate the selection of product-component solutions that, when implemented, will satisfy the intended use of the product. Operational concepts and
scenarios document the interaction of the product components with the environment, users, and other product components, regardless of engineering discipline. They should be documented for operations,
product deployment, delivery, support (including maintenance and sustainment), training, and disposal and for all modes and states.

The environments (operating, support, training, etc.) also need to be evolved. The environment of any given product component will be influenced by other product components as well as the external
environment.

Typical Work Products
1. Product-component operational concepts, scenarios, and environments for all product-related life-cycle processes (e.g., operations, support, training, manufacturing, deployment, fielding,delivery, and disposal)
2. Timeline analyses of product-component interactions
3. Use cases
Subpractices
1. Evolve the operational concepts and scenarios to a degree of detail appropriate for the product component.
2. Evolve the operational environments for the product components.

The environments may include thermal, stress, and electromagnetic and other elements that need to be documented.

SP 1.3 Select Product-Component Solutions
Select the product-component solutions that best satisfy the criteria established.

Selecting product components that best satisfy the criteria establishes the requirement allocations to product components. Lower level requirements are generated from the selected alternative and used to develop the product-component design. Interface requirements among product components are described, primarily functionally. Physical interface descriptions are included in the documentation for interfaces
to items and activities external to the product.
The description of the solutions and the rationale for selection are documented. The documentation evolves throughout development as solutions and detailed designs are developed and those designs are implemented. Maintaining a record of rationale is critical to downstream decision making. Such records keep downstream stakeholders from redoing work and provide insights to apply technology as it becomes available in applicable circumstances.

Typical Work Products
1. Product-component selection decisions and rationale
2. Documented relationships between requirements and product components
3. Documented solutions, evaluations, and rationale
Subpractices
1. Evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts, operating modes, and operating states.
2. Based on the evaluation of alternatives, assess the adequacy of the selection criteria and update these criteria as necessary.
3. Identify and resolve issues with the alternative solutions and requirements.
4. Select the best set of alternative solutions that satisfy the established selection criteria.
5. Establish the requirements associated with the selected set of alternatives as the set of allocated requirements to those product components.
6. Identify the product-component solutions that will be reused or acquired.
7. Establish and maintain the documentation of the solutions,evaluations, and rationale.

Technichal Solution : CMMI Maturity Level 3

2007-09-06T22:21:00.000-07:00

The purpose of Technical Solution is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle
processes either singly or in combinations as appropriate.

The Technical Solution process area is applicable at any level of the product architecture and to every product, product component, productrelated life-cycle process, and service. The process area focuses on the
following:
· Evaluating and selecting solutions (sometimes referred to as "design approaches," "design concepts," or "preliminary designs") that potentially satisfy an appropriate set of allocated requirements
· Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)
· Implementing the designs as a product or product component Typically, these activities interactively support each other
. Some level of design, at times fairly detailed, may be needed to select solutions.
Product-component prototypes may be used as a means of gaining sufficient knowledge to develop a technical data package or a complete set of requirements.
Technical Solution specific practices apply not only to the product and product components but also to services and product-related life-cycle processes. The product-related life-cycle processes are developed in
concert with the product or product component. Such development may include selecting and adapting existing processes (including standard processes) for use as well as developing new processes.

Processes associated with the Technical Solution process area receive the product and product-component requirements from the requirements management processes. The requirements management processes place the requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements.

For a maintenance or sustainment organization, the requirements in need of maintenance actions or redesign may be driven by user needs or latent defects in the product components. New requirements may arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where actual performance can be compared against the specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts.

Specific and Generic Goals
SG 1 Select Product-Component Solutions
Product or product-component solutions are selected from alternative solutions.
SG 2 Develop the Design
Product or product-component designs are developed.
SG 3 Implement the Product Design
Product components, and associated support documentation, are implemented from their designs.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Select Product-Component Solutions
SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria
SP 1.2 Evolve Operational Concepts and Scenarios
SP 1.3 Select Product-Component Solutions

SG 2 Develop the Design
SP 2.1 Design the Product or Product Component
SP 2.2 Establish a Technical Data Package
SP 2.3 Design Interfaces Using Criteria
SP 2.4 Perform Make, Buy, or Reuse Analyses

SG 3 Implement the Product Design
SP 3.1 Implement the Design
SP 3.2 Develop Product Support Documentation

GG 3 Institutionalize a Defined Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 3.1 (AB 1) Establish a Defined Process
GP 2.2 (AB 2) Plan the Process
GP 2.3 (AB 3) Provide Resources
GP 2.4 (AB 4) Assign Responsibility
GP 2.5 (AB 5) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 3.2 (DI 4) Collect Improvement Information
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

Requirement Development: GG 3 Institutionalize a Defined Process

2007-09-05T03:18:00.000-07:00

The process is institutionalized as a defined process.
Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the requirements development process.
Elaboration:
This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product-component requirements, and analyzing and validating those requirements.

Ability to Perform
GP 3.1 (AB 1) Establish a Defined Process
Establish and maintain the description of a defined requirements development process.

GP 2.2 (AB 2) Plan the Process
Establish and maintain the plan for performing the requirements development process.
Elaboration:
Typically, this plan for performing the requirements development process is a part of the project plan as described in the Project Planning process area.

GP 2.3 (AB 3) Provide Resources
Provide adequate resources for performing the requirements development process, developing the work products, and providing the services of the process.
Elaboration:
Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product-component requirements may be
required.
Examples of other resources provided include the following tools:
· Requirements specification tools
· Simulators and modeling tools
· Prototyping tools
· Scenario definition and management tools
· Requirements tracking tools

GP 2.4 (AB 4) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process.

GP 2.5 (AB 5) Train People
Train the people performing or supporting the requirements development process as needed.
Elaboration:
Examples of training topics include the following: [PA157.EL105]
· Application domain
· Requirements definition and analysis
· Requirements elicitation
· Requirements specification and modeling
· Requirements tracking

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the requirements development process under appropriate levels of configuration management.

Elaboration:
Examples of work products placed under configuration management include the following:
· Customer requirements
· Functional architecture
· Product and product-component requirements
· Interface requirements

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the requirements development 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:
· Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces
· Establishing operational concepts and scenarios
· Assessing the adequacy of requirements
· Establishing product and product-component requirements
· Assessing product cost, schedule, and risk

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the requirements development process against the plan for performing the process and take appropriate corrective action.

Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Cost, schedule, and effort expended for rework
· Defect density of requirements specifications

GP 3.2 (DI 4) Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements development process to support the future use and improvement of the organization’s processes and process assets.

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the requirements development process against its process description, standards, and procedures, and address noncompliance.

Elaboration:
Examples of activities reviewed include the following:
· Collecting stakeholder needs
· Formulating product and product-component requirements
· Analyzing and validating product and product-component requirements
Examples of work products reviewed include the following:
· Product requirements
· Product-component requirements
· Interface requirements
· Functional architecture

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the requirements development process with higher level management and resolve issues.

Requirement Development: Specific Practices by Goal SG3

2007-08-29T22:25:00.000-07:00

Analyze and Validate Requirements
The requirements are analyzed and validated, and a definition of required functionality is developed.
The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment. Analyses are performed to determine what impact the intended operational environment will have on the ability to satisfy the stakeholders' needs, expectations, constraints, and interfaces. Considerations such as feasibility, mission needs, cost constraints,potential market size, and acquisition strategy must all be taken into account, depending on the product context. A definition of required functionality is also established. All specified usage modes for the product are considered, and a timeline analysis is generated for timecritical sequencing of functions. The objectives of the analyses are to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints; and then translate these concepts into requirements. In parallel with this activity, the parameters that will be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept.
Requirements are validated to increase the probability that the resulting product will perform as intended in the use environment.

SP 3.1 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios.
A scenario is a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario. For example, the operational concept for a satellite-based communications product is quite different from one based on landlines. Since the alternative solutions have not usually been defined when preparing the initial operational concepts, conceptual solutions are developed for use when analyzing the requirements. The operational concepts are refined as solution decisions are made and lower level detailed requirements are developed.
Just as a design decision for a product may become a requirement for product components, the operational concept may become the scenarios (requirements) for product components.
The scenarios may include operational sequences, provided those sequences are an expression of customer requirements rather than operational concepts.

Typical Work Products
1. Operational concept
2. Product installation, operational, maintenance, and support concepts
3. Disposal concepts
4. Use cases
5. Timeline scenarios
6. New requirements

Subpractices
1. Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate.
Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints, in which the proposed product is expected to operate.
2. Define the environment the product will operate in, including boundaries and constraints.
3. Review operational concepts and scenarios to refine and discover requirements.
Operational concept and scenario development is an iterative process. The reviews should be held periodically to ensure that they agree with the requirements. The review may be in the form of a walkthrough.
4. Develop a detailed operational concept, as products and product components are selected, that defines the interaction of the product, the end user, and the environment, and that satisfies the operational, maintenance, support, and disposal needs.

SP 3.2 Establish a Definition of Required Functionality
Establish and maintain a definition of required functionality.
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.
Functional 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 the
services. The definition of functions, their logical groupings, and their association with requirements is referred to as a functional architecture.

Typical Work Products
1. Functional architecture
2. Activity diagrams and use cases
3. Object-oriented analysis with services identified

Subpractices
1. Analyze and quantify functionality required by end users.
2. Analyze requirements to identify logical or functional partitions (e.g., subfunctions).
3. Partition requirements into groups, based on established criteria (e.g., similar functionality, performance, or coupling), to facilitate and focus the requirements analysis.
4. Consider the sequencing of time-critical functions both initially and subsequently during product-component development.
5. Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions.
6. Allocate functional and performance requirements to functions and subfunctions.

SP 3.3 Analyze Requirements
Analyze requirements to ensure that they are necessary and sufficient. In light of the operational concept and scenarios, the requirements for one level of the product hierarchy are analyzed to determine whether they are necessary and sufficient to meet the objectives of higher levels of the product hierarchy. The analyzed requirements then provide the basis for more detailed and precise requirements for lower levels of the product hierarchy. As requirements are defined, their relationship to higher level requirements and the higher level defined functionality must be understood. One of the other actions is the determination of which key requirements will be used to track technical progress. For instance, the weight of a product or size of a software product may be monitored through development based on its risk.

Typical Work Products
1. Requirements defects reports
2. Proposed requirements changes to resolve defects
3. Key requirements
4. Technical performance measures

Subpractices
1. Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects.
2. Analyze requirements to determine whether they satisfy the objectives of higher level requirements.
3. Analyze requirements to ensure that they are complete, feasible,realizable, and verifiable.
While design determines the feasibility of a particular solution, this subpractice
addresses knowing which requirements affect feasibility.
4. Identify key requirements that have a strong influence on cost,schedule, functionality, risk, or performance.
5. Identify technical performance measures that will be tracked during the development effort.
6. Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements.
This analysis may result in more detailed operational concepts and scenarios as well as supporting the derivation of new requirements.

SP 3.4 Analyze Requirements to Achieve Balance
Analyze requirements to balance stakeholder needs and constraints.
Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.

Typical Work Products
1. Assessment of risks related to requirements

Subpractices
1. Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints. Results of the analyses can be used to reduce the cost of the product and the risk in developing the product.
2. Perform a risk assessment on the requirements and functional architecture.
3. Examine product life-cycle concepts for impacts of requirements on risks.

SP 3.5 Validate Requirements with Comprehensive Methods
Validate requirements to ensure the resulting product will perform as intended in the user's environment using multiple techniques as appropriate.
Requirements validation is performed early in the development effort to gain confidence that the requirements are capable of guiding a development that results in successful final validation. This activity should be integrated with risk management activities. Mature organizations will typically perform requirements validation in a more sophisticated way and will broaden the basis of the validation to include other stakeholder needs and expectations. These organizations will typically perform analyses, simulations, or prototypes to ensure that requirements will satisfy stakeholder needs and expectations.

Typical Work Products
1. Record of analysis methods and results

Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
2. Explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations,models, scenarios, and storyboards) and by obtaining feedback about them from relevant stakeholders.
3. Assess the design as it matures in the context of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements.
The following specific practice appears in the continuous representation as SP 3.5-1, but is subsumed in the staged representation by SP 3.5, Validate Requirements with Comprehensive Methods. The specific practice is presented here in gray only as informative material.

SP 3.5-1 Validate Requirements
Validate requirements to ensure the resulting product will perform appropriately in its intended-use environment.

Typical Work Products
1. Results of requirements validation

Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.

Requirements Development: Specific Practices by Goal SG2

2007-08-22T03:09:00.000-07:00

Develop Product Requirements
Customer requirements are refined and elaborated to develop product and product-component requirements.
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called "product and product-component
requirements." Product and product-component requirements address the needs associated with each product life-cycle phase. Derived requirements arise from constraints, consideration of issues implied but
not explicitly stated in the customer requirements baseline, and factors introduced by the selected architecture, the design, and the developer’s unique business considerations. The requirements are reexamined with each successive, lower level set of requirements and functional architecture, and the preferred product concept is refined.
The requirements are allocated to product functions and product components including objects, people, and processes. The traceability of requirements to functions, objects, tests, issues, or other entities is
documented. The allocated requirements and functions are the basis for the synthesis of the technical solution. As internal components are developed, additional interfaces are defined and interface requirements
established.

SP 2.1 Establish Product and Product-Component Requirements
Establish and maintain product and product-component requirements, which are based on the customer requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be
used for design decisions. An example of this translation is found in the first House of Quality Functional Deployment, which maps customer desires into technical parameters. For instance, "solid sounding door"
might be mapped to size, weight, fit, dampening, and resonant frequencies.
Product and product-component requirements address the satisfaction of customer, business, and project objectives and associated attributes, such as effectiveness and affordability.
Design constraints include specifications on product components that are derived from design decisions, rather than higher level requirements.
For Software Engineering
For example, application components that must interface with an off-theshelf database component must comply with interface requirements imposed by the selected database. Such product-component requirements are generally not traceable to higher level requirements.
Derived requirements also address the cost and performance of other life-cycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.
The modification of requirements due to approved requirement changes is covered by the "maintain" function of this specific practice; whereas, the administration of requirement changes is covered by the
Requirements Management process area.

Typical Work Products
1. Derived requirements
2. Product requirements
3. Product-component requirements

Subpractices
1. Develop requirements in technical terms necessary for product and product-component design.
Develop architecture requirements addressing critical product qualities and performance necessary for product architecture design.
2. Derive requirements that result from design decisions.
Selection of a technology brings with it additional requirements. For instance, use of electronics requires additional technology-specific requirements such as electromagnetic interference limits.
3. Establish and maintain relationships between requirements for consideration during change management and requirements allocation.

SP 2.2 Allocate Product-Component Requirements
Allocate the requirements for each product component.
The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production. In
cases where a higher level requirement specifies performance that will be the responsibility of two or more product components, the performance must be partitioned for unique allocation to each product
component as a derived requirement.

Typical Work Products
1. Requirement allocation sheets
2. Provisional requirement allocations
3. Design constraints
4. Derived requirements
5. Relationships among derived requirements

Subpractices
1. Allocate requirements to functions.
2. Allocate requirements to product components.
3. Allocate design constraints to product components.
4. Document relationships among allocated requirements.
Relationships include dependencies in which a change in one requirement may affect other requirements.

SP 2.3 Identify Interface Requirements
Identify interface requirements.
Interfaces between functions (or between objects) are identified.Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.
Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product-component integration and are an integral
part of the architecture definition.

Typical Work Products
1. Interface requirements

Subpractices
1. Identify interfaces both external to the product and internal to the product (i.e., between functional partitions or objects).
As the design progresses, the product architecture will be altered by technical solution processes, creating new interfaces between product components and components external to the product. Interfaces with product-related life-cycle processes should also be identified.
Examples of these interfaces include interfaces with test equipment,transportation systems, support systems, and manufacturing facilities.

2. Develop the requirements for the identified interfaces.
Requirements for interfaces are defined in terms of origination, destination,stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.

Requirement Development: Specific Practices by Goal SG1

2007-07-31T23:34:00.000-07:00

Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders (e.g., customers, end users, suppliers, builders, and testers) are the basis for determining customer requirements. The stakeholder needs, expectations, constraints,
interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting. Since stakeholder needs, expectations, constraints, and limitations should be clearly identified
and understood, an iterative process is used throughout the life of the project to accomplish this objective. To facilitate the required interaction, a surrogate for the end user or customer is frequently involved to represent their needs and help resolve conflicts. The customer relations or marketing part of the organization as well as members of the development team from disciplines such as human engineering or support can be used as surrogates. Environmental,legal, and other constraints should be considered when creating and
resolving the set of customer requirements.

SP 1.1 Elicit Needs
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product life-cycle activities and their impact on the product.

Examples of techniques to elicit needs include the following:
· Technology demonstrations
· Interface control working groups
· Technical control working groups
· Interim project reviews
· Questionnaires, interviews, and operational scenarios obtained from end users
· Operational walkthroughs and end-user task analysis
· Prototypes and models
· Brainstorming
· Quality Function Deployment
· Market surveys
· Beta testing
· Extraction from sources such as documents, standards, or specifications
· Observation of existing products, environments, and workflow patterns
· Use cases
· Business case analysis
· Reverse engineering (for legacy products)

Subpractices
1. Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces.
The following specific practice appears in the continuous representation as
SP 1.1-1, but is subsumed in the staged representation by SP 1.1, Elicit Needs.
The specific practice is presented here in gray only as informative material.

SP 1.1-1 Collect Stakeholder Needs
Identify and collect stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle.
The basic activity addresses the receipt of requirements that a customer provides to define what is needed or desired. These requirements may or may not be stated in technical terms. They should address the various product life-cycle activities and their impact on the product.

SP 1.2 Develop the Customer Requirements
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.
For Integrated Product and Process Development
Relevant stakeholders representing all phases of the product’s life cycle should include business as well as technical functions. In this way, concepts for all product-related lifecycle processes are considered concurrently with the concepts for the products. Customer requirements result from informed decisions on the business as well as technical effects of their requirements. The various inputs from the customer must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and
constraints with regard to verification and validation.
Typical Work Products
1. Customer requirements
2. Customer constraints on the conduct of verification
3. Customer constraints on the conduct of validation
Subpractices
1. Translate the stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.
2. Define constraints for verification and validation.

Requirements Development: CMMI Maturity Level 3

2007-07-31T22:34:00.000-07:00

The purpose of Requirements Development is to produce and analyze customer, product, and product-component requirements.

This process area describes three types of requirements:

customer requirements, product requirements, and product-component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).

Requirements are the basis for design. The development of requirements includes the following activities:
· Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
· Collection and coordination of stakeholder needs
· Development of the life-cycle requirements of the product
· Establishment of the customer requirements
· Establishment of initial product and product-component requirements consistent with customer requirements
This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.
Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product-component requirements are derived from the selected
design solutions.

Requirements are identified and refined throughout the phases of the product life cycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s life cycle are analyzed for
impact on derived and allocated requirements.
The Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses defining a set of customer requirements to use in the development of
product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product-component requirements to use in the design of products and product components. The Analyze
and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product-component requirements to define, derive, and understand the requirements. The specific practices
of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and those associated with
the Technical Solution process area may interact recursively with one another.
Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include the following:
· Analysis of needs and requirements for each product life-cycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user
expectations and satisfaction, such as safety, security, and affordability
· Development of an operational concept
· Definition of the required functionality
The definition of functionality, also referred to as "functional 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 the services. The definition of functions, their logical groupings, and their association with requirements is referred to as a "functional architecture."
Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a
result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived
requirements, including consideration of the following:

· Constraints of various types
· Technological limitations

· Cost and cost drivers
· Time constraints and schedule drivers
· Risks
· Consideration of issues implied but not explicitly stated by the customer or end user
· Factors introduced by the developer’s unique business considerations, regulations, and laws
A hierarchy of logical entities (functions and subfunctions, object classes and subclasses) is established through iteration with the evolving operational concept. Requirements are refined, derived, and
allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, associated processes, or services.
Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements.
This activity continually assures them that the requirements are being properly defined.

Specific and Generic Goals
SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
SG 2 Develop Product Requirements
Customer requirements are refined and elaborated to develop product and product-component requirements.
SG 3 Analyze and Validate Requirements
The requirements are analyzed and validated, and a definition of required functionality is developed.
GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Develop the Customer Requirements

SG 2 Develop Product Requirements
SP 2.1 Establish Product and Product-Component Requirements
SP 2.2 Allocate Product-Component Requirements
SP 2.3 Identify Interface Requirements

SG 3 Analyze and Validate Requirements
SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Establish a Definition of Required Functionality
SP 3.3 Analyze Requirements
SP 3.4 Analyze Requirements to Achieve Balance
SP 3.5 Validate Requirements with Comprehensive Methods

GG 3 Institutionalize a Defined Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 3.1 (AB 1) Establish a Defined Process
GP 2.2 (AB 2) Plan the Process
GP 2.3 (AB 3) Provide Resources
GP 2.4 (AB 4) Assign Responsibility
GP 2.5 (AB 5) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 3.2 (DI 4) Collect Improvement Information
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

Configuration Management: Institutionalize a Managed Process

2007-07-23T22:59:00.000-07:00

The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the configuration management process.

Elaboration:
This policy establishes organizational expectations for establishing and maintaining baselines, tracking and controlling changes to the work products (under configuration management), and establishing and
maintaining integrity of the baselines.

Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the configuration management process.

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

GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the configuration management process, developing the work products, and providing the services of the process.

Elaboration:
Examples of resources provided include the following tools:
· Configuration management tools
· Data management tools
· Archiving and reproduction tools
· Database programs

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the configuration management process.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the configuration management process as needed.

Elaboration:
Examples of training topics include the following:
· Roles, responsibilities, and authority of the configuration management staff
· Configuration management standards, procedures, and methods
· Configuration library system

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the configuration management process under appropriate levels of configuration management.

Elaboration:
Examples of work products placed under configuration management include the following:
· Access lists
· Change status reports
· Change request database
· CCB meeting minutes
· Archived baselines

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the configuration
management process as planned.

Elaboration:
Examples of activities for stakeholder involvement include the following:
· Establishing baselines
· Reviewing configuration management system reports and resolving issues
· Assessing the impact of changes for the configuration items
· Performing configuration audits
· Reviewing the results of configuration management audits

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the configuration management process against the plan for performing the process and take appropriate corrective action.

Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Number of changes to configuration items
· Number of configuration audits conducted

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the configuration management process against its process description, standards, and procedures, and address noncompliance.

Elaboration:
Examples of activities reviewed include the following:
· Establishing baselines
· Tracking and controlling changes
· Establishing and maintaining integrity of baselines

Examples of work products reviewed include the following:
· Archives of the baselines
· Change request database

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the configuration management process with higher level management and resolve issues.
(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required for a maturity level 3 rating and above.)

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 configuration
management process.

GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the configuration management process to support the future use and improvement of the organization’s processes and process assets.

Configuration Management: Specific Practices by Goal SG3

2007-07-17T04:43:00.000-07:00

Establish Integrity
Integrity of baselines is established and maintained. The integrity of the baselines, established by processes associated with the Establish Baselines specific goal, and maintained by processes associated with the Track and Control Changes specific goal, is provided by the specific practices under this specific goal.

SP 3.1 Establish Configuration Management Records
Establish and maintain records describing configuration items.

Typical Work Products
1. Revision history of configuration items
2. Change log
3. Copy of the change requests
4. Status of configuration items
5. Differences between baselines

Subpractices
1. Record configuration management actions in sufficient detail so the content and status of each configuration item is known and previous versions can be recovered.
2. Ensure that relevant stakeholders have access to and knowledge of the configuration status of the configuration items.
Examples of activities for communicating configuration status include the following:
· Providing access permissions to authorized end users
· Making baseline copies readily available to authorized end users
3. Specify the latest version of the baselines.
4. Identify the version of configuration items that constitute a particular baseline.
5. Describe the differences between successive baselines.
6. Revise the status and history (i.e., changes and other actions) of each configuration item as necessary.

SP 3.2 Perform Configuration Audits
Perform configuration audits to maintain integrity of the configuration baselines.
Audit configuration management activities and processes to confirm that the resulting baselines and documentation are accurate, and record the audit results as appropriate.

Typical Work Products
1. Configuration audit results
2. Action items

Subpractices
1. Assess the integrity of the baselines.
2. Confirm that the configuration records correctly identify the configuration of the configuration items.
3. Review the structure and integrity of the items in the configuration management system.
4. Confirm the completeness and correctness of the items in the configuration management system. Completeness and correctness of the content is based on the requirements as stated in the plan and the disposition of approved change requests.
5. Confirm compliance with applicable configuration management standards and procedures.
6. Track action items from the audit to closure.

Configuration Management: Specific Practices by Goal SG2

2007-07-03T22:24:00.000-07:00

SG 2 Track and Control Changes
Changes to the work products under configuration management are tracked and controlled.
The specific practices under this specific goal serve to maintain the baselines after they are established by the specific practices under the Establish Baselines specific goal.

SP 2.1 Track Change Requests
Track change requests for the configuration items. Change requests address not only new or changed requirements, but also failures and defects in the work products. Change requests are analyzed to determine the impact that the change will have on the work product, related work products, and schedule and
cost.

Typical Work Products
1. Change requests

Subpractices
1. Initiate and record change requests in the change request database.
2. Analyze the impact of changes and fixes proposed in the change requests. Changes are evaluated through activities that ensure that they are consistent with all technical and project requirements.
Changes are evaluated for their impact beyond immediate project or contract requirements. Changes to an item used in multiple products can resolve an immediate issue while causing a problem in other applications.
3. Review change requests that will be addressed in the next baseline with those who will be affected by the changes and get their agreement.
Conduct the change request review with appropriate participants. Record the disposition of each change request and the rationale for the decision, including success criteria, a brief action plan if appropriate, and needs met or unmet by the change. Perform the actions required in the disposition, and report the results to
relevant stakeholders.
4. Track the status of change requests to closure. Change requests brought into the system need to be handled in a proficient and timely manner. Once a change request has been processed, it is critical to close
the request with the appropriate approved action as soon as it is practical. Actions left open result in larger than necessary status lists, which in turn result in added costs and confusion.

SP 2.2 Control Configuration Items
Control changes to the configuration items. Control is maintained over the configuration of the work product
baseline. This control includes tracking the configuration of each of the configuration items, approving a new configuration if necessary, and updating the baseline.

Typical Work Products
1. Revision history of configuration items
2. Archives of the baselines

Subpractices
1. Control changes to configuration items throughout the life of the product.
2. Obtain appropriate authorization before changed configuration items are entered into the configuration management system.
For example, authorization may come from the CCB, the project manager, or the customer.
3. Check in and check out configuration items from the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of the configuration items.
Examples of check-in and check-out steps include the following:
· Confirming that the revisions are authorized
· Updating the configuration items
· Archiving the replaced baseline and retrieving the new baseline
4. Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that the changes have not compromised the safety and/or security of the system).
5. Record changes to configuration items and the reasons for the changes as appropriate.
If a proposed change to the work product is accepted, a schedule is identified for incorporating the change into the work product and other affected areas.
Configuration control mechanisms can be tailored to categories of changes. For example, the approval considerations could be less stringent for component changes that do not affect other components.
Changed configuration items are released after review and approval of configuration changes. Changes are not official until they are released.

Configuration Management: Specific Practices by Goal SG1

2007-07-02T23:27:00.000-07:00

SG 1 Establish Baselines
Baselines of identified work products are established. Specific practices to establish baselines are covered by this specific goal. The specific practices under the Track and Control Changes specific goal serve to maintain the baselines. The specific practices of the Establish Integrity specific goal document and audit the integrity of the baselines.

SP 1.1 Identify Configuration Items
Identify the configuration items, components, and related work products that will be placed under configuration management.
Configuration identification is the selection, creation, and specification of the following:
· Products that are delivered to the customer
· Designated internal work products
· Acquired products
· Tools
· Other items that are used in creating and describing these work products
Items under configuration management will include specifications and interface documents that define the requirements for the product. Other documents, such as test results, may also be included, depending on
their criticality to defining the product.
A "configuration item" is an entity designated for configuration management, which may consist of multiple related work products that form a baseline. This logical grouping provides ease of identification
and controlled access. The selection of work products for configuration management should be based on criteria established during planning.

For Systems Engineering
In a system that includes both hardware and software, where software represents a small part of the system, all of the software may be designated as a single configuration item. In other cases, the software may be decomposed into multiple configuration items.
Configuration items can be decomposed into configuration components and configuration units. Only the term "configuration item" is used in this process area. In these practices, "configuration item" may be
interpreted as "configuration component" or "configuration unit" as appropriate. For example, configuration items in the area of requirements management could vary from each individual requirement
to a set of requirements.

Typical Work Products
1. Identified configuration items

Subpractices
1. Select the configuration items and the work products that compose them based on documented criteria.
Example criteria for selecting configuration items at the appropriate work product level include the following:
· Work products that may be used by two or more groups
· Work products that are expected to change over time either because of errors or change of requirements
· Work products that are dependent on each other in that a change in one mandates a change in the others
· Work products that are critical for the project
Examples of work products that may be part of a configuration item include the following:
· Process descriptions
· Requirements
· Design
· Test plans and procedures
· Test results
· Interface descriptions
For Software Engineering
Examples of software work products that may be part of a configuration item include the following:
· Code/module
· Tools (e.g., compilers)

2. Assign unique identifiers to configuration items.

3. Specify the important characteristics of each configuration item.
Example characteristics of configuration items include author, document or file type, and programming language for software code files.

4. Specify when each configuration item is placed under configuration management.
Example criteria for determining when to place work products under configuration management include the following:
· Stage of the project life cycle
· When the work product is ready for test
· Degree of control desired on the work product
· Cost and schedule limitations
· Customer requirements

5. Identify the owner responsible for each configuration item.

SP 1.2 Establish a Configuration Management System
Establish and maintain a configuration management and change management system for controlling work products. A configuration management system includes the storage media, the procedures, and the tools for accessing the configuration system.
A change management system includes the storage media, the procedures, and tools for recording and accessing change requests.

Typical Work Products
1. Configuration management system with controlled work products
2. Configuration management system access control procedures
3. Change request database

Subpractices
1. Establish a mechanism to manage multiple control levels of configuration management.
Examples of situations leading to multiple levels of control include the following:
· Differences in the levels of control needed at different times in the project life cycle
(e.g., tighter control as product matures)
· Differences in the levels of control needed for different types of systems (e.g., software-only systems versus systems that include hardware and software)
· Differences in the levels of control needed to satisfy privacy and security requirements for the configuration items

2. Store and retrieve configuration items in the configuration management system.
Examples of configuration management systems include the following:
· Dynamic (or developer’s) systems contain components currently being created or revised. They are in the developer's workspace and are controlled by the developer. Configuration items in a dynamic system are under version control.
· Master (or controlled) systems contain current baselines and changes to them. Configuration items in a master system are under full configuration management as described in this process area.
· Static systems contain archives of various baselines released for use. Static
systems are under full configuration management as described in this process
area.

3. Share and transfer configuration items between control levels within the configuration management system.

4. Store and recover archived versions of configuration items.

5. Store, update, and retrieve configuration management records.

6. Create configuration management reports from the configuration
management system.

7. Preserve the contents of the configuration management system.
Examples of preservation functions of the configuration management system
include the following:
· Backups and restoration of configuration management files
· Archiving of configuration management files
· Recovery from configuration management errors

8. Revise the configuration management structure as necessary.

SP 1.3 Create or Release Baselines
Create or release baselines for internal use and for delivery to the customer.
A baseline is a set of specifications or work products that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through change
control procedures. A baseline represents the assignment of an identifier to a configuration item and its associated entities.

For Systems Engineering
Release of a baseline involves approving a set of configuration data for the agreed-upon set of configuration
items from the configuration management system and releasing the baseline for further development. Multiple baselines may be used to define an evolving product during its development cycle. One common set includes the systemlevel requirements, system-element-level design requirements, and the product definition at the end of development/beginning of production. These are referred to as the "functional baseline," "allocated baseline," and "product baseline."

For Software Engineering
A set of requirements, design, source code files and the associated executable code, build files, and user
documentation (associated entities) that have been assigned a unique identifier can be considered to be a baseline. Release of a baseline constitutes retrieval of source code files (configuration items) from the configuration management system and generating the executable files. A baseline that is delivered to a customer is typically called a "release" whereas a baseline for an internal use is typically called a "build."

Typical Work Products
1. Baselines
2. Description of baselines

Subpractices
1. Obtain authorization from the configuration control board (CCB) before creating or releasing baselines of configuration items.
2. Create or release baselines only from configuration items in the configuration management system.
For Systems Engineering
Ensure that the configuration items are built to the correct drawing.
3. Document the set of configuration items that are contained in a baseline.
4. Make the current set of baselines readily available.

Configuration Management: CMMI Maturity Level 2

2007-06-25T03:47:00.000-07:00

Purpose
The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification,configuration control, configuration status accounting, and configuration
audits.

Introductory Notes
The Configuration Management process area involves the following:
· Identifying the configuration of selected work products that compose the baselines at given points in time
· Controlling changes to configuration items
· Building or providing specifications to build work products from the configuration management system
· Maintaining the integrity of baselines
· Providing accurate status and current configuration data to developers, end users, and customers

The work products placed under configuration management include the products that are delivered to the customer, designated internal work products, acquired products, tools, and other items that are used in
creating and describing these work products.

For Supplier Sourcing
Acquired products may need to be placed under configuration management by both the supplier and the project. Provisions for conducting configuration management should be established in supplier agreements. Methods to ensure that the data is complete and consistent should be established and maintained.

Examples of work products that may be placed under configuration management include the following:
· Plans
· Process descriptions
· Requirements
· Design data
· Drawings
· Product specifications
· Code
· Compilers
· Product data files
· Product technical publications

Configuration management of work products may be performed at several levels of granularity. Configuration items can be decomposed into configuration components and configuration units. Only the term "configuration item" is used in this process area. Therefore, in these practices, "configuration item" may be interpreted as "configuration component" or "configuration unit" as appropriate.

Baselines provide a stable basis for continuing evolution of configuration items.
An example of a baseline is an approved description of a product that includes internally consistent versions of requirements, requirement traceability matrices, design, discipline-specific items, and end-user documentation.
Baselines are added to the configuration management system as they are developed. Changes to baselines and the release of work products built from the configuration management system are systematically
controlled and monitored via the configuration control, change management, and configuration auditing functions of configuration management.
This process area applies not only to configuration management on projects, but also to configuration management on organization work products such as standards, procedures, and reuse libraries.

Configuration management is focused on the rigorous control of the managerial and technical aspects of work products, including the delivered system.

This process area covers the practices for performing the configuration management function and is applicable to all work products that are placed under configuration management.

Specific and Generic Goals
SG 1 Establish Baselines
Baselines of identified work products are established.

SG 2 Track and Control Changes
Changes to the work products under configuration management are tracked and controlled.

SG 3 Establish Integrity
Integrity of baselines is established and maintained.

GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
(The following goal is not required for maturity level 2, but required for maturity level 3 and
above.)
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Establish Baselines
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines

SG 2 Track and Control Changes
SP 2.1 Track Change Requests
SP 2.2 Control Configuration Items

SG 3 Establish Integrity
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits

GG 2 Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required and expected for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information

Process And Product Quality Assurance: Institutionalize a Managed Process

2007-06-25T03:36:00.000-07:00

The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the process and product quality assurance process.

Elaboration:
This policy establishes organizational expectations for objectively evaluating whether processes and associated work products adhere to the applicable process descriptions, standards, and procedures, and ensuring that noncompliance is addressed.
This policy also establishes organizational expectations for process and product quality assurance being in place for all projects. Process and product quality assurance must possess sufficient independence from project management to provide objectivity in identifying and reporting noncompliance issues.

Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the process and product quality assurance process.

Elaboration:
This plan for performing the process and product quality assurance process may be included in (or referenced by) the project plan, which is described in the Project Planning process area.

GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the process and product quality assurance process, developing the work products, and providing the services of the process.

Examples of resources provided include the following tools:
· Evaluation tools
· Noncompliance tracking tool

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process and product quality assurance process.

Elaboration:
To guard against subjectivity or bias, ensure that those people assigned responsibility and authority for process and product quality assurance can perform their evaluations with sufficient independence and objectivity.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the process and product quality assurance process as needed.

Elaboration:
Examples of training topics include the following:
· Application domain
· Customer relations
· Process descriptions, standards, procedures, and methods for the project
· Quality assurance objectives, process descriptions, standards, procedures, methods, and tools
Directing Implementation

GP 2.6 (DI 1) Manage Configurations
Place designated work products of the process and product quality assurance process under appropriate levels of configuration management.

Elaboration:
Examples of work products placed under configuration management include the following:
· Noncompliance reports
· Evaluation logs and reports

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the process and product quality assurance process as planned.

Elaboration:
Examples of activities for stakeholder involvement include the following:
· Establishing criteria for the objective evaluations of processes and work products
· Evaluating processes and work products
· Resolving noncompliance issues
· Tracking noncompliance issues to closure

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the process and product quality assurance process against the plan for performing the process and take appropriate corrective action.

Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Variance of objective process evaluations planned and performed
· Variance of objective work product evaluations planned and performed

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the process and product quality assurance process against its process description, standards, and procedures, and address noncompliance.

Elaboration:
Examples of activities reviewed include the following:
· Objectively evaluating processes and work products
· Tracking and communicating noncompliance issues
Examples of work products reviewed include the following:
· Noncompliance reports
· Evaluation logs and reports

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the process and product quality assurance process with higher level management and resolve issues.
(The following goal is not required and its practices are not expected for a maturity level 2 rating, but are required for a maturity level 3 rating and above.)

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 process and product quality assurance process.

GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the process and product quality assurance process to support the
future use and improvement of the organization’s processes and process assets.

Process And Product Quality Assurance: Specific Practices by Goal SG2

2007-06-25T03:24:00.000-07:00

Provide Objective Insight
Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
Communicate quality issues and ensure resolution of noncompliance issues with the staff and managers.
Noncompliance issues are problems identified in evaluations that reflect a lack of adherence to applicable standards, process descriptions, or procedures. The status of noncompliance issues provides an indication
of quality trends. Quality issues include noncompliance issues and results of trend analysis.
When local resolution of noncompliance issues cannot be obtained, use established escalation mechanisms to ensure that the appropriate level of management can resolve the issue. Track noncompliance issues to
resolution.

Typical Work Products
1. Corrective action reports
2. Evaluation reports
3. Quality trends

Subpractices
1. Resolve each noncompliance with the appropriate members of the staff where possible.

2. Document noncompliance issues when they cannot be resolved within the project.
Examples of ways to resolve noncompliance within the project include the following:
· Fixing the noncompliance
· Changing the process descriptions, standards, or procedures that were violated
· Obtaining a waiver to cover the noncompliance issue

3. Escalate noncompliance issues that cannot be resolved within the project to the appropriate level of management designated to receive and act on noncompliance issues.

4. Analyze the noncompliance issues to see if there are any quality trends that can be identified and addressed.

5. Ensure that relevant stakeholders are aware of the results of evaluations and the quality trends in a timely manner.

6. Periodically review open noncompliance issues and trends with the manager designated to receive and act on noncompliance issues.

7. Track noncompliance issues to resolution.

SP 2.2 Establish Records
Establish and maintain records of the quality assurance activities.

Typical Work Products
1. Evaluation logs
2. Quality assurance reports
3. Status reports of corrective actions
4. Reports of quality trends

Subpractices
1. Record process and product quality assurance activities in sufficient detail such that status and results are known.

2. Revise the status and history of the quality assurance activities as necessary.

Process And Product Quality Assurance: Specific Practices by Goal SG1

2007-06-25T02:58:00.000-07:00

Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.

SP 1.1 Objectively Evaluate Processes
Objectively evaluate the designated performed processes against the applicable process descriptions, standards, and procedures.
Objectivity in quality assurance evaluations is critical to the success of the project. A description of the quality assurance reporting chain and how it ensures objectivity should be defined.

Typical Work Products
1. Evaluation reports
2. Noncompliance reports
3. Corrective actions

Subpractices
1. Promote an environment (created as part of project management) that encourages employee participation in identifying and reporting
quality issues.

2. Establish and maintain clearly stated criteria for the evaluations.
The intent of this subpractice is to provide criteria, based on business needs, such as the following:
· What will be evaluated
· When or how often a process will be evaluated
· How the evaluation will be conducted
· Who must be involved in the evaluation

3. Use the stated criteria to evaluate performed processes for adherence to process descriptions, standards, and procedures.

4. Identify each noncompliance found during the evaluation.

5. Identify lessons learned that could improve processes for future products and services.

SP 1.2 Objectively Evaluate Work Products and Services
Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures.

Typical Work Products
1. Evaluation reports
2. Noncompliance reports
3. Corrective actions

Subpractices
1. Select work products to be evaluated, based on documented sampling criteria if sampling is used.

2. Establish and maintain clearly stated criteria for the evaluation of work products. The intent of this subpractice is to provide criteria, based on business needs, such as the following:
· What will be evaluated during the evaluation of a work product
· When or how often a work product will be evaluated
· How the evaluation will be conducted
· Who must be involved in the evaluation

3. Use the stated criteria during the evaluations of work products.

4. Evaluate work products before they are delivered to the customer.

5. Evaluate work products at selected milestones in their development.

6. Perform in-progress or incremental evaluations of work products and services against process descriptions, standards, and procedures.

7. Identify each case of noncompliance found during the evaluations.

8. Identify lessons learned that could improve processes for future products and services.

Process and Product Quality Assurance: Specific Practices by Goal SG1

2007-06-19T22:49:00.000-07:00

SG 1 Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.

SP 1.1 Objectively Evaluate Processes
Objectively evaluate the designated performed processes against the applicable process descriptions, standards, and procedures.
Objectivity in quality assurance evaluations is critical to the success of the project. A description of the quality assurance reporting chain and how it ensures objectivity should be defined.

Typical Work Products
1. Evaluation reports
2. Noncompliance reports
3. Corrective actions

Subpractices
1. Promote an environment (created as part of project management) that encourages employee participation in identifying and reporting quality issues.

2. Establish and maintain clearly stated criteria for the evaluations.
The intent of this subpractice is to provide criteria, based on business needs, such as the following:
· What will be evaluated
· When or how often a process will be evaluated
· How the evaluation will be conducted
· Who must be involved in the evaluation

3. Use the stated criteria to evaluate performed processes for adherence to process descriptions, standards, and procedures.

4. Identify each noncompliance found during the evaluation.

5. Identify lessons learned that could improve processes for future products and services.

SP 1.2 Objectively Evaluate Work Products and Services
Objectively evaluate the designated work products and services against the applicable process descriptions, standards, and procedures.

Typical Work Products
1. Evaluation reports
2. Noncompliance reports
3. Corrective actions

Subpractices
1. Select work products to be evaluated, based on documented sampling criteria if sampling is used.
2. Establish and maintain clearly stated criteria for the evaluation of work products.
The intent of this subpractice is to provide criteria, based on business needs, such as the following:
· What will be evaluated during the evaluation of a work product
· When or how often a work product will be evaluated
· How the evaluation will be conducted
· Who must be involved in the evaluation
3. Use the stated criteria during the evaluations of work products.
4. Evaluate work products before they are delivered to the customer.
5. Evaluate work products at selected milestones in their development.
6. Perform in-progress or incremental evaluations of work products and services against process descriptions, standards, and procedures.
7. Identify each case of noncompliance found during the evaluations.
8. Identify lessons learned that could improve processes for future products and services.

Process and Product Quality Assurance: CMMI Maturity Level 2

2007-06-19T22:35:00.000-07:00

Purpose
The purpose of Process and Product Quality Assurance is to provide staff and management with objective insight into processes and associated work products.

Introductory Notes
The Process and Product Quality Assurance process area involves the following:
· Objectively evaluating performed processes, work products, and services against the applicable process descriptions, standards,and procedures
· Identifying and documenting noncompliance issues
· Providing feedback to project staff and managers on the results of quality assurance activities
· Ensuring that noncompliance issues are addressed The Process and Product Quality Assurance process area supports the delivery of high-quality products and services by providing the project staff and managers at all levels with appropriate visibility into, and feedback on, processes and associated work products throughout the life of the project.
The practices in the Process and Product Quality Assurance process area ensure that planned processes are implemented, while the practices in the Verification process area ensure that the specified requirements are satisfied. These two process areas may on occasion address the same work product but from different perspectives. Projects should take care to minimize duplication of effort.
Objectivity in process and product quality assurance evaluations is critical to the success of the project. Objectivity is achieved by both independence and the use of criteria. Traditionally, a quality assurance
group that is independent of the project provides this objectivity. It may be appropriate in some organizations, however, to implement the process and product quality assurance role without that kind of
independence. For example, in an organization with an open, quality oriented culture, the process and product quality assurance role may be performed, partially or completely, by peers; and the quality assurance function may be embedded in the process.
If quality assurance is embedded in the process, several issues must be addressed to ensure objectivity. Everyone performing quality assurance activities should be trained in quality assurance. Those performing
quality assurance activities for a work product should be separate from those directly involved in developing or maintaining the work product. An independent reporting channel to the appropriate level of
organizational management must be available so that noncompliance issues may be escalated as necessary.
Quality assurance should begin in the early phases of a project to establish plans, processes, standards, and procedures that will add value to the project and satisfy the requirements of the project and the
organizational policies. Those performing quality assurance participate in establishing the plans, processes, standards, and procedures to ensure that they fit the project’s needs and that they will be useable for
performing quality assurance evaluations. In addition, the specific processes and associated work products that will be evaluated during the project are designated. This designation may be based on sampling
or on objective criteria that are consistent with organizational policies and project requirements and needs.
When noncompliance issues are identified, they are first addressed within the project and resolved there if possible. Any noncompliance issues that cannot be resolved within the project are escalated to an
appropriate level of management for resolution. This process area primarily applies to evaluations of products and services, but it also applies to evaluations of nonproject activities and work products such as training activities. For these activities and work products, the term "project" should be appropriately interpreted.

Specific and Generic Goals

SG 1 Objectively Evaluate Processes and Work Products
Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.

SG 2 Provide Objective Insight
Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
(The following goal is not required for maturity level 2, but required for maturity level 3 and
above.)

GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table

SG 1 Objectively Evaluate Processes and Work Products
SP 1.1 Objectively Evaluate Processes
SP 1.2 Objectively Evaluate Work Products and Services

SG 2 Provide Objective Insight
SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
SP 2.2 Establish Records

GG 2 Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management
(The following goal is not required and its practices are not expected for a maturity level 2 rating, but are required and expected for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information

Measurement and Analysis: Institutionalize a Managed Process

2007-06-17T22:53:00.000-07:00

CG2 Institutionalize a Managed Process
The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the measurement and analysis process.
Elaboration:
This policy establishes organizational expectations for aligning measurement objectives and activities with identified information needs and objectives and for providing measurement results.
Ability to Perform

GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the measurement and analysis process.
Elaboration:
Typically, this plan for performing the measurement and analysis process is included in the project plan.

GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the measurement and analysis process, developing the work products, and providing the services of the process.
Elaboration:
Measurement personnel may be employed full time or part time. A measurement group may or may not exist to support measurement activities across multiple projects.
Examples of other resources provided include the following tools:
· Statistical packages
· Packages that support data collection over networks

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process,developing the work products, and providing the services of the measurement and analysis process.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the measurement and analysis process as needed.
Elaboration:
Examples of training topics include the following:
· Statistical techniques
· Data collection, analysis, and reporting processes
· Development of goal-related measurements (e.g., Goal Question Metric)

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the measurement and analysis process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Specifications of base and derived measures
· Data collection and storage procedures
· Base and derived measurement data sets
· Analysis results and draft reports
· Data analysis tools

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the measurement and analysis process as planned.
Elaboration:
Examples of activities for stakeholder involvement include the following:
· Establishing measurement objectives and procedures
· Assessing measurement data
· Providing meaningful feedback to those responsible for providing the raw data on which the analysis and results depend

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the measurement and analysis process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Percentage of projects using progress and performance measures
· Percentage of measurement objectives addressed

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the measurement and analysis process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Aligning measurement and analysis activities
· Providing measurement results
Examples of work products reviewed include the following:
· Specifications of base and derived measures
· Data collection and storage procedures
· Analysis results and draft reports

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the measurement and analysis process with higher level management and resolve issues.
(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined measurement and analysis process.

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

Measurement and Analysis: Specific Practices by Goal SG2

2007-06-11T02:37:00.001-07:00

SG 2 Provide Measurement Results
Measurement results that address identified information needs and objectives are provided. The primary reason for doing measurement and analysis is to address identified information needs and objectives. Measurement results based on objective evidence can help to monitor performance, fulfill contractual obligations, make informed management and technical decisions, and enable corrective actions to be taken.

SP 2.1 Collect Measurement Data
Obtain specified measurement data. The data necessary for analysis are obtained and checked for completeness and integrity.
Typical Work Products
1. Base and derived measurement data sets
2. Results of data integrity tests
Subpractices
1. Obtain the data for base measures.
Data are collected as necessary for previously used as well as for newly specified base measures. Existing data are gathered from project records or from elsewhere in the organization. Note that data that were collected earlier may no longer be available for reuse in existing databases, paper records, or formal repositories.
2. Generate the data for derived measures.
Values are newly calculated for all derived measures.
3. Perform data integrity checks as close to the source of the data as possible. All measurements are subject to error in specifying or recording data. It is alwaysbetter to identify such errors and to identify sources of missing data early in the measurement and analysis cycle. Checks can include scans for missing data, out-of-bounds data values, and unusual patterns and correlation across measures. It is particularly important to do the following:
Test and correct for inconsistency of classifications made by human judgment(i.e., to determine how frequently people make differing classification decisionsbased on the same information, otherwise known as "inter-coder reliability").
· Empirically examine the relationships among the measures that are used to calculate additional derived measures. Doing so can ensure that important distinctions are not overlooked and that the derived measures convey their intended meanings (otherwise known as "criterion validity").

SP 2.2 Analyze Measurement Data
Analyze and interpret measurement data. The measurement data are analyzed as planned, additional analyses are conducted as necessary, results are reviewed with relevant stakeholders, and necessary revisions for future analyses are noted.
Typical Work Products
1. Analysis results and draft reports
Subpractices
1. Conduct initial analyses, interpret the results, and draw preliminary conclusions. The results of data analyses are rarely self evident. Criteria for interpreting theresults and drawing conclusions should be stated explicitly.
2. Conduct additional measurement and analysis as necessary, and prepare results for presentation. The results of planned analyses may suggest (or require) additional, unanticipated analyses. In addition, they may identify needs to refine existing measures, to calculate additional derived measures, or even to collect data for additional primitive measures to properly complete the planned analysis. Similarly, preparing the initial results for presentation may identify the need for additional,unanticipated analyses.
3. Review the initial results with relevant stakeholders.It may be appropriate to review initial interpretations of the results and the way in which they are presented before disseminating and communicating them more widely. Reviewing the initial results before their release may prevent needless misunderstandings and lead to improvements in the data analysis and presentation. Relevant stakeholders with whom reviews may be conducted include intendedend users and sponsors, as well as data analysts and data providers
4. Refine criteria for future analyses. Valuable lessons that can improve future efforts are often learned from conducting data analyses and preparing results. Similarly, ways to improve measurement specifications and data collection procedures may become apparent, as may ideas for refining identified information needs and objectives.

SP 2.3 Store Data and Results
Manage and store measurement data, measurement specifications, and analysis results. Storing measurement-related information enables the timely and cost effectivefuture use of historical data and results. The information also is needed to provide sufficient context for interpretation of the data,measurement criteria, and analysis results. Information stored typically includes the following:
· Measurement plans
· Specifications of measures
· Sets of data that have been collected
· Analysis reports and presentations
The stored information contains or references the information needed to understand and interpret the measures and assess them for reasonableness and applicability (e.g., measurement specificationsused on different projects when comparing across projects).
Data sets for derived measures typically can be recalculated and need not be stored. However, it may be appropriate to store summaries based on derived measures (e.g., charts, tables of results, or report prose). Interim analysis results need not be stored separately if they can be efficiently reconstructed. Projects may choose to store project-specific data and results in aproject-specific repository. When data are shared more widely acrossprojects, the data may reside in the organization’s measurement repository.
Typical Work Products
1. Stored data inventory
Subpractices
1. Review the data to ensure their completeness, integrity, accuracy,and currency.
2. Make the stored contents available for use only by appropriategroups and personnel.
3. Prevent the stored information from being used inappropriately.
Examples of ways to prevent inappropriate use of the data and related information include controlling access to data and educating people on the appropriate use of data.
Examples of inappropriate use include the following:
· Disclosure of information that was provided in confidence
· Faulty interpretations based on incomplete, out-of-context, or otherwise misleading information
· Measures used to improperly evaluate the performance of people or to rank projects
· Impugning the integrity of specific individuals

SP 2.4 Communicate Results
Report results of measurement and analysis activities to all relevant stakeholders. The results of the measurement and analysis process arecommunicated to relevant stakeholders in a timely and usable fashionto support decision making and assist in taking corrective action.Relevant stakeholders include intended users, sponsors, data analysts,and data providers.
Typical Work Products
1. Delivered reports and related analysis results
2. Contextual information or guidance to aid in the interpretation of analysis results
Subpractices
1. Keep relevant stakeholders apprised of measurement results on a timely basis. Measurement results are communicated in time to be used for their intended purposes. Reports are unlikely to be used if they are distributed with little effort tofollow up with those who need to know the results. To the extent possible and as part of the normal way they do business, users of measurement results are kept personally involved in setting objectives and deciding on plans of action for measurement and analysis. The users are regularly kept apprised of progress and interim results.
2. Assist relevant stakeholders in understanding the results.Results are reported in a clear and concise manner appropriate to themethodological sophistication of the relevant stakeholders. They are understandable, easily interpretable, and clearly tied to identified information needs and objectives. The data are often not self evident to practitioners who are not measurement experts. Measurement choices should be explicitly clear about the following:
How and why the base and derived measures were specified
How the data were obtained
How to interpret the results based on the data analysis methods that were used
How the results address their information needs
Examples of actions to assist in understanding of results include the following:
· Discussing the results with the relevant stakeholders
· Providing a transmittal memo that provides background and explanation
· Briefing users on the results
· Providing training on the appropriate use and understanding of measurement results

Measurement and Analysis: Specific Practices by Goal SG1

2007-06-11T00:41:00.000-07:00

SG 1 Align Measurement and Analysis Activities
Measurement objectives and activities are aligned with identified information needs and objectives. The specific practices covered under this specific goal may be addressed concurrently or in any order:
· When establishing measurement objectives, experts often think ahead about necessary criteria for specifying measures and analysis procedures. They also think concurrently about the constraints imposed by data collection and storage procedures.
· It often is important to specify the essential analyses that will be conducted before attending to details of measurement specification, data collection, or storage.

SP 1.1 Establish Measurement Objectives
Establish and maintain measurement objectives that are derived from identified information needs and objectives.
Measurement objectives document the purposes for which measurement and analysis are done, and specify the kinds of actions that may be taken based on the results of data analyses.
The sources for measurement objectives may be management, technical, project, product, or process implementation needs.
The measurement objectives may be constrained by existing processes, available resources, or other measurement considerations.
Judgments may need to be made about whether the value of the results will be commensurate with the resources devoted to doing the work.
Modifications to identified information needs and objectives may, in turn, be indicated as a consequence of the process and results of measurement and analysis. Sources of information needs and objectives may include the following:
· Project plans
· Monitoring of project performance
· Interviews with managers and others who have information needs
· Established management objectives
· Strategic plans
· Business plans
· Formal requirements or contractual obligations
· Recurring or other troublesome management or technical problems
· Experiences of other projects or organizational entities
· External industry benchmarks
· Process-improvement plans

Typical Work Products
1. Measurement objectives
Subpractices
1. Document information needs and objectives.
Information needs and objectives are documented to allow traceability to subsequent measurement and analysis activities.
2. Prioritize information needs and objectives.
It may be neither possible nor desirable to subject all initially identified information needs to measurement and analysis. Priorities may also need to be set within the limits of available resources.
3. Document, review, and update measurement objectives.
It is important to carefully consider the purposes and intended uses of measurement and analysis.
The measurement objectives are documented, reviewed by management and other relevant stakeholders, and updated as necessary. Doing so enables traceability to subsequent measurement and analysis activities, and helps ensure that the analyses will properly address identified information needs and
objectives.
It is important that users of measurement and analysis results be involved in setting measurement objectives and deciding on plans of action. It may also be appropriate to involve those who provide the measurement data.
4. Provide feedback for refining and clarifying information needs and objectives as necessary.
Identified information needs and objectives may need to be refined and clarified as a result of setting measurement objectives. Initial descriptions of information needs may be unclear or ambiguous. Conflicts may arise between existing needs and objectives. Precise targets on an already existing measure may be
unrealistic.
5. Maintain traceability of the measurement objectives to the identified information needs and objectives.
There must always be a good answer to the question, "Why are we measuring this?"
Of course, the measurement objectives may also change to reflect evolving information needs and objectives.
SP 1.2 Specify Measures
Specify measures to address the measurement objectives.
Measurement objectives are refined into precise, quantifiable measures. Measures may be either "base" or "derived." Data for base measures are obtained by direct measurement. Data for derived measures come
from other data, typically by combining two or more base measures.
Examples of commonly used base measures include the following:
· Estimates and actual measures of work product size (e.g., number of pages)
· Estimates and actual measures of effort and cost (e.g., number of person hours)
· Quality measures (e.g., number of defects, number of defects by severity)

Examples of commonly used derived measures include the following:
· Earned Value
· Schedule Performance Index
· Defect density
· Peer review coverage
· Test or verification coverage
· Reliability measures (e.g., mean time to failure)
· Quality measures (e.g., number of defects by severity/total number of defects)

Derived measures typically are expressed as ratios, composite indices,or other aggregate summary measures. They are often more quantitatively reliable and meaningfully interpretable than the base
measures used to generate them.
Typical Work Products
1. Specifications of base and derived measures
Subpractices
1. Identify candidate measures based on documented measurement objectives.
The measurement objectives are refined into specific measures. The identified candidate measures are categorized and specified by name and unit of measure.
2. Identify existing measures that already address the measurement objectives.
Specifications for measures may already exist, perhaps established for other purposes earlier or elsewhere in the organization.
3. Specify operational definitions for the measures.
Operational definitions are stated in precise and unambiguous terms. They address two important criteria as follows: · Communication: What has been measured, how was it measured, what are the units of measure, and what has been included or excluded?
· Repeatability: Can the measurement be repeated, given the same definition, to get the same results?
4. Prioritize, review, and update measures.
Proposed specifications of the measures are reviewed for their appropriateness with potential end users and other relevant stakeholders. Priorities are set or changed, and specifications of the measures are updated as necessary.

SP 1.3 Specify Data Collection and Storage Procedures
Specify how measurement data will be obtained and stored.
Explicit specification of collection methods helps ensure that the right data are collected properly. It may also aid in further clarifying information needs and measurement objectives.
Proper attention to storage and retrieval procedures helps ensure that data are available and accessible for future use.
Typical Work Products
1. Data collection and storage procedures
2. Data collection tools
Subpractices
1. Identify existing sources of data that are generated from current work products, processes, or transactions.
Existing sources of data may already have been identified when specifying the measures. Appropriate collection mechanisms may exist whether or not pertinent data have already been collected.
2. Identify measures for which data are needed, but are not currently available.
3. Specify how to collect and store the data for each required measure.
Explicit specifications are made of how, where, and when the data will be collected. Procedures for collecting valid data are specified. The data are stored in an accessible manner for analysis, and it is determined whether they will be saved for possible reanalysis or documentation purposes. Questions to be considered typically include the following:
· Have the frequency of collection and the points in the process where measurements will be made been determined?
· Has the time line that is required to move measurement results from the points of collection to repositories, other databases, or end users been established?
· Who is responsible for obtaining the data?
· Who is responsible for data storage, retrieval, and security?
· Have necessary supporting tools been developed or acquired?
4. Create data collection mechanisms and process guidance.
Data collection and storage mechanisms are well integrated with other normal work processes. Data collection mechanisms may include manual or automated forms and templates. Clear, concise guidance on correct procedures is available to those responsible for doing the work. Training is provided as necessary to
clarify the processes necessary for collection of complete and accurate data and to minimize the burden on those who must provide and record the data.
5. Support automatic collection of the data where appropriate and feasible.
Automated support can aid in collecting more complete and accurate data.

Examples of such automated support include the following:
· Timestamped activity logs
· Static or dynamic analyses of artifacts
However, some data cannot be collected without human intervention (e.g.,customer satisfaction or other human judgments), and setting up the necessary infrastructure for other automation may be costly.
6. Prioritize, review, and update data collection and storage procedures.
Proposed procedures are reviewed for their appropriateness and feasibility with those who are responsible for providing, collecting, and storing the data. They also may have useful insights about how to improve existing processes, or be able to suggest other useful measures or analyses.
7. Update measures and measurement objectives as necessary.

Priorities may need to be reset based on the following:
· The importance of the measures
· The amount of effort required to obtain the data
Considerations include whether new forms, tools, or training would be required to obtain the data.

SP 1.4 Specify Analysis Procedures
Specify how measurement data will be analyzed and reported.
Specifying the analysis procedures in advance ensures that appropriate analyses will be conducted and reported to address the documented measurement objectives (and thereby the information needs and
objectives on which they are based). This approach also provides a check that the necessary data will in fact be collected.
Typical Work Products
1. Analysis specification and procedures
2. Data analysis tools
Subpractices
1. Specify and prioritize the analyses that will be conducted and the reports that will be prepared.
Early attention should be paid to the analyses that will be conducted and to the manner in which the results will be reported. These should meet the following criteria:
· The analyses explicitly address the documented measurement objectives
· Presentation of the results is clearly understandable by the audiences to whom the results are addressed
Priorities may have to be set within available resources.
2. Select appropriate data analysis methods and tools.

Issues to be considered typically include the following:
· Choice of visual display and other presentation techniques (e.g., pie charts, bar charts, histograms, radar charts, line graphs, scatter plots, or tables)
· Choice of appropriate descriptive statistics (e.g., arithmetic mean, median, or mode)
· Decisions about statistical sampling criteria when it is impossible or unnecessary
to examine every data element
· Decisions about how to handle analysis in the presence of missing data elements
· Selection of appropriate analysis tools
· The work does not cost more to perform than is justified by the benefits that it provides.
Criteria for evaluating the conduct of the measurement and analysis might include the extent to which the following apply:
· The amount of missing data or the number of flagged inconsistencies is beyond specified thresholds.
· There is selection bias in sampling (e.g., only satisfied end users are surveyed to evaluate end-user satisfaction, or only unsuccessful projects are evaluated to determine overall productivity).
· The measurement data are repeatable (e.g., statistically reliable).
· Statistical assumptions have been satisfied (e.g., about the distribution of data or about appropriate measurement scales).

Measurement And Analysis : CMMI Maturity Level 2

2007-06-03T23:36:00.000-07:00

Purpose
The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs.

Introductory Notes
The Measurement and Analysis process area involves the following:
· Specifying the objectives of measurement and analysis such that they are aligned with identified information needs and objectives
· Specifying the measures, data collection and storage mechanisms,analysis techniques, and reporting and feedback mechanisms
· Implementing the collection, storage, analysis, and reporting of the data
· Providing objective results that can be used in making informed decisions, and taking appropriate corrective actions
The integration of measurement and analysis activities into the processes of the project supports the following:
· Objective planning and estimating
· Tracking actual performance against established plans and objectives
· Identifying and resolving process-related issues
· Providing a basis for incorporating measurement into additional processes in the future

The staff required to implement a measurement capability may or may not be employed in a separate organization-wide program.Measurement capability may be integrated into individual projects or
other organizational functions (e.g., Quality Assurance). The initial focus for measurement activities is at the project level.However, a measurement capability may prove useful for addressing organization- and/or enterprise-wide information needs.

Projects may choose to store project-specific data and results in a project-specific repository. When data are shared more widely across projects, the data may reside in the organization’s measurement repository.

For Supplier Sourcing
Measurement and analysis of the product components provided by suppliers is essential for effective management of the quality and costs of the project. It may be possible, with careful management of supplier agreements, to provide insight into the data that support supplier-performance analysis.

Specific and Generic Goals
SG 1 Align Measurement and Analysis Activities
Measurement objectives and activities are aligned with identified information needs and objectives.

SG 2 Provide Measurement Results
Measurement results that address identified information needs and objectives are provided.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
(The following goal is not required for maturity level 2, but required for maturity level 3 and
above.)
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Align Measurement and Analysis Activities
SP 1.1 Establish Measurement Objectives
SP 1.2 Specify Measures
SP 1.3 Specify Data Collection and Storage Procedures
SP 1.4 Specify Analysis Procedures

SG 2 Provide Measurement Results
SP 2.1 Collect Measurement Data
SP 2.2 Analyze Measurement Data
SP 2.3 Store Data and Results
SP 2.4 Communicate Results

GG 2 Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management

(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required and expected for a maturity level 3 rating and above.)
GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information

Supplier Agreement Management:Specific Practices by Goal SG2

2007-05-22T22:28:00.000-07:00

Satisfy Supplier Agreements

Agreements with the suppliers are satisfied by both the project and the supplier.

SP 2.1 Review COTS Products
Review candidate COTS products to ensure they satisfy the specified requirements that are covered under a supplier agreement.
In the event that COTS products are desired, care in evaluating and selecting these products and the vendor may be critical to the project.
For Supplier Sourcing
Integral to the selection decision are proprietary issues and the availability of the products.
Typical Work Products
1. Trade studies
2. Price lists
3. Evaluation criteria
4. Supplier performance reports
5. Reviews of COTS products
Subpractices
1. Develop criteria for evaluating COTS products.
2. Evaluate candidate COTS products against the associated requirements and criteria.
These requirements address the following:
· Functionality, performance, quality, and reliability · Terms and conditions of warranties for the products
· Risk
· Suppliers' responsibilities for ongoing maintenance and support of the products
3. Evaluate the impact of candidate COTS products on the project's plans and commitments.
Evaluate according to the following:
· Cost of the COTS products
· Cost and effort to incorporate the COTS products into the project
· Security requirements
· Benefits and impacts that may result from future product releases. Future product releases may provide additional features that support planned or anticipated enhancements for the project, but may also result in the supplier withdrawing support of the version for the product that is acquired by the project.
4. Assess the suppliers' performance and ability to deliver.
5. Identify risks associated with the selected COTS product and the supplier agreement.
6. Select the COTS product to be acquired.
In some cases, selection of COTS products may require a supplier agreement in addition to the agreements in the product’s license.
Examples of agreements with COTS suppliers include the following:
· Discounts for large quantity purchases
· Coverage of relevant stakeholders under the licensing agreement, including project suppliers, team members, and the project’s customer
· Plans for future enhancements
· On-site support, such as responses to queries and problem reports
· Additional capabilities that are not in the product
· Maintenance support, including support after the product is withdrawn from general availability
7. Plan for the maintenance of the COTS product.

SP 2.2 Execute the Supplier Agreement
Perform activities with the supplier as specified in the supplier agreement.
Typical Work Products
1. Supplier progress reports and performance measures
2. Supplier review materials and reports
3. Action items tracked to closure
4. Documentation of product and document deliveries
Subpractices
1. Monitor supplier progress and performance (schedule, effort, cost,and technical performance) as defined in the supplier agreement.
2. Monitor selected supplier processes and take corrective action when necessary.
Examples of processes to be monitored are quality assurance and configuration management.
3. Conduct reviews with the supplier as specified in the supplier agreement.
Reviews cover both formal and informal reviews and include the following steps:
· Preparing for the review
· Ensuring that relevant stakeholders participate
· Conducting the review
· Identifying, documenting, and tracking all action items to closure
· Preparing and distributing to the relevant stakeholders a summary report of the review
4. Conduct technical reviews with the supplier as defined in the supplier agreement.
Technical reviews typically include the following:
· Providing the supplier with visibility into the needs and desires of the project’s customers and end users, as appropriate
· Reviewing the supplier's technical activities and verifying that the supplier’s interpretation and implementation of the requirements are consistent with the project’s interpretation
· Ensuring that technical commitments are being met and that technical issues are communicated and resolved in a timely manner
· Obtaining technical information about the supplier’s products
· Providing appropriate technical information and support to the supplier
5. Conduct management reviews with the supplier as defined in the supplier agreement.
Management reviews typically include the following:
· Reviewing critical dependencies
· Reviewing project risks involving the supplier
· Reviewing schedule and budget
Technical and management reviews may be coordinated and held jointly.
6. Use the results of reviews to improve the supplier's performance and to establish and nurture long-term relationships with preferred suppliers.
7. Monitor risks involving the supplier and take corrective action as necessary.
8. Revise the supplier agreement and project plans and schedules as necessary.

SP 2.3 Accept the Acquired Product
Ensure that the supplier agreement is satisfied before accepting the acquired product. Acceptance reviews and tests and configuration audits should be completed before accepting the product as defined in the supplier agreement.
Typical Work Products
1. Acceptance test procedures
2. Acceptance test results
3. Discrepancy reports or corrective action plans
Subpractices
1. Define the acceptance procedures.
2. Review and obtain agreement with relevant stakeholders on the acceptance procedures before the acceptance review or test.
3. Verify that the acquired products satisfy their requirements.
4. Confirm that the nontechnical commitments associated with the acquired work product are satisfied.
This may include confirming that the appropriate license, warranty, ownership,usage, and support or maintenance agreements are in place and that all supporting materials are received.
5. Document the results of the acceptance review or test.
6. Establish and obtain supplier agreement on an action plan for any acquired work products that do not pass their acceptance review or test.
7. Identify, document, and track action items to closure.
SP 2.4 Transition Products
Transition the acquired products from the supplier to the project.
Before the acquired product is transferred to the project for integration,appropriate planning and evaluation should occur to ensure a smooth transition.
Typical Work Products
1. Transition plans
2. Training reports
3. Support and maintenance reports
Subpractices
1. Ensure that there are appropriate facilities to receive, store, use,and maintain the acquired products.
2. Ensure that appropriate training is provided for those involved in receiving, storing, using, and maintaining the acquired products.
3. Ensure that storing, distributing, and using the acquired products are performed according to the terms and conditions specified in the supplier agreement or license.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the supplier agreement management process.
Elaboration:
This policy establishes organizational expectations for establishing,
maintaining, and satisfying supplier agreements.

Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the supplier agreement management process.
Elaboration:
Typically, portions of this plan for performing the supplier agreement management process are a part of the project plan. Often, however, some portions of the plan reside outside of the project with an independent group, such as contract management.

GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the supplier agreement management process, developing the work products, and providing the services of the process.

Elaboration:
Examples of resources provided include the following tools:
· Preferred supplier lists
· Requirements tracking programs
· Project management and scheduling programs

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process,developing the work products, and providing the services of the supplier agreement management process.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the supplier agreement management process as needed.

Elaboration:
Examples of training topics include the following:
· Regulations and business practices related to negotiating and working with suppliers
· Acquisition planning and preparation
· COTS products acquisition
· Supplier evaluation and selection
· Negotiation and conflict resolution
· Supplier management
· Testing and transitioning of acquired products
· Receiving, storing, using, and maintaining acquired products

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the supplier agreement management process under appropriate levels of configuration management.

Elaboration:
Examples of work products placed under configuration management include the following:
· Statements of work
· Supplier agreements
· Memoranda of agreement
· Subcontracts
· Preferred supplier lists

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the supplier agreement management process as planned.

Elaboration:
Examples of activities for stakeholder involvement include the following:
· Establishing criteria for evaluation of potential suppliers
· Reviewing potential suppliers
· Establishing supplier agreements
· Resolving issues with suppliers
· Reviewing supplier performance

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the supplier agreement management process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Number of changes made to the requirements for the supplier
· Cost and schedule variance per supplier agreement
Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the supplier agreement management process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Establishing and maintaining supplier agreements
· Satisfying supplier agreements
Examples of work products reviewed include the following:
· Plan for Supplier Agreement Management
· Supplier agreements

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the supplier agreement management process with higher level management and resolve issues.
(The following goal is not required and its practices are not expected for a maturity level 2 rating, but are required for a maturity level 3 rating and above.)
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 supplier agreement management process.
GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the supplier agreement management process to support the future use and improvement of the organization’s processes and process assets.

Supplier Agreement Management:Specific Practices by Goal SG1

2007-05-14T02:49:00.000-07:00

Establish Supplier Agreements
Agreements with the suppliers are established and maintained.

SP 1.1 Determine Acquisition Type
Determine the type of acquisition for each product or product component to be acquired.
There are many different types of acquisition that can be used to acquire products and product components that will be used by the project.
Examples of types of acquisition include the following:
· Purchasing commercial off-the-shelf (COTS) products
· Obtaining products through a contractual agreement
· Obtaining products from an in-house vendor
· Obtaining products from the customer
· Combining some of the above (e.g., contracting for a modification to a COTS
product or having another part of the business enterprise co-develop products
with an external supplier)

Typical Work Products
1. List of the acquisition types that will be used for all products and product components to be acquired

SP 1.2 Select Suppliers
Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria.Criteria should be established to address factors that are important to the project.

Examples of factors include the following:
· Geographical location of the supplier
· Supplier’s performance records on similar work
· Engineering capabilities
· Staff and facilities available to perform the work
· Prior experience in similar applications

Typical Work Products
1. List of candidate suppliers
2. Preferred supplier list
3. Rationale for selection of suppliers
4. Advantages and disadvantages of candidate suppliers
5. Evaluation criteria
6. Solicitation materials and requirements

Subpractices
1. Establish and document criteria for evaluating potential suppliers.
2. Identify potential suppliers and distribute solicitation material and requirements to them.
3. Evaluate proposals according to evaluation criteria.
4. Evaluate risks associated with each proposed supplier.
5. Evaluate proposed suppliers' ability to perform the work.

Examples of methods to evaluate the proposed supplier’s ability to perform the work include the following:
· Evaluation of prior experience in similar applications
· Evaluation of prior performance on similar work
· Evaluation of management capabilities
· Capability evaluations
· Evaluation of staff available to perform the work
· Evaluation of available facilities and resources
· Evaluation of the project’s ability to work with the proposed supplier

6. Select the supplier.

SP 1.3 Establish Supplier Agreements
Establish and maintain formal agreements with the supplier.

For Integrated Product and Process Development
When integrated teams are formed, team membership should be negotiated with suppliers and incorporated into the agreement. The agreement should identify any integrated decision making, reporting requirements (business and technical), and trade studies requiring supplier involvement.The supplier efforts should be orchestrated to support the IPPD efforts undertaken by the acquirer. A formal agreement is any legal agreement between the organization (representing the project) and the supplier. This agreement may be a
contract, a license, or a memorandum of agreement.

Typical Work Products
1. Statements of work
2. Contracts
3. Memoranda of agreement
4. Licensing agreement

Subpractices
1. Revise the requirements to be fulfilled by the supplier to reflect negotiations with the supplier when necessary.
2. Document what the project will provide to the supplier.
Include the following:
· Project-furnished facilities
· Documentation
· Services
3. Document the supplier agreement.
The supplier agreement should include a statement of work, a specification, terms and conditions, a list of deliverables, a schedule, a budget, and a defined acceptance process.

This subpractice typically includes the following:
· Establishing the statement of work, specification, terms and conditions, list of deliverables, schedule, budget, and acceptance process
· Identifying who from the project and supplier are responsible and authorized to make changes to the supplier agreement
· Identifying how requirements changes and changes to the supplier agreement are determined, communicated, and addressed
· Identifying standards and procedures that will be followed
· Identifying critical dependencies between the project and the supplier
· Identifying the type and depth of project oversight of the supplier, procedures, and evaluation criteria to be used in monitoring supplier performance
· Identifying the types of reviews that will be conducted with the supplier
· Identifying the supplier’s responsibilities for ongoing maintenance and support of the acquired products
· Identifying warranty, ownership, and usage rights for the acquired products
· Identifying acceptance criteria
4. Ensure all parties to the agreement understand and agree to all requirements before implementing the agreement.
5. Revise the supplier agreement as necessary.
6. Revise the project’s plans and commitments as necessary to reflect the supplier agreement.

Supplier Agreement Management: CMMI Maturity Level 2

2007-05-08T22:57:00.000-07:00

Purpose
The purpose of Supplier Agreement Management is to manage the acquisition of products from suppliers for which there exists a formal agreement.

Introductory Notes
The Supplier Agreement Management process area involves thefollowing:
Determining the type of acquisition that will be used for theproducts to be acquired
· Selecting suppliers
· Establishing and maintaining agreements with suppliers
· Executing the supplier agreement
· Accepting delivery of acquired products
· Transitioning acquired products to the project

This process area primarily applies to the acquisition of products andproduct components that are delivered to the project’s customer. To minimize risks to the project, this process area may also be applied to the acquisition of significant products and product components not delivered to the project’s customer (for example, development tools andtest environments). This process area does not directly address arrangements in which thesupplier is integrated into the project team (for example, integrated product teams). Typically, these situations are handled by other processes or functions, possibly external to the project, though some ofthe specific practices of this process area may be useful in managingthe formal agreement with such a supplier. Suppliers may take many forms depending on business needs,including in-house vendors (i.e., vendors that are in the sameorganization but are external to the project), fabrication capabilities andlaboratories, and commercial vendors.

A formal agreement is any legal agreement between the organization(representing the project) and the supplier. This agreement may be acontract, a license, or a memorandum of agreement. The acquiredproduct is delivered to the project from the supplier and becomes part ofthe products delivered to the customer.

Specific and Generic Goals
SG 1 Establish Supplier Agreements
Agreements with the suppliers are established and maintained.
SG 2 Satisfy Supplier Agreements
Agreements with the suppliers are satisfied by both the project and the supplier.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
(The following goal is not required for maturity level 2, but required for maturity level 3 andabove.)
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Establish Supplier Agreements
SP 1.1 Determine Acquisition Type
SP 1.2 Select Suppliers
SP 1.3 Establish Supplier Agreements

SG 2 Satisfy Supplier Agreements
SP 2.1 Review COTS Products
SP 2.2 Execute the Supplier Agreement
SP 2.3 Accept the Acquired Product
SP 2.4 Transition Products

GG 2 Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management(The following goal is not required and its practices are not expected for a maturity level 2 rating,but are required and expected for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information

Project Monitoring and Control: Specifc Practice By Goal SG2

2007-05-03T00:36:00.000-07:00

SG 2 Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.

SP 2.1 Analyze Issues
Collect and analyze the issues and determine the corrective actions necessary to address the issues.

Typical Work Products
1. List of issues needing corrective actions

Subpractices
1. Gather issues for analysis.
Issues are collected from reviews and the execution of other processes.

Examples of issues to be gathered include:
· Issues discovered through performing verification and validation activities
· Significant deviations in the project planning parameters from the estimates in the project plan
· Commitments (either internal or external) that have not been satisfied
· Significant changes in risk status
· Data access, collection, privacy, or security issues
· Stakeholder representation or involvement issues

2. Analyze issues to determine need for corrective action.
Corrective action is required when the issue, if left unresolved, may prevent the project from meeting its objectives.

SP 2.2 Take Corrective Action
Take corrective action on identified issues.

Typical Work Products
1. Corrective action plan

Subpractices
1. Determine and document the appropriate actions needed to address the identified issues.

Examples of potential actions include the following:
· Modifying the statement of work
· Modifying requirements
· Revising estimates and plans
· Renegotiating commitments
· Adding resources
· Changing processes
· Revising project risks

2. Review and get agreement with relevant stakeholders on the actions to be taken.
3. Negotiate changes to internal and external commitments.

SP 2.3 Manage Corrective Action
Manage corrective actions to closure.

Typical Work Products
1. Corrective action results

Subpractices
1. Monitor corrective actions for completion.
2. Analyze results of corrective actions to determine the effectiveness of the corrective actions.
3. Determine and document appropriate actions to correct deviations from planned results for corrective actions.
Lessons learned as a result of taking corrective action can be inputs to planning and risk management processes.

GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the project monitoring and control process.

Elaboration:
This policy establishes organizational expectations for monitoring performance against the project plan and managing corrective action to closure when actual performance or results deviate significantly from
the plan.

Ability to Perform:
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the project monitoring and control process.

Elaboration:
This plan for performing the project monitoring and control process is typically a part of the project plan, as described in the Project Planning process area.

GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the project monitoring and control process, developing the work products, and providing the services of the process.

Elaboration:
Examples of resources provided include the following tools:
· Cost tracking systems
· Effort reporting systems
· Action-item-tracking systems
· Project management and scheduling programs

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the project monitoring and control process.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the project monitoring and control process as needed. [GP107]

Elaboration:
Examples of training topics include the following:
· Monitoring and control of projects
· Risk management
· Data management

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the project monitoring and control process under appropriate levels of configuration management.

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the project monitoring and control process as planned.

Elaboration:
This generic practice is different from monitoring stakeholder interaction for the project, which is covered by a specific practice in this process area.

Examples of activities for stakeholder involvement include the following:
· Assessing the project against the plan
· Reviewing commitments and resolving issues
· Reviewing project risks
· Reviewing data management activities
· Reviewing project progress
· Managing corrective actions to closure

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the project monitoring and control process
against the plan for performing the process and take appropriate
corrective action.

Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Number of open and closed corrective actions
· Project milestone dates (e.g., planned versus actual and slipped milestones)
· Number and types of reviews performed
· Review schedule (planned versus actual and slipped target dates)

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the project monitoring and control process against its process description, standards, and procedures, and address noncompliance.

Elaboration:
Examples of activities reviewed include the following:
· Monitoring project performance against the project plan
· Managing corrective actions to closure

Examples of work products reviewed include the following:
· Records of project performance
· Project review results

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the project monitoring and control process with higher level management and resolve issues.
(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required for a maturity level 3 rating and above.)

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 project monitoring and control process.

GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the project monitoring and control process to support the future use and improvement of the organization’s processes and process assets.

Project Monitoring and Control: Specifc Practices By Goal SG1

2007-05-02T23:58:00.001-07:00

SG 1 Monitor Project Against Plan
Actual performance and progress of the project are monitored against the project plan.

SP 1.1 Monitor Project Planning Parameters
Monitor the actual values of the project planning parameters against the project plan. Project planning parameters constitute typical indicators of project progress and performance and include attributes of work products and tasks, cost, effort, and schedule. Attributes of the work products and tasks include such items as size, complexity, weight, form, fit, or function. Monitoring typically involves measuring the actual values of project planning parameters, comparing actual values to the estimates in the plan, and identifying significant deviations. Recording actual values ofthe project planning parameters includes recording associated contextual information to help understand the measures. An analysis of the impact that significant deviations have on determining what corrective actions to take is handled in the second specific goal and its specific practices in this process area.

Typical Work Products
1. Records of project performance
2. Records of significant deviations

Subpractices
1. Monitor progress against the schedule.
Progress monitoring typically includes the following:
· Periodically measuring the actual completion of activities and milestones
· Comparing actual completion of activities and milestones against the schedule documented in the project plan
· Identifying significant deviations from the schedule estimates in the project plan

2. Monitor the project's cost and expended effort.
Effort and cost monitoring typically includes the following:
· Periodically measuring the actual effort and cost expended and staff assigned
· Comparing actual effort, costs, staffing, and training to the estimates and budgetsdocumented in the project plan
· Identifying significant deviations from the budgets in the project plan

3. Monitor the attributes of the work products and tasks.Monitoring the attributes of the work products and tasks typically includes thefollowing:
· Periodically measuring the actual attributes of the work products and tasks, such as size or complexity (and the changes to the attributes)
· Comparing the actual attributes of the work products and tasks (and the changesto the attributes) to the estimates documented in the project plan
· Identifying significant deviations from the estimates in the project plan

4. Monitor resources provided and used.

For Software Engineering
Examples of software-engineering resources include the following:
· Host computers and peripherals
· Networks
· Software test computers and peripherals
· Target computer environment software
· Software-engineering environment (e.g., software tools)

SP 1.2 Monitor Commitments
Monitor commitments against those identified in the project plan.

Typical Work Products
1. Records of commitment reviews

Subpractices
1. Regularly review commitments (both external and internal).
2. Identify commitments that have not been satisfied or which are atsignificant risk of not being satisfied.
3. Document the results of the commitment reviews.

SP 1.3 Monitor Project Risks
Monitor risks against those identified in the project plan.

Typical Work Products
1. Records of project risk monitoring

Subpractices
1. Periodically review the documentation of the risks in the context ofthe project’s current status and circumstances.
2. Revise the documentation of the risks, as additional informationbecomes available, to incorporate changes. 3. Communicate risk status to relevant stakeholders.

Examples of risk status include the following:
· A change in the probability that the risk occurs
· A change in risk priority

SP 1.4 Monitor Data Management
Monitor the management of project data against the project plan.Once the plans for the management of project data are made, themanagement of that data must be monitored to ensure that those plans are accomplished.

Typical Work Products
1. Records of data management

Subpractices
1. Periodically review data management activities against theirdescription in the project plan.

2. Identify and document significant issues and their impacts.

3. Document the results of data management activity reviews.

SP 1.5 Monitor Stakeholder Involvement
Monitor stakeholder involvement against the project plan.
Once the stakeholders are identified and the extent of their involvementwithin the project is specified in project planning, that involvement mustbe monitored to ensure that the appropriate interactions are occurring.

Typical Work Products
1. Records of stakeholder involvement

Subpractices
1. Periodically review the status of stakeholder involvement.
2. Identify and document significant issues and their impacts.
3. Document the results of the stakeholder involvement statusreviews.

SP 1.6 Conduct Progress Reviews
Periodically review the project's progress, performance, andissues. Progress reviews are reviews on the project to keep stakeholdersinformed. These project reviews can be informal reviews and may notbe specified explicitly in the project plans.

Examples of these reviews include the following:
· Reviews with staff
· Reviews with project engineers and support
· Reviews with management

For Supplier Sourcing
Examples of these reviews also include the following:
· Reviews with key suppliers

Typical Work Products
1. Documented project review results

Subpractices
1. Regularly communicate status on assigned activities and workproducts to relevant stakeholders. Managers, staff members, customers, end users, suppliers, and other relevantstakeholders within the organization are included in the reviews as appropriate.

2. Review the results of collecting and analyzing measures forcontrolling the project.

3. Identify and document significant issues and deviations from theplan.

4. Document change requests and problems identified in any of thework products and processes.

5. Document the results of the reviews.

6. Track change requests and problem reports to closure.

SP 1.7 Conduct Milestone Reviews
Review the accomplishments and results of the project at selectedproject milestones. Milestone reviews are planned during project planning and are typicallyformal reviews.

Typical Work Products
1. Documented milestone review results

Subpractices
1. Conduct reviews at meaningful points in the project's schedule,such as the completion of selected stages, with relevant stakeholders. Managers, staff members, customers, end users, suppliers, and other relevantstakeholders within the organization are included in the milestone reviews asappropriate.

2. Review the commitments, plan, status, and risks of the project.

3. Identify and document significant issues and their impacts.

4. Document the results of the review, action items, and decisions.

5. Track action items to closure.

Project Monitoring and Control: CMMI Maturity Level 2

2007-05-02T23:34:00.000-07:00

Purpose:
The purpose of Project Monitoring and Control is to provide anunderstanding of the project’s progress so that appropriate correctiveactions can be taken when the project’s performance deviatessignificantly from the plan.

Introductory Notes:
A project's documented plan is the basis for monitoring activities,communicating status, and taking corrective action. Progress isprimarily determined by comparing actual work product and taskattributes, effort, cost, and schedule to the plan at prescribedmilestones or control levels within the project schedule or workbreakdown structure. Appropriate visibility enables timely correctiveaction to be taken when performance deviates significantly from theplan. A deviation is significant if, when left unresolved, it precludes theproject from meeting its objectives.
The term “project plan” is used throughout these practices to refer to theoverall plan for controlling the project.
When actual status deviates significantly from the expected values,corrective actions are taken as appropriate. These actions may requirere-planning, which may include revising the original plan, establishingnew agreements, or including additional mitigation activities within thecurrent plan.

Specific and Generic Goals:
SG 1 Monitor Project Against Plan
Actual performance and progress of the project are monitored against theproject plan.
SG 2 Manage Corrective Action to Closure
Corrective actions are managed to closure when the project's performance orresults deviate significantly from the plan.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.(The following goal is not required for maturity level 2, but required for maturity level 3 andabove.)
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.

Practice-to-Goal Relationship Table
SG 1 Monitor Project Against Plan
SP 1.1 Monitor Project Planning Parameters
SP 1.2 Monitor Commitments
SP 1.3 Monitor Project Risks
SP 1.4 Monitor Data Management
SP 1.5 Monitor Stakeholder Involvement
SP 1.6 Conduct Progress Reviews
SP 1.7 Conduct Milestone Reviews

SG 2 Manage Corrective Action to Closure
SP 2.1 Analyze Issues
SP 2.2 Take Corrective Action
SP 2.3 Manage Corrective Action
GG 2 Institutionalize a Managed Process
GP 2.1 (CO 1) Establish an Organizational Policy
GP 2.2 (AB 1) Plan the Process
GP 2.3 (AB 2) Provide Resources
GP 2.4 (AB 3) Assign Responsibility
GP 2.5 (AB 4) Train People
GP 2.6 (DI 1) Manage Configurations
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
GP 2.8 (DI 3) Monitor and Control the Process
GP 2.9 (VE 1) Objectively Evaluate Adherence
GP 2.10 (VE 2) Review Status with Higher Level Management(The following goal is not required and its practices are not expected for a maturity level 2 rating,but are required and expected for a maturity level 3 rating and above.)
GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information

Project Planning: Specific Practices by Goal: SG3

2007-04-26T02:17:00.000-07:00

Obtain Commitment to the Plan
Commitments to the project plan are established and maintained. To be effective, plans require commitment by those responsible for implementing and supporting the plan.

SP 3.1 Review Plans that Affect the Project
Review all plans that affect the project to understand project
commitments.
For Integrated Product and Process Development
When integrated teams are formed, their integrated work plans are among the plans to review. Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control. All plans that affect the project should be reviewed to ensure a common understanding of the scope, objectives, roles, and relationships that are required for the project to be successful. Many of these plans are
described by the Plan the Process generic practice in each of the process areas.

Typical Work Products
1. Record of the reviews of plans that affect the project

SP 3.2 Reconcile Work and Resource Levels
Reconcile the project plan to reflect available and estimated resources.

For Integrated Product and Process Development
When integrated teams are formed, special attention needs to be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or many projects. To obtain commitment from relevant stakeholders, it is important to reconcile any differences between the estimates and the available resources. Reconciliation is typically accomplished by lowering or
deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or
schedules.

Typical Work Products
1. Revised methods and corresponding estimating parameters (e.g.,better tools, use of off-the-shelf components)
2. Renegotiated budgets
3. Revised schedules
4. Revised requirements list
5. Renegotiated stakeholder agreements

SP 3.3 Obtain Plan Commitment
Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

For Integrated Product and Process Development
When integrated teams are formed, the integrated team plans will need buy-in from the team members, the interfacing teams, the project, and the process owners of the standard processes that team has selected for tailored application.
Obtaining commitment involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints.Often, a provisional commitment is adequate to allow the effort to begin and to permit research to be performed to increase confidence to the
appropriate level needed to obtain a full commitment.

Typical Work Products
1. Documented requests for commitments
2. Documented commitments

Subpractices
1. Identify needed support and negotiate commitments with relevant stakeholders.
The WBS can be used as a checklist for ensuring that commitments are obtained for all tasks. The plan for stakeholder interaction should identify all parties from whom commitment should be obtained.
2. Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories.Commitments must be documented to ensure a consistent mutual understanding as well as for tracking and maintenance. Provisional commitments should be accompanied by a description of the risks associated with the relationship.
3. Review internal commitments with senior management as appropriate.
4. Review external commitments with senior management as appropriate. Management may have the necessary insight and authority to reduce risks associated with external commitments.
5. Identify commitments on interfaces between elements in the project, and with other projects and organizational units, so they can be monitored.Well-defined interface specifications form the basis for commitments.

GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.

Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the project planning process.
Elaboration:
This policy establishes organizational expectations for estimating the planning parameters, making internal and external commitments, and developing the plan for managing the project.

Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the project planning process.
Elaboration:
This plan for performing the project planning process differs from the project plan described in specific practices in this process area. The plan called for in this generic practice would address the comprehensive planning for all of the specific practices in this process area, from estimating the scope of the project all the way to obtaining commitment for the project plan. In other words, this generic practice calls for one to "plan the plan." In contrast, the project plan called for in the specific practices would address planning for the project effort itself in a comprehensive manner.

GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the project planning process, developing the work products, and providing the services of the process.
Elaboration:
Special expertise, equipment, and facilities in project planning may be required. Special expertise in project planning may include the following:
· Experienced estimators
· Schedulers
· Technical experts in applicable areas (e.g., product domain and technology)
Examples of other resources provided include the following tools:
· Spreadsheet programs
· Estimating models
· Project planning and scheduling packages

GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process,developing the work products, and providing the services of the project planning process.

GP 2.5 (AB 4) Train People
Train the people performing or supporting the project planning process as needed.
Elaboration:
Examples of training topics include the following:
· Estimating
· Budgeting
· Negotiating
· Risk identification and analysis
· Data management
· Planning
· Scheduling

Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the project planning process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Work breakdown structure
· Project plan
· Data management plan
· Stakeholder involvement plan

GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the project planning process as planned.
Elaboration:
This generic practice is different from developing the plan for stakeholder involvement for the project itself, which is covered in a specific practice of this process area.
Select relevant stakeholders from senior managers, project managers,project functional managers (e.g., systems engineering, software engineering, other disciplines), software engineers, systems engineers,
manufacturing engineers, logisticians, suppliers, customers, and others who may be affected by, or may affect, the project.
Examples of activities for stakeholder involvement include the following:
· Establishing estimates
· Reviewing and resolving issues on the completeness and correctness of the project risks
· Reviewing data management plans
· Establishing project plans
· Reviewing project plans and resolving issues on work and resource issues

GP 2.8 (DI 3) Monitor and Control the Process
Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures used in monitoring and controlling include the following:
· Number of revisions to the plan
· Cost, schedule, and effort variance per plan revision

Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the project planning process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Establishing estimates
· Developing a project plan
· Obtaining commitments to the project plan

Examples of work products reviewed include the following:
· WBS
· Project plan
· Data management plan
· Stakeholder involvement plan

GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the project planning process with higher level management and resolve issues.

(The following goal is not required and its practices are not expected for a maturity level 2 rating,
but are required for a maturity level 3 rating and above.)

GG 3 Institutionalize a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined project planning process.
GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the project planning process to support the future use and improvement of the organization’s processes and process assets.