Szoftverfejlesztési módszertanok, 1. rész - Vízesés

Mint esetleg visszatérő olvasóimnak feltűnhetett, némileg ambivalens érzéseim vannak az IT megoldásokkal kapcsolatban. Egyértelműnek tűnik, hogy az informatika nem kikerülhető, ha kényelmesen és érdekesen szeretnénk élni, másrészről viszont ez a kényelem sokszor aránytalan méretű bosszankodással jár. A miértek az IT világában is érdekelnek, ezért kicsit utánajártam pár dolognak, és közben ráakadtam néhány érdekességre.

Az alkalmazásfejlesztés -ahogy én is megismertem- klasszikusan 4+1 elemből áll, ezt nevezik vízesés (waterfall) modellnek. Ezek a fázisok a következők:

1. igények összegyűjtése és dokumentálása
2. tervezés
3. implementálás
4. tesztelés, bevezetés
5. karbantartás, üzemeltetés

A modell lényege, hogy csak az adott fázis befejezése után lehet továbbmenni, azaz elvileg nincs tervezés az igények összegyűjtése és dokumentálása nélkül (azért elvileg, mert sokan még ezt az egyszeű modellt sem képesek betartani, és doksi nélkül vagy hiányos doksival vágnak neki a fejlesztésnek). Az alapos tervezésnek és a tökéletességre törekvő fázisoknak sok előnye van,
mivel elvileg megelőzi azt, hogy egy tervezési hibát pl. a tesztelés fázisában vegyünk először észre. Fontos, hogy a jó dokumentáció csökkentheti annak kockázatát, hogy a fejlesztő teamből kilépő munkatársak túl sok információt visznek magukkal. A vízesés modell egy megbízható, jó strukturált, lineáris modell, amelyet sokfelé (pl. NASA) alkalmaznak manapság. További -nem alábecsülendő előnye- a linearitásból adódóan, hogy a managementnek a projektek állása könnyen felvázolható, ütemtervei általában jól tarthatóak.

Vannak viszont hátrányai is. Az egyik, hogy sikeres kivitelezéséhez komoly szakértelem szükséges mind a management mind a team részéről annak érdekében, hogy az egyes fázisok valóban (be-)tarthatóak és hibátlanok legyenek. A felhasználó pl. komoly ellenfél ezen a téren. A felhasználó (homo usericus, mint a homo sapiens egyik vadhajtása) ui. olyan, hogy ha meglátja az első képernyőterveket vagy játszogatni kezd egy prototípussal, ezer új ötlete támad amivel tulajdonképpen átírja az egész dokumentációt. Még rosszabb, hogy ezt képes az egész projekt alatt folyamatosan produkálni, így projektvezető legyen a talpán, aki ezt felügyelni és irányítani képes. Fontos viszont, hogy szerintem az az elképzelés, miszerint a szoftverfejlesztés részleteiben szerződhető (azaz kőbe véshető, mi a probléma, mit kell fejleszteni, mik a szoftver tulajdonságai,...), nem életszerű. Természetesen számtalan más probléma is létezhet a modellel
kapcsolatban, de számomra ez az egyik legmeghatározóbb.

A szakirodalomban a vízesés modellnek néhány módosított változatáról is informálódni lehet, bármely keresővel könnyel megtalálhatóak pl "waterfall modell" begépelésével.

---