Design Methods

The previous chapter on the software process introduced two contrasting orientations: problem and product. Both orientations have the same objective: the efficient and effective creation of an automated response to a real-world problem. They differ only in the methods and tools used to achieve that end. In the product-oriented model, the difficulty of realizing a solution is accepted as the critical path. Thus, the approach applies the principle of separation of concerns and divides the process into two discrete activities: first establish the essential requirements of what is needed, and then build a product that will satisfy those requirements. As already noted, this model is appropriate when the requirements are stable or if the complexity of development is so great that a fixed specification is necessary to reduce risk. In contrast, the problemoriented model is valuable for real-world problems with open requirements (open both in the sense of initial uncertainty and of operational change). Unfortunately, it can be implemented only for domains in which the technology is relatively mature. For example, military applications that push the limits of technology have open requirements (i.e., they begin with uncertainty and are subject to modification as potential adversaries develop responses to newly introduced capabilities). In this domain, however, the technology may be too complex for development without frozen requirements. In other domains, such as interactive information systems, the technological challenges are sufficiently well understood to permit a problem-oriented approach with its one-step process model. The adaptive design paradigm proposed in this book is problem oriented. The instantiation I describe in the next two chapters creates interactive information systems. In principle, there is no reason why the adaptive design model may not be used for complex, real-time military applications; the fact that it has not been so used is a function of our knowledge of that domain and not a limitation of the paradigm. There always will be a fuzzy boundary about the technology that separates what we can and cannot do. At that boundary, we must rely on experimentation and hacking to gain understanding.