The Iterative Approach

In the past decade , many teams have migrated to a new approach, one that combines the best of the waterfall and spiral models and is a hybrid of the two. This new approach also incorporates some additional constructs from the advancing discipline of software process engineering. The iterative approach introduced by Kruchten [1995] has now been well described in a number of texts , including those by Kruchten [1999] and Royce [1998]. This approach has proved effective in a wide variety of project types and can exhibit a number of advantages over the waterfall and spiral models of development.

In the traditional software development process models, time moves forward through a series of sequential activities, with requirements preceding design, design preceding implementation, and so on. This seemed quite sensible . In the iterative approach, however, the lifecycle phases are decoupled from the logical software activities that occur in each phase, allowing us to revisit various activities, such as requirements, design, and implementation, during various iterations of the project. In addition, like the spiral model, each iteration is designed to mitigate whatever risks are present in that stage of development activity.

Lifecycle Phases

The iterative approach consists of four lifecycle phases : inception, elaboration, construction, and transition, corresponding to fairly natural "states" of the project at these times (Figure 3-3).

Figure 3-3. Lifecycle phases in the iterative approach

In the inception phase, the team is focused on understanding the business case for the project, the scope of the project, and the feasibility of an implementation. Problem analysis is performed, the vision for the solution is created, and preliminary estimates of schedule and budget, as well as project risk factors, are defined.

In the elaboration phase, the requirements for the system are refined, an initial, perhaps even executable, architecture is established, and an early feasibility prototype is typically developed and demonstrated.

In the construction phase, the focus is on implementation. Most of the coding is done in this phase, and the architecture and design are fully developed.

Beta testing typically happens in the transition phase, and the users and maintainers of the system are trained on the application. The tested baseline of the application is transitioned to the user community and deployed for use.

Iterations

Within each phase, the project typically undergoes multiple iterations (Figure 3-4). An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable of some type. Each iteration builds on the functionality of the prior iteration; thus, the project is developed in an "iterative and incremental" fashion.

Figure 3-4. Phase iterations, resulting in viable releases

Iterations are selected according to a number of criteria. Early iterations should be designed to evaluate the viability of the chosen architecture against some of the most important and risk-laden use cases.

Disciplines

In the iterative approach, the activities associated with the development of the software are organized into a set of disciplines . Each discipline consists of a logically related set of activities, and each defines how the activities must be sequenced to produce a viable work product (or artifact ). Although the number and kind of disciplines can vary, based on the company or project circumstances, there are typically at least six disciplines, as Figure 3-5 illustrates.

Figure 3-5. Disciplines of the iterative approach

During each iteration, the team spends as much time as appropriate in each discipline. Thus, an iteration can be regarded as a mini-waterfall through the activities of requirements, analysis and design, and so on, but each mini-waterfall is " tuned " to the specific needs of that iteration. The size of the "hump" in Figure 3-5 indicates the relative amount of effort invested in a discipline. For example, in the elaboration phase, significant time is spent on "refining" the requirements and in defining the architecture that will support the functionality. The activities can be sequential (a true mini-waterfall) or may execute concurrently, as is appropriate to the project.

The lifecycle model shown in Figure 3-5 is taken from the Rational Unified Process [Rational Software Corporation 2002]. The process is commonly referred to by its initials (RUP). The RUP provides a comprehensive set of best practices covering the full software lifecycle. For more on the RUP and its integral requirements practices, see Appendix E.