Spirálmodell

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez
Spirálmodell (Boehm, 1988). Számos tévképzet származik ennek a széles körben elterjesztett diagramnak az egyszerűsítéséből (ebben a diagramban vannak bizonyos hibák). [1] [1]

A spirálmodell kockázatvezérelt szoftverfejlesztési folyamatmodell. Az adott projekt egyedi kockázati mintázata alapján a spirálmodell segíti a csoportot egy vagy több folyamatmodell, például növekményes, vízesés- vagy evolúciós prototípus kialakításának elfogadásában.

Története[szerkesztés]

A modell meghatározását először Barry Boehm amerikai szoftvermérnök adta meg A szoftverfejlesztés és továbbfejlesztés spirálmodellje című 1986-os tanulmányában,[2] majd a témát a szélesebb közönség számára 1988-ban ismét feldolgozta.[3] Ezekben a tanulmányokban bevezetett egy olyan diagramot, amelyet a spirális modellt tárgyaló számos későbbi publikáció is közölt.

Ezek a korai tanulmányok a folyamatmodell kifejezést használják a spirálmodellre, ahogy az inkrementális, a vízesés-, a prototípus- és egyéb megközelítésekre is. Ugyanakkor a spirális modell jellegzetes, kockázatvezérelt keverése más folyamatmodellek jellemzőivel már e cikkekben is szerepel:

A spirálmodell lépéseinek kockázatalapú részhalmaza lehetővé teszi a modell számára, hogy a szoftverfejlesztéshez specifikáció-orientált, prototípus-orientált, szimulációs-orientált, automatikus transzformáció-orientált vagy más megközelítés megfelelő keverékét alkalmazza.”[2]

Későbbi írásaiban Boehm a spirális modellt folyamatmodell-generátornak írja le,[1] ahol a projekt kockázatain alapuló választások megfelelő folyamatmodellt hoznak létre a projekt számára. Így az inkrementális, a vízesés-, a prototípus- és a többi folyamatmodell a spirálmodell különleges esetei, amelyek illeszkednek egyes projektek kockázati mintázatához.

Boehm emellett számos olyan téves elképzelést azonosít, amelyek az eredeti spirális modelldiagram egyszerűsítéseiből származhatnak. Állítása szerint az alábbi félreértések lehetnek a legveszélyesebbek:

  • hogy a spirál egyszerűen egy vízesés növekményének sorrendje;
  • hogy a projekt minden tevékenysége egy spirálsorozatot kövessen;
  • hogy a diagram minden tevékenységét végre kell hajtani a bemutatott sorrendben.

Noha ezek a tévképzetek illeszkedhetnek néhány projekt kockázati mintázatához, a legtöbb projekt esetében nem igazak.

Az amerikai Nemzeti Kutatási Tanács (National Research Council) jelentésében[4] ezt a modellt kiterjesztették az emberi felhasználókkal kapcsolatos kockázatokra is.

Annak érdekében, hogy jobban megkülönböztessék őket a "káros, spirális megjelenésű folyamatoktól", Boehm hat követelményt sorol fel, amelyek a spirális modell hiteles alkalmazásához szükségesek.[1]

A spirálmodell ciklusainak hat követelménye[szerkesztés]

A spirális modell hiteles alkalmazásában minden ciklusnak meg kell felelnie az alábbiakban részletezett hat követelménynek. Boehm mindegyik követelmény megsértésére hozott fel olyan példát, ami alapján a csak látszólag spirális, de valójában káros folyamatok felismerhetőek.[1]

A tárgyak egyidejű meghatározása[szerkesztés]

A projekt legfontosabb tárgyainak egymás utáni meghatározása gyakran csökkenti annak lehetőségét, hogy olyan rendszert fejlesszenek ki, amely megfelel az érintettek „nyerési feltételeinek” (célok és korlátok).

Ez alapján a követelmény alapján zárhatók ki azon káros, spirális megjelenésű folyamatok, amelyekben inkrementális vízesés-sorozatot alkalmaznak olyan helyzetekben, ahol a vízesésmodell alapvető feltételezései nem érvényesek. Boehm az alábbiak szerint sorolja fel ezeket a feltételezéseket:

  1. A követelmények a végrehajtás előtt ismertek.
  2. A követelményeknek nincsenek megoldatlan, magas kockázatú következményei, például a költségek, az ütemterv, a teljesítmény, a biztonság, a felhasználói felületek, a szervezeti hatások stb. miatt felmerülő kockázatok.
  3. A követelmények jellege a fejlesztés vagy az evolúció során nem változik sokat.
  4. A követelmények összeegyeztethetőek a rendszer valamennyi kulcsfontosságú szereplőjével, beleértve a felhasználókat, az ügyfelet, a fejlesztőket, a karbantartókat és a befektetőket.
  5. A követelmények végrehajtásának megfelelő architektúrája jól megérthető.
  6. Elegendő naptári idő van a szekvenciális folytatáshoz.

Olyan helyzetekben, amikor ezek a feltételek teljesülnek, a projekt kockázata, hogy nem határozza meg a követelményeket, és egymást követve halad tovább. A vízesési modell tehát a spirálmodell kockázatvezérelt különleges esetévé válik.

A négy alaptevékenység elvégzése minden ciklusban[szerkesztés]

Ez a követelmény azonosítja azt a négy tevékenységet, amelyeknek a spirális modell minden ciklusában meg kell valósulnia:

  1. Vegye figyelembe az összes sikerkritikus érdekelt fél nyerési feltételeit.
  2. Azonosítsa és értékelje a nyerési feltételek teljesítésének alternatív módszereit.
  3. Azonosítsa és oldja fel a kiválasztott megközelítés(ek)ből eredő kockázatokat.
  4. Szerezzen jóváhagyást minden sikerkritikus érdekelt féltől, és biztosítsa ezek elkötelezettségét a következő ciklus folytatására.

Azok a projektciklusok, amelyek ezen tevékenységek bármelyikét kihagyják vagy rövidítik, azzal kockáztatják az erőfeszítések pazarlását, hogy olyan lehetőségeket keresnek, amelyek elfogadhatatlanok a kulcsfontosságú érdekelt felek számára, vagy amelyek túl kockázatosak.

Néhány káros, spirális megjelenésű folyamat megsérti ezt a követelményt, mivel kizárja a kulcsfontosságú szereplőket bizonyos szekvenciális fázisokból vagy ciklusokból. Lehetséges, hogy például a rendszer karbantartóit és rendszergazdáit nem hívják meg a rendszer meghatározásában és fejlesztésében való részvételre. Ennek eredményeként fennáll annak a veszélye, hogy a rendszer nem teljesíti nyerési feltételeit.

Az erőfeszítés mennyiségét a kockázat határozza meg[szerkesztés]

Minden projekttevékenységhez (pl. követelményelemzés, tervezés, prototípuskészítés, tesztelés) a projektcsoportnak el kell döntenie, hogy mekkora erőfeszítésre van szükség. Hiteles spirális folyamatciklusokban ezeket a döntéseket az általános kockázat minimalizálásával hozzák meg.

Például ha egy szoftvertermék tesztelésére több időt fordítanak, az általában csökkenti a hibás termék kockázatát. azonban növelheti a kockázatot a versenytárs korai piacra lépése miatt. A spirálmodell szemléletében a tesztelést csak addig kell végezni, amíg a teljes kockázat minimalizálódik, és nem tovább.

Ezen követelményt megsértő, káros, spirális megjelenésű folyamatok például az olyan evolúciós folyamatok, amelyek méretezhetőségi problémák miatt figyelmen kívül hagyják a kockázatot, vagy az olyan inkrementális folyamatok, amelyek túl nagy erőfeszítést tesznek egy olyan műszaki architektúra érdekében, amelyet a termék jövőbeli növekedése érdekében át kell majd alakítani vagy ki kell majd cserélni.

A részletességet kockázat határozza meg[szerkesztés]

Bármely projektjellemző esetén (pl. követelmény-specifikáció, tervezési dokumentum, tesztelési terv) a projekt csapatának el kell döntenie, hogy mekkora részlet elegendő. Hiteles spirális folyamatciklusokban ezeket a döntéseket az általános kockázat minimalizálásával hozzák meg.

Például tekintve a követelmények meghatározását, a projektnek pontosan meg kell határoznia azokat a jellemzőket, amelyekben a pontos specifikáció révén csökkentik a kockázatot (pl. Hardver és szoftver közötti interfészek, interfészek az elsődleges és alvállalkozók között). Ezzel szemben a projektnek nem kell pontosan meghatároznia azokat a funkciókat, amelyekben a pontos specifikáció növeli a kockázatot (pl. a grafikus képernyőkiosztás, az elkészített alkatrészek viselkedése).

Mérföldkövek alkalmazása[szerkesztés]

A spirálmodell eredeti Boehm-leírásában a folyamat mérföldkövei nem szerepeltek. A későbbi finomítások során azonban három sarkalatos mérföldkövet vezetett be, amelyek az előrehaladás mutatóiként és az elkötelezettségre jellemző pontokként szolgálnak. Ezeket a mérföldköveket az alábbi kulcsfontosságú kérdések jellemzik.

  1. Életcikluscélok. Megfelelően definiálják-e a technikai és irányítási megközelítést mindenki nyerési feltételeinek teljesítéséhez? Ha az érdekelt felek egyetértenek abban, hogy a válasz "igen", akkor a projekt elérte ezt a mérföldkövet. Ellenkező esetben a projekttel fel lehet hagyni, vagy az érintettek elkötelezhetik magukat egy másik ciklus mellett, amellyel ezen mérföldkő elérhető.
  2. Életciklus-szerkezet. Megfelelően definiálják-e az előnyben részesített megközelítést mindenki nyerési feltételeinek teljesítéséhez, és vajon minden jelentős kockázat kiküszöbölésre vagy enyhítésre kerül-e? Ha az érdekelt felek egyetértenek abban, hogy a válasz "igen", akkor a projekt elérte ezt a mérföldkövet. Ellenkező esetben a projekttel fel lehet hagyni, vagy az érintettek elkötelezhetik magukat egy másik ciklus mellett, amellyel ezen mérföldkő elérhető.
  3. Kezdeti működési képesség. Van-e megfelelő előkészítés a szoftver, a webhely, a felhasználók, az üzemeltetők és a karbantartók számára annak érdekében, hogy a rendszer elindításával mindenki kielégítse a nyerési feltételeket? Ha az érdekelt felek egyetértenek abban, hogy a válasz "igen", akkor a projekt elérte ezt a mérföldkövet, és a rendszer elindul. Ellenkező esetben a projekttel fel lehet hagyni, vagy az érintettek elkötelezhetik magukat egy másik ciklus mellett, amellyel ezen mérföldkő elérhető.

Ezen követelményt megsértő, káros, spirális megjelenésű folyamatok olyan evolúciós és inkrementális folyamatok, amelyek jelentős erőforrásokat fordítanak a rosszul meghatározott architektúrájú megoldás megvalósítására.

A három sarkalatos mérföldkő jól illeszkedik a egységesített racionális fejlesztési módszerbe (ERFM), az életcikluscélok jelölik a határt a ERFM beindulási és kidolgozási fázisai között, az életciklus-szerkezet jelöli a határt a fejlesztési és építési szakaszok között, és a kezdeti működési képesség jelöli a határt az építési és az átmeneti szakaszok között.

A rendszerre és annak életciklusára való összpontosítás[szerkesztés]

Ez a követelmény rávilágít az egész rendszer, a teljes életciklust átfogó hosszú távú szemlélet fontosságára. Az ezen követelménynek meg nem felelő káros, spirális megjelenésű folyamatok túl nagy figyelmet fordítanak a szoftverkód kezdeti fejlesztésére. Ezek a folyamatok az objektumorientált vagy strukturált szoftverelemzés és -tervezés közzétett megközelítéseinek követéséből származhatnak, miközben elhanyagolják a projekt folyamatkövetelményeinek más aspektusait.

Jegyzetek[szerkesztés]

  1. a b c d Boehm, B, "Spiral Development: Experience, Principles,and Refinements", Special Report CMU/SEI-2000-SR-008, July 2000 Forráshivatkozás-hiba: Érvénytelen <ref> címke, „:0” nevű forráshivatkozás többször van definiálva eltérő tartalommal
  2. a b Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986
  3. Boehm B, "A Spiral Model of Software Development and Enhancement", IEEE Computer, IEEE, 21(5):61-72, May 1988
  4. Pew RW, & Mavor AS (Eds.). (2007). "Human-system integration in the system development process: A new look", Washington, DC: National Academy Press

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Spiral 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 jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.