Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Model Problems
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 4. 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.