- Történelem
- Teremtés
- A vízesés modelljének alternatívája
- A spirálmodell jellemzői
- Kockázat-ellenőrzés
- A spirál leírása
- Generikus
- Rugalmas
- metamodellt
- Szakasz
- Határozza meg a célokat, alternatívákat és korlátokat
- A kockázatok értékelése
- Fejlesztés és tesztelés
- A következő ciklus tervezése
- Példa
- Előny
- Ciklikus szerkezet
- Kockázat kezelés
- Vevői részvétel és visszajelzés
- Ideális nagy projektekhez
- hátrányok
- Drága
- Elég bonyolult
- Idő beosztás
- Sok lépés
- Irodalom
A spirálmodell az alkalmazásfejlesztési folyamat egyik archetípusa. Annak a hipotézisnek az alapja, hogy a szoftverfejlesztés egy iteratív ciklus, amelyet addig ismételnek meg, amíg a kitűzött célokat el nem érik. Képes kezelni a számos kockázatot, amely bármilyen szoftver fejlesztésekor felmerülhet.
Ez az egyik legfontosabb modell a kockázatkezelés támogatására. Amint a neve is sugallja, ez a modell spirál alakú, ahol a modell különböző szakaszai különböző ciklusokban vannak elosztva. A ciklusok száma a modellben nincs rögzítve, és projektenként változhat.

Elemzés, értékelés, tervezés és fejlesztés. Szoftverfejlesztés spirál Forrás: Beao commons.wikimedia.org
Történelem
Teremtés
A spirális modellt Barry Boehm az amerikai matematikus és szoftvermérnök professzor határozta meg. Miután 1986-ban bemutatta a komplex alkalmazások fejlesztésére vonatkozó koncepcióját, 1988-ban egy átfogóbb keretek között publikálta modelljét "Szoftverfejlesztés és fejlesztés spirálmodellje" című cikkében.
Ennek az 1988-as kiadványnak egy része a spirálmodellt ábrázolta grafikusan, átfogó módon bemutatva, hogy a szoftverfejlesztési folyamat spirálisan néz ki, és ciklusok támogatják.
Boehm ismert a szoftverfejlesztésbe való számos hozzájárulásáról, például a konstruktív költségmodellről (COCOMO), a szoftverfolyamat spirális modelljéről, a G-elmélet megközelítéséről (mindenki számára hasznos) a követelmények meghatározására és kezelésére. a szoftver.
A vízesés modelljének alternatívája
Boehm publikációjában a spirális modellt a korábban kialakított vízesési modell lehetséges alternatívájaként írta le, amely szintén szolgált gyakorlatának.
A spirális modell nem volt az első, amely megvitatta a ciklikus fejlődést, ám ez volt az első modell, amely magyarázta, hogy miért fontos az iteráció. Az eredeti tervek szerint nagy, összetett projektekre célozták meg, amelyek iterációja általában 6 hónap és 2 év közötti.
Ez a modell nem feltételezi, hogy a szoftverfejlesztési feladatok lineárisan vannak megtervezve, ellentétben a vízesés modelljével, hanem inkább iteratív feladatoknak tekinti őket.
Ez a ciklikus modell befolyásolta a modell alapú szoftverfejlesztési architektúrát (MBASE) és az extrém programozást.
A spirálmodell jellemzői
Kockázat-ellenőrzés
A modell nagyban megkülönbözteti a többi szoftverfolyamat-modelltől az, hogy kifejezetten felismeri a kockázatokat. Így jelentősen csökkenti a nagy szoftverprojektek kudarcát azáltal, hogy ismételten felméri a kockázatokat és ellenőrzi a fejlesztés alatt álló terméket.
Ez a számítógépes modell a szoftver életciklusának szinte minden más modelljét tartalmazza, például a vízesés modellt, a prototípus modellt, az iteratív modellt, az evolúciós modellt és így tovább.
Emiatt szinte bármilyen típusú kockázatot képes kezelni, amelyet más modellek általában nem kezelnek. Mivel azonban oly sok alkatrész van, ez a modell sokkal összetettebb, mint a többi szoftverfejlesztési modell.
A spirál leírása
A spirál minden egyes fordulója egy teljes ciklust képvisel, amelyen a négy negyed mindig áthalad, képviselve a modell négy szakaszát.
A spirál méretének növekedésével ugyanúgy növekszik az elért haladás. Ezért a színpadokat nem egyszer, hanem többször, spirálisan hajtják végre.
Noha ez a ciklikus ismétlés a projektet lassan megközelíti a kitűzött célokat, a fejlesztési folyamat kudarcát erősen minimalizálják.
Generikus
A négy szakasz csak a ciklus alapvető céljait valósítja meg, de nem kell, hogy minden ciklusban megjelenjenek.
Az egyes ciklusok sorrendjét sem szigorúan határozzák meg. Ezért a modell bármikor kombinálható más modellekkel.
Rugalmas
Meglehetősen rugalmas, mivel a projekt minden szakaszára külön-külön végzi a célok meghatározását, a kockázatelemzést, a fejlesztési és tervezési folyamatokat.
metamodellt
Metamodellnek tekintik, mert magában foglalja a többi modellt. Például, ha a spirál egyetlen ciklusú lenne, akkor a vízesés modelljét képviseli, mivel magában foglalja a klasszikus modell fokozatos megközelítését.
A prototípus-modell megközelítést is használja, mivel minden ciklus elején összeállít egy prototípust a kockázat kezelése érdekében.
Ezenkívül összeegyeztethető az evolúciós modellel, mivel a spirál iterációi tekinthetők evolúciós szinteknek, amelyeken a végső rendszer felépül.
Szakasz
Határozza meg a célokat, alternatívákat és korlátokat
A rendszerkövetelményeket a lehető legrészletesebben határozzák meg, ideértve a teljesítményt, a hardver / szoftver interfészeket, a siker legfontosabb mutatóit stb. és hogy milyen célokat kell társítani a jelenlegi fejlesztési ciklushoz.
Ezen felül megvizsgálják a végrehajtásának különböző alternatíváit, például az építkezés vs. meglévő alkatrészek vásárlása, újrafelhasználása vagy kiszervezés stb.
Hasonlóképpen meghatározzák azokat a korlátozásokat, mint a költség, az ütemterv és az interfészek, az időigény stb.
A kockázatok értékelése
Az összes javasolt alternatívát ki kell értékelni. A célkitűzések és korlátozások szolgálnak referenciaként a legjobb megoldás kiválasztására.
Ezenkívül azonosítják azokat a kockázatokat, amelyek akadályozhatják a projekt sikerét, például tapasztalat hiánya, új technológiák, szűk ütemterv, rossz folyamatok stb., A legkisebb jövedelmező stratégiák végrehajtása mellett, a legkisebb kockázattal.
Végül olyan módszereket alkalmazunk, mint a prototípuskészítés, a szimulációk, az analitikai modellek és a felhasználói felmérések.
Fejlesztés és tesztelés
A szükséges fejlesztéseket a technológia és a kiválasztott megoldás felhasználásával hajtjuk végre. Minden iterációval létrejön az alkalmazás jobb verziója.
A tényleges kódot többször írják és tesztelik, amíg el nem érik a kívánt eredményt, amely ekkor szolgál majd a jövőbeli fejlesztési lépések alapjául.
A következő ciklus tervezése
Az egyik ciklus befejezése után megkezdődik a következő tervezés. Ez a tervezés lehet a projekt normál folytatása, ha a ciklus célját elérik, figyelembe véve a következő cél meghatározását.
Lehet más megoldásokat is találni, ha az előző fejlesztési szakasz hibásnak bizonyult. A meglévő stratégia helyettesíthető az előzőekben meghatározott alternatívák egyikével vagy egy új alternatívával. Ezzel új kísérlet indul az adott cél elérésére.
Példa
Az Egyesült Államok katonasága elfogadta a spirális modellt a Future Fighting Systems (SCF) modernizációs programjának fejlesztésére és frissítésére.
A hivatalosan 2003-ban elindított SCF-ek felkészültek arra, hogy a csapatokat olyan járművekkel látják el, amelyek valós időben csatlakoznak a rendkívül gyors és rugalmas csatatér-hálózathoz.
A projektet négy, körülbelül kétéves fejlesztési spirálra osztották. A Spirál 1 tervek szerint 2008-ban indulnak, és prototípusokat szállítanak felhasználásra és értékelésre.
Az 1. spirál befejezése után a 2. spirál a tervek szerint 2010-ben kezdődik. A végtermék fejlesztését a tervek szerint 2015-ben szállítják.
2005 augusztusában a Boeing bejelentette a projekt első nagyobb mérföldkövének befejezését, amely a rendszerek funkcionális átalakítása volt. A Boeing és a Science Applications International Corporation volt a projekt társvezetője.
A Pentagon azonban 2005 októberére javasolta a projekt elhalasztását az iraki háború és a Katrina hurrikán segélyeinek nagy kihatása miatt.
A projektet 2009-ben törölték, miután költségvetés-csökkentésre került sor, anélkül, hogy bizonyítani tudta volna a spirálmodell előnyeit ebben a misszióban
Előny
Ciklikus szerkezet
Az ilyen típusú szerkezet miatt az időszakos ellenőrzéseknek köszönhetően hallgatólagosan kiküszöbölésre kerülnek a szoftver tervezése és a műszaki követelmények közötti problémák.
Kockázat kezelés
A kockázatokat a termék minden szakaszában elemezzük, mielőtt tovább folytatnánk. Ez elősegíti a lehetséges kockázatok leküzdését vagy csökkentését.
A munkavállalók részesülnek a kockázatelemzés nagy fontosságáról ebben a modellben, amely valószínűleg a legnagyobb előnyt képviseli más folyamatmodellekkel szemben.
A rendszeres kockázatértékelés akkor hasznos, ha új technikai környezeteket alkalmazunk, amelyek általában az empirikus értékek hiánya miatt egy adott kockázati potenciállal társulnak.
Vevői részvétel és visszajelzés
Az ügyfelek részt vesznek a projekt minden szakaszában, a projekt befejezéséig. Ezért különböző visszajelzések gyűjthetők a projekt következő verziójának javítása érdekében.
Ezenkívül a spirál alakú előrehaladásnak köszönhetően bármikor visszajelzést lehet kapni. Így az ügyfelek és a felhasználók már a kezdetektől beépíthetők a fejlesztési folyamatba.
Ideális nagy projektekhez
Különösen népszerű és kiemelkedő a nagy és összetett projekteknél, ahol a költségvetés ellenőrzése az ügyfelek és a fejlesztők számára prioritást élvez. Ön maximálisan ellenőrizheti a szoftverprojekt költségeit, forrásait és minőségét.
hátrányok
Drága
Elég drága lehet, mivel a kockázatelemzéshez magas szintű szakértelemre van szükség. Ezenkívül a projektek kidolgozása sok időt vesz igénybe, ami növelheti az általános költségeket.
Elég bonyolult
A projekt nagyon aktív és összetett előzetes irányítására van szükség, ahol minden ciklust folyamatosan és gondosan ellenőriznek és dokumentálnak.
Ez viszonylag bonyolultabb, mint más modellek, mivel sok ciklus létezik, amelyek mindegyike különböző szakaszokon megy keresztül, ezáltal növelve a dokumentációs folyamat erőfeszítéseit.
Alapvető fontosságú a kockázatelemzés és -kezelés ismerete, amely gyakran nem áll rendelkezésre.
Idő beosztás
Az idő kezelése nehéz, mivel a ciklusok száma ismeretlen. Ezenkívül a fejlesztési folyamat bármikor késleltethető, ha egy fontos ciklust egy cikluson belül kell meghozni, vagy további lépésekkel kell meghozni a következő ciklus tervezésekor.
Sok lépés
A szoftverfejlesztésben sok lépés megtétele nem mindig kedvező, mert a tesztelés sokoldalúsága ellenére a program be nem fejezett részei elérhetik a kész rendszert.
Következésképpen mindig fennáll annak a veszélye, hogy bármilyen fogalmi hiba vagy következetlenség befolyásolja a végterméket.
Irodalom
- Victor Font Jr (2019). A spirálmodell. Az SDLC végső útmutatója. Forrás: ultimatesdlc.com.
- Ionos (2019). Spirálmodell: a kockázatvezérelt szoftverfejlesztési folyamatmodell. Forrás: ionos.com.
- Techuz (2018). Mi az a spirálmodell? A spirál szoftverfejlesztési életciklus (SDLC) egyszerű magyarázata. Forrás: techuz.com.
- Egyablakos tesztelés (2020). Spirálmodell. Forrás: onestoptesting.com.
- Geeks Geeks számára (2020). Szoftvertervezés - spirálmodell. Feltöltve: geeksforgeeks.org.
- Chandu (2019). Spirálmodell a szoftverfejlesztésben. Forrás: medium.com.
