Extreme Programming and Waterfall Modelling Software Processes: A Comparative Study

ABSTRACT

The purpose of writing this paper is to compare Extreme Programming and Waterfall Modelling software processes.

The Software Development Life Cycle (SDLC) describes the processes by which a piece of computer software goes from conception to delivery and beyond. There are many process models detailing the steps in an SDLC, each with different strengths and weaknesses. Models are useful for explaining, evaluating and exploring the different processes which teams use to move through the SDLC.

Extreme Programming (XP) is very different from Waterfall. XP itself is a collection of practices for Software Development, some of which create a development process comparable to Waterfall. It also contains values and best-practices to aid in the SDLC. At its core it is a multi-iterative approach with a focus on what the customer wants [1].

Keywords

compare, sdlc, xp, processes.

1. INTRODUCTION

The waterfall model was created in 1970 as an example of a software development methodology that does not work [2].

The founding document of the waterfall model, created by Winston W. Royce, included two figures: one of the model itself and a second illustrating the major problems inherent in the model, or the reasons not to use the waterfall model. It might seem a strange thing, then, that the waterfall model became one of the most popular programming methodologies after its publication and remained such for years. Even today, according to some surveys, the waterfall model is being used by a large portion of the software engineering world [3].

Why would so many software companies still be employing the waterfall model for developing software, especially since agile systems, such as XP and Scrum, have been the “hot topic” of the software engineering community for years? There are numerous reasons why, but the most important is a natural resistance to changing a tradition and the complications surrounding that issue.

In software engineering, new methodologies are generally advertised as carrying generous improvements in time to release, efficiency, and number of faults per release. But the very word improvements implies that there must be some established system or body of results against which to

compare the new methodology’s claims.

Many times, the compared system of software development is the waterfall model, and the improvements are measured against the existing advantages and disadvantages of that model. Thus, when proposing a system that is, for instance, “more efficient” and produces fewer errors per line of code, one must append “than the waterfall model” or something even more generic, such as “than the previously used method of