„Spirálmodell” változatai közötti eltérés

[nem ellenőrzött változat][ellenőrzött változat]
Tartalom törölve Tartalom hozzáadva
aNincs szerkesztési összefoglaló
→‎Történelem: nyelvhelyesség
2. sor:
A '''spirálmodell''' kockázatvezérelt [[Szoftverfejlesztési folyamat|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énelemTörténete ==
EztA amodell modelltmeghatározását először [[Barry Boehm]] amerikai [[Szoftverfejlesztő|szoftvermérnök]] írtaadta lemeg ''A szoftverfejlesztés és továbbfejlesztés spirálmodellje'' című 1986-os tanulmányában.,<ref name=":2">Boehm B, [http://doi.acm.org/10.1145/12944.12948 "A Spiral Model of Software Development and Enhancement]", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref> majd a témát a szélesebb közönség számára 1988-ban Boehm hasonló publikációtismét publikáltfeldolgozta.<ref name=":1">Boehm B, [http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-500/usccse88-500.pdf "A Spiral Model of Software Development and Enhancement]", IEEE Computer, IEEE, 21(5):61-72, May 1988</ref> a szélesebb közönség számára. EzekEzekben a tanulmányoktanulmányokban bevezetnekbevezetett egy olyan diagramot, amelyet a spirális modellt tárgyaló számos későbbi publikáció reprodukáltis közölt.
 
Ezek a korai tanulmányok a "''folyamatmodell"'' kifejezést használják a spirálmodellre, valamintahogy az inkrementális, a vízesés-, a prototípus- és egyéb megközelítésekre való utaláshozis. Ugyanakkor a spirális modell jellegzetes, kockázat vezéreltkockázatvezérelt keverése más folyamatmodellek jellemzőivel már megvane cikkekben is szerepel: <blockquote>„''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.”''<ref name=":2" /></blockquote>Későbbi írásaiban Boehm a spirális modellt ''folyamatmodell-generátornak'' írja le,<ref name=":0" /> 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. AztÁllítása állítja,szerint hogyaz aalábbi félreértések közüllehetnek a legveszélyesebblegveszélyesebbek:
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
 
* hogy a spirál egyszerűen egy vízesés növekményének sorrendje;
Későbbi publikációkban <ref name=":0">Boehm, B, "[https://resources.sei.cmu.edu/asset_files/SpecialReport/2000_003_001_13655.pdf Spiral Development: Experience, Principles,and Refinements]", Special Report CMU/SEI-2000-SR-008, July 2000</ref> Boehm a spirális modellt „folyamatmodell generátornak” írja le, 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.
* hogy a projekt minden tevékenysége egy spirál sorozatotspirálsorozatot kövessen;
 
* hogy a diagram minden tevékenységét végre kell hajtani, és a bemutatott sorrendben.
Boehm emellett számos téves elképzelést azonosít az eredeti spirális modelldiagram egyszerűsítéseiből. Azt állítja, hogy a félreértések közül a legveszélyesebb:
 
* hogy a spirál egyszerűen egy vízesés növekményének sorrendje;
* hogy a projekt minden tevékenysége egy spirál sorozatot kövessen;
* hogy a diagram minden tevékenységét végre kell hajtani, és 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.
 
AAz amerikai [[Nemzeti Kutatási Tanács]] (National Research Council) jelentésében<ref>Pew RW, & Mavor AS (Eds.). (2007). [http://books.nap.edu/catalog.php?record_id=11893 "Human-system integration in the system development process: A new look]", Washington, DC: National Academy Press</ref> 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 "veszélyeskáros, spirális megjelenésektőlmegjelenésű folyamatoktól", Boehm hat jellemzőtkövetelményt sorol fel, amelyek a spirális modell minden hiteles alkalmazásábanalkalmazásához közösekszükségesek.<ref name=":0" />
 
== A spirálmodell ciklusainak hat invariánsakövetelménye ==
A spirális modell hiteles alkalmazásátalkalmazásában olyanminden ciklusokciklusnak hajtják,meg amelyekkell mindigfelelnie hataz tulajdonságotalábbiakban mutatnakrészletezett hat követelménynek. Boehm illusztráljamindegyik mindegyiketkövetelmény egymegsértésére "veszélyeshozott spirálisfel megjelenésű"olyan példávalpéldát, amelyami megsértialapján aza csak látszólag spirális, de valójában káros folyamatok invariánstfelismerhetőek.<ref name=":0">Boehm, B, "[https://resources.sei.cmu.edu/asset_files/SpecialReport/2000_003_001_13655.pdf Spiral Development: Experience, Principles,and Refinements]", Special Report CMU/SEI-2000-SR-008, July 2000</ref>
 
=== A tárgyak egyidejű meghatározása ===
=== Definiálja a tárgyakat egyidejűleg ===
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 azalapján invariánsa követelmény nemalapján zárjazárhatók ki aazon „veszélyeskáros, spirális megjelenésű”megjelenésű folyamatokatfolyamatok, amelyekben növekményesinkrementális vízesés-sorozatot alkalmaznak olyan helyzetekben, ahol a vízesés modellvízesésmodell alapvető feltételezései nem érvényesek. Boehm az alábbiak szerint sorolja fel ezeket a feltételezéseket:
 
# A követelmények a végrehajtás előtt ismertek.
# 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. Miattmiatt felmerülő kockázatok.
# A követelmények jellege a fejlesztés vagy az evolúció során nem változik sokat.
# 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.
38 ⟶ 34 sor:
# Elegendő naptári idő van a szekvenciális folytatáshoz.
 
Olyan helyzetekben, amikor ezek a feltételezésekfeltételek érvényesekteljesü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ázat-vezéreltkockázatvezérelt különleges esetévé válik.
 
=== Végezzen elA négy alaptevékenységetalaptevékenység elvégzése minden ciklusban ===
Ez aza invariánskövetelmény azonosítja azt a négy tevékenységet, amelyeknek a spirális modell minden ciklusában meg kell valósulnia:
 
# Vegye figyelembe az összes sikerkritikus érdekelt fél nyerési feltételeit.
# Azonosítsa és értékelje a nyerési feltételek teljesítésének alternatív módszereit.
# Azonosítsa és oldja megfel a kiválasztott megközelítés(ek)ből eredő kockázatokat.
# Szerezzen jóváhagyást minden sikert kritikussikerkritikus érdekelt féltől, és vállaljabiztosí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 "veszélyeskáros, spirális megjelenésű" folyamat megsérti ezt aza invariánstkö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 ===
=== A kockázat határozza meg az erőfeszítés szintjét ===
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öltenek továbbitöbb időt fordítanak, gyakranaz általában csökkenti annak kockázatát, hogy a piachibás elutasítjatermék a rossz terméketkockázatát. A kiegészítő tesztelési idő azonban növelheti a kockázatot a versenytárs korai piacra lépése miatt. SpirálmodellA spirálmodell szempontjábólszemléletében a tesztelést csak addig kell elvégeznivégezni, amíg a teljes kockázat minimálisra nem kerülminimalizálódik, és nem tovább.
 
AEzen "veszélyeskövetelményt spirálismegsértő, megjelenés"káros, amelyspirális megsértimegjelenésű eztfolyamatok az invariánst,például magábanaz foglalja azolyan evolúciós folyamatokatfolyamatok, amelyek méretezhetőségi problémák miatt figyelmen kívül hagyják a kockázatot a méretezhetőségi problémák miatt, ésvagy az olyan inkrementális folyamatokatfolyamatok, amelyek erőteljesentúl befektetneknagy erőfeszítést tesznek egy olyan műszaki architektúrábaarchitektú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 termék jövőbeni növekedése érdekében.
 
=== A részletességet kockázat határozza meg a részletek mértékét ===
Bármely projekt leleteprojektjellemző 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. Aa grafikus képernyőkiosztás, az elkészített alkatrészek viselkedése).
 
=== Mérföldkövek alkalmazása ===
=== Használjon rögzítési pont mérföldköveket ===
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 rögzítési pontsarkalatos mérföldkövet mutatvezetett be, amelyek haladásiaz mutatókkéntelőrehaladás mutatóiként és elkötelezettségaz elkötelezettségre jellemző pontokként szolgálnak. Ezeket a rögzítésimérföldköveket az pontokatalábbi kulcsfontosságú kérdések jellemzik.
 
# Életciklus céljai'''É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 megtisztítottaelérte ezt az "életciklus céljai"a mérföldkövet. Ellenkező esetben a projektetprojekttel elfel lehet hagyni, vagy az érintettek elkötelezhetnekelkötelezhetik magukat egy másik ciklus mellett, hogyamellyel megpróbáljákezen elérnimérföldkő az "Igen" szótelérhető.
# '''É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 megtisztítottaelérte ezt aza "életciklus szerkezet "mérföldkövet. Ellenkező esetben a projektetprojekttel elfel lehet hagyni, vagy az érintettek elkötelezhetnekelkötelezhetik magukat egy másik ciklus mellett, hogyamellyel megpróbáljákezen elérnimérföldkő az "Igen" szótelérhető.
# '''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 megtisztítottaelérte ezt a "kezdetimérföldkövet, működésiés képesség"a mérföldkövét ésrendszer elindul. Ellenkező esetben a projektetprojekttel elfel lehet hagyni, vagy az érintettek elkötelezhetnekelkötelezhetik magukat egy másik ciklus mellett, hogyamellyel megpróbáljákezen elérnimérföldkő az "Igen" szótelérhető.
 
AEzen "veszélyeskövetelményt spirálismegsértő, megjelenés"káros, amely megsérti ezt az invariánst,spirális magábanmegjelenésű foglaljafolyamatok azolyan evolúciós és inkrementális folyamatokatfolyamatok, 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 rögzítésisarkalatos pontmérföldkő mérföldköve könnyenjól illeszkedik a [[egységesített racionális fejlesztési módszer|egységesített racionális fejlesztési módszerbe]] (ERFM) közé, az életciklus céljaiéletcikluscélok jelölijelölik a határt a ERFM beindulási és kidolgozási fázisai között, az Életciklusé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.
 
=== Összpontosítson aA rendszerre és annak életciklusára való összpontosítás ===
Ez a változatlanságkövetelmény rávilágít az egész rendszer fontosságára és, a teljes életciklusátéletciklust átfogó hosszú távú aggodalmakraszemlélet fontosságára. NemAz zárjaezen kikövetelménynek ameg "veszélyesnem felelő káros, spirális megjelenésimegjelenésű formákat", amelyekfolyamatok túl soknagy figyelmet fordítanak a szoftver kódszoftverkó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 ==