Plik wzór spirali jest archetypem procesu tworzenia aplikacji. Opiera się na hipotezie, że tworzenie oprogramowania to cykl iteracyjny, który powtarza się, aż do osiągnięcia ustalonych celów. Ma zdolność radzenia sobie z dużą liczbą zagrożeń, które mogą wystąpić podczas tworzenia dowolnego oprogramowania.
Jest to jeden z najważniejszych modeli wspierających zarządzanie ryzykiem. Jak sama nazwa wskazuje, model ten ma kształt spirali, gdzie poszczególne etapy modelu są rozłożone w różnych cyklach. Liczba cykli w modelu nie jest ustalona i może się różnić w zależności od projektu.
Indeks artykułów
Model spiralny został zdefiniowany przez amerykańskiego matematyka i profesora inżynierii oprogramowania Barry'ego Boehma. Po przedstawieniu w 1986 roku swojej koncepcji rozwoju złożonych aplikacji, opublikował swój model w 1988 roku w bardziej obszernych ramach w artykule „Spiralny model tworzenia i doskonalenia oprogramowania".
Część tej publikacji z 1988 roku przedstawiła graficznie model spiralny, w pełni pokazując, jak wygląda proces tworzenia oprogramowania w sposób spiralny i wspierany cyklami..
Boehm jest znany ze swoich licznych wkładów w inżynierię oprogramowania, takich jak konstruktywny model kosztów (COCOMO), spiralny model procesu tworzenia oprogramowania, teoria G (korzystna dla wszystkich) podejście do określania wymagań i zarządzania oprogramowaniem..
W swojej publikacji Boehm opisał model spiralny jako możliwą alternatywę dla wcześniej ustalonego modelu wodospadu, który był również podstawą jego praktyki..
Model spiralny nie był pierwszym, w którym omówiono cykliczny rozwój, ale jako pierwszy wyjaśnił, dlaczego iteracja jest ważna. Jak pierwotnie przewidywano, był on ukierunkowany na duże, złożone projekty, których powtórzenia zwykle trwają od 6 miesięcy do 2 lat..
Ten model nie zakłada, że zadania tworzenia oprogramowania są projektowane liniowo, w przeciwieństwie do modelu kaskadowego, ale postrzega je jako zadania iteracyjne.
Ten cykliczny model wpłynął na architekturę inżynierii oprogramowania opartą na modelach (MBASE) i programowanie ekstremalne.
To, co znacznie odróżnia ten model od innych modeli procesu tworzenia oprogramowania, to fakt, że wyraźnie rozpoznaje ryzyko. W ten sposób znacznie ogranicza niepowodzenie dużych projektów oprogramowania poprzez wielokrotną ocenę ryzyka i każdorazową weryfikację opracowywanego produktu..
Ten model komputerowy zawiera komponenty prawie każdego innego modelu cyklu życia oprogramowania, takie jak model kaskadowy, model prototypowania, model iteracyjny, model ewolucyjny itp..
Z tego powodu jest w stanie poradzić sobie z prawie każdym rodzajem ryzyka, z którym inne modele na ogół nie radzą sobie. Jednak ze względu na tak wiele komponentów ten model jest znacznie bardziej złożony niż inne modele tworzenia oprogramowania..
Każdy obrót spirali reprezentuje pełny cykl, przez który zawsze przechodzą cztery ćwiartki, reprezentujące cztery etapy modelu..
Wraz ze wzrostem rozmiaru spirali postępuje również. Dlatego etapy nie są wykonywane tylko raz, ale kilka razy w formie spirali..
Chociaż to cykliczne powtarzanie powoduje, że projekt powoli zbliża się do założonych celów, ryzyko niepowodzenia procesu rozwoju jest mocno zminimalizowane..
Cztery etapy realizują tylko podstawowe cele cyklu, ale nie muszą się one manifestować w każdym cyklu.
Kolejność każdego cyklu również nie jest ściśle określona. Dlatego model można w dowolnym momencie łączyć z innymi modelami.
Jest dość elastyczny, ponieważ procesy definiowania celów, analizy ryzyka, rozwoju i planowania przeprowadzane są osobno dla każdej fazy projektu..
Jest uważany za metamodel, ponieważ zawiera inne modele. Na przykład, gdyby spirala miała jeden cykl, reprezentowałaby model wodospadu, ponieważ zawiera stopniowe podejście tego klasycznego modelu.
Wykorzystuje również podejście oparte na modelu prototypowania, ponieważ na początku każdego cyklu składa prototyp w celu zarządzania ryzykiem..
Ponadto jest zgodny z modelem ewolucyjnym, ponieważ iteracje spirali można uznać za poziomy ewolucyjne, przez które budowany jest ostateczny system..
Wymagania systemowe są zdefiniowane tak szczegółowo, jak to możliwe, w tym wydajność, interfejsy sprzętowe / programowe, kluczowe wskaźniki sukcesu itp. i zastanów się, które cele powinny być powiązane z bieżącym cyklem rozwoju.
Ponadto badane są różne alternatywy dla jego implementacji, takie jak build vs. kupować, ponownie wykorzystywać istniejące komponenty lub zlecać na zewnątrz itp..
Podobnie określa się ograniczenia, takie jak koszt, harmonogram i interfejsy, zużycie czasu itp..
Wszystkie proponowane alternatywy są oceniane. Cele i ograniczenia służą jako wyznaczające punkty odniesienia przy wyborze najlepszego rozwiązania.
Ponadto identyfikowane są ryzyka, które mogą utrudniać powodzenie projektu, takie jak brak doświadczenia, nowe technologie, napięte harmonogramy, wadliwe procesy itp., Wdrażanie najbardziej dochodowych strategii przy najmniejszym ryzyku..
Wreszcie, wykorzystywane są takie metody, jak prototypowanie, symulacje, modele analityczne i ankiety wśród użytkowników..
Wszystkie niezbędne prace rozwojowe są przeprowadzane przy użyciu wybranej technologii i rozwiązania. Z każdą iteracją tworzona jest lepsza wersja aplikacji.
Rzeczywisty kod jest zapisywany i testowany kilka razy, aż do osiągnięcia pożądanego rezultatu, który posłuży jako podstawa do przyszłych etapów rozwoju.
Po zakończeniu jednego cyklu rozpoczyna się planowanie następnego. Planowanie to mogłoby polegać na normalnej kontynuacji projektu, jeśli cel cyklu zostałby osiągnięty, biorąc pod uwagę definicję następnego celu.
Można by też znaleźć inne rozwiązania, gdyby poprzedni etap rozwoju okazał się wadliwy. Istniejącą strategię można zastąpić jedną z wcześniej zdefiniowanych alternatyw lub nową. W ten sposób rozpoczęłaby się nowa próba osiągnięcia wyznaczonego celu..
Armia Stanów Zjednoczonych przyjęła spiralny model rozwoju i aktualizacji programu modernizacji Future Fighting Systems (SCF)..
Oficjalnie uruchomione w 2003 roku SCF miały wyposażyć żołnierzy w pojazdy połączone w czasie rzeczywistym z niezwykle szybką i elastyczną siecią pól bitewnych..
Projekt został podzielony na cztery spirale rozwoju, z których każda trwa około dwóch lat. Spiral 1 miał rozpocząć się w 2008 roku i dostarczyć prototypy do użytku i oceny..
Po ukończeniu Spiral 1, Spiral 2 miał rozpocząć się w 2010 roku. Ostateczny rozwój produktu miał być dostarczony w 2015 roku..
W sierpniu 2005 roku Boeing ogłosił zakończenie pierwszego ważnego etapu projektu, jakim był przegląd funkcjonalny systemów. Współprzewodniczącymi projektu byli Boeing i Science Applications International Corporation.
Jednak w październiku 2005 r. Pentagon zalecił opóźnienie realizacji projektu ze względu na duży wpływ na koszty wojny w Iraku i pomoc ze strony huraganu Katrina..
Projekt został anulowany w 2009 roku po cięciach budżetowych, nie będąc w stanie udowodnić zalet modelu spiralnego w tej misji.
Ze względu na tego typu konstrukcję problemy między projektem a wymaganiami technicznymi oprogramowania są milcząco eliminowane dzięki okresowym kontrolom..
Ryzyka są analizowane na każdym etapie produktu, zanim przejdziesz dalej. Pomaga to przezwyciężyć lub złagodzić potencjalne ryzyko.
Wszyscy pracownicy korzystają z dużego znaczenia analizy ryzyka w tym modelu, co może stanowić ich największą przewagę nad innymi modelami procesów.
Regularna ocena ryzyka zyskuje na wartości w przypadku korzystania z nowatorskich środowisk technicznych, które są generalnie związane z określonym potencjałem ryzyka ze względu na brak wartości empirycznych.
Klienci są zaangażowani na każdym etapie projektu, aż do jego zakończenia. Dlatego można zebrać różne opinie, aby ulepszyć następną wersję projektu..
Ponadto w każdej chwili można uzyskać informację zwrotną dzięki postępowi spirali. W ten sposób klienci i użytkownicy mogą zostać zintegrowani od samego początku w procesie rozwoju.
Jest szczególnie popularny i widoczny w przypadku dużych i złożonych projektów, w których kontrola budżetu jest priorytetem dla klientów i programistów. Masz maksymalną kontrolę nad kosztami, zasobami i jakością projektu oprogramowania.
Może to być dość kosztowne, ponieważ wymaga wysokiego poziomu wiedzy specjalistycznej w zakresie analizy ryzyka. Ponadto opracowanie projektów zajmuje dużo czasu, co może zwiększyć koszty ogólne.
Wymagane jest bardzo aktywne i kompleksowe wcześniejsze zarządzanie projektem, w którym każdy cykl jest stale i dokładnie kontrolowany i dokumentowany.
Jest stosunkowo bardziej złożony niż inne modele, ponieważ istnieje wiele cykli, z których każdy przechodzi przez inne etapy, co zwiększa wysiłek związany z procesem dokumentacji..
Niezbędna jest wiedza na temat analizy ryzyka i zarządzania nim, która często nie jest dostępna.
Zarządzanie czasem jest trudne, ponieważ liczba cykli jest nieznana. Dodatkowo, proces rozwoju może zostać opóźniony w dowolnym momencie, jeśli konieczne jest podjęcie ważnych decyzji w ramach cyklu lub przez dodatkowe działania podczas planowania kolejnego cyklu..
Nie zawsze jest korzystne wykonywanie wielu kroków w rozwoju oprogramowania, ponieważ pomimo wszechstronności testów niedokończone części programu mogą dotrzeć do gotowego systemu..
W konsekwencji zawsze istnieje niebezpieczeństwo, że jakikolwiek błąd lub niespójność koncepcyjna wpłynie na produkt końcowy..
Jeszcze bez komentarzy