NEWS AT SEI
This library item is related to the following area(s) of work:CMMI
This article was originally published in News at SEI on: June 1, 2003
The Technical Solution practice area is defined in the Engineering process area. 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. The techniques and practices described in BSCC satisfy the following specific goals of the Technical Solution:
SG 1 Select Product-Component Solutions
Product or product-component solutions are selected from alternative solutions.
SG 2 Develop the Design
Product or product-component designs are developed
The specific goal of selecting product-component solutions in CMMI is supported by three specific practices:
The specific goal for selecting product-component solutions requires considering alternative solutions in advance of selecting a solution. This goal is supported in BSCC through the use of contingency planning, a technique for managing multiple design alternatives of unknown feasibility and determining how and when to apply resources to resolve critical unknowns. Risk/Misfit, another BSCC technique, is a decision aide used for determining the level of resources to be used in exploring the different design alternatives based on cost, schedule, performance, and risk. While Risk/Misfit itself may be better aligned with the Decision, Analysis, and Resolution (DAR) process area, its application here satisfies the specific goal of evaluating design alternatives against these criteria.
SP 1.1 Develop detailed alternative solutions and selection criteria.
SP 1.2 Evolve operational concepts and scenarios.
SP 1.3 Select product-component solutions.
These specific practices are supported by BSCC processes and techniques as described in the following subsections.
Developing detailed alternative solutions is an essential concept of the Technical Solution process area. As already mentioned, BSCC encourages the development and management of multiple design alternatives through contingency management. The development of detailed design alternatives is supported in BSCC through the R3 process and the use of model problems. R3 stands for Risk analysis, Realize model problems, and Repair misfit. Risk analysis involves creating one or more model blackboards that illustrate a scenario through the design alternative containing a critical risk. If critical unknowns exist in the blackboard, model problems are realized to further assess the risk. Model problems are situated prototypes created to answer specific design questions. If specific risks still exist after creation of the model solution (to the model problem), it may still be possible to repair the misfit, either by adapting the design alternative or by changing the context (e.g., the requirements). Repair misfit is the final step in R3.
Selection criteria are an inherent part of BSCC. The major selection criterion used in BSCC is design risk; for example, that the design does not satisfy stakeholder needs. Project-level design risk is assessed at the beginning of the process. Design alternatives are continually assessed against these risks throughout the R3 process. The ability of each design alternative to address these risks is considered along with the costs and benefits of each approach in identifying a path for continued design-space exploration. Continued application of these criteria in the design process prevents unnecessary expenditure of resources on unfeasible solutions.
SP 1.2 evolves the operational concept, scenarios, and environments to describe the conditions, operating modes, and operating states specific to each product component. Operational concepts and scenarios are also a critical element of BSCC. Scenarios are developed and used in the creation of blackboards within R3 to assess specific design risks.
Typical work products for this specific practice include 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); timeline analyses of product-component interactions; and use cases. BSCC includes work products such as ensemble descriptions and blackboards that emphasize timeline analyses of product-component interactions. Use cases are used in BSCC to discover critical unknowns in a design alternative and to explore design risk in the R3 process.
The final specific practice for SG 1 selects the product-component solutions that best satisfy the criteria established. Since integration problems are a major source of risk in COTS-based systems development, COTS components must be selected in the context of a feasible design solution. Consequently, evaluation in BSCC is an inherent part of the design process. Successful execution of BSCC results in the selection of a feasible design alternative that consists of a collection of components and design decisions.
The application of BSCC satisfies the specific goal of developing detailed alternative solutions and selection criteria in the Technical Solution process area for COTS-based system development. Both CMMI models and BSCC emphasize the need to evaluate multiple design alternatives relative to cost, schedule, and risk, as well as achieving the required functionality and design qualities.
I will explore, in a future column, where and to what degree BSCC satisfies the specific practices of SG 2 (developing the design).
Capability Maturity Model Integration (CMMI ), Version 1.1 CMMI for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1) Staged Representation (CMU/SEI-2002-TR-012) March 2002.
Wallnau, Kurt; Hissam, Scott; & Seacord, Robert. Building Systems from Commercial Components. New York, NY: Addison-Wesley, 2001.
Robert C. Seacord is a senior member of the technical staff at the SEI and an eclectic technologist. He is coauthor of the book Building Systems from Commercial Components as well as more than 40 papers on component-based software engineering, Web-based system design, legacy system modernization, component repositories, search engines, security, and user interface design and development.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.