See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/313768860

The Waterfall Model and the Agile Methodologies : A comparison by project

characteristics - short

Working Paper · February 2017

DOI: 10.13140/RG.2.2.10021.50403

CITATIONS READS

2 16,785

1 author:

Wilfred Van Casteren

Open Universiteit Nederland
12 PUBLICATIONS   3 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Paper on software development methods View project

OU Bachelor afstudeerproject View project

All content following this page was uploaded by Wilfred Van Casteren on 07 March 2017.

The user has requested enhancement of the downloaded file.

 The Waterfall Model and Agile Methodologies :
A comparison by project characteristics
Wilfred van Casteren

Academic Competences in the Bachelor 2 System Requirements

assignment: Write a scientific article on 2 Software

Software Requirements
Development Models
March 7, 2017 Analysis
Abstract—Software development projects have long been plan-
driven processes, but the coming of age of Agile Methodologies Program Design
has given rise to a more adaptive approach to software/system
development. The purpose of this paper is to give a short
presentation of two Software Development Models (SDMs), The Coding
Waterfall Model and the Agile Methodologies (AM), and offer for
both SDMs issues and typical project characteristics.
Testing
Keywords: Software/System Development Model (SDM), Waterfall
Methodology, Agile Methodologies, plan-driven approach, adaptive
Operations
approach, comparison of SDMs, software engineering history,
archetypal projects, project characteristics
Fig. 1: The Waterfall Model
I. I NTRODUCTION
This paper will elaborate on a general idea on software System Requirements
development in the form of the Waterfall Model, and on its
issues. It will also introduce the Agile Methodologies as a Software Requirements
natural counterpart for the Waterfall Model, and the issues
related to this family of SDMs. The Waterfall Model adheres
Analysis
to a plan-driven approach while Agility pursues an adaptive
approach. Furthermore, this paper will offer a limited insight in
the aspects determining a project’s suitability for an Agile or a Program Design
Waterfall approach.
Coding
In Section II, a short explanation for the Waterfall Model
as an SDM, a history of its inception and some related issues will
Testing
be given. Section III on the Agile Methodologies will offer an
overview of Agile characteristics, practices and issues. Section IV
will offer an insight in typical characteristics for Waterfall and Operations

Agile projects. Section V adds references to articles on varying

Agile and plan-driven methodologies. Section VI outlines the
merits of this paper, by resuming the projects eligible for an
Agile or Waterfall approach.
II. T HE WATERFALL M ODEL
Based on experiences in developing software for spacecraft
missions, Royce [10] describes the fundamentals of
software/system development. In an intermediate phase of
his elaboration Royce presents a sequence of phases which form
a software development sequence, illustrated by Figure 1 and
designated as the Waterfall Model.
Concerning this Waterfall Model, Unhelkar [12] emphasizes
the sequential dependability on the previous deliverable. A
dependability which holds back system design when the analysis
model is still to be signed off, and holds back coding if the
design is still to be signed off. A next step in Royce’s disquisition
Fig. 2: The Waterfall Model: iterative relationship between
successive phases
covered the iterative relationship between successive development
phases. Figure 2 depicts this step in his elaboration. Royce [10]
believes that as each development step progresses, and the design
is further detailed, there is an iteration with the preceding and
succeeding steps, but rarely with the more remote steps. Thus, at
any point in the design process after the requirements analysis
is completed there exists a firm and closeup moving baseline
to which to return in the event of unforeseen design difficulties
[10].
A. Waterfall Issues
Ganis [6] has the opinion the Waterfall Model predominately
emphasizes on the freezing of requirement specifications or the

1
high-level design very early in the development life-cycle. So the
Waterfall model is likely to be unsuitable if requirements are not
well understood/defined or are likely to change in the course of
the project. Petersen et al. [9] associate the Waterfall Model with
high costs and efforts. The number of documents to be approved in
every phase, the difficulty to make changes, the difficulty iterations
take to initiate and achieve and problems that arise only in later
phases confirms this belief. Consequences of these issues have
been that the customers’ current needs are not addressed, resulting
in implemented but unused features.
III. AGILE M ETHODOLOGIES : P RINCIPLES AND PRACTICE
A. Agile principles
According to Cohen et al. [4], all Agile Methodologies share
common characteristics, a focus on interaction, communication,
and the reduction of resource-intensive intermediate artifacts.
Furthermore, Agile approaches combine short iterative cycles
with feature planning and dynamic prioritization, Highsmith and
Cockburn [7] state. Agility requires face-to-face communication,
which in turn implies working in close location, facilitating teams
to make decisions and act on them immediately rather than wait
on correspondence, Cohen et al. [4] add. Agile development also
requires close customer partnerships, Highsmith and Cockburn [7]
state.
B. Agile iterations
Williams [14] explains that each iteration in an iterative product,
is a self-contained, mini-project with activities that span require-
ments analysis, design, implementation, and test leading to an
internal or external iteration release. The customer adaptively
specifies his or her requirements for the next release based on the
observation of the current release [14]. The predetermined itera-
tion length, between one and four weeks, used when developing
Agile serves as a time-box for the team. Thus scope is chosen for
each iteration to fill the iteration length [14].
C. Agile: facilitating tools and techniques
Model Driven Architecture, where models are the central
artifacts, speed up development through automated generation
Fig. 3: Scrum: a schematic overview
2
of significant portions of application and middle-ware code, is
a tool facilitating Agile development, Turk et al. [11] affirm.
Furthermore, integrated development environments, systematic
improvement of code through refactoring and automated test suites
can help manage the cost of detecting and removing errors even
late in an Agile process [11]. Version control and change tracking,
very important in an iterative environment, can now be found
in the toolbox of any active programmer, add Beznosov and
Kruchten [1].
D. An Agile Methodology example: Scrum
For a schematic overview of Scrum refer to Figure 3. The
main Scrum techniques are the product backlog, sprints, and daily
scrums (a scrum is daily team meeting of 15 minutes), Paetsch
et al. [8] state. The product backlog plays a special role in Scrum
as all prioritized requirements, enhancements and bugs for the
product are listed in the product backlog [8]. The sprint is a 30
day development iteration [8]. For each sprint, the highest priority
tasks from the backlog are moved to the sprint backlog [8]. At the
end of a sprint, a sprint review meeting is held that demonstrates
the new functionality to the customer and solicits feedback [8].
E. Agile Issues
Concerning architectural design, not a key value in Agility,
flaws or errors that seriously compromise the integrity of the
design are more costly to correct when detected late in the
development process, Turk et al. [11] state. The focus on tacit
knowledge makes projects that use agile processes dependent on
experts [11]. Besides, the informal evaluation techniques of agile
processes may not be sufficient for establishing the quality of
safety-critical systems [11].
IV. AGILE M ETHODOLOGIES AND THE WATERFALL M ODEL :
A COMPARISON BY PROJECT CHARACTERISTICS
A. Archetypal projects
Agile approaches to software development are most conducive
in these projects wherein coding is at the center of activities
[12]. Typically, a small project comprising five programmers and
lasting for a period of about 6 months would be ideally placed
to make extensive use of Agile principles and practices [12]. An
experimental or pilot project in the small category is also likely
to benefit with Agility [12]. According to Petersen et al. [9], the
Waterfall Model is predictable and pays attention to planning the
architecture and structure of the software system in detail which
is especially important when dealing with large systems.
B. Agile and Waterfall project characteristics
The following aspects are decisive for a project’s development
approach.
2) Size: Waterfall methods scale better to large projects than
Agile methods do. Though a plan-driven bureaucratic organization
that requires an average of a person-month just to get a project
authorized and started won’t be very efficient on small projects
[2].
3) Customer relations: Agile methods work best when cus-
tomers operate in dedicated mode with the development team,
and when their tacit knowledge is sufficient for the full span of
the application [2]. This method risks tacit knowledge shortfalls,
which the Waterfall methods reduce via documentation and the
use of architecture review boards and independent expert project
reviews [2].
4) Planning and control: Project management requires careful
planning, estimation, coordination, tracking, and control. Aspects
formally covered in the Waterfall Model [12]. Agility places
more value on the planning process itself than on the resulting
documentation [2].
5) Communications: Agility advocates face-to-face communi-
cation, while the Waterfall Model requires explicitly documented
knowledge.
6) Requirements: Formal and solution-independent, up-front
requirements engineering is not directly used by pure Agile
practitioners [12]. The heavyweight, formal Waterfall Model will
encounter problems keeping up with rapidly changing require-
ments [2] unless the architecture anticipates and accommodates
requirement changes [2].
7) Development: Agility values working software over com-
prehensive documentation, and emphasizes simplicity, maximiz-
ing the amount of work not done [5]. This while the Waterfall
Model relies heavily upon software architecture, as it is part of
the development sequence, see [10].
8) Test: Conventional assurance methods are much more
adapted to Waterfall development, which is well-documented and
focused on architecture [1]. Agile Methodologies facilitate internal
design and code review, and motivate developers to adopt coding
standards [1].
9) Customers: Agility requires dedicated, co-located, knowl-
edgeable customers [2]. The Waterfall Model requires, adequately
skilled and knowledgeable customers [2].
10) Developers: Developers in an Agile project are to be
agile, knowledgeable, collocated, and collaborative and should
be amicable, talented, skillful and communicative [2]. Waterfall
developers are to be plan-oriented, adequately skilled with access
to external knowledge [2].
11) Culture: Agile methods will succeed better in a culture
that “thrives on chaos” than in one that “thrives on order,” while
the opposite is true for the Waterfall Model [3].
View publication stats
1) Primary goals: Boehm [2] states a major set of objectives
for the more traditional Waterfall methods, has been predictability,
repeatability, and optimization. This while Agility focuses on
rapid value and responding to change [5].
V. R ELATED WORK
In her surveys Williams [13, 14] introduces some prominent
plan-driven and Agile SDMs.
VI. C ONCLUSION
In this paper two SDMs were introduced, a plan-driven Water-
fall Model and the Agile Methodologies. Both models have their
uses, advantages and disadvantages. Small projects are almost
always suitable for an Agile approach and almost never for a
Waterfall approach. A big and complex project with multiple
teams working simultaneously on different parts of the application
is almost always a Waterfall project.
R EFERENCES
[1] Konstantin Beznosov and Philippe Kruchten. Towards agile
security assurance. In Proceedings of the 2004 workshop on
New security paradigms, pages 47–54. ACM, 2004.
[2] Barry Boehm. Get ready for agile methods, with care.
Computer, 35(1):64–69, 2002.
[3] Barry Boehm and Richard Turner. Using risk to balance agile
and plan-driven methods. IEE Computer Science, 2003.
[4] David Cohen, Mikael Lindvall, and Patricia Costa. Agile
software development. DACS SOAR Report, 11, 2003.
[5] Martin Fowler and Jim Highsmith. The agile manifesto.
Software Development, 9(8):28–35, 2001.
[6] Matt Ganis. Agile methods: Fact or fiction, 2010.
[7] Jim Highsmith and Alistair Cockburn. Agile software
development: The business of innovation. Computer, 34(9):
120–127, 2001.
[8] Frauke Paetsch, Armin Eberlein, and Frank Maurer. Re-
quirements engineering and agile software development. In
WETICE, volume 3, page 308, 2003.
[9] Kai Petersen, Claes Wohlin, and Dejan Baca. The waterfall
model in large-scale development. In International Con-
ference on Product-Focused Software Process Improvement,
pages 386–400. Springer, 2009.
[10] Winston W Royce. Managing the development of large soft-
ware systems. In proceedings of IEEE WESCON, number 8,
pages 328–338. Los Angeles, 1970.
[11] Dan Turk, Robert France, and Bernhard Rumpe. As-
sumptions underlying agile software development processes.
arXiv preprint arXiv:1409.6610, 2014.
[12] Bhuvan Unhelkar. The Art of Agile Practice: A Composite
Approach for Projects and Organizations. CRC Press, 2016.
[13] Laurie Williams. A survey of plan-driven development
methodologies, 2004.
[14] Laurie Williams. A survey of agile development methodolo-
gies, 2007.