Building Systems from Commercial Components Using Model Problems

This article by Robert Seacord, provided courtesy of the Software Engineering Institute, covers using model problems  focused experimental prototypes that reveal technology/product capabilities, benefits, and limitations in well-bounded ways  to add rigor to component based system design.

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.