Spirálový model - Spiral model

Spirálový model (Boehm, 1988). Řada mylných představ vychází ze zjednodušování v tomto široce šířeném diagramu (v tomto diagramu jsou některé chyby).

Spirála modelu je riziko-řízený proces vývoje softwaru modelu. Na základě jedinečných rizikových modelů daného projektu vede spirálový model tým k přijetí prvků jednoho nebo více procesních modelů, jako jsou přírůstkové , vodopády nebo evoluční prototypy .

Dějiny

Tento model poprvé popsal Barry Boehm ve svém článku z roku 1986 „Spirálový model vývoje a vylepšení softwaru“. V roce 1988 Boehm publikoval podobný dokument pro širší publikum. Tyto práce zavádějí diagram, který byl reprodukován v mnoha dalších publikacích pojednávajících o spirálovém modelu.

Tyto rané práce používají termín „procesní model“ pro označení spirálového modelu i pro přírůstkové, vodopádové, prototypové a další přístupy. Charakteristické míchání vlastností dalších procesních modelů spirálového modelu založené na riziku však již existuje:

[R] isk-driven podmnožina kroků spirálového modelu umožňuje modelu přizpůsobit se jakékoli vhodné směsi specifikací, prototypů, simulací, automatických transformací nebo jiného přístupu k vývoji softwaru.

V pozdějších publikacích Boehm popisuje spirálový model jako „generátor procesního modelu“, kde volby založené na rizicích projektu generují vhodný procesní model pro projekt. Inkrementální, vodopádové, prototypové a další procesní modely jsou tedy speciálními případy spirálového modelu, které odpovídají rizikovým modelům určitých projektů.

Boehm také identifikuje řadu mylných představ vyplývajících ze zjednodušování v původním spirálovém modelu. Říká, že nejnebezpečnější z těchto mylných představ jsou:

  • že spirála je jednoduše posloupností přírůstků vodopádu;
  • že všechny projektové aktivity sledují jednu spirálovou sekvenci;
  • že každá činnost v diagramu musí být provedena a v uvedeném pořadí.

I když tyto mylné představy mohou odpovídat rizikovým modelům několika projektů, u většiny projektů nejsou pravdivé.

Ve zprávě Národní rady pro výzkum byl tento model rozšířen o rizika spojená s lidskými uživateli.

Aby je lépe odlišil od „nebezpečných spirálových dvojníků“, uvádí Boehm šest charakteristik společných pro všechny autentické aplikace spirálového modelu.

Šest invarianty spirálového modelu

Autentické aplikace spirálového modelu jsou poháněny cykly, které vždy zobrazují šest charakteristik. Boehm ilustruje každý na příkladu „nebezpečné podobné spirály“, která porušuje invariant.

Definujte artefakty souběžně

Postupné definování klíčových artefaktů pro projekt často zvyšuje možnost vývoje systému, který splňuje „podmínky výhry“ zúčastněných stran (cíle a omezení).

Tento invariant vylučuje procesy „nebezpečného spirálového vzhledu“, které používají posloupnost přírůstkových vodopádových průchodů v nastavení, kde neplatí základní předpoklady modelu vodopádu. Boehm uvádí tyto předpoklady takto:

  1. Požadavky jsou známy před implementací.
  2. Požadavky nemají žádné nevyřešené, vysoce rizikové důsledky, jako jsou rizika způsobená náklady, plánem, výkonem, bezpečností, uživatelskými rozhraními, organizačními dopady atd.
  3. Povaha požadavků se během vývoje nebo evoluce příliš nezmění.
  4. Požadavky jsou kompatibilní s očekáváními všech klíčových účastníků systému, včetně uživatelů, zákazníků, vývojářů, správců a investorů.
  5. Správná architektura pro implementaci požadavků je dobře známa.
  6. K dispozici je dostatek kalendářního času na postupné postupování.

V situacích, kdy tyto předpoklady platí, je rizikem projektu nespecifikovat požadavky a postupovat postupně. Model vodopádu se tak stává rizikovým zvláštním případem spirálového modelu.

Provádějte čtyři základní činnosti v každém cyklu

Tento invariant identifikuje čtyři aktivity, které musí nastat v každém cyklu modelu spirály:

  1. Zvažte podmínky vítězství všech zúčastněných stran, které mají zásadní úspěch.
  2. Identifikujte a vyhodnoťte alternativní přístupy k uspokojení podmínek výhry.
  3. Identifikujte a vyřešte rizika, která vyplývají z vybraných přístupů.
  4. Získejte souhlas od všech zúčastněných stran, které mají zásadní význam pro úspěch, plus závazek pokračovat v dalším cyklu.

Projektové cykly, které některou z těchto aktivit vynechají nebo zkrátí, riskují plýtvání úsilím sledováním možností, které jsou pro klíčové zúčastněné strany nepřijatelné nebo jsou příliš riskantní.

Některé procesy podobné „nebezpečnému spirálovému vzhledu“ porušují tento invariant tím, že vylučují klíčové zúčastněné strany z určitých sekvenčních fází nebo cyklů. Například správci systému a správci nemusí být pozváni k účasti na definici a vývoji systému. Výsledkem je riziko, že systém nesplní své podmínky pro výhru.

Úroveň úsilí určuje riziko

U jakékoli projektové činnosti (např. Analýza požadavků, návrh, prototypování, testování) musí projektový tým rozhodnout, kolik úsilí stačí. V autentických spirálových procesních cyklech se tato rozhodnutí přijímají minimalizací celkového rizika.

Například investování dalšího času do testování softwarového produktu často snižuje riziko kvůli tomu, že trh odmítá nekvalitní produkt. Další čas na testování však může zvýšit riziko v důsledku brzkého vstupu konkurenta na trh. Z pohledu spirálového modelu by testování mělo být prováděno, dokud nebude minimalizováno celkové riziko, a dále.

Mezi „nebezpečné spirálové podobné“, které porušují tento invariant, patří evoluční procesy, které ignorují riziko kvůli problémům se škálovatelností, a přírůstkové procesy, které intenzivně investují do technické architektury, která musí být přepracována nebo nahrazena, aby vyhovovala budoucím přírůstkům produktu.

Stupeň detailů určuje riziko

U jakéhokoli artefaktu projektu (např. Specifikace požadavků, dokument návrhu, plán zkoušek) musí projektový tým rozhodnout, kolik podrobností stačí. V autentických spirálových procesních cyklech se tato rozhodnutí přijímají minimalizací celkového rizika.

S ohledem na specifikaci požadavků jako příklad by měl projekt přesně specifikovat ty funkce, kde je riziko sníženo přesnou specifikací (např. Rozhraní mezi hardwarem a softwarem, rozhraní mezi hlavními a subdodavateli). Naopak by projekt neměl přesně specifikovat ty funkce, u nichž přesná specifikace zvyšuje riziko (např. Grafické rozložení obrazovky, chování běžných komponent).

Použijte milníky kotevních bodů

Boehmův původní popis spirálového modelu neobsahoval žádné milníky procesu. V pozdějších vylepšeních zavádí tři milníky kotevních bodů, které slouží jako indikátory pokroku a body závazku. Tyto milníky kotevních bodů lze charakterizovat klíčovými otázkami.

  1. Cíle životního cyklu. Existuje dostatečná definice technického a manažerského přístupu k uspokojení podmínek výhry každého? Pokud se zúčastněné strany shodnou, že odpověď zní „ano“, projekt tento milník LCO odstranil. Jinak lze od projektu upustit nebo se zúčastněné strany mohou zavázat k dalšímu cyklu, aby se pokusily dostat na „Ano“.
  2. Architektura životního cyklu. Existuje dostatečná definice upřednostňovaného přístupu k uspokojení podmínek výhry všech a jsou všechna významná rizika eliminována nebo zmírněna? Pokud se zúčastněné strany shodnou, že odpověď zní „ano“, projekt tento milník LCA odstranil. Jinak lze od projektu upustit nebo se zúčastněné strany mohou zavázat k dalšímu cyklu, aby se pokusily dostat na „Ano“.
  3. Počáteční operační schopnost. Existuje dostatečná příprava softwaru, webu, uživatelů, operátorů a správců k uspokojení podmínek pro výhru každého spuštěním systému? Pokud se zúčastněné strany dohodnou, že odpověď zní „ano“, projekt vyčistil milník MOV a je zahájen. Jinak lze od projektu upustit nebo se zúčastněné strany mohou zavázat k dalšímu cyklu, aby se pokusily dostat na „Ano“.

Mezi „nebezpečné spirálové dvojníky“, které porušují tento invariant, patří evoluční a přírůstkové procesy, které vyčleňují značné prostředky na implementaci řešení se špatně definovanou architekturou.

Tři milníky kotevních bodů snadno zapadají do Rational Unified Process (RUP), přičemž LCO označuje hranici mezi fázemi RUP Inception a Elaboration, LCA označuje hranici mezi fázemi Elaboration a Construction a IOC označuje hranici mezi fázemi výstavby a přechodu.

Zaměření na systém a jeho životní cyklus

Tento invariant zdůrazňuje důležitost celého systému a dlouhodobé zájmy pokrývající celý jeho životní cyklus. Vylučuje to „nebezpečné spirálové podobné“, které se příliš zaměřují na počáteční vývoj softwarového kódu. Tyto procesy mohou vyplynout z následujících publikovaných přístupů k objektově orientované nebo strukturované softwarové analýze a designu, při zanedbání dalších aspektů procesních potřeb projektu.

Reference