Különféle típusú fejlesztési ciklusok vesznek részt a szoftverek gyártásában . Ezek a ciklusok figyelembe veszik a szoftvertervezés minden szakaszát .
Ezt a fejlesztési ciklust a repülés és az űripar is alkalmazza rendszerek, vagy fedélzeti vagy földi alrendszerek meghatározására, függetlenül attól, hogy tartalmazzák-e az informatikát.
A vízesés modellt az építőipar örökölte . Ez a modell a következő feltételezéseken alapul:
A fejlesztés hagyományos szakaszait egyszerűen egymás után hajtják végre, megtérülve az előzőekkel, még a ciklus legelején is. A kaszkádciklust használó fejlesztési folyamat fázisokat hajt végre, amelyek a következő jellemzőkkel rendelkeznek:
A ciklus V- modelljét úgy gondoltuk, hogy leküzdi a modell reaktivitásának problémáját kaszkádban. Ez a modell a vízesés modelljének továbbfejlesztése, amely rendellenesség esetén lehetővé teszi az előző szakaszokhoz való visszatérés korlátozását. A felszálló fázisoknak hibát észlelve vissza kell adniuk az ellentétes fázisokra vonatkozó információkat a szoftver fejlesztése érdekében. Kényes projektekben minden szakasz kezdő értekezlettel kezdődik .
Ezenkívül a V-ciklus kiemeli annak szükségességét, hogy a leereszkedő szakaszok során előre kell látni és felkészülni a jövőbeli felfelé irányuló szakaszok "elvárásaira": így a validációs tesztek elvárásai a specifikációk során, az egységtesztek elvárásai meg vannak határozva. tervezéskor stb. Ez megkönnyíti az egyes szakaszok projekt-felülvizsgálatát .
A fejlesztés az V-ciklus különböző szakaszait veszi igénybe. Az egymást követő verziók megvalósításával a ciklus újból egy teljesebb és robusztusabb termék kínálatával kezdődik.
A spirális ciklus azonban nagyobb hangsúlyt fektet a kockázatkezelésre, mint az V. ciklus, sőt, az egyes iterációk kezdete magában foglal egy kockázatelemzési fázist. Ezt az teszi szükségessé, hogy egy ciklikus fejlõdés során nagyobb a veszélye annak, hogy az iteráció során visszavonják az elõzõ iteráció során tetteket.
A félig iteratív ciklus James Martin 1989-ben megjelent, különböző észak-amerikai folyóiratokban publikált munkájából ered. Ezt a fejlesztési ciklust 1991-ben teljesen formalizálták a RAD ( Rapid application development ) könyvben . 1994-től további munkák végeztek Franciaországban (RAD2) és Angliában ( DSDM ) specializációkat vitt be a kezdeti alaptechnikákba. Az IBM Rational Unified Process és az Unified Process általi elfogadása rögzítette ennek a ciklusnak a csúcspontját, amely még mindig érvényes a nagyobb projektekben.
A félig iteratív ciklusban az első két klasszikus fázis ( felülről lefelé , szükség szerint) az igények kifejezésében és a megoldás kialakításában áll. A rövid és az utolsó nagyobb szakaszban, a termék felépítésében ( alulról felfelé , a szerkezet által) jön létre a rövid iterációk fogalma. 2001 körül, számos módszer megjelenésével, köztük az ASD, az FDD, a Crystal, a Scrum vagy a szélsőséges programozással, valamint az Agile Manifesto (Agile Manifesto) és az Agile Alliance szerzőinek egységes elképzelésével , mivel a félig iteratív ciklust általánosították. Minden agilis módszer a kutatás, az építészet és a tervezés szekvenciális, rövid, de nagyon valós szakaszával kezdődik. E módszerek teljesen iteratív használata azonban nem kizárt, hanem csak nagyon kicsi projektekre alkalmazható .
A tevékenységek el vannak választva a műtárgyaktól , a műtárgy egy tevékenység eredménye. Így Deming kerék típusú ciklust alkalmaznak a dokumentáció, egy alkatrész, egy teszt stb. Elkészítéséhez.
A projektmenedzsment típusú tevékenységhez kapcsolódó fázisok a következők:
Az iteratív ciklus nem egy bijekciót V ciklus típusát:
A PDCA és az iteráció közötti különbség az időtartam: rövidnek és szabályosnak kell lennie, míg a 300 fős szervezetnél alkalmazott Deming kerék több hónapot vagy akár évet vesz igénybe.
A kaszkád ciklus a nehéziparból származik. Ennek a környezetnek az a sajátossága, hogy az ezt követő szakasz sokkal több erőforrást igényel, mint az előző.
Például, hogy egy műanyag tárgy ,
Tudnia kell, hogy egy egyszerű tárgy, például egy műanyag pohár esetében a kialakítás néhány hét kérdése (azaz néhány ezer euró ), míg egy penész (lenyomat + hasított test) több hónapos gyártást igényel. És több százezer euró .
Ezért ilyen kontextusban a projekt megfelelő irányítása érdekében fontos, hogy ne hagyja figyelmen kívül az egyes lépések hitelesítését a bánásmód miatt.
Ez a jelenség olyan szoftverprojekteken fordul elő, amelyek több tíz vagy akár száz embert hoznak össze. A menedzsment csapat vagy a projekt építészének döntései olyan hosszú ideig hatnak a mérnökökre, hogy jobb biztosítani az egyes lépések érvényességét.
Ezen túlmenően, a projektcsapat által létrehozott rendszer entrópiájának (rendellenességének) korlátozása érdekében dokumentumok (vagy akár eszközök) segítségével kell formalizálni:
Egy tucatnyi embert érintő szoftverprojekt esetében egy-két évig a konfiguráció már nem ugyanaz; az ilyen projektekkel valóban:
Továbbá lehetséges az úgynevezett agilis fejlesztési módszerek felé haladni a formalizmus csökkentésével és a ciklusok számának megszorzásával (iteratív működés).