A módosítatlan "vízesésmodell". A haladás fentről lefelé folyik, mint a víz folyása egy lépcsős vízesésnél
A vízesésmodell a projekt tevékenységeinek sorozatos lineáris szakaszokra bontása, ahol az egyes szakaszok az előző fázis eredményeitől függnek, és az adott feladat specializációjának felelnek meg. A mérnöki tervezés bizonyos területeire jellemző ez a megközelítés, ezért a szoftverfejlesztésben inkább a kevésbé iteratív és rugalmatlan megközelítések közé tartozik, mivel a haladás nagyrészt egy irányba ("lefelé", mint egy vízesésnél) folyik az elgondolás, a kezdeményezés, az elemzés, a tervezés, a felépítés, a tesztelés, a telepítés és a karbantartás szakaszában.
A vízesés fejlesztési modellje a feldolgozó- és építőiparban jött létre; ahol a magasan strukturált fizikai környezet azt jelentette, hogy a tervezési változások sokkal hamarabb váltak költségessé a fejlesztési folyamat során. Amikor először használták a szoftverfejlesztésben, még nem létezett más ismert alternatív modell a tudásalapú, kreatív munkához.[1]
Történelem
Az első ismert prezentációt - ami ilyen fázisok használatát mutatja be a szoftverfejlesztésben -, Herbert D. Benington tartotta a digitális számítógépek fejlett programozási módszereinek szimpóziumán 1956. június 29-én. Az előadás a SAGE szoftver fejlesztéséről szólt.1983-ban a cikket újra közzétették Benington előszavával, amely rámutatott arra, hogy a fázisok szándékosan a feladatok specializációja szerint voltak megszervezve, és kifejtette, hogy a folyamat valójában nem teljesen felülről lefelé ment végbe, hanem a prototípuson is múlt.[1]
A vízesés modelljének első hivatalos leírását gyakran Winston W. Royce 1970-es cikkeként idézik,[2][3] bár Royce konkrétan nem alkalmazta a vízesés kifejezést a publikációjában. A modellt egy hibás, nem működő modell példájaként mutatta be, úgy ahogy a vízesés kifejezést általában használni szokták a szoftver fejlesztésről szóló írásokban, hogy leírjon egy kritikus szemléletet egy általánosan használt szoftverfejlesztési gyakorlatról.[4]
A "vízesés" kifejezés legkorábbi használata Bell és Thayer 1976. évi tanulmányában található.[5]
1985-ben az Egyesült Államok Védelmi Minisztériuma fogalmazta meg ezt a megközelítést a DOD-STD-2167A szabványban, amely a szoftverfejlesztési vállalkozókkal való együttműködésre vonatkozott, és kimondta, hogy "a vállalkozónak olyan szoftverfejlesztési ciklust kell implementálnia, amely a következő hat fázist tartalmazza: szoftverkövetelmény-elemzés, előzetes tervezés, részletes tervezés, kódolás és egységtesztelés, integráció és tesztelés ".[6]
Modell
Royce eredeti vízesésmodelljében a fázisok sorrendje a következő:
Rendszer- és szoftverkövetelmények: rögzítve van a termékkövetelmény a dokumentumban
Elemzés eredménye: a modellek, a sémák és az üzleti szabályok
Tesztelés: a hibák szisztematikus felfedezése és hibakeresés
Műveletek: komplett rendszerek telepítése, költöztetése, támogatása és karbantartása
Így a vízesés modell fenntartja, hogy a következő fázisra csak akkor lehet továbblépni, ha az előző fázist felülvizsgálják és verifikálják.
A különböző módosított vízesésmodellek (ideértve Royce végső modelljét) azonban ennek a folyamatnak csekély vagy akár jelentős változásait is tartalmazhatják.[2] Ezek a változások magukban foglalják az előző ciklushoz való visszatérést, miután hibákat találtak a "folyásirányban", vagy egészen a tervezési szakaszba való visszatérést, ha nem megfelelőek voltak a fázisok.
A módszertant támogató érvek
A szoftvergyártási ciklus elején eltöltött idő csökkentheti a költségeket a későbbi szakaszokban. Egy korai szakaszban talált problémát (például mint a követelmények meghatározása) olcsóbban lehet kijavítani, mintha ugyanazt a hibát a későbbi folyamatokban találták volna meg, mert a javítás költsége akár az 50-200 szorosa is lehet.[7]
A gyakorlatban a vízesésmodell módszertana eredményeként az első két fázisra fordított idő a teljes ráfordított időtartam 20–40 százaléka, a kódolásra fordított idő 30–40 százalék, a maradék idő pedig a implementálásra és a tesztelésre jut. A valódi projektszervezésnek nagyon strukturáltnak kell lennie. A legtöbb közép és nagy projekt részletes eljárásokkal és vezérlőkkel rendelkezik, amelyek a projekt minden folyamatát szabályozzák.[8]
További érv a vízesésmodell mellett, hogy hangsúlyt fektet a dokumentációra (mint a követelmény- és tervezési dokumentációk) is, a forráskód megírása mellett. A kevésbé alaposan megtervezett és dokumentált módszertanokban tudás vész el, ha a csapat tagjai a projekt befejezése előtt távoznának, és nehéznek bizonyulhat, hogy a projekt "feltámadjon" a hiányzó csapattagok nélkül. Ha a tervezési dokumentum gondosan van elkészítve, akkor az új csapattagoknak, vagy akár egy teljesen új csapatnak is képesnek kell lenni arra, hogy megismerjék a projektet a dokumentumok elolvasásával.[9]
A vízesésmodell egy strukturált megközelítést biztosít, illetve a modell maga lineárisan halad előre egy diszkrét, könnyen érthető és magyarázható szakaszon keresztül; ezenkívül könnyen azonosítható mérföldköveket biztosít a fejlesztési folyamatban. Többek között ez az oka annak, hogy a vízesésmodellt a fejlesztési modellek kezdő példájaként használják számos szoftverfejlesztési szövegben és kurzusban.[10]
A módszertan támogatói úgy gondolják, hogy a vízesésmodell olyan projekteknél lehet alkalmas, ahol a követelmények és az alkalmazási kör rögzítve van, maga a termék biztosan megvalósítható, és a technológia is érthető.[11]
Kritika
Előfordulhat, hogy az ügyfelek nem tudják vagy nem biztosak a pontos követelményekben, és amikor bemutatják nekik a működő, majdnem teljesen elkészített szoftvert, az igényeik könnyen megváltozhatnak, ami újra tervezéshez, átdolgozáshoz és újbóli teszteléshez, valamint megnövekedett költségekhez vezethet.[12]
Fennáll a lehetősége, hogy a tervezők nem ismerik a jövőbeli nehézségeket egy új szoftvertermék vagy funkció megtervezésekor; ebben az esetben jobb a terv felülvizsgálata, mint a réginél maradás, amelyben még nincs szó az újonnan felfedezett korlátozásokról, követelményekről vagy problémákról.[13]
A cégek megkísérelhetik kezelni az ügyfelek konkrét követelményeinek hiányosságát azáltal, hogy rendszerelemzőket alkalmaznak, akik megvizsgálják a meglévő manuális rendszereket, és elemzik, mit csinálnak, és hogyan lehetne azokat helyettesíteni. A gyakorlatban azonban nehéz fenntartani a rendszerelemzés és a programozás szigorú szétválasztását.[14] Ennek az az oka, hogy bármilyen nem triviális rendszer implementálása szinte elkerülhetetlenül felvet olyan kérdéseket és szélsőséges eseteket, amelyeket a rendszerelemző nem vett figyelembe.
Az elméleti vízesésmodellel észlelt problémák kapcsán különböző módosított vízesésmodelleket vezettek be, például: "Sashimi (átfedő fázisú vízesés), vízesés alprojektekkel és vízesés kockázatcsökkentéssel".[7]
Néhány szervezet, például az Egyesült Államok Védelmi Minisztériuma előnyben részesíti a nem vízesés típusú módszereket, kezdve a MIL-STD-498-as szabvánnyal.
Míg az agilis szoftverfejlesztés támogatói azt állítják, hogy a vízesésmodell nem egy hatékony eljárás a szoftverfejlesztéshez, egyes szkeptikusok szerint a vízesésmodell csak egy megtévesztés, amelyet pusztán az alternatív fejlesztési módszerek reklámozására használnak.[15]
A Rational Unified Process (RUP) szakaszai elismerik a mérföldkövek programozási szükségességét a projekt nyomon követése érdekében, de a fázisokban ösztönzik az iterációkat, ezért ezeket a fázisokat gyakran "vízesésszerűnek" nevezik.
Módosított vízesésmodellek
Az elméleti vízesésmodellel észlelt problémákra válaszul számos módosított vízesésmodellt vezettek be. Ezek a modellek választ adnak az elméleti vízesésmodell néhány vagy talán mindegyik kritikájára.
Ide tartoznak a gyors fejlesztési modellek, amelyeket Steve McConnell "módosított vízeséseknek" hív:[7] ilyen például Peter DeGrace "sashimi modell"-je (átfedő fázisú vízesés), a vízesés alprojektekkel vagy a vízesés kockázatcsökkentéssel. Más szoftverfejlesztési modellkombinációk, például az „inkrementális vízesésmodell” is léteznek.[16]
Royce végső modellje
Royce végső modellje
Winston W. Royce végső modellje, amely továbbfejlesztése az eredeti "vízesésmodelljének", szemléltette, hogy visszajelzésnek el kellene és gyakran el is vezet a kód tesztelésétől a tervezéshez (mivel a kód tesztelése felfedez hibákat a tervben), és tervezéstől vissza a követelményspecifikációhoz (mivel a tervezési problémák szükségessé tehetik konfliktusok vagy más kielégíthetetlen / megtervezhetetlen követelmények törlését). Ugyanabban a cikkben Royce támogatta továbbá a nagy mennyiségű dokumentációt, a munka elvégzését "kétszer, ha lehetséges" (a felfogás hasonló Fred Brookséhoz, aki híres Mythical Man Month című könyvéért, amely egy elismert könyv a szoftverprojekt menedzsment terén), és az ügyfél bevonását, amennyire csak lehetséges (a felfogás hasonló az extrém programozáshoz).
Royce feljegyzései a végső modellhez a következők:
A programot teljesen meg kell tervezni, az elemzés és a kódírás megkezdése előtt
A dokumentációnak frissnek és teljesnek kell lennie
Ha lehetséges, minden munkát kétszer is el kell végezni
A tesztelést meg kell tervezni, végre kell hajtani és ellenőrizni kell
Ez a szócikk részben vagy egészben a Waterfall model című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
