The comparision several different models of the
software development life cycle (SDLC).
The SDLC is a structure imposed on the process of developing software, from the scoping of requirements
through analysis, design, implementation, and maintenance.
Top-Down and Bottom-Up Design
Top-down and bottom-up design represent two
contrasting approaches for designing a large system. The top-down approach
requires a complete design view of the system before any actual coding can
begin. It takes the big-picture view of the system and breaks the problem apart
into many subsystems that require more design detail. The overall perspective
of the project is monolithic:
There is one design, and all modules are small
parts of it. The top-down style of program design is traditionally associated
with procedural languages. The bottom-up approach, in contrast, emphasizes
assembling the big picture by completing many small pieces that work together.
These components are then integrated into the larger system. Coding of individual
modules, and their testing, commences before the entire design is complete.
Proponents of the bottom-up approach argue that this produces reusable code
that saves time later in the process. The bottom-up style of program design is
traditionally associated with object-oriented languages such as C++ and Java.
In practice, some blend of top-down and bottom-up
is a common compromise:
Project managers and architects work on the
overall design even as development teams begin building modules and tools. This
approach is sometimes called hybrid design or hybrid development.
The Waterfall Model
The waterfall model is one of the oldest, and
perhaps the best-known, software
development method. It presents development as a sequential process,
proceeding downhill through the phases in the sequence. W. W. Royce first
explained the waterfall model in 1970, but he was criticizing the approach at
the time, calling it risky and an invitation to failure. The waterfall model is
considered one of the most direct approaches, with short development times and
minimal costs. However, it does presume an unvarying target: The original
specifications cannot change.
In the waterfall model, when a phase is completed,
the phase is closed and cannot be revisited. This limitation has lead to
widespread criticism of this approach. The software development process
involves discovery, and the different phases of development often overlap.
Critics maintain that the waterfall model limits options to correct mistakes:
if a limitation of the requirements is discovered during the design phase, it
is too late to fix it.
Several variations of the waterfall model address
these criticisms by allowing some degree of feedback or overlap. These variants
begin to blur the distinction between the waterfall model and the iterative
processes.
Iterative Processes
When Royce explained the waterfall model in 1970,
he was actually writing in defense of the iterative process. The iterative
model proceeds by using the lessons learned from each phase to modify the
results of the previous phase.
Iterative development is sometimes referred to as
incremental development.
An iterative process begins with a simple
implementation of the project requirements. Each iteration adds more
functionality until the full design is realized. The lessons learned during
each incremental stage of development are applied to refining the design.
Learning comes from the development process and from experience using the
incomplete system, where possible.
This approach, of building corrections, design
changes, and discoveries into the process, more accurately reflects how most
commercial software is developed.
Designers miss requirements and make mistakes.
Customers often have only a vague idea of what they require. Developers
frequently find that initial designs do not adequately reflect the hardware,
complexity of the problem, or needs of the users. By making allowance for
modifications, iterative processes build flexibility and responsiveness into
the process.
The Spiral Model
Barry Boehm first proposed the spiral model in
1988. Although the iterative model was
used well before this, Boehm was the first to explain why iteration is important to producing software that meets
customer expectations. Development proceeds through the stages: requirements,
design, implementation, and testing.
When testing at the end of a cycle is completed,
the next step is the planning phase of a new cycle that adds additional
features and components. Each cycle of the spiral involves stepping through all
the phases. The spiral model tries to combine the advantages of the top-down
and bottom-up approaches and is often used in larger projects.
No comments:
Post a Comment