Page 59 -

30 PART ONE THE PRODUCT AND THE PROCESS

The linear sequential model is the oldest and the most widely used paradigm for
software engineering. However, criticism of the paradigm has caused even active
supporters to question its efficacy [HAN95]. Among the problems that are sometimes
encountered when the linear sequential model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly.
As a result, changes can cause confusion as the project team proceeds.
? Why does 2. It is often difficult for the customer to state all requirements explicitly. The
the linear
model sometimes linear sequential model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects.
fail?
3. The customer must have patience. A working version of the program(s) will
not be available until late in the project time-span. A major blunder, if unde-
tected until the working program is reviewed, can be disastrous.
In an interesting analysis of actual projects Bradac [BRA94], found that the linear
nature of the classic life cycle leads to “blocking states” in which some project team
members must wait for other members of the team to complete dependent tasks. In
fact, the time spent waiting can exceed the time spent on productive work! The block-
ing state tends to be more prevalent at the beginning and end of a linear sequential
process.
Each of these problems is real. However, the classic life cycle paradigm has a def-
inite and important place in software engineering work. It provides a template into
which methods for analysis, design, coding, testing, and support can be placed. The
classic life cycle remains a widely used procedural model for software engineering.
While it does have weaknesses, it is significantly better than a haphazard approach
to software development.

2.5 THE PROTOTYPING MODEL
Often, a customer defines a set of general objectives for software but does not iden-
tify detailed input, processing, or output requirements. In other cases, the developer
may be unsure of the efficiency of an algorithm, the adaptability of an operating sys-
tem, or the form that human/machine interaction should take. In these, and many
other situations, a prototyping paradigm may offer the best approach.
The prototyping paradigm (Figure 2.5) begins with requirements gathering. Devel-
oper and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory. A "quick design" then occurs. The quick design focuses on a representa-
tion of those aspects of the software that will be visible to the customer/user (e.g.,
input approaches and output formats). The quick design leads to the construction of