Comparative Analysis: Waterfall Model Problems and Extreme Programming

This report provides a comparative analysis of the Waterfall model and Extreme Programming (XP), two prominent software development methodologies. The first part of the report outlines the problems associated with the Waterfall model, including its sequential nature, inflexibility to requirement ...Read More

Task 1: Waterfall Model
1. List the problems associated with waterfall model
Waterfall model is considered to be a very basic software development approach
which was used over the decade. With the passage of time when development
continue to increase on a very large-scale people use to find this model difficult to
adopt for every project. Here are some problems which are associated with this
model.
I. Linear or sequential process:
In water fall model processes are linear which mean they use to be
performed in a sequence. And those all the process doesn’t allows to revisit
any phase. There is no chance to repeat any phase during the project. Once a
project is complete it will be evaluated after completion and if changes are
required the whole model will be repeated from requirement phase to
maintenance phase.
II. Do not support requirement changes:
As already explained that processes are linear thus if there is any change in
requirement during any phase of the project this model doesn’t entertain
those changes. As it is very difficult in large projects to define all clearly state
all the requirements at once, there is always change in requirements which
this model doesn’t supports.
III. Every phase needs to complete previous phase:
All the phases of this model need the previous phase to be completed to
continue to move towards the next phase. Which means there is delay and

wait time before and after every phase. Also, this is a big drawback as
different teams were assigned different task designers to design the product,
developers to code the programs so those teams may be wasting their time
while waiting for a phase to complete by other teams.
IV. Difficult to measure progress:
In this model is it always difficult to measure progress. Every team is focused
to complete their assigned work but there is difficulty to measure overall
progress of the project which is one the big drawback of this model.
V. Difficult to estimate risk and problems:
Risk and problems ae very important to measure for any type of project
whether it’s a small or big project. Unless there is iteration and feedback but
it is really difficult to accommodate the imperfection of early stages in one of
the later phases.
2. Why do organizations continue to use the waterfall model?
Where every model has some problems, they also have some good point or advantages
so organization still prefer to choose this model. Many organizations are still using the
waterfall model on and off for their projects. Following are some advantages which are
supporting the waterfall model adaption for developing software.
I. Easy to understand:
This is sequential and hierarchal model thus easy to understand for people within the
team and outside the team like clients. It provides a complete life cycle for controlling
and organizing software development projects.
II. Focus on goal:
Every team whether they are part of development team or part of design team, every
person has a common goal to complete this project. They share common goal and stay
stick on one point to complete their work in assigned time frame.
III. Coordination between teams:
This development model allows departmentalization and managerial controls. They
focus to coordinate with each team and provide a specific time frame to each of them to
complete their work on time. In this model team’s coordination is easy when a design
team finish their work and complete design phase, they handover all the material to
development team to start coding the design.
Task 2: Alternative Models
Extreme Programming
1. Who is primarily responsible for introducing the model and when was it introduced?
Extreme programming was introduced in March 6, 1996 by Kent Beck.

2. Draw and explain the main stages/features of the model in brief.
Extreme programming uses object-oriented approach and it encompasses a set of rules and
practices that comes within the context of four framework activities: planning, design, code
and testing.
Planning: The planning activity begins with listening, a requirement gathering activity that
enable the team members to understand the business context for the software and to
understand the output and major features and functionalities. The process leads to the
creation of set of stories that describe the output features and functionalities. Each story is
written by the customer and a value is assigned to story based on business value. XP team
members assess each story and assign cost and schedule for the story.
Design: XP design follows KIS (keep it simple) principle. Here CRC (class responsibility
collaborator) cards are used. The CRC cards identify and organize the object-oriented classes
that are relevant to the current software increment. If a difficult design problem is
encountered, XP commends the immediate creation of an operational prototype of that
portion of that design which is called a spike solution.
Coding: After story cards and preliminary design work is done, the team does not move
towards the code or development. But rather they develop a series of unit test that is
according to the stories in the current release. Once the unit test is completed the
developers would better be able to focus on what must be implemented to pass the test. A
concept of pair programming is used in XP which recommends that two people work
together at one computer work station to create code for a story as it is said that “two
heads are often better than one”.
Testing: As already noted that creation of unit tests before coding commence is the key
element of XP approach. The unit tests that are created should be implemented using a
framework. As unit tests are organized into a “universal testing suite” integration and

validation testing occurs on daily basis so the warning flags can raise early if things go
wrong.
3. What is the difference between the two models (referring to the Waterfall model
above)?
Waterfall is another name for the traditional approach to software development. Before
the Agile method was invented, all the projects were managed in Waterfall style. This
good old methodology is sequential. Its projects have a number of stages (usually no less
than five) they have to pass before delivering to the customer. The testing in Waterfall is
conducted only at the final stages of work. That is why it is sometimes hard to fix the
bugs that occurred at the early stages of project’s realization with the means of this
methodology. Extreme Programming has lots of features that distinguish it from the
Waterfall approach.
4. Is the model Agile or not? Explain.
it is one of the Agile approaches to software development. Agile originated at the beginning
of 2000’s as a methodology aimed at improving the efficiency of software development
process.
5. Which of the problems of the Waterfall model does it attempt to solve?
Extreme programming model address and solve the requirement change problem of
waterfall model. This model involves the customer and customer or product owner prepare
and priorities the story cards which are further implemented, designed and tested by the XP
team.
XP model also don’t wait for another task to be completed, each piece of software is created
parallel and no team waits for the other to complete their work. Each team works on the
assigned piece of software thus they work parallel and generate outputs quickly.
6. Are there any disadvantages to this model?
Not only the XP, where a model has advantages it also has some disadvantages side by side.
We will address some of the issue associated with the extreme programming model.
Requirement volatility: As customer is an active member is XP team, change to the
requirement is requested informally. As the scope of the project changes the earlier work
also needs to be changes.
Requirements are expressed informally: There is always an argument by the critics that a
more formal model is needed to ensure that omissions, inconsistencies, and error are
uncovered before system is built. Change in requirements make the model and specification
obsolete almost as soon as they are developed.

Lack of formal design: There is also an argument that complex system are built; design must
be emphasized to ensure that the overall structure of the software will exhibit quality and
maintainability.
Reference:
https://www.jois.eu/files/21_557_Dima.pdf
7th edition software engineering a practitioners approach by roger s. pressman