7.3 Alternatives to Waterfall

If the waterfall model is in conflict with today's fast-changing business world, what are the alternatives? There have certainly been several models proposed since the introduction of waterfall that help to solve some of these problems.

7.3.1 Rapid Application Development (RAD)

Waterfall lifecycles have increased risk as the schedule of the project lengthens. A methodology called rapid application development (RAD) helped address this by pulling the business users in more tightly into the lifecycle. Sessions called joint application development (JAD) brought all the stakeholders together and basically designed the system as a group . Also, RAD lifecycles relied on prototyping to share information among users and technologists. The feedback loops were tightened using these techniques and tools.

RAD did not work well for several reasons. First, as we examined in Chapter 1, prototypes are not good artifacts for discussion about software requirements. They tend to shift the focus of businesspeople onto the lesser important factors of design ( user interface widgets, Web page navigation, and so on) and away from the important requirements. They also often set unrealistic expectations of how far the project has progressed based on "how complete it looks."

Also, although RAD was a step toward adaptivity, it did not have enough specific tools and techniques to deal with a constant flow of changes coming from the business to allow teams to function effectively. As a result, RAD became a satisfactory lifecycle for small projects, but was deemed as insufficient for endeavors with more than three to four member teams operating for 3 “4 months or more.

7.3.2 Spiral

The Spiral lifecycle, credited largely to Barry Boehm (1986), uses a series of iterations to refine the understanding of the project scope and reduce the risk. The Spiral lifecycle is effective in peeling away the layers of a large project scope. It relies on prototypes or simulations early in the lifecycle.

The Spiral lifecycle does much to reduce risk in the software lifecycle. However, prototypes and simulations can tend to pull away the attention of a business user to unimportant details instead of important requirements. However, it is accurate to say that the iterative/incremental lifecycles owe much to the Spiral philosophy that preceded them.

For an example of the Spiral process, see this link:

http://metr.cua.edu/faculty/mckenzie/mis327/Spiral.html

7.3.3 Staged Delivery

If larger projects cause bigger risks and problems, why not reduce a large project into smaller subprojects? The Staged Delivery lifecycle has taken hold in the software industry in a big way. A large project, which taken in one big chunk , would take two years and a team of twenty people, can theoretically be broken down into eight smaller pieces, each subproject taking three months and ten people. These individual subprojects are much more manageable, and much less risky.

The difficulties in Staged Delivery are about the "cutting." What are the best dividing lines to cut the project into smaller pieces? If you attack the Forecasting subsystem first, will there be so much dependence on the other subsystems that you'll end up developing the whole application before getting Forecasting to work? Also, new software that is replacing old software is problematic for Staged Delivery. When does the point come where the old system can be turned off? How will the old system accomplish some of the functionality not implemented yet in the new system, but turn off the functionality already done in the new system?

Also, within each "stage" the Staged Delivery lifecycle is still waterfall. This means that, like our friend Nell, even though the projects are short (perhaps 3 “6 months) their ability to adapt to business changes during the lifecycle is feeble.

7.3.4 Holistic Iterative/Incremental (HI/I)

Taking much of what works in other lifecycles, a variety of methodologists in the late 1990s put together lifecycles that could be summed up as holistic iterative/incremental (HI/I ”pronounced hi-eye ). Lifecycles such as the Unified Process (UP), eXtreme Programming (XP), Adaptive Software Development (ASD), and Agile Software Development (AgileSD) use tools and techniques that make it possible for a software team to keep up with the massive changes in business today. Although these lifecycles are not specific to business software development (they claim to cover military, real-time, and scientific software as well), they solve the major issues we've faced with waterfall and other earlier lifecycles in the business world.

The HI/I lifecycles have a rigorous focus on continuous feedback loops between software development and its stakeholders, primarily in our case, businesspeople. What differentiates them from RAD, Spiral, or other older lifecycles is that the HI/I lifecycles have a built-in "holistic perspective," in which the view of the whole is never lost. This is accomplished with a strong architectural vision.