Traditional Software Process Models

Effective requirements management can occur only within the context of a reasonably well-defined software process that defines the full set of activities your team must execute to deliver the final software product. Some software processes are relatively formal, some are informal, but a process is always at work, whether or not it is rigorous or documented.

Your team's software development process defines who (which member of the team) is doing what (which activity is being performed), when (the timing in relation to other activities), and how (the details and steps in the activity) in order for your team to reach its goal. Software processes have been shown to have a significant effect on your team's ability to develop software on time and on budget. In this chapter, we look at a few different software processes and attempt to understand the time-dependent phases and major types of activities in those phases. We then go on to describe a specific, recommended model: the iterative model. Within the context of the iterative model we can begin to understand the key role that requirements play throughout the software lifecycle. Most of the techniques described in this book apply to a variety of software processes, but it is through using an iterative approach that you are likely to achieve the maximum benefits.

The Waterfall Model

Boehm [1988] points out that as early as the 1950s the software industry, recognizing the cost of discovering software defects late in the cycle, adopted a logical, stepwise process model that progressed from a requirement phase to a design phase to a coding phase and so on. This was a major improvement over the earlier, two-phase "code and fix" model, whereby programmers first wrote the code and then fixed it until it couldn't be fixed any more.

In the 1970s, Royce [1970], working at TRW, defined what became known as the "waterfall model" of software development. The waterfall model improved on the strictly stepwise model by:

• Recognizing the need for feedback loops between stages, thereby acknowledging that design affects requirements, that coding the system will cause the design to be revisited, and so on

• Developing a prototype system in parallel with requirements analysis and design activities

In the waterfall model (Figure 3-1), software activities proceed logically through a sequence of steps. Each step bases its work on the activities of the previous step. Design logically follows requirements, coding follows design, and so on. The waterfall model was widely followed in the 1970s and '80s and served successfully as a process model for a variety of medium- to large-scale projects.

Figure 3-1. Waterfall model of software development

Note that, as commonly applied, Figure 3-1 does not reference the prototyping activity that Royce prescribed. This is an unfortunate mistake in history that we'll return to shortly.

The waterfall model has been somewhat successful in reinforcing the role of requirements, which form a first step in software development and serve as the basis for design and coding activities. However, this strength also very quickly became a primary source of weakness, as it tended to emphasize fully elaborated requirements and design documents as a barrier to exit from each phase. Also, through perhaps its misapplication by overzealous development teams , the waterfall model has come to represent a fixed, rigid approach to development, wherein requirements are "frozen" for the life of the project, change is anathema, and the process of development takes on a life of its own, independent of the changes occurring in the marketplace or in the users' needs.

In this case, over time, the team may become completely disengaged from the real world on which the project was originally based. Disaster invariably results.

As we'll see later, the waterfall model comes under additional pressure when it is aligned to the scope management challenge. Specifically, if the waterfall model is applied to a project that is initiated with too large a scope, the results can be woefully short of the initial expectations. At deadline time, nothing really works, unit test and system integration are forced or abandoned , and significant investments have been made in the specification, design, and coding of system features that are never delivered. The result: nothing deliverable , chaos, poor quality, and software scrap.

Primarily for these reasons, the waterfall model has fallen out of favor. One unfortunate result has been the tendency for teams to leap right into code, with an inadequate understanding of the requirements for the system ”one of the main problems the waterfall model attempted to solve!

The Spiral Model

Boehm's pivotal study [1988] recommended a different framework for guiding the software development process. His "spiral model" of software development serves as a role model for those who believe that success follows a more risk-driven and incremental development path (Figure 3-2).

Figure 3-2. The spiral model of development

In the spiral model, development is initially driven by a series of risk-driven prototypes ; then a structured waterfall-like process is used to produce the final system. Of course, when misused, the spiral model can exhibit as many problems as the misused waterfall model. Projects sometimes fall into a cut-and-try approach, providing incremental deliverables that must be expanded and maintained with the addition of bubble gum and baling wire. Some refer to this as the process of creating instant legacy code, progress being measured by our newfound ability to create unmaintainable and incomprehensible code two to three times as fast as with earlier methods !

When you look at the spiral model more carefully , however, it provides a sensible road map that helps address some of the requirements challenges noted in this book. Specifically, the spiral model starts with requirements planning and concept validation, followed by one or more prototypes to assist in early confirmation of our understanding of the requirements for the system. The main advantage of this process is the availability of multiple feedback opportunities with the users and customers, which is intended to get the "Yes, Buts" (see Chapter 8) out early. Opponents of this rigorous approach note that, in today's environment, we typically do not have the luxury of time for full concept validation and two or three prototypes, followed by a rigorous waterfall methodology.