SOFTWARE MODELS-5

LINEAR SEQUENTIAL MODEL


Sometimes called the classic life cycle or the waterfall model, the linear sequential model
suggests a systematic, sequential approach5 to software development that begins at
the system level and progresses through analysis, design, coding, testing, and support.
Figure illustrates the linear sequential model for software engineering. Modeled
after a conventional engineering cycle, the linear sequential model encompasses
the following activities:
System/information engineering and modeling. Because software is always
part of a larger system (or business), work begins by establishing requirements for
all system elements and then allocating some subset of these requirements to software.
This system view is essential when software must interact with other elements
such as hardware, people, and databases. System engineering and analysis encompass
requirements gathering at the system level with a small amount of top level design and analysis. Information engineering encompasses requirements gathering
at the strategic business level and at the business area level.
Software requirements analysis. The requirements gathering process is intensified
and focused specifically on software. To understand the nature of the program(s)
to be built, the software engineer ("analyst") must understand the information domain
(described in Chapter 11) for the software, as well as required function, behavior, performance,
and interface. Requirements for both the system and the software are documented
and reviewed with the customer.
Design. Software design is actually a multistep process that focuses on four distinct
attributes of a program: data structure, software architecture, interface representations,
and procedural (algorithmic) detail. The design process translates requirements
into a representation of the software that can be assessed for quality before coding
begins. Like requirements, the design is documented and becomes part of the software
configuration.
Code generation. The design must be translated into a machine-readable form.
The code generation step performs this task. If design is performed in a detailed manner,
code generation can be accomplished mechanistically.
Testing. Once code has been generated, program testing begins. The testing process
focuses on the logical internals of the software, ensuring that all statements have
been tested, and on the functional externals; that is, conducting tests to uncover
errors and ensure that defined input will produce actual results that agree with required
results.
Support. Software will undoubtedly undergo change after it is delivered to the customer
(a possible exception is embedded software). Change will occur because errors
have been encountered, because the software must be adapted to accommodate
changes in its external environment (e.g., a change required because of a new operating
system or peripheral device), or because the customer requires functional or
performance enhancements. Software support/maintenance reapplies each of the
preceding phases to an existing program rather than a new one 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.
2. It is often difficult for the customer to state all requirements explicitly. The
linear sequential model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects.
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 undetected
until the working program is reviewed, can be disastrous.
In an interesting analysis of actual projects Bradac, 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 blocking
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 definite
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.