Vízesésmodell
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 szerkesztés
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 szerkesztés
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.[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 szerkesztés
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 szerkesztés
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 szerkesztés
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 szerkesztés
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 szerkesztés
- ↑ a b Benington (1983. október 1.). „Production of Large Computer Programs”. IEEE Annals of the History of Computing 5 (4), 350–361. o, Kiadó: IEEE Educational Activities Department. [2011. július 18-i dátummal az eredetiből archiválva]. DOI:10.1109/MAHC.1983.10102. (Hozzáférés: 2011. március 21.)
- ↑ a b Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9, <http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf> Archiválva 2020. október 2-i dátummal a Wayback Machine-ben
- ↑ 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
- ↑ Conrad Weisert, Waterfall methodology: there's no such thing!
- ↑ 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.
- ↑ Military Standard Defense System Software Development
- ↑ a b c McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Microsoft Press (1996). ISBN 1-55615-900-5
- ↑ Waterfall Software Development Model, 2014. február 5. (Hozzáférés: 2014. augusztus 11.)
- ↑ Arcisphere technologies. „Tutorial: The Software Development Life Cycle (SDLC)”. [2019. február 17-i dátummal az eredetiből archiválva] (Hozzáférés: 2012. november 13.)
- ↑ Hughey: Comparing Traditional Systems Analysis and Design with Agile Methodologies. University of Missouri – St. Louis, 2009 (Hozzáférés: 2014. augusztus 11.)
- ↑ When should you use Waterfall Model?. (Hozzáférés: 2016. szeptember 28.)
- ↑ Parnas (1986. április 19.). „A rational design process: How and why to fake it”. IEEE Transactions on Software Engineering, 251–257. o. (Hozzáférés: 2011. március 21.)
- ↑ McConnell, Steve. Code Complete, 2nd edition. Microsoft Press (2004). ISBN 1-55615-484-4
- ↑ Ensmenger, Nathan. The Computer Boys Take Over, 42. o. (2010). ISBN 978-0-262-05093-7
- ↑ A Waterfall Systems Development Methodology … Seriously? by David Dischave. 2012. Archiválva 2014. július 2-i dátummal a Wayback Machine-ben.
- ↑ Methodology:design methods. [2016. március 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. június 23.)
Fordítás szerkesztés
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.