18.5 Sequential Development

"The waterfall development model is dead," claim many of today's developers and researchers. But it isn't. Experience shows that many companies still follow some variation of a sequential development model, of which the waterfall model is the origin.

A sequential development model is one where development activities follow each other in a forward sequence. This is illustrated in Figure 18-6 in a waterfall model for a simple, pure software project. The work flows from one development activity to the next, and each development activity has to be finishedthe planned work products approvedbefore the next starts.

Figure 18-6. Pure Waterfall Development Model

However, some backpass from a development activity to a previous development activity always occurs, as indicated by the dotted lines. Not all possible backpasses are shownjust a few examples. This happens because changes of mind are as inevitable as are mistakes, so both new knowledge and error corrections will contribute to backpasses. A waterfall model with backpass is different from an iterative model, in that backpass is considered an exception, and the aim is to conclude each activity before starting the next, even when going through a backpass.

W-Model

The so-called W-model, shown in Figure 18-7 and widely used today, is an extension of the classical waterfall model and the V-model. The principle of the V-model is that testing is performed as a number of different test types, according to different test objects, shown as the right "arm" in Figure 18-7. This means that testing is not just one test at the end of the project but a number of tests performed as early as possible, starting with the unit test. This is based on the detailed design and is performed on individual units as soon as they are ready. The unit test is followed by an integration test, system test, and acceptance test.

Figure 18-7. W-Model

The extra principle in the W-model in relation to the V-model is that each test is prepared as soon as the basis for it is ready. For example, the acceptance test is planned and specified along with the user requirementspreferably in parallel, but at the latest as soon as the requirements are finished. This is shown as the right part of the left "arm" in Figure 18-7. The results of the tests are documented and reported ; this is shown as the right part of the right "arm."

Figure 18-7 does not include the backpasses, but this doesn't imply there are none. On the contrary, this model has even more than the pure waterfall model, since the early work on test specifications creates awareness of both necessary enhancements and errors to the basis for the test specification (e.g., the architectural design).

Configuration Management Considerations

It may look as if configuration management is not important when you are using one of the sequential models. They usually involve few planned releases and at least the theoretical assumption that everything is done right the first time. This is not the reality, as the inclusion of one or more test activities indicates and as experience shows (illustrated in the backpasses). Hence, configuration management is relevant as a support function for sequential development but perhaps a little easier than in agile models.

Identification

Tracing, both vertically and horizontally, is an important part of the sequential development model, especially the W-model. The vertical trace ensures that everything in a development activity is catered to in the next development activity; this is an important contribution to "doing it right the first time." It also ensures that the product doesn't growisn't gold-plated with unwarranted functionality or features. This is an important contribution to keeping the plans.

The horizontal tracebetween the test basis and the test specification (such as user requirements and acceptance test cases) ensures that everything is testable and is going to be tested . This trace also contributes to "doing it right the first time" and to keeping the plans. To be able to perform and register these traces, the objects involved must be placed under configuration management early. This means at least having identification procedures in place when new objects are created and, as part of this, a good and easy trace procedure.

Change Control

A project must be prepared for changes and have a change-handling procedure ready, even when using sequential development. Events should not come as a surprise, and the configuration control board(s) should be constituted as early as possible. Changes must be catered to in planning. Even if the intention is to do everything right the first time around, planning must allow for changes, not least as part of test activities. Experience shows that project management is often surprised by the number of errors found in testing and the time involved in finding and resolving them.

Status Reporting

Usually, it's important for project management on sequential development models to follow up closely on project plans. Status reporting from the configuration management system can provide valuable information. Therefore, it's important to ensure that status reporting is fast, comprehensive, and reliable. Trace reports can reveal the state of completeness for each development activity in turn , as can reports on event registrations and change requests . A development activity is not complete until the trace is complete and the number of open event registrations and change requests has reached an acceptable level.