From amongst numerous questions eventually arising in every project, one issue is outstanding: what is the best way to manage the product development process? What particularly comes to mind is Waterfall — one of the options proven over the years (or a cascade waterfall model to manage software development).
As a matter of fact, this methodology is being severely criticized now, but is it really so bad, or once again we will figure out that history repeats itself?
Life cycle of software development
Each and every team of developers can either create its own software life cycle model or use something which is generally acknowledged. One of the options is Waterfall. An American V.U.Royce is considered to have founded this model. He was rumored to have borrowed many things from his colleagues by taking credit for their work. It took place in 1970. Up to this day, the method presented by Royce is used in many projects either in its original version or modified.
However some IT insiders claim that such methodology has never existed:
«As an IT professional and teacher, for more than 40 years have I heard many myths about the IT industry. But what keeps me surprised is the reason why the word „Waterfall“ is still used to describe a non-existing methodology, and why creators of development methods and systems use it as an object for comparison.»
David Dischave, Professor of the School of Information Studies, Syracuse University, USA
It is weird to hear such thing about the methodology which has been used for decades in software development for various activities, such as the automotive industry, construction of buildings and structures, finance&accounting, medicine and electronics.
Waterfall in IT
The main fundamental principle of the Waterfall model for software development is that every subsequent step cannot be started unless the previous one is completed. At the same time, no arbitrary moves forward or backward are allowed, and phases should not overlap. This is the basic thing that distinguishes the cascade methodology from amongst its agile peers (or rivals), such as Agile, DSDM, Scrum or FDD.
Action Algorithm in Waterfall
To understand Royce’s ideas underlying the model you may study his original work:
Royce,Winston (1970), Managing the Development of Large Software Systems.
Conceiving and discussing an idea
This phase does not include development basically. Just a certain new idea interesting for one or more persons is considered.
This phase includes the most detailed specification of the customer’s requirements for the project. Ways to reach the goal are determined; deadlines for operations are outlined along with the financial aspect. At the same time, a certain time and money reserve is spared for each work unit. When the analysis of requirements is completed, a technical assignment for programmers and a budget are ready.
This phase includes definite steps:
- selecting a programming platform (Python, PHP, JS etc.)
- clarifying technical details (e.g. interaction between the service or product with servers, whether or not to use API, logic of the external and internal interfaces etc.)
- solving project security issues (e.g. whether or not to use HTTPS, SSL encryption etc.)
- outlining the roles of software users (administrator, client, manager etc.)
- finalizing the issues of reliability, efficiency and further technical support of the target product.
- forming a designated team.
This phase encompasses writing a code conforming to the documents previously drawn up.
Specialists test the final version of the product under conditions close to reality by recording bugs in it. The most critical ones for general software operation are fixed, less significant ones may remain without fixing if the time is expired or if the budget is spent.
Technical support of software
The resulting serviceable software product comes into use according to its intended purpose with support provided. That means making sure the product is serviceable, fixing failures, planning functionality upgrades based on users’ feedback.
All the above phases are implemented in a strict sequential order, and their results are recorded.
To understand the evolution of the classic Waterfall methodology described above, you may study the Project Management Body of Knowledge. The 3rd and 4th versions have a number of discrepancies which will help to understand the «cascade» path.
Advantages and disadvantages of the cascade model of software development
Unfortunately, nothing is perfect in our world, thus the cascade methodology also has both strong and weak points.
|Strong points of the cascade model of software development
||Weak points of the cascade model of softwaredevelopment
- every step of work is ultimately detailed, its progress is recorded
- time-consuming maintenance of detailed documents which, moreover, may not always be understandable for the customer thus giving rise to questioning
- requirements are set out explicitly and
clearly to the ultimate extent, they cannot
contradict each other or get modified
during the workflow
- necessity for qualified business analysts
capable of defining a Technical Assignment
feasible for efficient work
- no room for maneuver if during the
development process the product appears to
fail to meet the market demands
- it is possible to know in advance how
much time and money will be spent on
- time and money consumption is rather
- the methodology itself is easily
understandable even for developers with
- critical problems are much likely to be
detected in the final development phase; and
fixing such problems is an extremely
expensive process at the end product stage.
- simplicity of monitoring and transfer of
a project to another team if necessary due
to a strict accountability system.
How to use the cascade development model and in what cases?
According to the practice, the Waterfall model of software development is quite relevant in the following cases:
- the customer participates in the project only in the first phase, and afterwards he accepts the end product;
- requirements for the product are not subject to change;
- the project is highly complicated, long-term and expensive;
- quality is the main priority, even to the detriment of time;
- lack of a team comprising extra-class developers;
- it is possible to outsource specialists for project implementation.
To understand possible motives for abandoning the cascade methodology, you may read the
book Scrum. The Revolutionary Method of Project Management by Jeff Sutherland.
Examples of Waterfall in use
The pure cascade model is not so much widespread in modern development, and very often
what cannot be classified as Agile is named Waterfall, thus it is quite difficult to determine where this very methodology is used.
According to experts, a significant part of ERP systems and programs designed for construction, medicine, operations under governmental contracts, industrial use or for similar fundamental applications, are developed by using a certainly modified Waterfall version.
Specific features of handling such projects are better understood with the book «Pattern-based Development of Enterprise Systems» by Sergey Zykov.
And it is logically justified. This was also described by Chuck Cobb, a mentor, trainer and the author of books dedicated to Agile methods in project management.
If you are building a bridge across a river, it would be funny to say: «We will build the first superstructure, then we will see the outcome, and then we will decide whether or not to complete the rest of its superstructures!»
From amongst the companies where Waterfall is or was used, the following ones may be noted:
||Whether or not
is used now
||Comment by the company’s
system for the
parts of them
||Aleksey Ionov: «...it is not
necessary to make a whole
large project by Agile —
flexible development may be
used within certain phases or
parts of them
||Rosalind Radcliffe: «It’s now
the time when development
teams handling Waterfall are
unable to fulfill the business
requirements, so such projects
and products receive more
maintenance works ...
Waterfall will be gradually
replaced by new technologies
and new teams engaged in
introducing new business —
parts of them
||«Over the last few years... all
our teams have acquired
flexible methodologies. We
have discovered that they have
solved many problems stemming from the traditional
Waterfall model where projects
are planned in advance and
may last for months or even
years. Within this model, a
product may turn out to be outof-date once released by us».
parts of them
||Vasiliy Korablev: «To develop
systems „from scratch“, we use
either flexible (Agile) or
development approach, or both
of them combined.»
parts of them
||Nikolay Dobrovolskiy: «In
different projects we use
different approaches — in
some cases Agile with one-or
two-week sprints, in other
cases — quasi-Waterfall with
milestones which may take
several months. Over many
years, we have shaped an idea
that the larger is a project or a
team working on it, the more
complex and the less efficient
it is to try to stuff development
into an agile process».
parts of them
||Evgeniy Arnautov: «At the
stage of product creation, we
may often see Agile variants,
and sometimes they are
combined with the Waterfall
parts of them
||Satoshi Ishii: "...we are trying
to learn how to apply TPS
(Lean in the West) to software
Applications and programs to manage development based on the Cascade Model
To handle Waterfall, you may use a range of products facilitating time tracking and capable of making up Gantt charts.
It is an attractive Ukrainian saas service offering a convenient mobile version.
It is suitable for careful scheduling due to the following features available:
- Gantt diagram with links between tasks and deadlines
- distribution of duties among executives with different authorities
- system of diversified reporting forms
- saving comments, emojis and all history of activities within the project
- limited access of the customer/client for transparency of the development process
- possibility to indicate budgets and expenses
- checklists for small phases of tasks to facilitate execution exactly as instructed.
Waterfall is a methodology used for quite a long time, and whatever criticizers say, it is efficient
in numerous cases.
At the same time, this approach is irrelevant in pure form for many projects requiring prompt responding to volatile market demands. Based on what is said by representatives of largely diversified companies, we may conclude that Waterfall deserves a role in contemporary projects. But using Waterfall is justified where requirements are constant and will definitely remain the same by the project deadline.