The purpose of Technical Solution (TS) is to design, develop, 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. It is an Engineering process area at Maturity Level 3.
The 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 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.
Technical Solution specific practices apply not only to the product and product components but also to product-related lifecycle processes. Processes associated with the Technical Solution process area receive the product and product component requirements from the requirements management processes.
Specific Practices by Goal
SG 1 Select Product-Component Solutions
Product or product component solutions are selected from alternative solutions. 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.
- SP 1.1 Develop Alternative Solutions and Selection Criteria.
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 lifecycle processes (e.g., manufacturing, support, training, verification, and disposal).
- SP 1.2 Select Product Component Solutions.
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.
SG 2 Develop the Design
Product or product component designs must provide the appropriate content not only for implementation, but also for other phases of the product lifecycle such as modification, procurement, 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 lifecycle.
- SP 2.1 Design the Product or Product Component.
Product design consists of two broad phases that may overlap in execution: preliminary and detailed design.
- SP 2.2 Establish a Technical Data Package.
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.
- SP 2.3 Design Interfaces Using Criteria.
Design product component interfaces using established criteria. The criteria for interfaces frequently reflect 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 service) and are often associated with safety, security, durability, and mission-critical characteristics.
- SP 2.4 Perform Make, Buy, or Reuse Analysis.
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.
SG 3 Implement the Product Design
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.
- SP 3.1 Implement the Design.
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. 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.
- SP 3.2 Develop Product Support Documentation.
Develop and maintain the end-use documentation. This specific practice develops and maintains the documentation that will be used to install, operate, and maintain the product.
No comments:
Post a Comment