The Software Process

Now that the foundation has been laid, I can turn to the principal concern of this book: software design. I use the word design in its most expansive sense. That is, design is contrasted with discovery; it encompasses all deliberate modifications of the environment, in this case modifications that employ software components. Thus, software design should not be interpreted as a phase in the development of a product— an activity that begins after some prerequisite is complete and that terminates with the acceptance of a work product. The context of software design in Part III is extended to include all aspects of the software process from the design of a response to a real-world need (which ultimately may be expressed as a requirements document) through the design of changes to the product (i.e., lifetime maintenance). This broader use of “design” can be confusing, and the reader may think of software design as the equivalent of the software process. In what follows, the goal is to discover the essential nature of software design, which I also shall refer to as the software process. what of the foundation constructed so laboriously during the first two parts of the book? It is not one of concrete and deep pilings. Rather it is composed of crushed rock. It can support a broad-based model of software design, but it may be unstable when it comes to specifics. The foundation has been chipped from the monolith of Positivism, of Technical Rationality. Its constituents are solid and cohesive models, but they defy unification and resist integration. we interpret them as science, technology, culture, philosophy, cognition, emotion, art; they comprise the plural realities from which we compose human knowledge. Unfortunately, my description of the foundation holds little promise of broad, general answers. Indeed, it suggests that science may be of limited help to design and that we may never discover the essence of design. That is, we must accept design as a human activity; whatever answers we may find will be valid within narrow domains where knowledge is determined by its context. Thus, Parts I and II prepare us to accept that the study of software design may not be amenable to systematic analysis.