Hi, welcome to this lesson where we will look at the basics of the waterfall model.

What is the content of this lesson?

In the next few minutes we will talk about

  • the definition of technical terms that are important for understanding this lesson,
  • 2 different versions for the standard phases,
  • project phases and activities,
  • guidelines,
  • advantages and disadvantages,
  • as well as use cases and application areas for this method.

In advance, again the definition for technical terms in this lesson:

What is a requirements phase?

The requirements phase in project management describes the time period of recording requirements from the business units and IT, from which a solution is subsequently developed.

What is a requirements specification?

The requirements specification describes what the requesters want to have and is thus the result from the requirements phase.

What is a specification?

The specification is derived from the requirements of the business units and IT and describes the necessary requirements that go beyond this, which a business unit or IT cannot know without software development knowledge or special expert knowledge.

What is a system design?

The system design describes the rough interaction of the solution to be developed with other software systems and at the same time also describes the hardware and software infrastructure fundamentally required for this.

What is a system specification?

The system specification is derived from the system design and describes the details of the necessary interfaces to other software systems and the exact requirements for the hardware and software infrastructure.

What is a product model?

The software architecture describes the data model (sometimes referred to as the product model), the interaction of front-end, back-end and user interface (often referred to simply as GUI), and the structure of data storage and memory management. The structure of the data storage describes the permanent storage of data, the structure of the storage management the interaction of temporary and permanent storage.

What is a functional specification?

The functional specification is derived from the specifications and describes everything that must be done to meet the requirements from the specifications and is thus the result of the specification, the system design, the system specification and the software architecture.

What is a module test?

A module test describes the functional test of a newly developed functionality derived from a requirement “within” the development infrastructure. For this purpose, either a comprehensive installation on a sandbox on a development computer, a specially set up comprehensive development instance on a server or even a specially set up test instance on a server can be used. For the understanding it is important that the module test does not yet include the interaction with other new developments.

What is integration testing or system testing?

Integration tests or system tests only take place at a later stage on an instance set up specifically for this purpose. In this phase, new developments are collected, the requirements are checked, and if there are problems with correction specifications, they are referred back to the developers – after they have been corrected, they are checked again.

What is a UML diagram?

UML diagrams are firmly defined diagram types with firmly defined diagram elements and mandatory contents, which in their entirety should describe all features of a software. UML 2.3 knows 7 structure diagrams and 7 behavior diagrams. You can find more information about this on Wikipedia under Unified Modeling Language: https://de.wikipedia.org/wiki/Unified_Modeling_Language.

What is a structure chart?

A structure chart is a diagram that graphically illustrates the structure and interaction of software in a way that is easier to understand.

What is a top-down method?

The top-down method assumes that a solution starts with a rough description and is then deepened into more and more detail in several steps until the solution is fully developed.

What is a return of investment (ROI)?

The return of investment (often simply called ROI) describes the point in time at which an investment pays off, taking into account all positive and negative effects from the old and new solution, i.e. the savings exceed the investment. Only tangible figures can ever be processed in an ROI analysis. Non-tangible influences must be converted into tangible figures or delivered as an appendix to the ROI analysis as additional decision criteria.

What is a Gantt chart?

Now to the content of this lesson: The name waterfall derives from the graphical representation of a project in cascades, as shown in this exemplary Gantt chart:

Fig.: Gantt Chart
Where did the waterfall model originate?

Originally, this model comes from the building construction industry, then spread to other industries via complex plant construction, where subsequent changes are very expensive to practically impossible. Changes to the foundation are simply no longer possible after completion of a shell – or very expensive, because then everything would have to be torn down again, removed and rebuilt.

Which standard phases does the waterfall model describe for software development?

The waterfall model “for software development” describes the following standard phases:

  1. The requirements analysis and specification phase, which results in a requirement specification. I also mention the English terms here because we so often use the English terms in software projects. Maybe this will make you feel a little more connected to your practical experiences.
  2. The system design and specification, from which the software architecture emerges (English: System Design and Specification).
  3. The programming and module testing in which the actual software is created (English: Coding and Module Testing)
  4. The integration and system tests to ensure the functionality in the overall system (English: Integration and System Testing).
  5. The delivery, operation and maintenance of the software solution in the productive system (English: Delivery, Deployment and Maintenance).

Another commonly used alternative makes it 6 phases:

  1. The planning with preparation of the specifications, project costing and project planning (English: Systems Engineering)
  2. The definition phase with the creation of the requirements specification, the product model, the GUI model and possibly already with a basic model for the user manual (English: Analysis)
  3. The design phase with UML diagrams and structure charts (English: Design)
  4. The implementation (English: Coding or also Implementation)
  5. The testing (English: Testing)
  6. The use and maintenance (English: Maintenance)
How are project phases planned in the waterfall model?

In the waterfall model, project phases (shown here in blue in the diagram) and associated activities are planned and implemented in a linear sequence. Project phases include one or more activities. Project phases and activities can be organized sequentially as well as in parallel or overlapping. If an activity is completed late, for example, all dependent follow-up and possibly also parallel activities are automatically postponed, including the associated changes in personnel and infrastructure requirements.

Each phase and activity in the waterfall model includes a predefined start and end time with clearly defined outcome expectations. In addition, milestones are scheduled in the waterfall model. Milestones are fixed dates at which previously defined result expectations are checked and accepted by project management. Milestones are usually set at each phase end, at the end of selected activities, or at times defined outside the project, e.g., by higher-level hierarchies.

What are the guidelines of the waterfall model?

To make the waterfall model work cleanly, there are the guidelines:

  1. Activities are to be carried out “completely” in the “specified” order
  2. The waterfall model is a document-driven model. This means that at the end of each activity there is a completed document (typically in software tools such as Confluence, Sharepoint, TFS (short for Team Foundation Server), Jira or Polarion)
  3. The development process is sequential: an activity can only be started when all the necessary foundations are “completely” available, which are mostly created in the previous activities
  4. As in the top-down process, work is done from the general towards the specific
  5. The model is simple and easy to understand and overview even for outsiders
  6. In the first phase of the waterfall model, the support of the department or the customer is explicitly provided. From the second phase onwards, the department or customer is “not” provided for
What are the advantages of the waterfall model?

The advantage of this model is clearly that, if the planning is consistently updated, an always up-to-date time, personnel and resource planning is available. In addition, this model provides us with the basis for the continuous recalculation of budget, time and resource planning as well as the updating of target/actual planning for controlling until project completion. This model also gives us the flexibility to react to unplanned changes or additional as well as reduced expenses by postponing them.

What are the disadvantages of the waterfall model?

The disadvantages of this model are that there are rarely clearly defined phases in software development; the transitions tend to be fluid. Parts of the system may still be in the planning stage, while other parts are already being implemented or even in use.

There is also a sequencing problem: the individual activities run in a planned, tightly connected manner, one after the other, in parallel or overlapping. The regressions that occur in practice cannot be represented in this model.

In addition, the model is very inflexible towards requirement changes or requirement additions. Any change or addition, even a very small one, must start the entire process from scratch in the model, thus generating disproportionately high efforts and the time to implementation is therefore disproportionately high. Early specification of requirements is problematic because it therefore leads to disproportionately expensive changes that could also be solved with little effort if the requirements were adapted. In addition, requirements in today’s business environment are very short-lived. Often, requirements are already outdated by the time they are put into operation if the realization times are too high. The result is a software solution with yesterday’s requirements that always lags behind. To whom does this statement not sound familiar among software users and department heads? This is also the reason why so many users work with self-made Excel solutions instead of provided software functionality – with all the resulting problems.

Fig.: Cost of Delay

In addition, it is the case that software with this model goes into operation extremely late after the start of the development cycle and the associated return of investment is delayed so much that it may even have become negative and the “improvement project” was not worthwhile at all, only caused costs. This cannot be the goal and is a frequent point of criticism for software projects from both the business departments and the company management. In any case, this criticism cannot be dismissed out of hand. Only to solve!

What is a Big Bang?

In the waterfall model, a solution is implemented from start to finish and is ready for deployment only after all tasks are completed. This point in time is not called the “big bang” for nothing, when it becomes clear whether the solution works or, as is usual with software, it only becomes clear in real operation that there are still a large number of bugs to be fixed. In contrast to an alternating project method, the subsequent bug reports then all flood the development department at once – and, as expected, the solution is a long time coming. The worst thing, however, would be if the solution then no longer fits the requirement at all, is never used in business operations and the entire investment is thus sunk. And that, unfortunately, is not so rare …

When is a waterfall model beneficial?

Waterfall models are especially advantageous if,

  • requirements and processes can be precisely described and planned already in the planning phase,
  • the solution is composed of solution modules that do not change too much,
  • no experimental content with uncertain outcome is included,
  • the solution is to be used predictably over a long period of time even after a long implementation period,
  • the requirements do not change or expand after the requirements have been determined
  • the project has to adhere strictly to higher-level hierarchies, human resources or the finance departments, which work with fixed timelines, resource planning and budgets – or are even obliged to publish the solution to be developed and therefore have to meet investor expectations, and
  • if alternating organizational models had to repeat a complete groundwork and all solutions based on it over and over again.

In these cases, it then actually makes great sense to deal with the basics a little more intensively and, after a well-considered determination, to touch them no longer or rarely. In practice, in the area of software development, this is primarily the development of the data model and the system architecture. Because think about what would happen if after 2/3 of the project time the data model had to be completely revised and all developments based on it had to be adapted or newly developed. This does indeed happen with unclean requirements elicitation for the data model and the system architecture – and not infrequently equates to project termination due to massive budget and time overruns. A resounding slap in the face to the project organization for wasting budget and resources.

Where is the waterfall model widespread?

In practice, the waterfall model is particularly widespread in large companies, which are also known for their sluggishness. On the other hand, the corporate mentality, stakeholder satisfaction, and financially-driven decisions of large corporations require exactly this approach. I will discuss the obvious contradiction between this mentality and agile organization in more detail later.

And as I said, in this overview I only want to give a very rough and superficial description of the project management methods that we have points of contact with in everyday life, so that we know which options are available to us for which challenges.

Now let’s summarize what we have covered in this lesson:

  • we have learned a whole range of technical terms.
  • We now know 2 versions for the standard phases,
  • we know the project phases and activities,
  • guidelines,
  • advantages and disadvantages of this method,
  • as well as suitable use cases and application areas for the waterfall model.

In the lesson after next, we will cover the counterpart to the waterfall model, namely Agile Project Management. But first there is a little surprise for you: The following lesson contains a short quiz, in which you can check for yourself which contents from this lesson have stuck with you. Have fun with it, see you again in the lesson after next!

next lesson

Leave a Reply