Miért nem a “waterfall model”

A vízesés modell többszintes elképzelése a következőkből áll: rendszerkövetelmények majd szoftverkövetelmények tisztázása, ami után következik az elemzés majd a programtervezés és csak azután a kódolás. Ezt követi egy tesztelési fázis, mielőtt piacra bocsátanák a rendszert.

"A fázisok eredménye tulajdonképpen egy dokumentum. A modell fontos szabálya, hogy a következő fázis addig nem indulhat el, amíg az előző fázis be nem fejeződött. A gyakorlatban persze ezek a szakaszok kissé átfedhetik egymást. Maga a szoftverfolyamat nem egyszerű lineáris modell, hanem a fejlesztési tevékenységek iterációjának sorozata. Ez a vízesésmodellnél a visszacsatolásokban jelenik meg.” - írja dr. Mileff Péter a Szoftverfejlesztés című tankönyvében. Az idézetben említett dokumentum tulajdonképpen egy részletes specifikáció. Ez az elejétől meghatározza a végterméket és a fejlesztést, ami mentén haladni kell a projekt folyamán.

A vízesés modell hátrányai

A vízesés modellnek vannak azonban problémái, annak ellenére, hogy sok cégnél bevált az előző 40 évben. Ám az elméletet Winston W. Royce űrhajó-projektben eltöltött 9 évéből alakította ki. Tehát viszonylag nagy szoftverfejlesztésről beszélünk, ahol a pontos előre tervezés elengedhetetlen.
De nem minden szoftverfejlesztés ilyen mértékű és nem minden vállalat környezete ilyen stabil.

Egy űrhajó építésénél a követelmények évek kutatásai alapján alakulnak ki, és várható az egy-két év múlva fennálló állapot is, így könnyebb tartani a tervet.

A mai világban viszont a változás a mindennapok része. Ezekhez a folyamatosan változó felhasználói igényekhez a vállalatoknak és a szoftverfejlesztésnek is igazodniuk kell. A változó igényeket és ennek kiszolgálását célzó törekvéseket mi sem érzékelteti jobban, mint a Skyscanner 2018 áprilisában tartott előadásán elhangzó kijelentés, miszerint naponta tízezer deploy-t / release-t szeretnének a weboldalukra.
Egy vállalat versenyképességének fenntartásához a meglévő igényeket kell kiegészíteni, az igazi versenyelőnyt viszont az okozza, ha a vállalat a célközönségének rejtett igényeire is rátapint. Emiatt a folyamatos innováció elengedhetetlen a szoftverfejlesztésben.

De nézzük csak meg a vízesés modelljét! Mire eljut a kódolásig, a folyamat már túl van jó esetben egy prototípus elkészítésén és két felhasználói igényfelmérésen. Tekintsünk el most attól a ténytől, hogy a felhasználó rejtett igényekkel rendelkezhet, és nem biztos, hogy tudja, mit akar. A projekt a harmadánál jár, és még nem történt kód írás, de a specifikáció már nagyon kidolgozott, és részletes.
Látjuk tehát, hogy már az elején eldől, mivel fog hosszabb távon foglalkozni a csapat, és ebben egy új igénynek nincsen helye. Tudásom szerint egyelőre nincs olyan folyamatmodell, amely a váratlan problémákat elkerülné, ezért a váratlan problémák rugalmas és olcsó kezelésében rejlik a megoldás.

A vízesés modell nem eredményes, ha a követelmények nem jól definiáltak, vagy nem értelmezhetőek egyértelműen.
Az elemzést megelőző igényfelmérési időszakon és a végén az elemzésben megfogalmazott dokumentáción múlik minden. Ha a követelmény félreérthető és ha az igényt rosszul fogalmazzák meg, minden olyan döntés, ami ezeken alapszik valószínűleg a projektet rossz irányba viszi, így minden kód ami azokból a döntésekből indult ki, megkérdőjelezhető. Ráadásul a tesztelés hiába eredményes, és mutatja a termék rendeltetésszerű működését, hogyha a rossz feltételeknek megfelelően van elkészítve.
Azt is tudjuk, hogy hibák mindig jönnek elő. A vízesés modellben a hibák a szoftverfejlesztési életciklusban nagyon későn jelennek meg, mivel a tesztelők nincsenek bevonva a kezdetektől, hanem csak a tesztelési fázisnál.
Az SDLC (Softwer decelo) minél későbbi szakaszában jön elő egy hiba, a javítása annál nagyobb költséget jelent S. Ambler eltelt idő - hiba javításának költsége mátrixa alapján.

Tehát a folyamatos felülvizsgálás és a változásokhoz való igazodás nagyon fontos az IT iparban, ami nem erőssége ennek a modellnek.