# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hanfak.gitbook.io/workspace/management-workflow/waterfall.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
