Cascade model enhed

Vandfaldsmodellen, også kendt som Waterfall, er en af ​​de mest kendte tilgange til softwareudvikling. Forfatteren af ​​modellen er Winston Royce. I 1970 beskrev han essensen af ​​sin innovation i en artikel, der detaljerede dens fordele og ulemper. Samme sted forklarede han, hvordan denne model kan forfines til en iterativ model. I første omgang, i vandfaldsmodellen, går udviklingsstadierne i følgende rækkefølge:

  • Definition og koordinering af krav;
  • Projektgodkendelse;
  • Kodning;
  • Oprettelse af en fungerende version af softwareproduktet;
  • Test og fejlretning;
  • Installation af software;
  • Support.

Ifølge vandfaldsmodellen sker udførelsen af ​​handlinger fra udviklerens side sekventielt - punkt for punkt. Til at begynde med arbejdes der på at fastlægge og aftale softwarekrav i form af en liste, der skal udfyldes.

Java university

Herefter er der overgang til oprettelse og godkendelse af projektet, hvorved der skrives dokumentation, der beskriver, hvordan de tidligere aftalte softwarekrav implementeres.

Hvis designet er gennemført, påtager udviklerne sig implementeringen. Dernæst kommer sammenlægningen af ​​koden - integrationen af ​​de enkelte dele af projektet, som blev arbejdet med af forskellige teammedlemmer.

Det næste trin er at teste og fejlfinde produktet. Tidligere fundne fejl rettes her.

Endelig er programmet installeret og understøttet. Det involverer om nødvendigt at foretage ændringer i funktionaliteten og eliminere de fundne fejl.

Kaskademodellen forudsætter, at du kan flytte til næste udviklingstrin strengt sekventielt - først efter afslutningen af ​​den forrige opgave. Mulighed for tilbagerulning eller inkonsistens i faserne er ikke givet.

Fordele og ulemper

Fra tid til anden bliver vandfaldsmodellen kritiseret på grund af dens manglende fleksibilitet. Mange kan ikke lide det, fordi målet om projektledelse råder i det, mens overholdelse af deadlines, omkostninger og kvalitet i udviklingen er meget vigtigere.

Men når det drejer sig om store projekter, så er ledelse ofte vigtigere i dem, da det reducerer risici ved projektet og forbedrer gennemsigtigheden i arbejdet.

På trods af manglerne specificerer PMBOK 3. version formelt kun metoden "kaskademodel". Andre muligheder, herunder iterativ projektledelse, tilbydes ikke.

Fordele ved vandfaldsmodellen:

  • Teamudvikling er nemmere at kontrollere. Kunden er bekendt med, hvad programmørerne arbejder med i øjeblikket, han kan ændre deadlines og budget for projektet.
  • Udgifterne til udvikling godkendes i første fase. Efter aftale om alle faser af implementeringen skrives softwareproduktet løbende.
  • Erfarne testere er ikke nødvendige. Til testfasen kan du bruge programdokumentationen.

Ulemper ved vandfaldsmodellen:

  • Da test starter på færdiggørelsesstadiet af udviklingen, vil det, hvis en fejl bliver opdaget, koste mere at rette den end i den indledende fase. Når alt kommer til alt, vil testere kun finde en fejl, når udvikleren allerede er færdig med at skrive koden, og tekstforfattere - dokumentationen.
  • Kunden stifter bekendtskab med det færdige produkt, efter at udviklingen er afsluttet. Derfor kan han kun vurdere produktet, når det er næsten helt klar. Hvis han ikke bryder sig om resultatet, vil udgifterne til projektbudgettet stige markant på grund af behovet for korrektion.
  • Jo mere teknisk dokumentation, jo længere tid tager det at færdiggøre arbejdet. Sådan dokumentation kræver flere ændringer og godkendelser.

"Waterfall" bruges ofte i projekter inden for medicin- og rumfartsindustrien, hvor der allerede er en bred basis af dokumenter, på grundlag af hvilke det er muligt at udarbejde krav til ny software.

Når du bruger vandfaldsmodellen, er det vigtigste at skrive detaljerede krav. Under test skal det ikke vise sig, at der er en fejl et sted, som har en skadelig effekt på hele projektet.