NEWS AT SEI
This article was originally published in News at SEI on: June 1, 2001
Model problems are focused experimental prototypes that reveal technology/product capabilities, benefits, and limitations in well-bounded ways. They are useful for adding rigor to component-based system design as well as reforming the means by which component evaluation and selection is performed.
In 1982 my employer presented me with a new toy, an IBM 5051 computer, which became better known as the “IBM PC.” I was also provided with a list of all the software programs available for the platform—on a single sheet of paper.
For some time, developing software for this platform (and others) meant developing custom software. Commercial components were simply not available. While this situation was not particularly conducive to productivity (it seemed the first step of each project in those days was to create a systems services layer), it was a comfortable situation for developers. Once you had mastered the DOS and BIOS interfaces, and had a comfortable understanding of 8086/8088 assembler (or a higher-level programming language), there were not many surprises.
Today, developers do not have this comfort zone when they build systems from commercial components. The dynamics of the component market practically guarantee that engineers are, at least in part, unfamiliar with the capabilities and limitations of individual software components and their interactions when combined into a component ensemble.
Prototyping is a fundamental technique of software engineering, as it has been incorporated into Boehm’s Spiral Model [Boehm 88] and institutionalized in various industrial-strength software processes [Cusumano 95, Jacobson 99]. In spiral process models, a project is conceived as a series of iterations over a prescribed development process. Usually, each iteration (except the last, of course) produces a prototype that is further refined by succeeding iterations.
Prototypes may be developed for the customer of the system or they may be built for the designers of the system. Ultimately, all prototyping is motivated by the desire to reduce risk. For example, the development team might build a prototype to reduce the risk that a customer will be unsatisfied with the interface or planned functionality of a system.
There are three motivations for designers to build prototypes. The first is for the designer to develop a basic level of competence in a component, or in an ensemble of components. Typically, this is best accomplished through unstructured “play” with the component. The second motivation is to answer a specific design question: for example, can I use my Web browser to launch an external application? The use of model problems—focused experimental prototypes that reveal technology/product capabilities, benefits, and limitations in well-bounded ways—is well suited to this purpose. The third motivation for building prototypes for the designer is persuasion—after all, good ideas are irrelevant if they are not adopted. Model problems are also an effective mechanism for advocating a particular design approach.
The use of model problems in evaluating technology and product capabilities is fully explored in our new book, Building Systems from Commercial Components, published by Addison-Wesley [Wallnau 01]. In the remainder of this article, I provide an introduction to model problems including the terminology and an overview of the process.
A model problem is actually a description of the design context. The design context defines the constraints on the implementation. For example, if the software under development must provide a Web-based interface for both Netscape Navigator and Microsoft Internet Explorer, this is part of the design context that constrains the solution space.
A prototype situated in a specific design context is called a model solution. A model problem may have any number of model solutions. The number of model solutions developed depends on the severity of the risk inherent in the design context, and the relative success of the model solutions in addressing this risk.
Model problems are normally used by design teams. Optimally, the design team consists of an architect who is the technical lead on the project and makes the principal design decisions, as well as a number of designers/engineers who may be tasked by the architect to execute the model problem.
The overall process consists of the following steps that can be executed in sequence:
- The architect and engineer identify a design question. The design question initiates the model problem. It refers to an unknown that is expressed as a hypothesis.
- The architect and engineer define the a priori evaluation criteria. These criteria describe how the model solution will be shown to support or contradict the hypothesis.
- The architect and engineer define the implementation constraints. The implementation constraints specify the fixed (i.e., inflexible) part of the design context that governs the implementation of the model solution. These constraints might include such things as platform requirements, component versions, and business rules.
- The engineer produces a model solution situated in the design context. The model solution is a minimal spanning application that uses only those features of a component (or components) that are necessary to support or contradict the hypothesis.
- The engineer identifies a posteriori evaluation criteria. A posteriori evaluation criteria include the a priori criteria plus criteria that are discovered as a byproduct of implementing the model solution.
- Finally, the architect performs an evaluation of the model solution against the a posteriori criteria. The evaluation may result in the design solution being rejected or adopted, but often leads to the generation of new design questions that must be resolved in similar fashion.
Model problems have been successfully applied by the SEI in collaboration with organizations over the past five years. These can be applied with varying degrees of formality, but successful model problems always consist of the steps outlined in this article (that is a design question, a priori evaluation criteria, implementation constraints, one or more model solutions, a posteriori evaluation criteria, and evaluation).
Model problems are extensively covered in Building Systems from Commercial Components, including an extensive case study describing multiple applications of this technique in the Web-based system and security domains. Generally speaking, model problems have proven to be a successful technique for adding rigor to component-based system design as well as reforming the means by which component evaluation and selection is performed.
[Boehm 88] Barry Boehm. “A Spiral Model of Software Development and Enhancement.” Computer, May 1988: pp. 61-72.
[Cusumano 95] Michael A. Cusumano and Richard W. Selby. Microsoft Secrets. New York: The Free Press, 1995.
[Jacobson 99] Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process. Reading, MA: Addison-Wesley, 1999.
[Wallnau 01] Kurt Wallnau, Scott Hissam, Robert Seacord. Building Systems from Commercial Components. Reading, MA: Addison-Wesley, 2001.
About the Author
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 30 papers on component-based software engineering, Web-based system design, legacy system modernization, component repositories and 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.