Waterfall mudel - JOstapjuk/Konspeekt_Agiil GitHub Wiki

Waterfall mudel

  • Definitsioon oma sõnadega

    Waterfall ehk "kosk" mudel on lineaarne ja järjestikune arendusmudel, kus iga projektietapp tuleb lõpetada enne, kui liikuda järgmise juurde. Iga etapp on selgelt määratletud ja täidetakse järjestuses, nagu vee voolamine juga kaudu.

  • Peamised omadused

    1. Lineaarne lähenemine – Iga etapp järgneb teisele, kuna üks etapp peab olema lõppenud enne järgmise alustamist.
    2. Selged etapid ja piiritletud ülesanded – Iga etapp on selgelt määratletud (nt nõuete kogumine, disainimine, arendamine, testimine jne).
    3. Kerge hallatavus ja jälgitavus – Kuna iga etapp on eraldi, on kergem jälgida projekti edenemist.
    4. Sõltumatus etappide vahel – Üks etapp ei sõltu eelnevast etappi tegurist, kuid järjekorras tuleb neid täita järjestikku.

  • Waterfall mudeli näide

    Näiteks tarkvara arendamine, kus alguses määratakse täpselt kõik toote nõuded, siis liigutakse edasi disaini juurde, millele järgneb arendus, testimine ja lõpuks juurutamine. Kogu projekt liigub järk-järgult edasi iga etapi lõppedes.

  • Lisa skeem või joonis

    {EA406875-FD1C-4C96-B45A-B4FA2119CEEA}

  • Eelised

    1. Selged etapid ja eesmärgid – Iga etapp on määratletud ja arusaadav, mis muudab projekti kergemini hallatavaks.
    2. Kergesti hallatav ajakava – Kuna etapid on eelnevalt määratud, saab projekti aja ja ressursside planeerimist täpselt.
    3. Selged nõuded alguses – Projekti alguses selgitatakse välja kõik nõuded, mis aitavad vältida hilisemaid muudatusi.

  • Puudused

    1. Paindumatu muutuste suhtes – Kuna iga etapp peab olema lõppenud enne järgmise alustamist, on raske teha muudatusi juba alguses määratud nõuetesse.
    2. Hilinenud tagasiside – Lõplik tagasiside saadakse alles pärast kogu arenduse lõppu, mis võib tähendada, et vigu avastatakse hilja.

2. Waterfall mudeli etapid

  • Nõuded kogumine

    Kõik toote nõuded ja funktsionaalsus on määratletud ja dokumenteeritud.

  • Süsteemi ja tarkvara disain

    Luues süsteemi arhitektuuri ja toote disaini vastavalt nõuetele.

  • Arendus

    Arendatakse kogu tarkvara vastavalt eelnevalt loodud disainile ja nõuetele.

  • Testimine

    Testitakse loodud süsteemi, et tagada vastavus algsetele nõuetele ja disainile.

  • Juurutamine

    Lõplik toode viiakse kasutusele.

  • Hooldus

    Pärast juurutamist võib toode vajada hooldust ja täiendusi, kuid see ei ole osa algsest Waterfall mudelist.

3. Võrdlus: Waterfall vs Iteratiivne vs Inkrementaalne

  • Tabel või nimekiri võrdluseks
Kriteerium Waterfall mudel Iteratiivne mudel Inkrementaalne mudel
Lähenemine Lineaarne ja järjestikune Tsükliline (korduvad iteratsioonid) Kasvav (funktsioonide lisamine samm-sammult)
Tagasiside sagedus Hiline tagasiside pärast kõiki etappe Pidev tagasiside iga tsükli lõpus Tagasiside igas inkrementis
Sobivus projekti tüübile Sobib projektidele, kus nõuded on selged ja muutumatud Sobib projektidele, kus nõuded võivad muutuda Sobib projektidele, kus toode peab pidevalt täiendama funktsioone
Riskide juhtimine Madal risk, kuna kõik etapid on määratud, kuid hilised muudatused on keerulised Paindlik, kuid võib tekitada probleeme hilisemates iteratsioonides Madalam risk, kuna iga inkrement on väiksem ja hallatav
Funktsionaalsuse valmimise järjekord Toodet ei ole täielikult valmis enne, kui kõik etapid on lõpetatud Iga iteratsioon toob täiendusi ja toode saab pidevalt valmis Funktsionaalsus valmib igas inkrementis, kuid kogu süsteem valmib alles pärast kõiki inkremente

Waterfall Model

Definition in Your Own Words

The Waterfall model is a linear and sequential development methodology where each project phase must be completed before moving on to the next. Each stage is clearly defined and follows a strict order—like water flowing down a waterfall.

Key Features

  1. Linear Approach
    Each phase follows the previous one. A phase must be completed before the next begins.

  2. Clearly Defined Stages and Tasks
    Each stage is well-documented and structured (e.g., requirements gathering, design, development, testing).

  3. Easy to Manage and Track
    Because phases are separate, it's easier to monitor progress.

  4. Stage Independence
    While the order is fixed, each phase can operate relatively independently based on completed prior steps.

Example of the Waterfall Model

Example: In software development, first all product requirements are clearly defined. Then the team moves on to design, followed by development, testing, and finally deployment. Each phase is completed fully before the next one starts.

Diagram

{EA406875-FD1C-4C96-B45A-B4FA2119CEEA}

Advantages

  1. Clear Stages and Goals
    Each phase is well-defined and helps simplify project management.

  2. Manageable Schedule
    Since the stages are fixed in advance, time and resources can be planned precisely.

  3. Defined Requirements from the Start
    All requirements are identified up front, reducing scope changes later.

Disadvantages

  1. Inflexible to Changes
    It’s difficult to make changes once a phase is complete.

  2. Delayed Feedback
    Feedback typically comes only after the product is fully developed, increasing the risk of late-stage problems.

Phases of the Waterfall Model

  • Requirements Gathering
    All functional and non-functional requirements are identified and documented.

  • System and Software Design
    The system architecture and software design are created based on the requirements.

  • Implementation (Development)
    The software is developed according to the design specifications.

  • Testing
    The system is thoroughly tested to verify it meets the original requirements.

  • Deployment
    The finished product is delivered and implemented in the live environment.

  • Maintenance
    Post-deployment maintenance and updates may be needed, though it's not part of the original Waterfall model.

Comparison: Waterfall vs Iterative vs Incremental Models

Criteria Waterfall Model Iterative Model Incremental Model
Approach Linear and sequential Cyclical (repeated iterations) Growing (step-by-step functionality additions)
Feedback Frequency Late, after all stages are complete Continuous, at the end of each iteration Feedback available after each increment
Best Fit Projects Clear, fixed requirements Projects where requirements may evolve Projects needing constant updates and functionality add-ons
Risk Management Lower risk if requirements are stable, but changes are hard Flexible but risks can arise in later cycles Lower risk, as increments are small and manageable
Function Delivery Order Full product delivered only after all stages are complete Product evolves with each iteration Functional parts are delivered with each increment