Develop the Design
Product 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.
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.
SP 2.1 Design the Product or Product Component
Develop 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.
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.
For Software Engineering
In addition to tasks identified above, software architecture definition may include:
· 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.
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.
Typical Work Products
1. Product architecture
2. Product-component designs
Subpractices
1. Establish and maintain criteria against which the design can be evaluated.
Examples of attributes, in addition to expected performance, for which design criteria can be established, include the following:
· Modular
· Clear
· Simple
· Maintainable
· Verifiable
· Portable
· Reliable
· Accurate
· Secure
· Scalable
· Usable
2. Identify, develop, or acquire the design methods appropriate for the product.
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.
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.
Examples of techniques and methods that facilitate effective design include the following:
· 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.
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):
· 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.
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.
5. Document the design.
SP 2.2 Establish a Technical Data Package
Establish 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. Thistechnical data package is maintained throughout the life of the productto record essential details of the product design. The technical datapackage provides the description of a product or product component(including product-related life-cycle processes if not handled asseparate 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 ofthe 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 maynot be useful for product components associated with software servicesor processes):
· Product architecture description
· Allocated requirements
· Product-component descriptions
· Product-related life-cycle process descriptions, if not described asseparate product components
· Key product characteristics
· Required physical characteristics and constraints
· Interface requirements
· Materials requirements (bills of material and materialcharacteristics)
· Fabrication and manufacturing requirements (for both the originalequipment manufacturer and field support)
· The verification criteria used to ensure that requirements havebeen 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:
· Customers
· Requirements
· The environment
· Functional
· Logical
· Security
· Data
· States/modes
· Construction
· Management
These views are documented in the technical data package.
Typical Work Products
1. Technical data package
Subpractices
1. Determine the number of levels of design and the appropriate level of documentation for each design level.
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.
2. Base detailed design descriptions on the allocated product component requirements, architecture, and higher level designs.
3. Document the design in the technical data package.
4. Document the rationale for key (i.e., significant effect on cost, schedule, or technical performance) decisions made or defined.
5. Revise the technical data package as necessary.
SP 2.3 Design Interfaces Using Criteria
Design comprehensive product-component interfaces in terms of established and maintained criteria.
Interface designs include the following:
· 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.
Typical Work Products
1. Interface design specifications
2. Interface control documents
3. Interface specification criteria
4. Rationale for selected interface design
Subpractices
1. Define interface criteria.
These criteria can be a part of the organizational process assets.
2. Apply the criteria to the interface design alternatives.
3. Document the selected interface designs and the rationale for the
selection.
SP 2.4 Perform Make, Buy, or Reuse Analyses
Evaluate 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
Factors affecting the make-or-buy decision include the following:
· 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.
The make-or-buy decision can be conducted using a formal evaluation
approach.
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 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.
Typical Work Products
1. Criteria for design and product-component reuse
2. Make-or-buy analyses
3. Guidelines for choosing COTS product components
Subpractices
1. Develop criteria for the reuse of product-component designs.
2. Analyze designs to determine if product components should be developed, reused, or purchased.
3. When purchased or non-developmental (COTS, government off the shelf, and reuse) items are selected, plan for their maintenance.
For Software Engineering
Consider how the compatibility of future releases of an operating system and a database manager will be handled.
