The following sections detail the Process Areas specific to engineering.
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 requirements—incomplete, inconsistent, ill-expressed—have 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 requirements—at least a baseline of sound requirements—should 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.
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:
The engineering team should have the opportunity to review the requirements prior to adopting them. In other words, the team should get the chance to understand the requirements before committing to their implementation.
The project team, including relevant stakeholders, should formally approve the agreed-upon requirements as a group, establishing a common base of understanding.
Once approved, the requirements should be tracked and monitored to maintain their consistency with project plans and work products across the life of the project.
Traceability should be established in order to verify that the proper requirements have been incorporated into the proper functioning components and work products of the system.
If inconsistencies are discovered between the requirements and their work products, corrective action should be taken to realign the two.
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:
Systems Engineering
Software Engineering
Integrated Product and Process Development
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.
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.
CMMI identifies three goals within the Requirements Development Process Area:
Develop customer requirements. Customer requirements are those requirements that define the customers' (and relevant stakeholders') expectations of the system. These requirements usually deal with fulfilling specific business and performance needs. The job of your analysts—and usually this is an iterative job—is to elicit these needs and then document the customer requirements based on them.
Develop product requirements. Product requirements are usually a finer, more detailed set of requirements that work to realize the customer requirements through more technical descriptions. This step includes defining the product makeup and its constituent components and then allocating requirements to these components and their linking interfaces.
Analyze and validate the requirements. This step calls for your analysts to organize the documented requirements into operational concepts and scenarios, extract and map the resulting functionality, prioritize the functionality, and then validate that this functionality meets the business and performance expectations of the customer.
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:
Systems Engineering
Software Engineering
Integrated Product and Process Development
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.
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.
This Process Area comes with three specific goals:
Select the right product-component solution (or solutions). This first goal provides guidelines for investigating the best architectural path to apply to the project. This involves developing alternate solutions against criteria of the performance and technical capabilities of the organization, and then examining the requirements to determine which available solution fits best. Many IT organizations are tempted to simply apply a solution that fits their current strengths, such as "We're a .NET shop" or "We do Java better than anyone" or "MQ Series can handle anything." The practice specified here encourages a more considered approach. It gives you and your development team a mechanism to formally hunt for the best technical solution for the project.
Develop the designs for the solution. This goal sets guidelines for creating the overall design (and any necessary subcomponent designs) based on the architectural solution established through Goal 1. This includes establishing the technical tools and resources needed, defining the product components in detail, and defining and detailing any interfaces that will be needed to link the components together.
Implement the designs across the project. This third goal carries out the defined activity in Goal 2. You create the design according to the specifications you defined for it and implement it in an appropriate way (i.e., coding the solution). In addition, the team develops the supporting documentation (here called a technical data package) required to support the implementation of the design.
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:
Systems Engineering
Software Engineering
Integrated Product and Process Development
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.
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, and—finally—delivering.
CMMI provides three goals for Product Integration:
Prepare for Product Integration. This is a planning and documentation process, one that deals with how you'll plan and define the process that maps out how the product components fit together. Here the engineering staff defines the product's components, the sequence in which they should be integrated, the configuration of the integration environment (what's needed to fit the pieces together), and the criteria to use to determine if the assembly (the integration) has been successful.
Ensure interface compatibility. This goal is designed to account for the various interfaces that link project components into an integrated whole. This part of the integration process should include a definition of the interfaces and how they fit together. This is important because interfaces have a tendency to be overlooked from time to time, the focus being on the major product parts. But interfaces—because they too can change and evolve over time as the product develops—need to be given the same attention and focus on integration.
Assemble the defined components and deliver the product. This step includes confirming that the components are ready to be integrated—that they have reached that final phase of development—then assembling the components using the criteria and procedures you have developed, verifying that the resulting product is operational, and then delivering the assembled product with relevant supporting material to the customer.
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:
Systems Engineering
Software Engineering
Integrated Product and Process Development
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.
The Verification Process Area has three goals under CMMI:
Prepare for Verification. This is the planning phase for this Process Area. It usually occurs (and probably should occur) prior to project execution. Here you define—for the full length of the project—what work products will be subject to the verification process. Then you define what inspection criteria you'll use to verify these key work products and product components. For example, you might define the format, structure, and contents of what you'd expect to see in an acceptable design document. This will then serve as the basis for evaluating that document later in the project.
Perform peer reviews. This is an oversight facet of the verification process. Peer reviews are an exercise in which members of the project teams inspect and evaluate each other's work to ensure that it is ready to move on in the production process. For this goal, material is organized for each peer review, peer teams are identified, inspections are conducted, and resulting recommendations are analyzed for any further actions deemed appropriate.
Verify the selected work products. This is the closing step of Verification. Here, selected follow-up recommendations that arose out of the peer review may be acted on. Additionally, major work products and product components are subjected to the robust verification evaluations planned for in Goal 1. (The classic form of this is system and regression testing.) The result should be products that pass verification criteria and are ready to move on into further project activity, or perhaps on to Product Integration 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:
Systems Engineering
Software Engineering
Integrated Product and Process Development
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.
Two goals exist for Validation. The structure is very similar to that of Verification.
Prepare for Validation. This is the planning phase for this Process Area. Here the team selects the products that will be put through validation exercises. Then the team identifies the proper configuration that will be needed to replicate the field environment and, based on that, defines what tests and exercises will be required to confirm that the product operates in the intended environment in the intended way.
Validate the product and its product components. Here the validation plan is executed, and the results are analyzed. Based on this analysis, the product may be deemed suitable for production, or it (or some of its components) may be returned to the engineering process for refinement.
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:
Systems Engineering
Software Engineering
Integrated Product and Process Development
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.
[*] The term requirements can refer to any form of scope definition. Here we most often think of the functional requirements that stipulate how a system should operate. But before that, there had to be some form of requirements to generate those requirements—perhaps module descriptions. And before that, there needed to be requirements for what modules an application of a certain kind should possess—perhaps a business vision. The point is, a reliable starting mark—something that describes what the end should look like—is always needed to reach that end.