An Engineering Process Area at Maturity Level 3
The purpose of Technical Solution (TS) is to select, design, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related
lifecycle processes either singly or in combination as appropriate.
The Technical Solution process area is applicable at any level of the product architecture and to every product, product component, and product related lifecycle process. Throughout the process areas, where
the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.
This process area focuses on the following:
· Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated functional and quality attribute
requirements
· Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)
· Implementing the designs as a product or product component
Typically, these activities interactively support each other. Some level of design, at times fairly detailed, can be needed to select solutions. Prototypes or pilots can be used as a means of gaining sufficient knowledge to develop
a technical data package or a complete set of requirements. Quality attribute models, simulations, prototypes or pilots can be used to provide additional information about the properties of the potential design solutions to aid in the selection of
solutions. Simulations can be particularly useful for projects developing systems-of-systems.
Technical Solution specific practices apply not only to the product and product components but also to product related lifecycle processes. The product related lifecycle processes are developed in concert
with the product or product component. Such development can include selecting and adapting existing processes (including standard processes) for use as well as developing new processes.
Processes associated with the Technical Solution process area receive the product and product component requirements from the requirements management processes. The requirements management processes place the
requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements.
For a maintenance or sustainment project, the requirements in need of maintenance actions or redesign can be driven by user needs, technology maturation and obsolescence, or latent defects in the product components. New requirements
can arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where its actual performance can be compared against its specified performance and unacceptable degradation can be
identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts.
For product lines, these practices apply to both core asset development (i.e., building for reuse) and product development (i.e., building with reuse). Core asset development additionally requires product line variation management
(the selection and implementation of product line variation mechanisms) and product line production planning (the development of processes and other work products that define how products will be built to make best use of these core
assets).
In Agile environments, the focus is on early solution exploration. By making the selection and tradeoff decisions more explicit, the Technical Solution process area helps improve the quality of those
decisions, both individually and over time. Solutions can be defined in terms of functions, feature sets, releases, or any other components that facilitate product development. When someone other than the team will be working on the product in
the future, release information, maintenance logs, and other data are typically included with the installed product. To support future product updates, rationale (for trade-offs, interfaces, and purchased parts) is captured so that why the
product exists can be better understood. If there is low risk in the selected solution, the need to formally capture decisions is significantly reduced. (See “Interpreting CMMI When Using Agile Approaches” in Part I.)
Refer to the Requirements Development process area for more information about allocating product component requirements, establishing operational concepts and scenarios, and identifying interface
requirements.
Refer to the Verification process area for more information about performing peer reviews and verifying selected work products.
Refer to the Decision Analysis and Resolution process area for more information about analyzing possible decisions using a formal evaluation process that evaluates identified alternatives against established
criteria.
Refer to the Organizational Performance Management process area for more information about selecting improvements and deploying improvements.
Refer to the Requirements Management process area for more information about managing requirements of the project’s products and product components and ensuring alignment between those requirements and the
project’s plans and work products.
Specific Goal and Practice Summary
SG 1 Select Product Component Solutions
SP 1.1 Develop Alternative Solutions and Selection Criteria
SP 1.2 Select Product Component Solutions
SG 2 Develop the Design
SP 2.1 Design the Product or Product Component
SP 2.2 Establish a Technical Data Package
SP 2.3 Design Interfaces Using Criteria
SP 2.4 Perform Make, Buy, or Reuse Analyses
SG 3 Implement the Product Design
SP 3.1 Implement the Design
SP 3.2 Develop Product Support Documentation
321/670 - 11 sub articles
CMMI for Development 1.3
5.