SDLC - model wodospadu
Model Waterfall to klasyczny model SDLC, który jest szeroko znany, rozumiany i powszechnie stosowany. Został wprowadzony przez Royce'a w 1970 roku i nadal jest stosowany jako powszechne podejście do tworzenia oprogramowania w różnych organizacjach w branży.
W modelu wodospadu każda faza cyklu życia może rozpocząć się dopiero po zakończeniu wcześniejszej fazy cyklu życia. Jest to zatem model liniowy bez pętli sprzężenia zwrotnego.
Model wodospadu - mocne strony
Mocne strony modelu Waterfall to -
- Łatwy do zrozumienia, łatwy w użyciu.
- Zapewnia strukturę niedoświadczonemu zespołowi programistów.
- Kamienie milowe są dobrze rozumiane.
- Ustala stabilność wymagań.
- Idealny do kontroli zarządczej (planowanie, monitorowanie, raportowanie).
- Działa dobrze, gdy jakość jest ważniejsza niż koszt lub harmonogram.
Model wodospadu - słabości
Słabości lub wady modelu Waterfall to -
Wyidealizowany - nie pasuje do rzeczywistości.
Nierealistyczne - nie można oczekiwać dokładnych wymagań na wczesnym etapie projektu.
Nie odzwierciedla iteracyjnego charakteru rozwoju eksploracyjnego, który jest bardziej powszechny.
Trudne i drogie zmiany.
Oprogramowanie jest dostarczane dopiero po zakończeniu projektu. Z tego powodu -
Opóźnia wykrycie poważnych usterek.
Możliwość dostarczenia przestarzałych wymagań.
Znaczne koszty zarządzania, które mogą być kosztowne dla małych zespołów i projektów.
Wymaga doświadczonych zasobów na każdym etapie - analityków, projektantów, programistów, testerów.
Testowanie rozpoczyna się dopiero po zakończeniu tworzenia oprogramowania, a testerzy nie biorą udziału w żadnej z wcześniejszych faz.
Ekspertyza zespołów wielofunkcyjnych nie jest dzielona, ponieważ każda faza jest wykonywana w silosach.
Kiedy używać modelu wodospadu?
Możesz użyć modelu Waterfall, jeśli -
Wymagania są bardzo dobrze znane.
Definicja produktu jest stabilna.
Technologia jest dobrze rozumiana.
Nowa wersja istniejącego produktu.
Przeniesienie istniejącego produktu na nową platformę.
Duża organizacja ze zorganizowanymi zespołami wielofunkcyjnymi.
Kanały komunikacji są dobrze ugruntowane w organizacji, a także z klientem.
Ewolucyjny model prototypowania
Podczas tworzenia oprogramowania przy użyciu modelu Evolutionary Prototyping programiści budują prototyp w fazie wymagań. Następnie użytkownicy końcowi oceniają prototyp i przekazują informacje zwrotne. Informacje zwrotne mogą być poprawkami do prototypu lub dodatkową funkcjonalnością. Na podstawie otrzymanych opinii programiści dopracowują prototyp.
W ten sposób produkt ewoluuje poprzez Prototyp → Opinie → Udoskonalone cykle prototypowe i stąd nazwa Evolutionary Prototyping. Gdy użytkownik jest zadowolony z funkcjonalności i działania produktu, kod prototypu jest dostosowywany do wymaganych standardów w celu dostarczenia produktu końcowego.
Ewolucyjny model prototypowania - mocne strony
Mocne strony lub zalety ewolucyjnego modelu prototypowania to:
Klienci / użytkownicy końcowi mogą wizualizować wymagania systemowe w miarę gromadzenia się, patrząc na prototyp.
Programiści uczą się od klientów, dzięki czemu nie ma żadnych niejasności dotyczących domeny lub środowiska produkcyjnego.
Umożliwia elastyczne projektowanie i rozwój.
Interakcja z prototypem stymuluje świadomość dodatkowo potrzebnej funkcjonalności.
Niespodziewane wymagania i zmiany wymagań są łatwo uwzględniane.
Powstają stałe i widoczne oznaki postępu.
Dostawa dokładnego i łatwego do konserwacji produktu końcowego.
Ewolucyjny model prototypowania - słabości
Wady lub wady modelu ewolucyjnego prototypowania są następujące:
Tendencja do porzucania ustrukturyzowanego programowania w tworzeniu kodu i poprawiania, chociaż nie jest to zalecane przez model.
Model ten zyskał złą opinię za metody szybkie i brudne.
Można przeoczyć ogólną łatwość konserwacji.
Klient może ewentualnie poprosić o dostarczenie prototypu jako finalnego, nie dając twórcom możliwości wykonania ostatniego kroku, czyli standaryzacji produktu końcowego.
Projekt może trwać wiecznie (z ciągłym rozszerzaniem się zakresu) i kierownictwo może tego nie doceniać.
Kiedy używać ewolucyjnego modelu prototypowania?
Możesz skorzystać z modelu Evolutionary Prototyping -
- Gdy wymagania są niestabilne lub wymagają wyjaśnienia
- Jako etap wyjaśnienia wymagań modelu kaskadowego
- Opracowywanie interfejsów użytkownika
- Do krótkotrwałych demonstracji
- Do nowego lub oryginalnego rozwoju
- Za wdrożenie nowej technologii