SG 1 Select Product-Component SolutionsProduct 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. 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.
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. Sometimes the search for solutions examines alternative instances of the same requirements with no allocations needed for 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). 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. 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. The following specific practice is subsumed in the staged representation by SP 1.1-2, Develop Detailed Alternative Solutions and Selection Criteria. SP 1.1-1 Develop Alternative Solutions and Selection CriteriaDevelop alternative solutions and selection criteria. 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. Refer to the Decision Analysis and Resolution process area for more information about establishing selection criteria and identifying alternatives. Refer to the Requirements Management process area for more information about managing the provisional and established allocated requirements. 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. As selections are made, the design space can 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. The alternative solutions evaluated frequently encompass alternative requirement allocations to different product components. These alternatives also can 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. 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. Typical Work Products
Subpractices
SP 1.1-2 Develop Detailed Alternative Solutions and Selection CriteriaDevelop detailed alternative solutions and selection criteria. Refer to the Decision Analysis and Resolution process area for more information about establishing criteria used in making decisions.
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. 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:
The considerations listed here 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. Typical Work Products
Subpractices
SP 1.2-2 Evolve Operational Concepts and ScenariosEvolve the operational concept, scenarios, and environments to describe the conditions, operating modes, and operating states specific to each product component. 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.
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. The environments (e.g., operating, support, training) 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. Typical Work Products
Subpractices
SP 1.3-1 Select Product-Component SolutionsSelect the product-component solutions that best satisfy the criteria established. 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. Refer to the Decision Analysis and Resolution process area for more information about formal evaluations. 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. 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 in sights to apply technology as it becomes available in applicable circumstances. Typical Work Products
Subpractices
SG 2 Develop the DesignProduct or product-component designs are developed. 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.
SP 2.1-1 Design the Product or Product ComponentDevelop a design for the product or product component. 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. Refer to the Requirements Development process area for more information about developing architecture requirements. 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. 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. 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. 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.
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 that those requirements are satisfied. Refer to the Requirements Management process area for more information about tracking requirements for product components.
Typical Work Products
Subpractices
SP 2.2-3 Establish a Technical Data PackageEstablish and maintain 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. 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. 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):
Because design descriptions can involve a very large amount of data and can 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:
These views are documented in the technical data package. Typical Work Products
Subpractices
The following specific practice is subsumed in the staged representation by SP 2.3-3, Design Interfaces Using Criteria. SP 2.3-1 Establish Interface DescriptionsEstablish and maintain the solution for product-component interfaces. The product-component interface description covers interfaces between the following:
Typical Work Products
Subpractices
SP 2.3-3 Design Interfaces Using CriteriaDesign comprehensive product-component interfaces in terms of established and maintained criteria. Interface designs include the following:
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. Typical Work Products
Subpractices
SP 2.4-3 Perform Make, Buy, or Reuse AnalysesEvaluate whether the product components should be developed, purchased, or reused based on established criteria. 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. Refer to the Requirements Development process area for more information about determining the product and product-component requirements. Refer to the Requirements Management process area for more information about managing requirements. Factors affecting the make-or-buy decision include the following:
Many of these factors are addressed by the project. The make-or-buy decision can be conducted using a formal evaluation approach. Refer to the Decision Analysis and Resolution process area for more information about defining criteria and alternatives and performing formal evaluations. 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. 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 nondeveloped items is because 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. 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. Typical Work Products
Subpractices
SG 3 Implement the Product DesignProduct components, and associated support documentation, are implemented from their designs. 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-1 Implement the DesignImplement the designs of the product components.
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. Refer to the Requirements Development process area for more information about the allocation and refinement of requirements. Refer to the Product Integration process area for more information about the management of interfaces and the integration of products and product components.
Typical Work Products
Subpractices
SP 3.2-1 Develop Product Support DocumentationDevelop 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. Typical Work Products
Subpractices
|