Monday, October 22, 2007

Verification: Specific Practices by Goal SG2

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.

Friday, October 19, 2007

Verification: Specific Practices by Goal SG1

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

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

Wednesday, October 17, 2007

Product Integration : Institutionalize a Defined Process GG3

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.

Thursday, October 11, 2007

Product Integration : Specific Practices by Goal SG3

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.

Monday, October 1, 2007

Product Integration : Specific Practices by Goal SG2

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

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

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

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.