Model wodospadu - Waterfall model

Niezmodyfikowany „model wodospadu”. Postęp płynie od góry do dołu, jak kaskadowy wodospad.

Model kaskadowy to podział działań projektowych na liniowe sekwencyjne fazy, gdzie każda faza zależy od rezultatów poprzedniej i odpowiada specjalizacji zadań. Podejście to jest typowe dla niektórych obszarów projektowania inżynierskiego . W tworzeniu oprogramowania zwykle należy do mniej iteracyjnych i elastycznych podejść, ponieważ postęp płynie głównie w jednym kierunku („w dół” jak wodospad ) przez fazy koncepcji, inicjacji, analizy , projektowania , budowy , testowania , wdrażania i konserwacji .

Model rozwoju wodospadu powstał w przemyśle wytwórczym i budowlanym ; gdzie wysoce ustrukturyzowane środowiska fizyczne powodowały, że zmiany projektowe stały się zbyt kosztowne znacznie wcześniej w procesie rozwoju. Kiedy po raz pierwszy przyjęto do tworzenia oprogramowania, nie było uznanych alternatyw dla kreatywnej pracy opartej na wiedzy.

Historia

Pierwszą znaną prezentację opisującą zastosowanie takich faz w inżynierii oprogramowania wygłosił Herbert D. Benington na Sympozjum Zaawansowanych Metod Programowania Komputerów Cyfrowych w dniu 29 czerwca 1956 r. Prezentacja ta dotyczyła rozwoju oprogramowania dla SAGE . W 1983 r. artykuł został ponownie opublikowany z przedmową Beningtona wyjaśniającą, że fazy zostały celowo zorganizowane zgodnie ze specjalizacją zadań i wskazując, że proces nie był w rzeczywistości wykonywany w sposób ściśle odgórny, ale opierał się na prototypie. .

Chociaż termin „wodospad” nie jest używany w artykule, pierwszy formalny szczegółowy schemat procesu, znany później jako „model wodospadu”, jest często cytowany jako artykuł Winstona W. Royce'a z 1970 roku . Czuł jednak również, że ma on poważne wady wynikające z faktu, że testowanie odbywało się dopiero pod koniec procesu, który opisał jako „ryzykowny i zachęcający do niepowodzenia”. W pozostałej części jego artykułu przedstawiono pięć kroków, które jego zdaniem były konieczne do „wyeliminowania większości zagrożeń rozwojowych” związanych z niezmienionym podejściem kaskadowym.

Pięć dodatkowych kroków Royce'a (które obejmowały pisanie pełnej dokumentacji na różnych etapach rozwoju) nigdy nie przyjęły głównego nurtu, ale jego diagram tego, co uważał za wadliwy proces, stał się punktem wyjścia przy opisywaniu podejścia „wodospadowego”.

Najwcześniejsze użycie terminu „wodospad” mogło mieć miejsce w artykule Bella i Thayera z 1976 roku.

W 1985 roku Departament Obrony Stanów Zjednoczonych uchwycił to podejście w DOD-STD-2167A , swoich standardach pracy z wykonawcami oprogramowania, w których stwierdzono, że „wykonawca wdroży cykl rozwoju oprogramowania, który obejmuje następujące sześć faz: Analiza wymagań dotyczących oprogramowania , Projekt wstępny, projekt wykonawczy, kodowanie i testy jednostkowe, integracja i testowanie”.

Model

W oryginalnym modelu wodospadu Royce'a następujące fazy są przestrzegane w kolejności:

  1. Wymagania systemowe i programowe : ujęte w dokumencie wymagań produktu
  2. Analiza : wynikające z modeli , schematu i reguł biznesowych
  3. Projekt : w wyniku architektury oprogramowania
  4. Kodowanie : rozwój , sprawdzanie i integracja oprogramowania
  5. Testowanie : systematyczne odkrywanie i debugowania od wad
  6. Operacje : instalacja , migracja , wsparcie i utrzymanie kompletnych systemów

Zatem model kaskadowy zakłada, że ​​należy przejść do fazy tylko wtedy, gdy poprzednia faza jest przeglądana i weryfikowana.

Różne zmodyfikowane modele kaskadowe (w tym ostateczny model Royce'a) mogą jednak zawierać niewielkie lub duże zmiany tego procesu. Zmiany te obejmowały powrót do poprzedniego cyklu po wykryciu wad w dalszej części procesu lub powrót do fazy projektowania, jeśli kolejne fazy zostały uznane za niewystarczające.

Wspieranie argumentów

Czas spędzony na wczesnym etapie cyklu produkcyjnego oprogramowania może obniżyć koszty na późniejszych etapach. Na przykład, problem znaleziony na wczesnych etapach (taki jak specyfikacja wymagań) jest tańszy do naprawienia niż ten sam błąd znaleziony później w procesie (od 50 do 200 razy).

W powszechnej praktyce metodologie kaskadowe skutkują harmonogramem projektu, w którym 20-40% czasu przeznacza się na pierwsze dwie fazy, 30-40% czasu na kodowanie, a resztę poświęca się na testowanie i wdrażanie. Rzeczywista organizacja projektu musi być wysoce ustrukturyzowana. Większość średnich i dużych projektów będzie zawierać szczegółowy zestaw procedur i kontroli, które regulują każdy proces w projekcie.

Kolejnym argumentem przemawiającym za modelem kaskadowym jest to, że kładzie on nacisk na dokumentację (taką jak dokumenty wymagań i dokumenty projektowe), a także na kod źródłowy . W mniej dokładnie zaprojektowanych i udokumentowanych metodologiach wiedza jest tracona, jeśli członkowie zespołu odchodzą przed zakończeniem projektu, a odzyskanie projektu po utracie może być trudne. Jeśli obecny jest w pełni działający dokument projektowy (jak jest to intencja Big Design Up Front i modelu kaskadowego), nowi członkowie zespołu lub nawet zupełnie nowe zespoły powinni mieć możliwość zapoznania się z dokumentami.

Model kaskadowy zapewnia ustrukturyzowane podejście; sam model postępuje liniowo przez dyskretne, łatwo zrozumiałe i wyjaśnialne fazy, a zatem jest łatwy do zrozumienia; zapewnia również łatwe do zidentyfikowania kamienie milowe w procesie rozwoju. Być może z tego powodu model kaskadowy jest używany jako początkowy przykład modelu programistycznego w wielu tekstach i kursach z zakresu inżynierii oprogramowania.

Krytyka

Klienci mogą nie wiedzieć dokładnie, jakie są ich wymagania, zanim zobaczą działające oprogramowanie, a zatem zmieniają swoje wymagania, co prowadzi do przeprojektowania, przebudowy i ponownego testowania oraz wzrostu kosztów.

Projektanci mogą nie zdawać sobie sprawy z przyszłych trudności podczas projektowania nowego oprogramowania lub funkcji, w którym to przypadku lepiej jest zrewidować projekt, niż trwać w projekcie, który nie uwzględnia żadnych nowo odkrytych ograniczeń, wymagań lub problemów.

Organizacje mogą próbować poradzić sobie z brakiem konkretnych wymagań ze strony klientów, zatrudniając analityków systemowych w celu zbadania istniejących systemów ręcznych i przeanalizowania, co robią i jak mogą zostać zastąpione. Jednak w praktyce trudno jest utrzymać ścisły rozdział między analizą systemów a programowaniem. Dzieje się tak, ponieważ wdrożenie dowolnego nietrywialnego systemu prawie nieuchronnie ujawni problemy i przypadki brzegowe, których analityk systemowy nie wziął pod uwagę.

W odpowiedzi na zauważone problemy z czystym modelem kaskadowym wprowadzono zmodyfikowane modele kaskadowe, takie jak „Sashimi (wodospad z nakładającymi się fazami), wodospad z podprojektami i wodospad z redukcją ryzyka”.

Niektóre organizacje, takie jak Departament Obrony Stanów Zjednoczonych, preferują obecnie metodologie typu kaskadowego, zaczynając od MIL-STD-498 , który zachęca do ewolucyjnego pozyskiwania oraz rozwoju iteracyjnego i przyrostowego .

Podczas gdy zwolennicy zwinnego tworzenia oprogramowania twierdzą, że model kaskadowy jest nieefektywnym procesem tworzenia oprogramowania, niektórzy sceptycy sugerują, że model kaskadowy jest fałszywym argumentem używanym wyłącznie w celu promowania alternatywnych metod rozwoju oprogramowania.

Fazy Rational Unified Process (RUP) potwierdzają programową potrzebę kamieni milowych, aby utrzymać projekt na torze, ale zachęcają do iteracji (zwłaszcza w ramach dyscyplin) w ramach faz. Fazy ​​RUP są często określane jako „podobne do wodospadu”.

Zmodyfikowane modele wodospadów

W odpowiedzi na dostrzegane problemy z „czystym” modelem kaskadowym wprowadzono wiele zmodyfikowanych modeli kaskadowych . Modele te mogą odnosić się do niektórych lub wszystkich zarzutów dotyczących „czystego” modelu kaskadowego.

Należą do nich modele szybkiego rozwoju, które Steve McConnell nazywa „zmodyfikowanymi wodospadami”: „model sashimi” Petera DeGrace'a (wodospad z nakładającymi się fazami), wodospad z podprojektami i wodospad z redukcją ryzyka. Istnieją również inne kombinacje modeli rozwoju oprogramowania, takie jak „przyrostowy model kaskadowy”.

Ostateczny model Royce'a

Ostateczny model Royce'a

Ostateczny model Winstona W. Royce'a , jego zamierzone ulepszenie początkowego „modelu wodospadu”, pokazał, że opinie mogą (powinny i często prowadziłyby) prowadzić od testowania kodu do projektu (ponieważ testowanie kodu ujawniło wady w projekcie) i od projektowanie z powrotem do specyfikacji wymagań (ponieważ problemy projektowe mogą wymagać usunięcia sprzecznych lub w inny sposób niespełnionych/niemożliwych do zaprojektowania wymagań). W tym samym artykule Royce opowiadał się również za dużą ilością dokumentacji, wykonując pracę „dwa razy, jeśli to możliwe” (odczucie podobne do sentymentu Freda Brooksa , znanego z napisania Mitycznego Miesiąca Człowieka, wpływowej książki z zakresu zarządzania projektami oprogramowania , który opowiadał się za planowaniem "wyrzuć jedną") i angażując klienta w jak największym stopniu (sens podobny do Extreme Programming ).

Notatki Royce'a do ostatecznego modelu to:

  1. Kompletny projekt programu przed rozpoczęciem analizy i kodowania
  2. Dokumentacja musi być aktualna i kompletna
  3. Wykonaj pracę dwa razy, jeśli to możliwe
  4. Testy muszą być zaplanowane, kontrolowane i monitorowane
  5. Zaangażuj klienta

Zobacz też

Bibliografia

Zewnętrzne linki