CMMi - Product Integration (PI) Process Area



Product Integration (PI)
Process Areas
The CMMi easy button concept and disclaimer

Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.

The concept of The CMMi easy button is to be able to
jump start SQA software professionals in establishing an
effective Software process Improvement (SPI) framework that is based on CMMi theories and best practices.

CMMI, CMM, and Capability Maturity Model are registered
in the U.S. Patent and Trademark Office.
CMM Integration, SCAMPI, and IDEAL are service marks of
Carnegie Mellon University.
Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR)
Integrated Project Management +IPPD (IPM+IPPD) Measurement and Analysis (MA) Organizational Innovation and Deployment (OID)
Organizational Process Definition +IPPD (OPD+IPPD) Organizational Process Focus (OPF) Organizational Process Performance (OPP)
Organizational Training (OT) Product Integration (PI) Project Monitoring and Control (PMC)
Project Planning (PP) Process and Product Quality Assurance (PPQA) Quantitative Project Management (QPM)
Requirements Development (RD) Requirements Management (REQM) Risk Management (RSKM)
Supplier Agreement Management (SAM) Technical Solution (TS) Validation (VAL)
. Verification (VER) .
The CMMi Easy button notes on Product Integration (PI) Product Integration (PI) purpose and introductory notes
Specific Goals and Practices
Specific Goal 1 (SG 1) Prepare for Product Integration (SP 1.*)
SP 1.1 Determine Integration Sequence SP 1.2 Establish the Product Integration Environment SP 1.3 Establish Product Integration Procedures and Criteria .
Specific Goal 2 (SG 2) Ensure Interface Compatibility (SP 2.*)
SP 2.1 Review Interface Descriptions for Completeness SP 2.2 Manage Interfaces . .
Specific Goal 3 (SG 3) Assemble Product Components and Deliver the Product (SP 3.*)
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
Generic Goals and Practices
Generic Goal 1 (GG 1) Achieve Specific Goals, Generic Practices (GP 1.*)
GP 1.1 Perform Specific Practices . . .
Generic Goal 2 (GG 2) Institutionalize a Managed Process, Generic Practices (GP 2.*)
GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility
GP 2.5 Train People GP 2.6 Manage Configurations GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management . .
Generic Goal 3 (GG 3) Institutionalize a Defined Process, Generic Practices (GP 3.*)
GP 3.1 Establish a Defined Process GP 3.2 Collect Improvement Information . .
Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process, Generic Practices (GP 4.*)
GP 4.1 Establish Quantitative Objectives for the Process GP 4.2 Stabilize Subprocess Performance . .
Generic Goal 5 (GG 5) Institutionalize an Optimizing Process, Generic Practices (GP 5.*)
GP 5.1 Ensure Continuous Process Improvement GP 5.2 Correct Root Causes of Problems . .

The CMMi Easy button notes on Product Integration (PI) Process Area

Product Integration (PI) is one of the core Engineering Process Areas within CMMi, this process is concerned with assembly of product components to build the finished software product.

One major risk area in a component based software architecture is that the components do not talk (or interface) to each other. In today's multi tier Client Server environment (which includes Web Servers, Web Services, Application Servers for business rules and Databases) there are many opportunities for introducing defects due to misaligned interfaces. Product Integration (PI) confirms that each component matches its agreed specification prior to assembly. This activity (conformance) makes use of the Verification (VER) CMMi process area which includes testing (post-assembly) as well as inspection (pre-assembly).



Product Integration (PI)





An Engineering Process Area at Maturity Level 3

Purpose


The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.

Introductory Notes


This process area addresses the integration of product components into more complex product components or into complete products.

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. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.

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 on knowledge gained in the evaluation process. The degree of virtual versus 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 and services, the last integration phase will occur when they are deployed at the intended operational site.

Related Process Areas.

Refer to the Requirements Development process area for more information about identifying interface requirements.

Refer to the Technical Solution process area for more information about defining the interfaces and the integration environment (when the integration environment needs to be developed).

Refer to the Verification process area for more information about verifying the interfaces, the integration environment, and the progressively assembled product components.

Refer to the Validation process area for more information about performing validation of the product components and the integrated product.

Refer to the Risk Management process area for more information about identifying risks and the use of prototypes in risk mitigation for both interface compatibility and product component integration.

Refer to the Decision Analysis and Resolution process area for more information about using a formal evaluation process for selecting the appropriate integration sequence and procedures and for deciding whether the integration environment should be acquired or developed.

Refer to the Configuration Management process area for more information about managing changes to interface definitions and about the distribution of information.

Refer to the Supplier Agreement Management process area for more information about acquiring product components or parts of the integration environment.

Specific Practices by Goal

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.

Refer to the Decision Analysis and Resolution process area for more information about using a formal evaluation process to select the appropriate product integration sequence.

Refer to the Risk Management process area for more information about identifying and handling risks associated with the integration sequence.

Refer to the Supplier Agreement Management process area for more information about transitioning acquired product components and the need for handling those product components in the product integration sequence.

Typical Work Products
  • Product integration sequence
  • Rationale for selecting or rejecting integration sequences
Subpractice 1: Identify the product components to be integrated.

Subpractice 2: Identify the verifications to be performed during the integration of the product components.

Subpractice 3: Identify alternative product component integration sequences.

This can include defining the specific tools and test equipment to support the product integration.

Subpractice 4: Select the best integration sequence.

Subpractice 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 on which earlier decisions were made.

Subpractice 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.

Refer to the Technical Solution process area for more information about make-or-buy decisions.

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 unavailable product components), pieces of real equipment, and recording devices.

Typical Work Products
  • Verified environment for product integration
  • Support documentation for the product integration environment
Subpractice 1: Identify the requirements for the product integration environment.

Subpractice 2: Identify verification criteria and procedures for the product integration environment.

Subpractice 3: Decide whether to make or buy the needed product integration environment.

Refer to the Supplier Agreement Management process area for more information about acquiring parts of the integration environment.

Subpractice 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.

Subpractice 5: Maintain the product integration environment throughout the project.

Subpractice 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.

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

Refer to the Supplier Agreement Management process area for more information about communicating with suppliers

Typical Work Products
  • Product integration procedures
  • Product integration criteria
Subpractice 1: Establish and maintain product integration procedures for the product components.

Subpractice 2: Establish and maintain criteria for product component integration and evaluation.

Subpractice 3: Establish and maintain criteria for validation and delivery of the integrated product.

SG 2 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
  • Categories of interfaces
  • List of interfaces per category
  • Mapping of the interfaces to the product components and the product integration environment
Subpractice 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.

Examples of interfaces (e.g., for mechanical or electronic components) that may be classified within these three classes 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, and shocks and vibrations received from the bearing structure)
  • Noise interfaces (e.g., noise transmitted by the structure, noise transmitted in the air, and acoustics)
  • Climatic interfaces (e.g., temperature, humidity, pressure, and salinity)
  • Thermal interfaces (e.g., heat dissipation, transmission of heat to the bearing structure, and 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, and exhaust gas outlet)
  • Electrical interfaces (e.g., power supply consumption by network with transients and peak values; nonsensitive control signal for power supply and communications; sensitive signal [e.g., analog links]; disturbing signal [e.g., microwave]; and grounding signal to comply with the TEMPEST standard)
  • Electromagnetic interfaces (e.g., magnetic field, radio and radar links, optical band link wave guides, and coaxial and optical fibers)
  • Human-machine interface (e.g., audio or voice synthesis, audio or voice recognition, display [analog dial, television screen, or liquid-crystal display, indicators' light-emitting diodes], and manual controls [pedal, joystick, ball, keys, push buttons, or touch screen])
  • Message interfaces (e.g., origination, destination, stimulus, protocols, and data characteristics)
Subpractice 2: Ensure that product components and interfaces are marked to ensure easy and correct connection to the joining product component.

Subpractice 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.

The interface descriptions for product components should be reviewed with relevant stakeholders 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.

Refer to the Requirements Development process area for more information about requirements for interfaces.

Refer to the Technical Solution process area for more information about design of interfaces between product components.

Refer to the Requirements Management process area for more information about managing the changes to the interface requirements.

Refer to the Configuration Management process area for more information about distributing changes to the interface descriptions (specifications) so that everyone can know the current state of the interfaces.

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 management of interfaces between products acquired from suppliers and other products or product components is critical for success of the project.

Refer to the Supplier Agreement Management process area for more information about managing suppliers.

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
  • Table of relationships among the product components and the external environment (e.g., main power supply, fastening product, and computer bus system)
  • Table of relationships among the different product components
  • List of agreed-to interfaces defined for each pair of product components, when applicable
  • Reports from the interface control working group meetings
  • Action items for updating interfaces
  • Application program interface (API)
  • Updated interface description or agreement
Subpractice 1: Ensure the compatibility of the interfaces throughout the life of the product.

Subpractice 2: Resolve conflict, noncompliance, and change issues.

Subpractice 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.

SG 3 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.

Refer to the Verification process area for more information about verifying product components.

Refer to the Technical Solution process area for more information about unit test of product components.

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
  • Acceptance documents for the received product components
  • Delivery receipts
  • Checked packing lists
  • Exception reports
  • Waivers
Subpractice 1: Track the status of all product components as soon as they become available for integration.

Subpractice 2: Ensure that product components are delivered to the product integration environment in accordance with the product integration sequence and available procedures.

Subpractice 3: Confirm the receipt of each properly identified product component.

Subpractice 4: Ensure that each received product component meets its description.

Subpractice 5: Check the configuration status against the expected configuration.

Subpractice 6: Perform a pre-check (e.g., 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.

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.

Typical Work Products
  • Assembled product or product components
Subpractice 1: Ensure the readiness of the product integration environment.

Subpractice 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).

Subpractice 3: Revise the product integration sequence and available procedures as appropriate.

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.

SP 3.3 Evaluate Assembled Product Components

Evaluate assembled product components for interface compatibility.

Refer to the Verification process area for more information about verifying assembled product components.

Refer to the Validation process area for more information about validating assembled product components.

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 product integration sequence and available procedures could have determined that only a final evaluation was the best one to perform.

Typical Work Products
  • Exception reports
  • Interface evaluation reports
  • Product integration summary reports
Subpractice 1: Conduct the evaluation of assembled product components following the product integration sequence and available procedures.

Subpractice 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.

Refer to the Verification process area for more information about verifying the product or an assembly of product components before packaging.

Refer to the Validation process area for more information about validating the product or an assembly of product components before packaging.

The packaging requirements for some products can 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., shrink wrapping)
  • Ease and safety of unpacking (e.g., sharp edges, strength of binding methods, childproofing, environmental friendliness of packing material, and weight)
The adjustment required to fit product components together in the factory could be different from the one required to fit product components together 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
  • Packaged product or product components
  • Delivery documentation
Subpractice 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.

Subpractice 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
Subpractice 3: Satisfy the applicable requirements and standards for packaging and delivering the product.

Examples of requirements and standards include those for safety, the environment, security, transportability, and disposal.

For Software Engineering

Examples of requirements and standards for packaging and delivering software include the following:
  • Type of storage and delivery media
  • Custodians of the master and backup copies
  • Required documentation
  • Copyrights
  • License provisions
  • Security of the software
Subpractice 4: Prepare the operational site for installation of the product.

Preparing the operational site may be the responsibility of the customer or end users.

Subpractice 5: Deliver the product and related documentation and confirm receipt.

Subpractice 6: Install the product at the operational site and confirm correct operation.

Installing the product may be the responsibility of the customer or the 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.

Generic Practices by Goal

GG 1 Achieve Specific Goals

The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.

GP 1.1 Perform Specific Practices

Perform the specific practices of the product integration process to develop work products and provide services to achieve the specific goals of the process area.

GG 2 Institutionalize a Managed Process

The process is institutionalized as a managed process.

GP 2.1 Establish an Organizational Policy

Establish and maintain an organizational policy for planning and performing the 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.

GP 2.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 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 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 Train People

Train the people performing or supporting the product integration process as needed.

Elaboration:

Examples of training topics include the following:
  • Application domain
  • Product integration procedures and criteria
  • Organizationís facilities for integration and assembly
  • Assembly methods
  • Packaging standards
GP 2.6 Manage Configurations

Place designated work products of the product integration process under appropriate levels of control.

Elaboration:

Examples of work products placed under control 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 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 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 and work products 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)
  • Schedule for conduct of specific integration activities
GP 2.9 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 Review Status with Higher Level Management

Review the activities, status, and results of the product integration process with higher level management and resolve issues.

GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

This generic goal's appearance here reflects its location in the continuous representation.

GP 3.1 Establish a Defined Process

Establish and maintain the description of a defined product integration process.

GP 3.2 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.

Elaboration:

Examples of work products, measures, measurement results, and improvement information include the following:
  • Records of the receipt of product components, exception reports, confirmation of configuration status, and results of readiness checking
  • Percent of total development effort spent in product integration (actual to date plus estimate to complete)
  • Defects found in the product and test environment during product integration
  • Problem reports resulting from product integration
GG 4 Institutionalize a Quantitatively Managed Process

The process is institutionalized as a quantitatively managed process.

GP 4.1 Establish Quantitative Objectives for the Process

Establish and maintain quantitative objectives for the product integration process, which address quality and process performance, based on customer needs and business objectives.

GP 4.2 Stabilize Subprocess Performance

Stabilize the performance of one or more subprocesses to determine the ability of the product integration process to achieve the established quantitative quality and process-performance objectives.

GG 5 Institutionalize an Optimizing Process

The process is institutionalized as an optimizing process.

GP 5.1 Ensure Continuous Process Improvement

Ensure continuous improvement of the product integration process in fulfilling the relevant business objectives of the organization.

GP 5.2 Correct Root Causes of Problems

Identify and correct the root causes of defects and other problems in the product integration process.


Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi and Software Quality Assurance. No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-