Engineering

Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. The Engineering process areas were written using general engineering terminology so that any technical discipline involved in the product development process (e.g., software engineering, mechanical engineering) can use them for process improvement.

The Engineering process areas also integrate software engineering and systems engineering processes into a single product development process, supporting a product-oriented process improvement strategy. Such a strategy targets essential business objectives rather than specific technical disciplines. This approach to processes effectively avoids the tendency toward an organizational "stovepipe" mentality.

The Engineering process areas apply to the development of any product or service in the engineering development domain (e.g., software products, hardware products, services, or processes).

The technical foundation for IPPD is grounded in a robust systems engineering approach that encompasses development in the context of the phases of the product's life. The Engineering process areas provide this technical foundation. The implementation of IPPD is further addressed through amplifications to specific practices in the Engineering process areas that emphasize concurrent development and focus on all phases of the product's life.

The Engineering process areas of CMMI are as follows:

• Requirements Development

• Requirements Management

• Technical Solution

• Product Integration

• Verification

• Validation

Figure 4.5 provides a bird's-eye view of the interactions among the six Engineering process areas.

Figure 4.5. Engineering Process Areas

The Requirements Development process area identifies customer needs and translates these needs into product requirements. The set of product requirements is analyzed to produce a high-level conceptual solution. This set of requirements is then allocated to establish an initial set of product-component requirements. Other requirements that help define the product are derived and allocated to product components. This set of product and product-component requirements clearly describes the product's performance, design features, verification requirements, and so forth in terms the developer understands and uses.

The Requirements Development process area supplies requirements to the Technical Solution process area, where the requirements are converted into the product architecture, product-component design, and the product component itself (e.g., coding, fabrication). Requirements are also supplied to the Product Integration process area, where product components are combined and interfaces are verified to ensure that they meet the interface requirements supplied by Requirements Development.

The Requirements Management process area maintains the requirements. It describes activities for obtaining and controlling requirement changes and ensuring that other relevant plans and data are kept current. It provides traceability of requirements from customer to product to product component.

Requirements Management ensures that changes to requirements are reflected in project plans, activities, and work products. This cycle of changes may affect all the other Engineering process areas; thus requirements management is a dynamic and often recursive sequence of events. The Requirements Management process area is fundamental to a controlled and disciplined engineering design process.

The Technical Solution process area develops technical data packages for product components that will be used by the Product Integration or Supplier Agreement Management process areas. Alternative solutions are examined with the intent of selecting the optimum design based on established criteria. These criteria may be significantly different across products, depending on product type, operational environment, performance requirements, support requirements, and cost or delivery schedules. The task of selecting the final solution makes use of the specific practices in the Decision Analysis and Resolution process area.

The Technical Solution process area relies on the specific practices in the Verification process area to perform design verification and peer reviews during design and prior to final build.

The Verification process area ensures that selected work products meet the specified requirements. The Verification process area selects work products and verification methods that will be used to verify work products against specified requirements. Verification is generally an incremental process, starting with product-component verification and usually concluding with verification of fully assembled products.

Verification also addresses peer reviews. Peer reviews are a proved method for removing defects early and provide valuable insight into the work products and product components being developed and maintained.

The Validation process area incrementally validates products against the customer's needs. Validation may be performed in the operational environment or a simulated operational environment. Coordination with the customer on the validation requirements is an important element of this process area.

The scope of the Validation process area includes validation of products, product components, selected intermediate work products, and processes. These validated elements may often require reverification and revalidation. Issues discovered during validation are usually resolved in the Requirements Development or Technical Solution process areas.

The Product Integration process area contains the specific practices associated with generating the best possible integration sequence, integrating product components, and delivering the product to the customer.

Product Integration uses the specific practices of both Verification and Validation in implementing the product integration process. Verification practices verify the interfaces and interface requirements of product components prior to product integration. This is an essential event in the integration process. During product integration in the operational environment, the specific practices of the Validation process area are used.

Engineering Process Areas and Recursion

All Engineering process areas have been written to support recursion throughout the product architecture. An example is the "Establish Product Integration Procedures and Criteria" specific practice in the Product Integration process area. For a product with many complex product components, this specific practice would be applied to the product components of the complete product delivered to the customer as well as to the product components assembled to form the product, and so on. Thus, this specific practice is applied to as many levels as necessary to integrate everything that the product comprises.

There is no specific practice that forces recursive process application. Rather, the specific practices are written in a fashion that expects process application throughout the product architecture. When implementing the specific practices of an Engineering process area, you must interpret them according to the needs of your product. You may be more comfortable viewing this approach as providing a sufficiently generic set of expectations that can be applied at any level of product detail rather than as enabling recursive behavior of a process. Either description of this approach is appropriate.

There are a number of advantages gained by this approach. For example, the Engineering process areas can be applied to a product that has several layers of product components and can ensure that the specific practices will address each layer. Thus, different segments of a very large project can be appraised using the same model.