Subset Overview / Details
______________________________________________________________
Requirement Set: CMMI
Subset: Technical Solution
(TS)
______________________________________________________________
Notes:
·
The contents of this web page were extracted from
the following document: Capability Maturity Model® Integration
(CMMISM), Version 1.1, Continuous Representation,
CMU/SEI-2002-TR-011, March 2002 (CMMI-SE/SW/IPPD/SS). Copyright 2002 by Carnegie
Mellon University. NO WARRANTY.
·
Ignore the identifiers
in square brackets that appear at the end of paragraphs.
·
The formatting may not
be the same as in the printed CMMI document. The web page is best viewed in
Internet Explorer.
·
In the CMMI, a subset is known as a "Process
Area (PA)" and a requirement is known as a "Practice". The
specific practices are referred to as SPs and the generic practices are
referred to as GPs.
·
This web page contains the text for SPs and GPs as
it appears in Chapter 7 of the CMMI document, in the section corresponding to
the process area named in the heading of this page. This web page does not
include the detailed description of the GPs that appears in a separate chapter
of the CMMI document; the detailed
description of the GPs is available in a separate web
page. (Note: Using the hyperlink provided here will open that web page in a
separate window.)
______________________________________________________________
Category: Engineering
Purpose
The purpose of Technical Solution is to design, develop,
and implement solutions to requirements. Solutions, designs, and
implementations encompass products, product components, and product-related
life-cycle processes either singly or in combinations as appropriate. [PA160]
Introductory Notes
The Technical Solution process area is applicable at any
level of the product architecture and to every product, product component,
product-related life-cycle process, and service. The process area focuses on
the following: [PA160.N101]
· Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated 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, may be needed to select
solutions. Product-component prototypes may be used as a means of gaining
sufficient knowledge to develop a technical data package or a complete set of
requirements. [PA160.N102]
Technical Solution specific practices apply not only to
the product and product components but also to services and product-related
life-cycle processes. The product-related life-cycle processes are developed in
concert with the product or product component. Such development may include
selecting and adapting existing processes (including standard processes) for
use as well as developing new processes.
[PA160.N103]
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. [PA160.N104]
For a maintenance or sustainment organization, the
requirements in need of maintenance actions or redesign may be driven by user
needs or latent defects in the product components. New requirements may arise
from changes in the operating environment. Such requirements can be uncovered
during verification of the product(s) where actual performance can be compared
against the 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. [PA160.N105]
Refer to the Requirements Development process area for more information
about requirements allocations, establishing an operational concept, and
interface requirements definition. [PA160.R101]
Refer to the Verification process area for more information about conducting
peer reviews and verifying that the product and product components meet
requirements. [PA160.R102]
Refer to the Decision Analysis and Resolution process area for more
information about formal evaluation. [PA160.R103]
Refer to the Requirements Management process area for more information
about managing requirements. The specific practices in the Requirements
Management process area are performed interactively with those in the Technical
Solution process area. [PA160.R104]
Refer to the Organizational Innovation and Deployment process area for
more information about improving the organization's technology.
[PA160.R105]
Specific Goals
SG 1 Select
Product-Component Solutions
[PA160.IG101]
Product or product-component solutions are selected from alternative solutions.
SG 2 Develop
the Design [PA160.IG102]
Product or product-component designs are developed.
SG 3 Implement
the Product Design [PA160.IG103]
Product components, and associated support documentation, are implemented from their designs.
Generic Goals
GG 1 Achieve
Specific Goals [CL102.GL101]
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
GG 2 Institutionalize
a Managed Process [CL103.GL101]
The process is institutionalized as a managed process.
GG 3 Institutionalize
a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GG 4 Institutionalize
a Quantitatively Managed Process
[CL105.GL101]
The process is institutionalized as a quantitatively managed process.
GG 5 Institutionalize
an Optimizing Process [CL106.GL101]
The process is institutionalized as an optimizing process.
Practice-to-Goal Relationship Table
SG 1 Select Product-Component Solutions [PA160.IG101]
SP 1.1-1 Develop Alternative Solutions and Selection Criteria
SP 1.1-2 Develop Detailed Alternative Solutions and Selection Criteria
SP 1.2-2 Evolve Operational Concepts and Scenarios
SP 1.3-1 Select Product-Component Solutions
SG 2 Develop the Design
[PA160.IG102]
SP 2.1-1 Design the Product or Product Component
SP 2.2-3 Establish a Technical Data Package
SP 2.3-1 Establish Interface Descriptions
SP 2.3-3 Design Interfaces Using Criteria
SP 2.4-3 Perform Make, Buy, or Reuse Analyses
SG 3 Implement the Product Design
[PA160.IG103]
SP 3.1-1 Implement the Design
SP 3.2-1 Develop Product Support Documentation
GG 1 Achieve Specific Goals [CL102.GL101]
GP 1.1 Perform Base Practices
GG 2 Institutionalize a Managed Process [CL103.GL101]
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
GP 2.3 Provide Resources
GP 2.4 Assign Responsibility
GP 2.5 Train People
GP 2.6 Manage Configurations
GP 2.7 Identify and Involve Relevant Stakeholders
GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence
GP 2.10 Review Status with Higher Level Management
GG 3 Institutionalize a Defined Process [CL104.GL101]
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
GG 4 Institutionalize a Quantitatively Managed Process [CL105.GL101]
GP 4.1 Establish Quantitative Objectives for the Process
GP 4.2 Stabilize Subprocess Performance
GG 5 Institutionalize an Optimizing Process [CL106.GL101]
GP 5.1 Ensure Continuous Process Improvement
GP 5.2 Correct Root Causes of Problems
Specific Practices by Goal
SG 1 Select Product-Component Solutions
Product or product-component solutions are
selected from alternative solutions.
[PA160.IG101]
Alternative solutions and their relative merits are
considered in advance of selecting a solution. Key requirements, design issues,
and constraints are established for use in alternative solution analysis.
Architectural features that provide a foundation for product improvement and
evolution are considered. Use of commercial off-the-shelf (COTS) product
components are considered relative to cost, schedule, performance, and risk.
COTS alternatives may be used with or without modification. Sometimes such
items may require modifications to aspects such as interfaces or a
customization of some of the features to better achieve product requirements. [PA160.IG101.N101]
One indicator of a good design process is that the design
was chosen after comparing and evaluating it against alternative solutions.
Decisions on architecture, custom development versus off the shelf, and
product-component modularization are typical of the design choices that are
addressed.
[PA160.IG101.N102]
Sometimes the search for solutions examines alternative
instances of the same requirements with no allocations needed to lower level
product components. Such is the case at the bottom of the product architecture.
There are also cases where one or more of the solutions are fixed (e.g., a
specific solution is directed or available product components, such as COTS,
are investigated for use).
[PA160.IG101.N103]
In the general case, solutions are defined as a set. That
is, when defining the next layer of product components, the solution for each
of the product components in the set is established. The alternative solutions
are not only different ways of addressing the same requirements, but they also
reflect a different allocation of requirements among the product components
comprising the solution set. The objective is to optimize the set as a whole
and not the individual pieces. There will be significant interaction with
processes associated with the Requirements Development process area to support
the provisional allocations to product components until a solution set is
selected and final allocations established.
[PA160.IG101.N104]
Product-related life-cycle processes are among the
product-component solutions that are selected from alternative solutions.
Examples of these product-related life-cycle processes are the manufacturing
and the support processes.
[PA160.IG101.N105]
SP 1.1-1 Develop Alternative Solutions and Selection Criteria
Develop
alternative solutions and selection criteria.
[PA160.IG101.SP101]
In the staged representation,
this specific practice is only included as informative material and appears
after the Develop Detailed Alternative Solutions and Selection Criteria
specific practice.
Refer to the Allocate Product-Component Requirements specific practice in
the Requirements Development process area for more information about obtaining
provisional allocations of requirements to solution alternatives for the
product components. [PA160.IG101.SP101.R101]
Refer to the Decision Analysis and Resolution process area for more
information about establishing selection criteria and identifying alternatives.
[PA160.IG101.SP101.R102]
Refer to the Requirements Management process area for more information
about managing the provisional and established allocated requirements.
[PA160.IG101.SP101.R103]
Alternatives are based on potential product architectures
and span a design space of feasible solutions. The Design Product or Product
Component specific practice of the Develop the Design specific goal contains
more information about developing potential product architectures to
incorporate into alternative solutions for the product. [PA160.IG101.SP101.N101]
As selections are made, the design space may be
constricted and other alternatives examined until the most promising (i.e.,
optimal) solutions that meet requirements and criteria are identified. The
selection criteria identify the key factors that provide a basis for the
selection of the solution. These criteria should provide clear discrimination
and an indication of success in arriving at a balanced solution across the life
of the product. They typically include measures of cost, schedule, performance,
and risk.
[PA160.IG101.SP101.N102]
The alternative solutions evaluated frequently encompass
alternative requirement allocations to different product components. These
alternatives may also be structured to evaluate the use of COTS solutions in
the product architecture. Processes associated with the Requirements
Development process area would then be employed to provide a more complete and
robust provisional allocation of requirements to the alternative solutions. [PA160.IG101.SP101.N103]
Selection of the best solution establishes the requirements
provisionally allocated to that solution as the set of allocated requirements.
The circumstances in which it would not be useful to examine alternative
solutions are infrequent in new developments. However, developments of
precedented product components are candidates for not examining, or only
minimally examining, alternative solutions.
[PA160.IG101.SP101.N104]
Typical Work Products
1. Alternative solutions [PA160.IG101.SP101.W101]
2. Selection criteria [PA160.IG101.SP101.W102]
Subpractices
1. Establish and maintain a process or
processes for identifying solution alternatives, selection criteria, and design
issues. [PA160.IG101.SP101.SubP101]
Selection criteria are influenced
by a wide variety of factors driven by the requirements imposed on the project
as well as the product life cycle. For example, criteria related to mitigating
cost and schedule risks may influence a greater preference for COTS solutions
provided such selections do not result in unacceptable risks for the remaining
product components to be developed. When using existing items, such as COTS,
either with or without modification, criteria dealing with diminishing sources
of supply or technological obsolescence should be examined, as well as criteria
capturing the benefits of standardization, maintaining relationships with
suppliers, and so forth. The criteria used in selections should provide a
balanced approach to costs, benefits, and risks. [PA160.IG101.SP101.SubP101.N101]
2. Identify alternative groupings of
requirements that characterize sets of solution alternatives that span the
feasible design space. [PA160.IG101.SP101.SubP102]
Effective employment of COTS
alternatives can provide special challenges. Knowledgeable designers familiar
with candidate COTS alternatives may explore architectural opportunities to
exploit potential COTS payoffs.
[PA160.IG101.SP101.SubP102.N101]
3. Identify design issues for each solution
alternative in each set of alternatives.
[PA160.IG101.SP101.SubP103]
4. Characterize design issues and take appropriate
action. [PA160.IG101.SP101.SubP104]
Appropriate action could be to
characterize the issues as a risk for risk management, adjust the solution
alternative to preclude the issues, or reject the solution alternative and
replace it with a different alternative. [PA160.IG101.SP101.SubP104.N101]
5. Obtain a complete requirements allocation
for each alternative. [PA160.IG101.SP101.SubP105]
6. Document the rationale for each alternative
set of solutions. [PA160.IG101.SP101.SubP106]
SP 1.1-2 Develop Detailed Alternative Solutions and Selection Criteria
Develop
detailed alternative solutions and selection criteria. [PA160.IG101.SP102]
In the staged representation,
this specific practice takes the place of the Develop Alternative Solutions and
Selection Criteria specific practice.
Refer to the Decision Analysis and Resolution process area for more
information about establishing criteria used in making decisions.
[PA160.IG101.SP102.R101]
For Integrated Product and Process Development
The
activity of selecting alternative solutions and issues to be subject to
decision analyses and trade studies is accomplished by the involvement of
relevant stakeholders. These stakeholders represent both business and technical
functions and the concurrent development of the product and the product-related
life-cycle processes (e.g., manufacturing, support, training, verification, and
disposal). In this way, important issues surface earlier in product development
than with traditional serial development and can be addressed before they
become costly mistakes. [PA160.IG101.SP102.AMP101]
Detailed alternative solutions are an essential concept
of the Technical Solution process area. They provide more accurate and
comprehensive information about the solution than nondetailed alternatives. For
example, characterization of performance based on design content rather than on
simple estimating enables effective assessment and understanding of environment
and operating concept impacts. Alternative solutions need to be identified and
analyzed to enable the selection of a balanced solution across the life of the
product in terms of cost, schedule, and technical performance. These solutions
are based on proposed product architectures that address critical product
qualities. Specific practices associated with the Develop the Design specific
goal provide more information on developing potential product architectures
that can be incorporated into alternative solutions for the product. [PA160.IG101.SP102.N104]
Alternative solutions span the acceptable range of cost,
schedule, and performance. The product-component requirements are received and
used along with design issues, constraints, and criteria to develop the
alternative solutions. Selection criteria would typically address costs (e.g.,
time, people, money), benefits (e.g., performance, capability, effectiveness),
and risks (e.g., technical, cost, schedule). Considerations for detailed
alternative solutions and selection criteria include the following: [PA160.IG101.SP102.N102]
· Cost (development, procurement, support, product life cycle)
· Technical performance
· Complexity of the product component and product-related life-cycle processes
· Robustness to product operating and use conditions, operating modes, environments, and variations in product-related life-cycle processes
· Product expansion and growth
· Technology limitations
· Sensitivity to construction methods and materials
· Risk
· Evolution of requirements and technology
· Disposal
· Capabilities and limitations of end users and operators
The considerations listed above are a basic set;
organizations should develop screening criteria to narrow down the list of
alternatives that are consistent with their business objectives. Product
life-cycle cost, while being a desirable parameter to minimize, may be outside
the control of development organizations. A customer may not be willing to pay
for features that cost more in the short term but ultimately decrease cost over
the life of the product. In such cases, customers should at least be advised of
any potential for reducing life-cycle costs. The criteria used in selections of
final solutions should provide a balanced approach to costs, benefits, and
risks. [PA160.IG101.SP102.N103]
Typical Work Products
1. Alternative solution
screening criteria [PA160.IG101.SP102.W103]
2. Evaluations of new
technologies [PA160.IG101.SP102.W104]
3. Alternative solutions [PA160.IG101.SP102.W101]
4. Selection criteria for
final selection [PA160.IG101.SP102.W102]
Subpractices
1. Identify screening criteria to select a set
of alternative solutions for consideration.
[PA160.IG101.SP102.SubP101]
2. Identify technologies currently in use and
new product technologies for competitive advantage.
[PA160.IG101.SP102.SubP102]
Refer
to the Organizational Innovation and Deployment process area for more
information about improving the organization's technology. [PA160.IG101.SP102.SubP102.R101]
The project should identify
technologies applied to current products and processes and monitor the progress
of currently used technologies throughout the life of the project. The project
should identify, select, evaluate, and invest in new technologies to achieve
competitive advantage. Alternative solutions could include newly developed
technologies, but could also include applying mature technologies in different
applications or to maintain current methods. [PA160.IG101.SP102.SubP102.N101]
3. Generate alternative solutions. [PA160.IG101.SP102.SubP103]
4. Obtain a complete requirements allocation
for each alternative. [PA160.IG101.SP102.SubP104]
5. Develop the criteria for selecting the best
alternative solution. [PA160.IG101.SP102.SubP105]
Criteria should be included that
address design issues for the life of the product, such as provisions for more easily
inserting new technologies or the ability to better exploit commercial
products. Examples include criteria related to open design or open architecture
concepts for the alternatives being evaluated. [PA160.IG101.SP102.SubP105.N101]
6. Develop timeline scenarios for product
operation and user interaction for each alternative solution. [PA160.IG101.SP102.SubP106]
SP 1.2-2 Evolve Operational Concepts and Scenarios
Evolve
the operational concept, scenarios, and environments to describe the
conditions, operating modes, and operating states specific to each product
component. [PA160.IG101.SP103]
Refer to the Establish Operational Concepts and Scenarios specific
practice of the Requirements Development process area for information on
product-level influences and implications of product-component operations.
[PA160.IG101.SP103.R101]
For Systems Engineering
Integrate the operational concepts and scenarios produced by various individuals or groups for each level of physical product decomposition. [PA160.IG101.SP103.AMP101]
Operational concepts and scenarios are evolved to
facilitate the selection of product-component solutions that, when implemented,
will satisfy the intended use of the product. Operational concepts and
scenarios document the interaction of the product components with the
environment, users, and other product components, regardless of engineering
discipline. They should be documented for operations, product deployment,
delivery, support (including maintenance and sustainment), training, and
disposal and for all modes and states.
[PA160.IG101.SP103.N101]
The environments (operating, support, training, etc.)
also need to be evolved. The environment of any given product component will be
influenced by other product components as well as the external environment. [PA160.IG101.SP103.N102]
Typical Work Products
1. Product-component
operational concepts, scenarios, and environments for all product-related
life-cycle processes (e.g., operations, support, training, manufacturing,
deployment, fielding, delivery, and disposal)
[PA160.IG101.SP103.W101]
2. Timeline analyses of
product-component interactions [PA160.IG101.SP103.W102]
3. Use cases [PA160.IG101.SP103.W104]
Subpractices
1. Evolve the operational concepts and
scenarios to a degree of detail appropriate for the product component. [PA160.IG101.SP103.SubP101]
2. Evolve the operational environments for the
product components. [PA160.IG101.SP103.SubP102]
The environments may include
thermal, stress, and electromagnetic and other elements that need to be
documented.
[PA160.IG101.SP103.SubP102.N101]
SP 1.3-1 Select Product-Component Solutions
Select
the product-component solutions that best satisfy the criteria established. [PA160.IG101.SP104]
Refer to the Allocate Product-Component Requirements and Identify
Interface Requirements specific practices of the Requirements Development
process area for information on establishing the allocated requirements for
product components and interface requirements among product components.
[PA160.IG101.SP104.R101]
Refer to the Decision Analysis and Resolution process area for more
information about formal evaluations.
[PA160.IG101.SP104.R102]
Selecting product components that best satisfy the
criteria establishes the requirement allocations to product components. Lower
level requirements are generated from the selected alternative and used to
develop the product-component design. Interface requirements among product
components are described, primarily functionally. Physical interface
descriptions are included in the documentation for interfaces to items and
activities external to the product.
[PA160.IG101.SP104.N101]
The description of the solutions and the rationale for
selection are documented. The documentation evolves throughout development as
solutions and detailed designs are developed and those designs are implemented.
Maintaining a record of rationale is critical to downstream decision making.
Such records keep downstream stakeholders from redoing work and provide
insights to apply technology as it becomes available in applicable
circumstances.
[PA160.IG101.SP104.N102]
Typical Work Products
1. Product-component selection
decisions and rationale [PA160.IG101.SP104.W101]
2. Documented relationships
between requirements and product components
[PA160.IG101.SP104.W102]
3. Documented solutions,
evaluations, and rationale [PA160.IG101.SP104.W103]
Subpractices
1. Evaluate each alternative solution/set of
solutions against the selection criteria established in the context of the
operating concepts, operating modes, and operating states. [PA160.IG101.SP104.SubP101]
2. Based on the evaluation of alternatives,
assess the adequacy of the selection criteria and update these criteria as necessary. [PA160.IG101.SP104.SubP102]
3. Identify and resolve issues with the
alternative solutions and requirements. [PA160.IG101.SP104.SubP103]
4. Select the best set of alternative solutions
that satisfy the established selection criteria. [PA160.IG101.SP104.SubP104]
5. Establish the requirements associated with
the selected set of alternatives as the set of allocated requirements to those
product components. [PA160.IG101.SP104.SubP105]
6. Identify the product-component solutions
that will be reused or acquired. [PA160.IG101.SP104.SubP107]
Refer
to the Supplier Agreement Management process area for more information about
acquiring products and product components.
[PA160.IG101.SP104.SubP107.R101]
7. Establish and maintain the documentation of
the solutions, evaluations, and rationale.
[PA160.IG101.SP104.SubP106]
SG 2 Develop the Design
Product or product-component designs are
developed. [PA160.IG102]
Product or product-component designs must provide the
appropriate content not only for implementation, but also for other phases of
the product life cycle such as modification, reprocurement, maintenance,
sustainment, and installation. The design documentation provides a reference to
support mutual understanding of the design by relevant stakeholders and
supports future changes to the design both during development and in subsequent
phases of the product life cycle. A complete design description is documented
in a technical data package that includes a full range of features and
parameters including form, fit, function, interface, manufacturing process
characteristics, and other parameters. Established organizational or project
design standards (e.g., checklists, templates, object frameworks) form the
basis for achieving a high degree of definition and completeness in design
documentation.
[PA160.IG102.N101]
For Integrated Product and Process Development
The integrated teams develop the designs of the appropriate product-related life-cycle processes concurrently with the design of the product. These processes may be selected without modification from the organization’s set of standard processes, if appropriate. [PA160.IG102.AMP101]
SP 2.1-1 Design the Product or Product Component
Develop
a design for the product or product component.
[PA160.IG102.SP101]
Product design consists of two broad phases that may
overlap in execution: preliminary and detailed design. Preliminary design
establishes product capabilities and the product architecture, including
product partitions, product-component identifications, system states and modes,
major intercomponent interfaces, and external product interfaces. Detailed
design fully defines the structure and capabilities of the product components. [PA160.IG102.SP101.N101]
Refer to the Requirements Development process area for more information
about developing architecture requirements.
[PA160.IG102.SP101.N101.R101]
Architecture definition is driven from a set of
architectural requirements developed during the requirements development
processes. These requirements express the qualities and performance points that
are critical to the success of the product. The architecture defines structural
elements and coordination mechanisms that either directly satisfy requirements
or support the achievement of the requirements as the details of the product
design are established. Architectures may include standards and design rules
governing development of product components and their interfaces as well as
guidance to aid product developers. Specific practices in the Select
Product-Component Solutions specific goal contain more information about using
product architectures as a basis for alternative solutions. [PA160.IG102.SP101.N102]
Architects postulate and develop a model of the product,
making judgments about allocation of requirements to product components
including hardware and software. Multiple architectures, supporting alternative
solutions, may be developed and analyzed to determine the advantages and
disadvantages in the context of the architectural requirements. [PA160.IG102.SP101.N103]
Operational concepts and scenarios are used to generate
use cases and quality scenarios that are used to refine the architecture. They
are also used as a means to evaluate the suitability of the architecture for
its intended purpose during architecture evaluations, which are conducted
periodically throughout product design. The Evolve Operational Concepts and
Scenarios specific practice gives more information about elaborating
operational concepts and scenarios used in architecture evaluation. [PA160.IG102.SP101.N104]
Refer to the Establish Operational Concepts and Scenarios specific
practice of the Requirements Development process area for information about
developing operational concepts and scenarios used in architecture evaluation.
[PA160.IG102.SP101.N104.R101]
For Software Engineering
In addition to tasks identified above, software architecture definition may include: [PA160.IG102.SP101.N104.AMP101]
· Establishing the structural relations of partitions and rules regarding interfaces between elements within partitions, and between partitions
· Identifying major internal interfaces and all external interfaces of software
· Identifying software product components
· Defining software coordination mechanisms
· Establishing infrastructure capabilities and services
· Developing product-component templates or classes and frameworks
· Establishing design rules and authority for making decisions
· Defining a process/thread model
· Defining physical deployment of software to hardware
· Identifying major reuse approaches and sources
During detailed design, the product architecture details
are finalized, product components are completely defined, and interfaces are
fully characterized. Product-component designs may be optimized for certain
qualities or performance characteristics. Designers may evaluate the use of
legacy or COTS products for the product components. As the design matures, the
requirements assigned to lower level product components are tracked to ensure
those requirements are satisfied.
[PA160.IG102.SP101.N105]
Refer to the Requirements Management process area for more information
about tracking requirements for product components.
[PA160.IG102.SP101.N105.R101]
For Software Engineering
Detailed design is focused on software product-component development. The internal structure of product components is defined, data schema are generated, algorithms are developed, and heuristics are established to provide product-component capabilities that satisfy allocated requirements. [PA160.IG102.SP101.N105.AMP101]
Typical Work Products
1. Product architecture [PA160.IG102.SP101.W101]
2. Product-component designs [PA160.IG102.SP101.W102]
Subpractices
1. Establish and maintain criteria against
which the design can be evaluated. [PA160.IG102.SP101.SubP101]
Examples
of attributes, in addition to expected performance, for which design criteria
can be established, include the following:
[PA160.IG102.SP101.SubP101.N101]
· Modular
· Clear
· Simple
· Maintainable
· Verifiable
· Portable
· Reliable
· Accurate
· Secure
· Scalable
· Usable
2. Identify, develop, or acquire the design
methods appropriate for the product. [PA160.IG102.SP101.SubP102]
Effective design methods can
embody a wide range of activities, tools, and descriptive techniques. Whether a
given method is effective or not depends on the situation. Two companies may
have very effective design methods for products in which they specialize, but
these methods may not be effective in cooperative ventures. Highly
sophisticated methods are not necessarily effective in the hands of designers
that have not been trained in the use of the methods. [PA160.IG102.SP101.SubP102.N101]
Whether or not a method is
effective also depends on how much assistance it provides the designer, and the
cost effectiveness of that assistance. For example, a multiyear prototyping
effort may not be appropriate for a simple product component but might be the
right thing to do for an unprecedented, expensive, and complex product
development. Rapid prototyping techniques, however, may be highly effective for
many product components. Methods that use tools to ensure that a design will
encompass all the necessary attributes needed to implement the
product-component design can be very effective. For example, a design tool that
“knows” the capabilities of the manufacturing processes can allow the
variability of the manufacturing process to be accounted for in the design
tolerances.
[PA160.IG102.SP101.SubP102.N102]
Examples
of techniques and methods that facilitate effective design include the
following: [PA160.IG102.SP101.SubP102.N103]
· Prototypes
· Structural models
· Object-oriented design
· Essential systems analysis
· Entity relationship models
· Design reuse
· Design patterns
3. Ensure that the design adheres to applicable
design standards and criteria. [PA160.IG102.SP101.SubP103]
Examples
of design standards include the following (some or all of these standards may
be design criteria, particularly in circumstances where the standards have not
been established): [PA160.IG102.SP101.SubP103.N101]
· Operator interface standards
· Safety standards
· Production constraints
· Design tolerances
· Parts standards (e.g., production scrap and waste)
4. Ensure that the design adheres to allocated
requirements. [PA160.IG102.SP101.SubP104]
Identified COTS product
components must be taken into account. For example, putting existing product
components into the product architecture might modify the requirements and the
requirements allocation.
[PA160.IG102.SP101.SubP104.N101]
5. Document the design.
[PA160.IG102.SP101.SubP105]
SP 2.2-3 Establish a Technical Data Package
Establish
and maintain a technical data package.
[PA160.IG102.SP103]
A technical data package provides the developer with a
comprehensive description of the product or product component as it is
developed. Such a package also provides procurement flexibility in a variety of
circumstances such as performance-based contracting or build to print. [PA160.IG102.SP103.N102]
The design is recorded in a technical data package that
is created during preliminary design to document the architecture definition.
This technical data package is maintained throughout the life of the product to
record essential details of the product design. The technical data package
provides the description of a product or product component (including
product-related life-cycle processes if not handled as separate product
components) that supports an acquisition strategy, or the implementation,
production, engineering, and logistics support phases of the product life
cycle. The description includes the definition of the required design
configuration and procedures to ensure adequacy of product or product-component
performance. It includes all applicable technical data such as drawings,
associated lists, specifications, design descriptions, design databases,
standards, performance requirements, quality assurance provisions, and
packaging details. The technical data package includes a description of the
selected alternative solution that was chosen for implementation. [PA160.IG102.SP103.N106]
A technical data package should include the following if
such information is appropriate for the type of product and product component
(for example, material and manufacturing requirements may not be useful for
product components associated with software services or processes): [PA160.IG102.SP103.N103]
· Product architecture description
· Allocated requirements
· Product-component descriptions
· Product-related life-cycle process descriptions, if not described as separate product components
· Key product characteristics
· Required physical characteristics and constraints
· Interface requirements
· Materials requirements (bills of material and material characteristics)
· Fabrication and manufacturing requirements (for both the original equipment manufacturer and field support)
· The verification criteria used to ensure that requirements have been achieved
· Conditions of use (environments) and operating/usage scenarios, modes and states for operations, support, training, manufacturing, disposal, and verifications throughout the life of the product
· Rationale for decisions and characteristics (requirements, requirement allocations, and design choices)
Because design descriptions can involve a very large
amount of data and be crucial to successful product-component development, it
is advisable to establish criteria for organizing the data and for selecting
the data content. It is particularly useful to use the product architecture as
a means of organizing this data and abstracting views that are clear and
relevant to an issue or feature of interest. These views include the following: [PA160.IG102.SP103.N104]
· Customers
· Requirements
· The environment
· Functional
· Logical
· Security
· Data
· States/modes
· Construction
· Management
These views are documented in the technical data package. [PA160.IG102.SP103.N105]
Typical Work Products
1. Technical data package [PA160.IG102.SP103.W101]
Subpractices
1. Determine the number of levels of design and
the appropriate level of documentation for each design level. [PA160.IG102.SP103.SubP101]
Determining the number of levels
of product components (e.g., subsystem, hardware configuration item, circuit
board, computer software configuration item [CSCI], computer software product
component, computer software unit) that require documentation and requirements
traceability is important to manage documentation costs and to support
integration and verification plans. [PA160.IG102.SP103.SubP101.N101]
2. Base detailed design descriptions on the
allocated product-component requirements, architecture, and higher level
designs. [PA160.IG102.SP103.SubP102]
3. Document the design in the technical data
package. [PA160.IG102.SP103.SubP103]
4. Document the rationale for key (i.e.,
significant effect on cost, schedule, or technical performance) decisions made
or defined. [PA160.IG102.SP103.SubP104]
5. Revise the technical data package as
necessary. [PA160.IG102.SP103.SubP105]
SP 2.3-1 Establish Interface Descriptions
Establish
and maintain the solution for product-component interfaces. [PA160.IG102.SP104]
In the staged representation,
this specific practice is only included as informative material and appears
after the Design Interfaces Using Criteria specific practice.
The product-component interface description covers
interfaces between the following:
[PA160.IG102.SP104.N101]
· Product components and product components
· Lower level product components and higher level product components
· Product components and product-related life-cycle processes
· Product components and external items
Typical Work Products
1. Interface design [PA160.IG102.SP104.W101]
2. Interface design documents [PA160.IG102.SP104.W102]
Subpractices
1. Identify and document interfaces associated
with other product components. [PA160.IG102.SP104.SubP101]
2. Identify interfaces associated with external
items. [PA160.IG102.SP104.SubP102]
3. Identify interfaces between product
components and the product-related life-cycle processes.
[PA160.IG102.SP104.SubP103]
For example, such interfaces
could include those between a product component to be fabricated and the jigs
and fixtures used to enable that fabrication during the manufacturing process. [PA160.IG102.SP104.SubP103.N101]
4. Ensure that the solution includes the
interface requirements developed in the requirements development processes. [PA160.IG102.SP104.SubP104]
Refer
to the Identify Interface Requirements specific practice in the Requirements
Development process area for more information about identifying product and
product-component interface requirements.
[PA160.IG102.SP104.SubP104.R101]
SP 2.3-3 Design Interfaces Using Criteria
Design
comprehensive product-component interfaces in terms of established and
maintained criteria.
[PA160.IG102.SP105]
In the staged representation,
this specific practice takes the place of the Establish Interface Descriptions
specific practice.
Interface designs include the following: [PA160.IG102.SP105.N101]
· Origination
· Destination
· Stimulus and data characteristics for software
· Electrical, mechanical, and functional characteristics for hardware
The criteria for interfaces frequently reflect a
comprehensive list of critical parameters that must be defined, or at least
investigated, to ascertain their applicability. These parameters are often
peculiar to a given type of product (e.g., software, mechanical, electrical)
and are often associated with safety, security, durability, and
mission-critical characteristics.
[PA160.IG102.SP105.N102]
Typical Work Products
1. Interface design
specifications [PA160.IG102.SP105.W101]
2. Interface control documents [PA160.IG102.SP105.W102]
3. Interface specification
criteria [PA160.IG102.SP105.W103]
4. Rationale for selected
interface design [PA160.IG102.SP105.W104]
Subpractices
1. Define interface criteria. [PA160.IG102.SP105.SubP101]
These criteria can be a part of
the organizational process assets. [PA160.IG102.SP105.SubP101.N101]
Refer
to the Organizational Process Definition process area for more information
about establishing and maintaining organizational process assets. [PA160.IG102.SP105.SubP101.N101.R101]
2. Apply the criteria to the interface design
alternatives. [PA160.IG102.SP105.SubP102]
Refer
to the Decision Analysis and Resolution process area for more information about
identifying criteria and selecting alternatives based on those criteria. [PA160.IG102.SP105.SubP102.R101]
3. Document the selected interface designs and
the rationale for the selection. [PA160.IG102.SP105.SubP103]
SP 2.4-3 Perform Make, Buy, or Reuse Analyses
Evaluate
whether the product components should be developed, purchased, or reused based
on established criteria.
[PA160.IG102.SP106]
The determination of what products or product components
will be acquired is frequently referred to as a “make-or-buy analysis.” It is
based on an analysis of the needs of the project. This make-or-buy analysis
begins early in the project during the first iteration of design, continues
during the design process, and is completed with the decision to develop,
acquire, or reuse the product.
[PA160.IG102.SP106.N103]
Refer to the Requirements Development process area for more information
about determining the product and product-component requirements.
[PA160.IG102.SP106.N103.R101]
Refer to the Requirements Management process area for more information
about managing requirements. [PA160.IG102.SP106.N103.R102]
Factors affecting the make-or-buy decision include the
following:
[PA160.IG102.SP106.N104]
· Functions the products or services will provide and how these functions will fit into the project
· Available project resources and skills
· Costs of acquiring versus developing internally
· Critical delivery and integration dates
· Strategic business alliances, including high-level business requirements
· Market research of available products, including COTS products
· Functionality and quality of available products
· Skills and capabilities of potential suppliers
· Impact on core competencies
· Licenses, warranties, responsibilities, and limitations associated with products being acquired
· Product availability
· Proprietary issues
· Risk reduction
Many of these factors are addressed by the project. [PA160.IG102.SP106.N105]
The make-or-buy decision can be conducted using a formal
evaluation approach.
[PA160.IG102.SP106.N106]
Refer to the Decision Analysis and Resolution process area for more
information about defining criteria and alternatives and performing formal
evaluations. [PA160.IG102.SP106.N106.R101]
As technology evolves, so does the rationale for choosing
to develop or purchase a product component. While complex development efforts
may favor purchasing an off-the-shelf product component, advances in
productivity and tools may provide an opposing rationale. Off-the-shelf
products may have incomplete or inaccurate documentation and may or may not be
supported in the future.
[PA160.IG102.SP106.N101]
Once the decision is made to purchase an off-the-shelf
product component, the requirements are used to establish a supplier agreement.
There are times when “off the shelf” refers to an existing item that may not be
readily available in the marketplace. For example, some types of aircraft and
engines are not truly “off the shelf” but can be readily procured. In some
cases the use of such non-developed items is in situations where the specifics
of the performance and other product characteristics expected need to be within
the limits specified. In these cases, the requirements and acceptance criteria
may need to be included in the supplier agreement and managed. In other cases,
the off-the-shelf product is literally off the shelf (word processing software,
for example) and there is no agreement with the supplier that needs to be
managed.
[PA160.IG102.SP106.N102]
Refer to the Supplier Agreement Management process area for more information
about how to address the acquisition of the product components that will be
purchased. [PA160.IG102.SP106.N102.R101]
Typical Work Products
1. Criteria for design and
product-component reuse [PA160.IG102.SP106.W101]
2. Make-or-buy analyses [PA160.IG102.SP106.W102]
3. Guidelines for choosing
COTS product components [PA160.IG102.SP106.W103]
Subpractices
1. Develop criteria for the reuse of
product-component designs. [PA160.IG102.SP106.SubP102]
2. Analyze designs to determine if product
components should be developed, reused, or purchased.
[PA160.IG102.SP106.SubP103]
3. When purchased or non-developmental (COTS,
government off the shelf, and reuse) items are selected, plan for their
maintenance. [PA160.IG102.SP106.SubP101]
For Software Engineering
Consider
how the compatibility of future releases of an operating system and a database
manager will be handled. [PA160.IG102.SP106.SubP101.AMP101]
SG 3 Implement the Product Design
Product components, and associated support
documentation, are implemented from their designs.
[PA160.IG103]
Product components are implemented from the designs
established by the specific practices in the Develop the Design specific goal.
The implementation usually includes unit testing of the product components
before sending them to product integration and development of end-user
documentation.
[PA160.IG103.N101]
Implement
the designs of the product components.
[PA160.IG103.SP101]
For Software Engineering
Software code is a typical software product component. [PA160.IG103.SP101.AMP101]
Once the design has been completed, it is implemented as
a product component. The characteristics of that implementation depend on the
type of product component.
[PA160.IG103.SP101.N101]
Design implementation at the top level of the product
hierarchy involves the specification of each of the product components at the
next level of the product hierarchy. This activity includes the allocation,
refinement, and verification of each product component. It also involves the
coordination between the various product-component development efforts. [PA160.IG103.SP101.N103]
Refer to the Requirements Development process area for more information
about the allocation and refinement of requirements.
[PA160.IG103.SP101.N103.R101]
Refer to the Product Integration process area for more information about
the management of interfaces and the integration of products and product
components. [PA160.IG103.SP101.N103.R102]
Example
characteristics of this implementation are as follows: [PA160.IG103.SP101.N102]
· Software is coded.
· Data is documented.
· Services are documented.
· Electrical and mechanical parts are fabricated.
· Product-unique manufacturing processes are put into operation.
· Processes are documented.
· Facilities are constructed.
· Materials are produced (e.g., a product-unique material could be a petroleum, oil, or lubricant, or a new alloy).
Typical Work Products
1. Implemented design [PA160.IG103.SP101.W101]
Subpractices
1. Use effective methods to implement the
product components. [PA160.IG103.SP101.SubP101]
For Software Engineering
Examples of software coding methods include the following: [PA160.IG103.SP101.SubP101.AMP101]
· Structured programming
· Object-oriented programming
· Automatic code generation
· Software code reuse
· Use of applicable design patterns
For Systems Engineering
Examples of appropriate fabrication methods include the following: [PA160.IG103.SP101.SubP101.AMP102]
· Casting
· Molding
· Forming
· Joining
· Machining
· Tooling
· Welding
· Extruding
2. Adhere to applicable standards and criteria. [PA160.IG103.SP101.SubP102]
For Software Engineering
Examples of software coding standards include the following: [PA160.IG103.SP101.SubP102.AMP101]
· Language standards
· Naming conventions for variables
· Acceptable language structures
· Structure and hierarchy of software product components
· Format of code and comments
For Software Engineering
Examples of software coding criteria include the following: [PA160.IG103.SP101.SubP102.AMP102]
· Modularity
· Clarity
· Simplicity
· Structured (e.g., no GOTOs, one entrance, and one exit)
· Maintainability
For Systems Engineering
Examples of standards include the following: [PA160.IG103.SP101.SubP102.AMP103]
· Standard Parts Lists
· Standard drawing requirements
· International Organization for Standardization (ISO) T3303 standards for manufactured parts
For Systems Engineering
Examples of criteria include the following: [PA160.IG103.SP101.SubP102.AMP104]
· Maintainability
· Reliability
· Safety
3. Conduct peer reviews of the selected product
components. [PA160.IG103.SP101.SubP103]
Refer
to the Verification process area for more information about conducting peer
reviews. [PA160.IG103.SP101.SubP103.R101]
4. Perform unit testing of the product
component as appropriate. [PA160.IG103.SP101.SubP104]
Note that unit testing is not
limited to software. Unit testing involves the testing of individual hardware
or software units or groups of related items prior to integration of those
items.
[PA160.IG103.SP101.SubP104.N101]
Refer
to the Verification process area for more information about verification
methods and procedures and about verifying work products against their
specified requirements. [PA160.IG103.SP101.SubP104.N101.R101]
For Software Engineering
Examples of unit testing methods include the following: [PA160.IG103.SP101.SubP104.N101.AMP101]
· Statement coverage testing
· Branch coverage testing
· Predicate coverage testing
· Path coverage testing
· Boundary value testing
· Special value testing
5. Revise the product component as necessary. [PA160.IG103.SP101.SubP105]
An
example of when the product component may need to be revised is when problems
surface during implementation that could not be foreseen during design. [PA160.IG103.SP101.SubP105.N101]
SP 3.2-1 Develop Product Support Documentation
Develop
and maintain the end-use documentation.
[PA160.IG103.SP102]
This specific practice develops and maintains the
documentation that will be used to install, operate, and maintain the product. [PA160.IG103.SP102.N101]
Typical Work Products
1. End-user training materials [PA160.IG103.SP102.W101]
2. User's manual [PA160.IG103.SP102.W102]
3. Operator's manual [PA160.IG103.SP102.W103]
4. Maintenance manual [PA160.IG103.SP102.W104]
5. Online help [PA160.IG103.SP102.W105]
Subpractices
1. Review the requirements, design, product,
and test results to ensure that issues affecting the installation, operation,
and maintenance documentation are identified and resolved. [PA160.IG103.SP102.SubP101]
2. Use effective methods to develop the
installation, operation, and maintenance documentation.
[PA160.IG103.SP102.SubP102]
3. Adhere to the applicable documentation
standards. [PA160.IG103.SP102.SubP103]
Examples
of documentation standards include the following:
[PA160.IG103.SP102.SubP103.N101]
· Compatibility with designated word processors
· Acceptable fonts
· Numbering of pages, sections, and paragraphs
· Consistency with a designated style manual
· Use of abbreviations
· Security classification markings
· Internationalization requirements
4. Develop preliminary versions of the
installation, operation, and maintenance documentation in early phases of the
project life cycle for review by the relevant stakeholders. [PA160.IG103.SP102.SubP104]
5. Conduct peer reviews of the installation,
operation, and maintenance documentation.
[PA160.IG103.SP102.SubP105]
Refer
to the Verification process area for more information about conducting peer
reviews. [PA160.IG103.SP102.SubP105.R101]
6. Revise the installation, operation, and
maintenance documentation as necessary. [PA160.IG103.SP102.SubP106]
Examples
of when documentation may need to be revised include when the following events
occur: [PA160.IG103.SP102.SubP106.N101]
· Requirements change
· Design changes are made
· Product changes are made
· Documentation errors are identified
· Workaround fixes are identified
Generic Practices by Goal
(Note: The detailed description of the GPs is available in a separate web page. Using the hyperlink provided here will open that web page in a separate window. However, the GP elaborations pertinent to the process area of this web page are available below.)
GG 1 Achieve Specific Goals
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
Perform
the base practices of the technical solution process to develop work products
and provide services to achieve the specific goals of the process area. [GP102]
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
GP 2.1 Establish an Organizational Policy
Establish
and maintain an organizational policy for planning and performing the technical
solution process. [GP103]
Elaboration:
This policy establishes organizational expectations for
addressing the iterative cycle in which product-component solutions are
selected, product and product-component designs are developed, and the
product-component designs are implemented.
[PA160.EL101]
Establish
and maintain the plan for performing the technical solution process. [GP104]
Elaboration:
Typically, this plan for performing the technical
solution process is a part of the project plan as described in the Project
Planning process area. [PA160.EL102]
Provide
adequate resources for performing the technical solution process, developing
the work products, and providing the services of the process. [GP105]
Elaboration:
Special facilities may be required for developing,
designing, and implementing solutions to requirements. When necessary, the
facilities required for the activities in the Technical Solution process area
are developed or purchased. [PA160.EL111]
Examples of
other resources provided include the following tools: [PA160.EL104]
· Design specification tools
· Simulators and modeling tools
· Prototyping tools
· Scenario definition and management tools
· Requirements tracking tools
· Interactive documentation tools
Assign
responsibility and authority for performing the process, developing the work
products, and providing the services of the technical solution process. [GP106]
Train
the people performing or supporting the technical solution process as needed. [GP107]
Elaboration:
Examples of
training topics include the following: [PA160.EL105]
· Application domain of the product and product components
· Design methods
· Interface design
· Unit testing techniques
· Standards (e.g., product, safety, human factors, environmental)
Place
designated work products of the technical solution process under appropriate
levels of configuration management. [GP109]
Elaboration:
Examples of work
products placed under configuration management include the following: [PA160.EL106]
· Product, product component, process, service, and interface designs
· Technical data packages
· Interface design documents
· Criteria for design and product-component reuse
· Implemented designs (e.g., software code, fabricated product components)
· User, installation, operation, and maintenance documentation
GP 2.7 Identify and Involve Relevant Stakeholders
Identify
and involve the relevant stakeholders of the technical solution process as
planned. [GP124]
Elaboration:
Select relevant stakeholders from customers, end users,
developers, producers, testers, suppliers, marketers, maintainers, disposal
personnel, and others who may be affected by, or may affect, the product as well
as the process. [PA160.EL113]
Examples of
activities for stakeholder involvement include the following: [PA160.EL114]
· Developing alternative solutions and selection criteria
· Evolving operational concept and scenarios
· Obtaining approval on external interface specifications and design descriptions
· Developing the technical data package
· Assessing the make, buy, or reuse alternatives for product components
· Implementing the design
GP 2.8 Monitor and Control the Process
Monitor
and control the technical solution process against the plan for performing the
process and take appropriate corrective action.
[GP110]
Elaboration:
Examples of
measures used in monitoring and controlling include the following: [PA160.EL108]
· Cost, schedule, and effort expended for rework
· Percentage of requirements addressed in the product or product-component design
· Size and complexity of the product, product components, interfaces, and documentation
· Defect density of technical solutions work products
GP 2.9 Objectively Evaluate Adherence
Objectively
evaluate adherence of the technical solution process against its process
description, standards, and procedures, and address noncompliance. [GP113]
Elaboration:
Examples of
activities reviewed include the following: [PA160.EL110]
· Selecting product-component solutions
· Developing product and product-component designs
· Implementing product-component designs
Examples of
work products reviewed include the following: [PA160.EL112]
· Technical data packages
· Product, product-component, and interface designs
· Implemented designs (e.g., software code, fabricated product components)
· User, installation, operation, and maintenance documentation
GP 2.10 Review Status with Higher Level Management
Review
the activities, status, and results of the technical solution process with
higher level management and resolve issues.
[GP112]
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish
and maintain the description of a defined technical solution process. [GP114]
GP 3.2 Collect Improvement Information
Collect
work products, measures, measurement results, and improvement information
derived from planning and performing the technical solution process to support
the future use and improvement of the organization’s processes and process
assets. [GP117]
GG 4 Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
GP 4.1 Establish Quantitative Objectives for the Process
Establish
and maintain quantitative objectives for the technical solution process that
address quality and process performance based on customer needs and business
objectives. [GP118]
GP 4.2 Stabilize Subprocess Performance
Stabilize
the performance of one or more subprocesses to determine the ability of the
technical solution process to achieve the established quantitative quality and
process-performance objectives. [GP119]
GG 5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
GP 5.1 Ensure Continuous Process Improvement
Ensure
continuous improvement of the technical solution process in fulfilling the
relevant business objectives of the organization.
[GP125]
GP 5.2 Correct Root Causes of Problems
Identify
and correct the root causes of defects and other problems in the technical
solution process. [GP121]