bélyegkép|350x350px| 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.
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.
A vízesés modelljének első hivatalos leírását gyakran Winston W. Royce 1970-es cikkeként idézik, Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Retrieved on 2007-11-28 from http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html 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.Conrad Weisert, Waterfall methodology: there's no such thing!
A "vízesés" kifejezés legkorábbi használata Bell és Thayer 1976. évi tanulmányában található.Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.
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 ".
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 Tervezés eredménye: a szoftver architektúrája Kódolás: szoftver fejlesztése, egységtesztelése és integrálása 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. 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.
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.
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.
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.
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ő.
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.
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.
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. 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".
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.A Waterfall Systems Development Methodology … Seriously? by David Dischave. 2012.
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: 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.
Royce végső modellje bélyegkép|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 A szoftver elkészítésbe be kell vonni az ügyfelet
Jegyzetek
Fordítás
További információk Understanding the pros and cons of the Waterfall Model of software development Project lifecycle models: how they differ and when to use them Going Over the Waterfall with the RUP by Philippe Kruchten CSC and IBM Rational join to deliver C-RUP and support rapid business change c2:WaterFall
Kapcsolódó szócikkek Agilis szoftverfejlesztés DevOps Gyors alkalmazásfejlesztés Szoftverfejlesztési folyamat Spirálmodell
Kategória:Formatervezés Kategória:Projektmenedzsment Kategória:Szoftverfejlesztési módszertanok