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.
Cascade-based workflow
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.
Analyzing requirements
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.
Designing software
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.
Software development
This phase encompasses writing a code conforming to the documents previously drawn up.
Software testing
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 |
|
|
|
|
|
|
|
|
|
|
|
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:
| Company name | Purpose of using the Waterfall model | Whether or not the methodology is used now | Comment by the company’s representative |
| Wüstenrot & Württembergische (W&W) | Development of the ERP system for the financial sector | No data | — |
| Cisco | Development of safety systems | Yes | — |
| EPAM | Diverse products or solutions or parts of them | Yes | Aleksey Ionov: “…it is not necessary to make a whole large project by Agile — flexible development may be used within certain phases or workflows…” |
| IBM | Diverse products or solutions or parts of them | Yes | 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 – practices”. |
| Microsoft IT | Diverse products or solutions or parts of them | No | “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”. |
| AT Consulting | Diverse products or solutions or parts of them | Yes | Vasiliy Korablev: “To develop systems “from scratch”, we use either flexible (Agile) or cascade (Waterfall) development approach, or both of them combined.” |
| Parallels | Diverse products or solutions or parts of them | Yes | 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”. |
| SAP | Diverse products or solutions or parts of them | Yes | Evgeniy Arnautov: “At the stage of product creation, we may often see Agile variants, and sometimes they are combined with the Waterfall approach”. |
| Toyota | Diverse products or solutions or parts of them | No | Satoshi Ishii: “…we are trying to learn how to apply TPS (Lean in the West) to software development |
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.
Worksection
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.
Verdict
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.