6.8. Engineering Process Areas
The following sections detail the Process Areas specific to engineering.
6.8.1. Requirements Management
If the IT industry as a whole were asked to isolate one activity that led to more problems than any other, it would probably be requirements management. Poor requirementsincomplete, inconsistent, ill-expressedhave been known to derail a project faster than almost anything else. Without sound requirements, a project operates in an amorphous world where nothing can be fixed, where no quality mark can be set. Therefore, sound requirementsat least a baseline of sound requirementsshould be in place before you embark on any development effort.[*] It's a critical path item for project success. It's not hard to see why. If your project team has no methods or tools for managing requirements, no degree of effective oversight or engineering talent will keep a project on its rails. The tracks have been greased for slipperiness from start to finish. Requirements Management then is an essential characteristic of any quality model.
At its core, Requirements Management is a control technique that should be adopted as early as possible in a project's life cycle. Because it recognizes that people change their minds, that business rules fluctuate, that no one thinks of everything at once, requirements management serves as a facility to handle change in a manner that promotes the clean intake of requirements, their smooth integration into project plans, and their eventual evolution across project phases.
220.127.116.11. One specific goal
CMMI defines one basic goal for Requirements Management: that requirements are managed. By this, the spec implies five common practices, each one leading from and building on the other:
18.104.22.168. Core Requirements Management actions
The team agrees to a core set of requirements and then actively tracks and monitors their evolution across every phase of the project.
Applies to Engineering:
Figure 6-7 illustrates the Requirements Management PA.
Figure 6-7. Requirements Management is focused on how requirements are reviewed, approved, and baselined for project work. This includes obtaining an understanding of the requirements, obtaining commitment to the requirements prior to work, tracking changes to requirements, and keeping requirements and work products consistent with each other.
6.8.2. Requirements Development
Requirements Development is the logical "pre-extension" of Requirements Management. It deepens Requirements Management, a technology-engineering task, by linking it with a primary systems-engineering task, the development of the requirements. In the CMMI model, Requirements Development is concerned with producing requirements through interactions with customers and then analyzing those requirements to validate their completeness.
Developing requirements is a big job any way you look at it. And CMMI doesn't describe in detail just how the job should be done. It outlines at a high level the tasks of stakeholder coordination, elicitation, documentation, verification, and communication. Its main concern is that requirements development is conducted through a set process, a process composed of defined steps. The use of process is especially important here: requirements development is a notoriously intuitive regimen. By its nature, it's in the business of translation, and translation is always open to misinterpretation and missing detail. A process won't make the regimen perfect, but it will give your people an arena to operate in that promotes consistency and thoroughness, and it will foster mechanisms for feedback and review. With those kinds of elements in place, your Requirements Development effort should become cleaner and cleaner over time.
22.214.171.124. Three specific goals
CMMI identifies three goals within the Requirements Development Process Area:
126.96.36.199. Core Requirements Development actions
Your business analysts work with customers and other selected stakeholders to elicit and document customer requirements and product requirements. These requirements are then analyzed for completeness, suitability, and viability.
Applies to Engineering:
Figure 6-8 illustrates the Requirements Development PA.
Figure 6-8. Requirements Development deals with the elicitation, composition, and analysis of requirements. The activities provide structure for tasks to develop customer requirements, develop product component requirements and any interfaces needed to link the components, and develop methods for prioritizing and balancing requirements across the project life cycle.
6.8.3. Technical Solution
Technical Solution is designed to provide the organization with guidelines for determining the technical direction of a project, then organizing and implementing an appropriate design. This Process Area is in many ways an extension of the two Requirements Process Areas: Requirements Management and Requirements Development. Those Process Areas provide means for eliciting, documenting, and managing the requirements that form the basis of a development project. They can be thought of (if you prefer to think of these Engineering PAs in a traditional SDLC order) as the first two Process Areas of CMMI. The Technical Solution PA moves you from requirements to design.
Here the model makes recommendations for evaluating, organizing, and implementing an appropriate design for the project. The focus is on finding the right technical solution, one that makes sense based on the needs of the project as a whole and on the different subcomponents of the project.
188.8.131.52. Three specific goals
This Process Area comes with three specific goals:
184.108.40.206. Core Technical Solution actions
The project team uses the requirements as a base for determining and implementing an appropriate product design, one that accounts for all product components and interfaces. This is based on evaluations of viable alternatives, as well as on the technical capabilities of the organization. The designs are then implemented.
Applies to Engineering:
Figure 6-9 illustrates the Technical Solution PA.
Figure 6-9. Technical Solution contains practices for deriving the right technical solution for a project, and then implementing an appropriate design based on the solution. This Process Area also includes implementing the design (through coding, construction, etc.) and establishing a technical data package to support the design.
6.8.4. Product Integration
Product Integration is concerned with the gradual, prescribed assembly and delivery of the developed product along with its accompanying materials. This Process Area is related to Configuration Management (discussed later under "Support Process Areas") in that it deals with how configured components are linked, compiled, and assembled for delivery. It is also related to Validation (discussed later in this section), in that what are being validated are the final integrated components. The purpose of Product Integration is to ensure that a method is in place that provides for the orderly assembly of what can often be many product subcomponents, often at different life-cycle phases. Additionally, Product Integration exists to provide a mechanism to determine whether the assembled subcomponents function properly before they are released as an integrated whole. In general, the process of Product Integration is one of planning, confirming, assembling, andfinallydelivering.
220.127.116.11. Three specific goals
CMMI provides three goals for Product Integration:
18.104.22.168. Core Product Integration actions
The engineering team devises a coordinated method for linking all components and interfaces of a product into an integrated whole, one suitable for delivery to the customer. The team then assembles the product following this method and delivers the product to the customer.
Applies to Engineering:
Figure 6-10 illustrates the Product Integration PA.
Figure 6-10. Product Integration is often seen as the next step following Technical Solution. The practices contained in this Process Area focus on defining how the product components should be assembled, what the integration environment should be, and what the assembly procedures should address. Interface management is another aspect of Product Integration. Interfaces should be regularly managed to be kept current with the components being assembled.
The purpose of this Process Area is to ensure that selected work products produced across the project life cycle have been developed according to appropriate requirements, standards, and formats. Verification can be thought of as an extension of the Process and Product Quality Assurance Process Area (discussed later under "Support Process Areas"). But (as you'll see) while PPQA is an independent, "external" quality-compliance component, Verification is internal to the project team. Verification is typically implemented in phases across the project, usually at selected milestones and in the form of quality gates. This Process Area serves its most effective use as a means for accomplishing the smooth transition of work products from one team to another, on through product delivery. We typically think of Verification in terms of peer reviews and functional tests. Here, peer groups are organized to conduct product inspections, comment on their quality and completeness, and approve their downstream transition. And like teams are formed to put product components through tests to verify compliance with requirements.
22.214.171.124. Three specific goals
The Verification Process Area has three goals under CMMI:
126.96.36.199. Core Verification actions
The project team inspects selected work products based on preset criteria (i.e., appropriate requirements, content, format, and standards). Products that fall outside of these criteria are reworked before moving along the project life cycle.
Applies to Engineering:
Figure 6-11 illustrates the Verification PA.
Figure 6-11. Verification is often thought of as "test," but it includes more than that. It contains activities that help ensure that the product components truly reflect the requirements given to the project team. This involves establishing verification environments and procedures, performing peer reviews, and then executing verification activities as planned.
The Validation Process Area presents a method for ensuring that a developed product operates in its intended environment according to performance expectations. This Process Area is related to Verification and might be seen as the end point in the Verification line. Validation is concerned with the delivery and deployment of the product, but it should take place well before deployment. The process of validation works best when conducted using, as close as possible, the operational environment intended for the product in the field. The overall intention of validation is to confirm that the product will work in the field as the customer first envisioned.
188.8.131.52. Two specific goals
Two goals exist for Validation. The structure is very similar to that of Verification.
184.108.40.206. Core Validation actions
Selected products (or components) are exercised and evaluated in production-like environments to ensure that they meet operational and performance field expectations.
Applies to Engineering:
Figure 6-12 illustrates the Validation PA.
Figure 6-12. Validation sets into place activities to help ensure that the product built by the project team will operate properly in its intended environment. The activities defined here include defining the validation environment, establishing validation procedures and criteria, performing validation tasks as defined, and analyzing the results of the validation activities.