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.
Tuesday, July 31, 2007
Requirements Development: CMMI Maturity Level 3
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
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
Monday, July 23, 2007
Configuration Management: 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 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.
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.
Tuesday, July 17, 2007
Configuration Management: Specific Practices by Goal SG3
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.
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.
Tuesday, July 3, 2007
Configuration Management: Specific Practices by Goal SG2
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.
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.
Monday, July 2, 2007
Configuration Management: Specific Practices by Goal SG1
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.
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.
Subscribe to:
Posts (Atom)