GEC 215 APPLIED COMPUTER PROGRAMMING I

SOFTWARE DEVELOPMENT MODELS

Software model is an abstract representation of the software processes. It
determines the order of the stages involved in software development and the
transitional criteria for progressing from one stage to another. The models
discussed include: waterfall, incremental, v-shaped, spiral and prototype.
WATERFALL MODEL
This is the most common and classic of the life cycle models. It is a widely
accepted software development model. It is also referred to as a linearsequential software model. This is because of the sequential pattern that is
followed by the model. It is very simple to understand and use. In a waterfall
model, each phase must be completed in its entirety before the next phase
can begin. At the end of each phase, a review takes place to determine if
the project is on the right path before it can proceed to the next phase.
Unlike the general model, phases do not overlap in a waterfall model.
Waterfall Life Cycle

Advantages

Simple and easy to use.

It provides structure to inexperienced staffs.

Phases are processed and completed one at a time.

Page 1 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

Easy to manage due to the rigidity of the model each phase has specific
deliverables and a review process.

Works well for smaller projects where requirements are very well understood.

It works well when quality is more important than cost or schedule

Disadvantages

Adjusting scope during the life cycle can kill a project

No working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Deliverables produced at the end of each stage is considered rigid.

It can give a false impression of progress.

Poor model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Poor model where requirements are at a moderate to high risk of changing.

It is a model that can be used when any of the following condition is true:
When the requirements are well known.
The definition of the product is stable
Technology is understood
Designing a new version of an existing product.

SPIRAL MODEL
This model is one of the models created to make up for the deficiencies identified in
waterfall model. This model incorporated the common methodologies followed in
"The Waterfall Model", but it also eliminated almost every possible/known risk
factors from it. This model is referred as "The Spiral Model" or "Boehms Model".
There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk
Analysis and Engineering. These four phases are iteratively followed one after other
in order to eliminate all the problems, which were faced in "The Waterfall Model".
Iterating the phases helps in understating the problems associated with a phase and
dealing with those problems when the same phase is repeated next time, planning
and developing strategies to be followed while iterating through the phases. The
phases in "Spiral Model" are:
Page 2 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

Plan: In this phase, the objectives, alternatives and constraints of the project are
determined and are documented. The objectives and other specifications are
fixed in order to decide which strategies/approaches to follow during the project
life cycle.
Risk Analysis: This phase is the most important part of "Spiral Model". In this
phase all possible and available alternatives, which can help in developing a cost
effective project are analyzed and strategies are decided to use them. This
phase has been added specially in order to identify and resolve all the possible
risks in the project development. If risks indicate any kind of uncertainty in
requirements, prototyping may be used to proceed with the available data and
find out possible solution in order to deal with the potential changes in the
requirements.

Engineering: In this phase, the actual development of the project is carried out.
The output of this phase is passed through all the phases iteratively in order to
obtain
improvements
in
the
same.
Page 3 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

Customer Evaluation: In this phase, developed product is passed on to the

customer in order to receive customers comments and suggestions which can
help in identifying and resolving potential problems/errors in the software
developed. This phase is very much similar to TESTING phase.

The process progresses in spiral sense to indicate iterative path followed,

progressively more complete software is built as we go on iterating through all four
phases. The first iteration in this model is considered to be most important, as in the
first iteration almost all possible risk factors, constraints, requirements are identified
and in the next iterations all known strategies are used to bring up a complete
software system. The radical dimensions indicate evolution of the product towards a
complete
system.
However, as every system has its own pros and cons, "The Spiral Model" does have
its pros and cons too. As this model is developed to overcome the disadvantages of
the "Waterfall Model", to follow "Spiral Model", highly skilled people in the area of
planning, risk analysis and mitigation, development, customer relation etc. are
required. This along with the fact that the process needs to be iterated more than
once demands more time and is somehow expensive task.

Advantages

High amount of risk analysis

Cumulative costs accessed frequently.

Good for large and mission critical projects

Early and frequent feedbacks from the users

Software is produced early in the software life cycle because of the rapid
prototyping tools.

Disadvantages

Can be a costly model to use

Risk analysis requires highly skilled experts

Projects success is highly dependent on the risk analysis phase

Doesnt work well for smaller projects because of the time and expertise
required for risk evaluation.

It requires a longer time than some other models because of its iterative
nature.
Page 4 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

V SHAPED MODEL
Just like the waterfall model, the V-Shaped life cycle is a sequential pattern of
execution of processes. Each phase must be completed before the next phase
begins. It is slightly different in the sense that it emphasizes on verification and
validation of the requirements and developments respectively. The testing
procedures are developed early in the life cycle before any coding is done, during
each of the phases preceding implementation.
The V-Shape of the model divides the stages involved into two general phases:
verification and validation phases. The verification phase comprises of the
requirement, high level design and low level design phases. The validation phase is
comprises of the unit testing, integration testing and the system testing. The
verification phase verifies the requirements along with reviews and processes while
the validation phase validates the different developments through the different
testing phases.
Requirements begin the life cycle model just like the waterfall model. Before
development is started, a system test plan is created. The test plan focuses on
meeting the functionality specified in the requirements gathering.
The high-level design phase focuses on system architecture and design. An
integration test plan is created in this phase as well in order to test the pieces of the
software systems ability to work together.
The low-level design phase is where the algorithm for each architectural
components are designed, and unit tests are created in this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test
plans developed earlier are now put to use.

Page 5 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

Advantages

Simple and easy to use.

Each phase has specific deliverables.

Higher chance of success over the waterfall model due to the development of
test plans early on during the life cycle.

Works well for small projects where requirements are easily understood.

Disadvantages

Very rigid, like the waterfall model.

Little flexibility and adjusting scope is difficult and expensive.

Software is developed during the implementation phase, so no early

prototypes of the software are produced.

Model doesnt provide a clear path for problems found during testing phases.

INCREMENTAL MODEL
The incremental model is an intuitive approach to the waterfall model.
Multiple development cycles take place here, making the life cycle a multiwaterfall cycle. Cycles are divided up into smaller, more easily managed
iterations. Each iteration passes through the requirements, design,
implementation and testing phases.
A partial implementation of the total software is done, and then increased
functionalities are added slowly that is, a working version of software is
produced during the first iteration, so you have working software early on
Page 6 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

during the software life cycle. Subsequent iterations build on the initial
software produced during the first iteration.
Incremental Life Cycle Model

Advantages

Generates working software quickly and early during the software life cycle.
More flexible less costly to change scope and requirements.

Easier to test and debug during a smaller iteration.

Easier to manage risk because risky pieces are identified and handled during
its iteration.

Each release delivers an operational product.

Page 7 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

Risk of changing requirements is reduced.

Disadvantages

Each phase of an iteration is rigid and do not overlap each other.

It requires good planning and design.

Problems may arise pertaining to system architecture because not all

requirements are gathered up front for the entire software life cycle.

PROTOTYPING MODEL
It begins with requirements gathering. Developer and Customers meet and define
the overall objectives of the software, identify whatever requirements are known
and identify the areas which require further definition. In many instances the client
only has a general view of what is expected from the software product. In such a
scenario where there is an absence of detailed information regarding the input to
the system, the processing needs and the output requirements, the prototyping
model may be employed. This model reflects an attempt to increase the flexibility of
the development process by allowing the client to interact and experiment with a
working representation of the product.
Advantages of Prototyping
There are many advantages to using prototyping in software development, some
tangible and some abstract.

Reduced time and costs: Prototyping can improve the quality of requirements
and specifications provided to developers. Because changes cost exponentially
more to implement as they are detected later in development, the early
determination of what the user really wants can result in faster and less
expensive software.
Improved and increased user involvement: Prototyping requires user
involvement and allows them to see and interact with a prototype allowing them
to provide better and more complete feedback and specifications. The presence
of the prototype being examined by the user prevents many misunderstandings
and miscommunications that occur when each side believe the other
understands what they said. Since users know the problem domain better than
anyone on the development team does, increased interaction can result in final
product that has greater tangible and intangible quality. The final product is
more likely to satisfy the users desire for look, feel and performance.

Disadvantages of Prototyping
Using, or perhaps misusing, prototyping can also have disadvantages.
Page 8 of 9

GEC 215 APPLIED COMPUTER PROGRAMMING I

Insufficient analysis: The focus on a limited prototype can distract developers

from properly analyzing the complete project. This can lead to overlooking better
solutions, preparation of incomplete specifications or the conversion of limited
prototypes into poorly engineered final projects that are hard to maintain.
Further, since a prototype is limited in functionality it may not scale well if the
prototype is used as the basis of a final deliverable, which may not be noticed if
developers are too focused on building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think
that a prototype, intended to be thrown away, is actually a final system that
merely needs to be finished or polished. (They are, for example, often unaware
of the effort needed to add error-checking and security features which a
prototype may not have.) This can lead them to expect the prototype to
accurately model the performance of the final system when this is not the intent
of the developers. Users can also become attached to features that were
included in a prototype for consideration and then removed from the
specification for a final system. If users are able to require all proposed features
be included in the final system this can lead to feature creep.

Developer attachment to prototype: Developers can also become attached

to prototypes they have spent a great deal of effort producing; this can lead to
problems like attempting to convert a limited prototype into a final system when
it does not have an appropriate underlying architecture. (This may suggest that
throwaway prototyping, rather than evolutionary prototyping, should be used.)

Excessive development time of the prototype: A key property to

prototyping is the fact that it is supposed to be done quickly. If the developers
lose sight of this fact, they very well may try to develop a prototype that is too
complex. When the prototype is thrown away the precisely developed
requirements that it provides may not yield a sufficient increase in productivity
to make up for the time spent developing the prototype. Users can become stuck
in debates over details of the prototype, holding up the development team and
delaying the final product.

Expense of implementing prototyping: the start up costs for building a

development team focused on prototyping may be high. Many companies have
development methodologies in place, and changing them can mean retraining,
retooling, or both. Many companies tend to just jump into the prototyping
without bothering to retrain their workers as much as they should.

A common problem with adopting prototyping technology is high expectations for

productivity with insufficient effort behind the learning curve. In addition to training
for the use of a prototyping technique, there is an often overlooked need for
developing corporate and project specific underlying structure to support the
technology. When this underlying structure is omitted, lower productivity can often
result.

Page 9 of 9