Page 57 -

28 PART ONE THE PRODUCT AND THE PROCESS

4
even at the line of code level. Therefore, a fractal representation can be used to pro-
vide an idealized view of process. In Figure 2.3b, each stage in the problem solving
loop contains an identical problem solving loop, which contains still another prob-
lem solving loop (this continues to some rational boundary; for software, a line of
code).
Realistically, it is difficult to compartmentalize activities as neatly as Figure 2.3b
implies because cross talk occurs within and across stages. Yet, this simplified view
leads to a very important idea: regardless of the process model that is chosen for a
software project, all of the stages—status quo, problem definition, technical develop-
All stages of a ment, and solution integration—coexist simultaneously at some level of detail. Given
software process— the recursive nature of Figure 2.3b, the four stages discussed apply equally to the
status quo, problem
definition, technical analysis of a complete application and to the generation of a small segment of code.
development, and Raccoon [RAC95] suggests a “Chaos model” that describes “software develop-
solution integration— ment [as] a continuum from the user to the developer to the technology.” As work
coexist simultaneously progresses toward a complete system, the stages are applied recursively to user needs
at some level of detail.
and the developer’s technical specification of the software.
In the sections that follow, a variety of different process models for software engi-
neering are discussed. Each represents an attempt to bring order to an inherently
chaotic activity. It is important to remember that each of the models has been char-
acterized in a way that (ideally) assists in the control and coordination of a real soft-
ware project. And yet, at their core, all of the models exhibit characteristics of the
Chaos model.

2.4 THE LINEAR SEQUENTIAL MODEL
Sometimes called the classic life cycle or the waterfall model, the linear sequential model
5
suggests a systematic, sequential approach to software development that begins at
the system level and progresses through analysis, design, coding, testing, and sup-
port. Figure 2.4 illustrates the linear sequential model for software engineering. Mod-
eled 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 soft-
ware. This system view is essential when software must interact with other elements
such as hardware, people, and databases. System engineering and analysis encom-
pass requirements gathering at the system level with a small amount of top level

4 Fractals were originally proposed for geometric representations. A pattern is defined and then
applied recursively at successively smaller scales; patterns fall inside patterns.
5 Although the original waterfall model proposed by Winston Royce [ROY70] made provision for
“feedback loops,” the vast majority of organizations that apply this process model treat it as if it
were strictly linear.