Model spiralny - Spiral model

Model spiralny (Boehm, 1988). Szereg nieporozumień wynika z uproszczeń na tym szeroko rozpowszechnionym schemacie (w tym schemacie są pewne błędy).

Model spiralny jest opartym na ryzyku modelem procesu tworzenia oprogramowania . Opierając się na unikalnych wzorcach ryzyka danego projektu, model spiralny prowadzi zespół do przyjęcia elementów jednego lub więcej modeli procesów, takich jak prototypowanie przyrostowe , kaskadowe lub ewolucyjne .

Historia

Model ten został po raz pierwszy opisany przez Barry'ego Boehma w jego artykule z 1986 r. „A Spiral Model of Software Development and Enhancement”. W 1988 roku Boehm opublikował podobny artykuł dla szerszej publiczności. Artykuły te wprowadzają schemat, który został powtórzony w wielu kolejnych publikacjach omawiających model spiralny.

Te wczesne artykuły używają terminu „model procesu” w odniesieniu do modelu spiralnego, a także do podejść przyrostowych, kaskadowych, prototypowania i innych. Jednak charakterystyczne, oparte na ryzyku mieszanie cech innych modeli procesów w modelu spiralnym jest już obecne:

Oparte na ryzyku podzbiory etapów modelu spiralnego pozwalają na dostosowanie modelu do dowolnej odpowiedniej kombinacji podejścia zorientowanego na specyfikację, zorientowanego na prototyp, zorientowanego na symulację, zorientowanego na automatyczną transformację lub innego podejścia do tworzenia oprogramowania.

W późniejszych publikacjach Boehm opisuje model spiralny jako „generator modelu procesu”, gdzie wybory oparte na ryzyku projektu generują odpowiedni model procesu dla projektu. Tak więc modele przyrostowe, kaskadowe, prototypowe i inne modele procesów są szczególnymi przypadkami modelu spiralnego, które pasują do wzorców ryzyka niektórych projektów.

Boehm identyfikuje również szereg nieporozumień wynikających z nadmiernych uproszczeń w oryginalnym diagramie modelu spiralnego. Mówi, że najbardziej niebezpieczne z tych nieporozumień to:

  • że spirala jest po prostu sekwencją przyrostów wodospadu;
  • że wszystkie działania w ramach projektu podążają jedną spiralną sekwencją;
  • że każda czynność na diagramie musi być wykonana w pokazanej kolejności.

Chociaż te błędne przekonania mogą pasować do wzorców ryzyka kilku projektów, nie są one prawdziwe w przypadku większości projektów.

W raporcie National Research Council model ten został rozszerzony o ryzyko związane z użytkownikami.

Aby lepiej odróżnić je od „niebezpiecznych podobnych do spirali”, Boehm wymienia sześć cech wspólnych dla wszystkich autentycznych zastosowań modelu spiralnego.

Sześć niezmienników modelu spiralnego

Autentyczne zastosowania modelu spiralnego są napędzane przez cykle, które zawsze wykazują sześć cech. Boehm ilustruje każdą z nich przykładem „niebezpiecznej spirali sobowtóra”, która narusza niezmiennik.

Definiuj artefakty jednocześnie

Kolejne definiowanie kluczowych artefaktów dla projektu często zwiększa możliwość opracowania systemu, który spełnia „warunki wygranej” interesariuszy (cele i ograniczenia).

Ten niezmiennik wyklucza procesy „niebezpiecznych podobnych do spirali”, które wykorzystują sekwencję przyrostowych przejść kaskadowych w ustawieniach, w których podstawowe założenia modelu kaskadowego nie mają zastosowania. Boehm wymienia te założenia w następujący sposób:

  1. Wymagania są znane przed wdrożeniem.
  2. Wymagania nie mają nierozwiązanych konsekwencji wysokiego ryzyka, takich jak ryzyko związane z kosztami, harmonogramem, wydajnością, bezpieczeństwem, interfejsami użytkownika, wpływami organizacyjnymi itp.
  3. Charakter wymagań nie zmieni się zbytnio podczas rozwoju lub ewolucji.
  4. Wymagania są zgodne z oczekiwaniami wszystkich kluczowych interesariuszy systemu, w tym użytkowników, klientów, programistów, opiekunów i inwestorów.
  5. Właściwa architektura implementacji wymagań jest dobrze zrozumiana.
  6. Jest wystarczająco dużo czasu w kalendarzu, aby postępować sekwencyjnie.

W sytuacjach, w których te założenia mają zastosowanie, istnieje ryzyko projektowe, aby nie określać wymagań i postępować sekwencyjnie. Model kaskadowy staje się w ten sposób szczególnym przypadkiem modelu spiralnego opartym na ryzyku.

Wykonaj cztery podstawowe czynności w każdym cyklu

Ten niezmiennik identyfikuje cztery czynności, które muszą wystąpić w każdym cyklu modelu spiralnego:

  1. Rozważ warunki wygranej wszystkich interesariuszy, którzy mają kluczowe znaczenie dla sukcesu.
  2. Zidentyfikuj i oceń alternatywne podejścia do spełnienia warunków zwycięstwa.
  3. Zidentyfikuj i rozwiąż ryzyko wynikające z wybranego podejścia (podejść).
  4. Uzyskaj zgodę wszystkich interesariuszy, którzy mają kluczowe znaczenie dla sukcesu, oraz zobowiązanie do kontynuowania kolejnego cyklu.

Cykle projektowe, które pomijają lub zmieniają dowolne z tych działań, ryzykują marnowanie wysiłku na poszukiwanie opcji, które są nie do przyjęcia dla kluczowych interesariuszy lub są zbyt ryzykowne.

Niektóre procesy „podobnych do niebezpiecznej spirali” naruszają ten niezmiennik, wykluczając kluczowych interesariuszy z pewnych sekwencyjnych faz lub cykli. Na przykład opiekunowie i administratorzy systemu mogą nie zostać zaproszeni do udziału w definiowaniu i rozwijaniu systemu. W rezultacie system jest zagrożony niespełnieniem warunków wygranej.

Ryzyko determinuje poziom wysiłku

W przypadku każdej czynności projektowej (np. analiza wymagań, projektowanie, prototypowanie, testowanie) zespół projektowy musi zdecydować, ile wysiłku wystarczy. W autentycznych spiralnych cyklach procesowych decyzje te podejmowane są poprzez minimalizację ogólnego ryzyka.

Na przykład poświęcenie dodatkowego czasu na testowanie oprogramowania często zmniejsza ryzyko związane z odrzuceniem przez rynek tandetnego produktu. Jednak dodatkowy czas testowania może zwiększyć ryzyko ze względu na wczesne wejście konkurenta na rynek. Z perspektywy modelu spiralnego, testowanie powinno być przeprowadzane do momentu zminimalizowania całkowitego ryzyka i nie dalej.

„Niebezpieczne podobieństwa spirali”, które naruszają ten niezmiennik, obejmują procesy ewolucyjne, które ignorują ryzyko ze względu na problemy ze skalowalnością, oraz procesy przyrostowe, które mocno inwestują w architekturę techniczną, którą należy przeprojektować lub wymienić, aby uwzględnić przyszłe przyrosty produktu.

Ryzyko determinuje stopień szczegółowości

W przypadku każdego artefaktu projektowego (np. specyfikacja wymagań, dokument projektowy, plan testów) zespół projektowy musi zdecydować, jaka ilość szczegółów jest wystarczająca. W autentycznych spiralnych cyklach procesowych decyzje te podejmowane są poprzez minimalizację ogólnego ryzyka.

Biorąc pod uwagę specyfikację wymagań jako przykład, projekt powinien precyzyjnie określać te cechy, w przypadku których ryzyko jest zredukowane poprzez precyzyjną specyfikację (np. interfejsy pomiędzy sprzętem a oprogramowaniem, interfejsy pomiędzy głównymi i podwykonawcami). I odwrotnie, projekt nie powinien precyzyjnie określać tych cech, w przypadku których precyzyjna specyfikacja zwiększa ryzyko (np. graficzne układy ekranów, zachowanie gotowych komponentów).

Użyj punktów kontrolnych punktów kontrolnych

Oryginalny opis modelu spiralnego przez Boehma nie zawierał żadnych kamieni milowych procesu. W późniejszych udoskonaleniach wprowadza trzy kamienie milowe punktów kontrolnych, które służą jako wskaźniki postępu i punkty zaangażowania. Te kamienie milowe punktów kontrolnych można scharakteryzować za pomocą kluczowych pytań.

  1. Cele cyklu życia. Czy istnieje wystarczająca definicja podejścia technicznego i zarządczego do zaspokojenia wszystkich warunków zwycięstwa? Jeśli interesariusze zgodzą się, że odpowiedź brzmi „Tak”, to projekt oczyścił ten kamień milowy LCO. W przeciwnym razie projekt może zostać porzucony lub interesariusze mogą zobowiązać się do innego cyklu, aby spróbować uzyskać „Tak”.
  2. Architektura cyklu życia. Czy istnieje wystarczająca definicja preferowanego podejścia do zaspokojenia wszystkich warunków zwycięstwa i czy wszystkie znaczące ryzyka są eliminowane lub ograniczane? Jeśli interesariusze zgodzą się, że odpowiedź brzmi „Tak”, to w ramach projektu został usunięty kamień milowy LCA. W przeciwnym razie projekt może zostać porzucony lub interesariusze mogą zobowiązać się do innego cyklu, aby spróbować uzyskać „Tak”.
  3. Początkowa zdolność operacyjna. Czy oprogramowanie, witryna, użytkownicy, operatorzy i opiekunowie są wystarczająco przygotowani, aby spełnić wszystkie warunki wygranej poprzez uruchomienie systemu? Jeśli interesariusze zgodzą się, że odpowiedź brzmi „Tak”, to projekt został uznany za kamień milowy MKOl i zostaje uruchomiony. W przeciwnym razie projekt może zostać porzucony lub interesariusze mogą zobowiązać się do innego cyklu, aby spróbować uzyskać „Tak”.

„Niebezpieczne spiralne sobowtóry”, które naruszają ten niezmiennik, obejmują procesy ewolucyjne i przyrostowe, które przeznaczają znaczne zasoby na wdrożenie rozwiązania o słabo zdefiniowanej architekturze.

Trzy kamienie milowe punktów kontrolnych łatwo wpasowują się w Rational Unified Process (RUP), przy czym LCO oznacza granicę między fazami rozpoczęcia i opracowywania RUP, LCA oznacza granicę między fazami opracowania i budowy, a IOC oznacza granicę między fazami budowy i przejścia.

Skup się na systemie i jego cyklu życia

Ten niezmiennik podkreśla znaczenie całego systemu i długoterminowe problemy obejmujące cały cykl życia. Wyklucza to „niebezpieczne spiralne sobowtóry”, które zbytnio skupiają się na początkowym rozwoju kodu oprogramowania. Procesy te mogą wynikać z przestrzegania opublikowanych podejść do analizy i projektowania oprogramowania zorientowanego obiektowo lub ustrukturyzowanego, przy jednoczesnym pominięciu innych aspektów potrzeb procesowych projektu.

Bibliografia