Waterfall Methodology

What

• Way of creating software, where software was planend, built and tested in distinct phases.

• Figuring all things up front

• Built on old engineering concepts for hardware/buildings etc

Advantages

• Waterfall is superior to Agile when the requirements are already locked in and are guaranteed not to change due to clarity gained from knowing exactly how much work there is to do at the inception of the project.

Issues

• The way software was planned was fraught with many unforseen issues, which forced serious compromises in both quality and budget

• By the time the software was live,

  • it was out of date

  • Not meeting the customer needs

  • lots of bugs

• Long releases and fewer releases

  • When the consequences of their work/code is not apparant fairly quickly ie from testing/integration etc, the feed back is slow and the it doesnt register properly

    • devs start to think in terms of just creating/modifying features rather than preventing them or being able to find them, ie pass the responsibilty elsewhere.

• The further along the process an error is made, the more it costs to fix

  • bugs which often happen when all the dev work is done and in integration phase cost more to fix and leaves uncertainty when codeing

  • Changes in one area, may affect other areas and testing of the whole system needs to be redone

• In order for anything to work, everything has to work

• Issues with batching features, which waterfall proposes

  • long release cycle

  • hard to know which feature caused the issue

  • Forces code to be built that is unchangeable

• Manages want to know that the work is being done and look for improvement

  • But dev work is not that easy, it information work

  • measuring productivit like time spent coding, lines coded etc on complex work leads to demotivating workers

Stages

Requirements

• Information is gathered from subject matter experts and prospective users to creae a requirements documents

• Requirement documents

  • Set of instructions that tell us what features we are supposed to be building in the current release

• features

  • things that software documents

Design

• Software is designed to fulfill the written requirements.

• The design is usually in the form of diagrams, ie uml, that describe the design

• It is not code but another document

  • containing diagrams and how software will be built

• It is not as precise as a blue print for a building

Implementation

• Where code is written conforming to the design documentation.

• Transforming the language of the design to code for the computer

Integration

• When all code is written this phase begins

• All the code written is put together into a computer program.

• Generally the first time this happens.

• This is where many bugs appear

Testing

• Once the program is ready and integrated, a release, it is tested

• Verifies the software does what it should and proves the software works as expected.

Installation

• The software is put on the machine, and released/started and can be used

• Cds, link to download, api available to be consumed.

Maintenance

• Ongoing, where the program is monitored and problems are fixed