1.4 The Iterative Model

The iterative model of software development is basically a waterfall model, except we allow software developers to move in two directions along the flow of the project (see Figure 1.2). If we detect a design flaw while coding part of the application, we can move back to the design phase and correct it. Or if we detect the need for a new system requirement while testing part of the application, we can move back to the analysis phase and repair the problem. This model of software engineering causes many problems in the action-oriented paradigm. Action-oriented software often has many hidden dependencies between data and behavior. Combine that with a centralized control mechanism, and you run into a situation where you touch an existing application and the whole world crumbles into dust. The thought of adding a new requirement or changing the design when 90 percent of the application has been coded is not an option. The object-oriented paradigm corrects this problem by providing its developers with a decentralized form of flow control and the ability to prevent hidden dependencies between data and behavior. For these reasons, the iterative model of software development is becoming the process of choice among object-oriented developers.

Figure 1.2. The iterative model of software development.

The iterative model is not without its problems, however. While I believe that the model accurately reflects the development process from a system architect's point of view, it presents a large problem to the project manager. In short, the model currently lacks a series of well-defined development milestones. This does not imply that a project manager needs to wait until the day before a software system is to be shipped to customers before he or she receives any feedback. It implies that we need new iterative milestones that can provide the necessary feedback without the burden of casting large portions of the application in concrete.

One such deliverable is known as the software prototype . The field of prototyping comes from the realization that complex entities in the real world are grown and not built. Many developers are looking to prototyping as a method for controlling the essential complexity of modern-day software. Through prototyping, an application can be grown a layer at time, each layer being thoroughly tested before moving on to the next layer. In this way, design flaws can be detected early enough to facilitate inexpensive corrections, while the working prototype can also serve as a productivity metric. By measuring the amount of functionality in the prototype versus the amount of smoke and mirrors, we can track progress.