NEWS AT SEI
This article was originally published in News at SEI on: September 1, 2002
Experience has shown that new management and engineering processes are needed for building, fielding, and supporting systems that make extensive use of commercial components. Existing processes tend to take either a management or an engineering perspective but not both. As a result, these processes fail to directly address the needs of the other group. Instead, disparate processes are often combined in an ad hoc fashion. This is complicated further because these processes are often based on disparate assumptions.
The COTS-Based Systems (CBS) initiative at the SEI has performed extensive research on processes needed in the management of COTS-based systems, engineering techniques for designing and evolving COTS-based systems, and evaluation techniques for assessing COTS-based program risks. While these CBS initiative products have been developed separately to meet the needs of different customers, they are compatible in that they share a common understanding of the underlying issues in building systems from commercial components.
The Evolutionary Process for Integrating COTS-based systems (EPIC), for example, extends the Rational Unified Process (RUP) to accommodate COTS-based system development. EPIC shares the RUP principles that a development process must be risk- and use-case driven, architecture centric, iterative, and incremental. As shown in the figure below, EPIC accomplishes this through concurrent discovery and negotiation of stakeholder needs and business processes; applicable technology and components; the architecture and design; and the programmatics and risk across four RUP phases of inception, elaboration, construction, and transition.
EPIC provides a structured flow of activities and artifacts that keeps the four spheres fluid and balanced as the project evolves from a strategic vision to an implemented and sustained solution. In EPIC, a solution is composed of the integration of one or more COTS products with any legacy or other reuse components, any required custom code (including wrappers and “glue”), and any changes to end-user business processes necessary to match the capabilities of the COTS products. EPIC makes no attempt to be complete; the detailed information necessary for implementation is left to RUP and other methods.
The CBS initiative has also produced a book in the SEI Series in Software Engineering titled Building Systems from Commercial Components (BSCC). BSCC describes component-based design methods, including a variety of design and engineering techniques that have been effectively applied in practice in the development of large, complex systems from commercial components. A central proposition in BSCC is that a principal source of risk in component-based design is a lack of knowledge about how components should be integrated and how they behave when integrated. BSCC describes the software engineering methods and techniques necessary to respond to the engineering challenges posed by the commercial component market.
BSCC identifies design and engineering techniques that respond to the complex, idiosyncratic, and unstable nature of commercial components. The table below shows the core elements from BSCC.
A design abstraction that exposes component incompatibilities by shifting emphasis from individual components to collections of integrable components.
A design notation that depicts what is currently known, and what remains to be discovered, about an ensemble.
A risk-driven discovery process that exposes design risk and defines ensemble feasibility criteria.
A prototyping process for generating situated component expertise and for establishing ensemble feasibility.
How do BSCC Techniques Map to EPIC?
While designed to meet different needs, EPIC and BSCC share a common foundation and are complimentary. EPIC provides BSCC with a prescriptive framework that links the disparate system stakeholders into a coherent team. Conversely, the methods and techniques described in BSCC can be used to implement the design activities and workflows of EPIC. With that in mind, the following are a few examples of how the BSCC techniques map to EPIC and how the EPIC artifacts support BSCC techniques.
Model problems are a useful mechanism in the inception and elaboration phases. In these phases, stakeholders are focused on discovering what the components do, how they are combined with other components to form an ensemble, and how best to structure a design solution that makes the best use of components. A model problem expresses a design question pertaining to integrating software components in its simplest, most primitive form. It defines a problem that needs to be solved, and defines criteria for evaluating solutions. Using model problems encourages identification of relevant component sources, can assist in characterizing available components, and provides a vehicle for understanding the behavior of the components in the context of ensembles that support the solution’s design.
A model problem’s inputs are structured as a design question or unknown that is expressed as a hypothesis with the minimum relevant constraints and the starting evaluation criteria that describe how the hypothesis will be supported or refuted. The EPIC artifact, Component Screening Criteria and Rationale, maps nicely to the necessary input elements of a model problem. A model solution is an executable prototype that answers the question posed by the model problem and demonstrates that the evaluation criteria is satisfied, cannot be satisfied, or is conditionally satisfied. This is complementary to EPIC, which emphasizes the importance of an executable representation to demonstrate the stakeholder consensus on decisions made in each iteration.
Model problems may also be used in concert with more formal evaluation techniques such as Multi-Criteria Evaluation and Risk/Misfit to evaluate applicable components. The EPIC Component Dossier (one for each examined component) artifact supports this evaluation by capturing a wealth of information for each component. The component data provided by the vendors is supplemented with information discovered during prototyping to provide knowledge about how the components interact in the context of the solution. Over the lifetime of a system, components may undergo significant change. The dossier acts as an audit trail or log to view the component’s evolution. BSCC blackboards are one mechanism for representing component dossiers, used to capture component knowledge. This knowledge is labeled with credentials that define the source and level of confidence in the data.
Where model problems ensure that prototyping is highly efficient, R3 (Risk Analysis, Realize model problem, Repair residual risk) provides a workflow that ensures that the right questions are posed, that model solutions are developed only where significant design risk exists, and that the risks are mitigated by “repairing” them where practical. For risks that are not repaired, BSCC describes contingency-planning approaches that are fundamental to EPIC’s risk-driven approach.
BSCC and EPIC can be readily used together because they are based on a common understanding of the underlying issues affecting the success of building, fielding, and supporting systems built from commercial components. Both identify an investment in risk identification, analysis, and mitigation to identify and negotiate product mismatches early in the development process as central to any successful project. BSCC provides engineering techniques such as model problems and Risk/Misfit that can provide concrete mechanisms to accomplish EPIC life-cycle activities.
Albert, Cecilia; Brownsword, Lisa. Evolutionary Process for Integrating COTS-Based Systems (EPIC): An Overview. Software Engineering Institute technical report (CMU/SEI-2002-TR-009) 2002.
Krutchen, Phillippe. The Rational Unified Process: An Introduction, 2nd ed. New York: Addison-Wesley Object Technology. March 2000.
Wallnau, Kurt C.; Hissam, Scott A.; and Seacord, Robert C. Building Systems from Commercial Components. Boston: Addison-Wesley, July 2001.
About the Authors
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.
Russ Bunting is a member of the technical staff in the COTS-Based Systems Initiative at the SEI. Before joining the SEI, Bunting led teams developing component management, requirements management, visual modeling, and code generation tools, and was a practicing Rational Certified Trainer in Object Oriented Analysis and Design\UML.
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.