Building Systems from Commercial Components Using Model Problems
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
Fundamental Ideas
Prototyping is a fundamental technique of software engineering, as it has been incorporated into Boehm’s Spiral Model1 and institutionalized in various industrial-strength software processes 2, 3. 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.