18.3 Integrated Product Development

The Software Engineering Institute (SEI) defines integrated product development (IPD) as

a systematic approach to product development that achieves a timely collaboration of necessary disciplines throughout the product life cycle to better satisfy customer needs. It typically involves a teaming of the functional disciplines to integrate and concurrently apply all necessary processes to produce an effective and efficient product that satisfies the customer's needs.

SEI developed and supported an IPD-CMM (capability maturity model) for integrated product development that is now part of CMMI. The field of IPD is characterized by cross-functionality and holistic thinking, which is becoming more relevant as products become more complex. Products may be composed of subproducts , such as

• Softwarethe application(s)

• Hardwareboxes and/or PCs and/or peripherals

• NetworkLAN or the internet

• Datasystem data or parameter values

• Servicesintangible deliveries such as training and maintenance

IPD requires considering a product's entire life, from conception to destructionfrom the initial idea to disposal of all the parts . This is especially interesting for products that create nuclear waste, where destruction may take hundreds or thousands of years .

Products are also more than just the product, since they includes processesfor design, test, logistics, manufacturing, and so onthat make the product possible.

Organizational Considerations

Integrated product development is an organization-wide decision. The definition of IPD already presented has an impact on the way an integrated configuration management system is set up: the teaming of functional disciplines to integrate and concurrently apply all necessary processes.

Configuration Management Considerations

A configuration management system for integrated product development must take all the aspects of this philosophy into account and ensure that all the items defined for an integrated product can be placed under configuration management in an integrated and concurrent way. This is not easy.

Approach

Existing configuration management system(s) must be identified:

• For the full product and all subtypes (e.g., software and hardware development)

• For all defined lifecycle development activities (e.g., preparation, design, and production)

• For all processes (e.g., process management)

If a configuration management system does not exist for one or more of the aspects or if it's not complete, the missing parts must be defined. The processes involved must be analyzed to identify overlaps and conflicts, which must be resolved. It's unrealistic to imagine that no borderlines will exist between configuration management of the various types of items, but they must be made as smooth and imperceptible as possible.