w praktycznym projekcie tworzenia oprogramowania klasyczny model wodospadu jest trudny w użyciu. Iteracyjny model wodospadu można uznać za zawierający niezbędne zmiany w klasycznym modelu wodospadu, aby można go było wykorzystać w praktycznych projektach programistycznych. Jest prawie taki sam jak klasyczny model wodospadu, z wyjątkiem pewnych zmian wprowadzonych w celu zwiększenia wydajności rozwoju oprogramowania.
iteracyjny model wodospadu zapewnia ścieżki sprzężenia zwrotnego z każdej fazy do jej poprzedzających faz, co jest główną różnicą od klasycznego modelu wodospadu.
ścieżki sprzężenia zwrotnego wprowadzone przez iteracyjny model wodospadu są pokazane na rysunku poniżej.
gdy błędy zostaną wykryte w późniejszej fazie, te ścieżki sprzężenia zwrotnego umożliwiają korygowanie błędów popełnionych przez programistów podczas pewnej fazy. Ścieżki informacji zwrotnej pozwalają na przerobienie fazy, w której popełniane są błędy, a zmiany te znajdują odzwierciedlenie w późniejszych fazach. Ale, nie ma ścieżki sprzężenia zwrotnego do etapu-studium wykonalności, ponieważ raz projekt został podjęty, nie rezygnuje z projektu łatwo.
dobrze jest wykrywać błędy w tej samej fazie, w której są popełniane. Zmniejsza to wysiłek i czas potrzebny na poprawienie błędów.
Faza powstrzymywania błędów: zasada wykrywania błędów jak najbliżej ich punktów zaangażowania jest znana jako faza powstrzymywania błędów.
zalety iteracyjnego modelu wodospadu
- ścieżka opinii: W klasycznym modelu wodospadu nie ma ścieżek sprzężenia zwrotnego, więc nie ma mechanizmu korekcji błędów. Ale w iteracyjnym modelu kaskadowym ścieżka sprzężenia zwrotnego z jednej fazy do fazy poprzedzającej pozwala skorygować popełnione błędy, a zmiany te znajdują odzwierciedlenie w późniejszych fazach.
- proste: iteracyjny model wodospadu jest bardzo prosty do zrozumienia i użycia. Dlatego jest to jeden z najczęściej używanych modeli rozwoju oprogramowania.
wady iteracyjnego modelu wodospadu
- trudne do uwzględnienia żądania zmian: Główną wadą iteracyjnego modelu waterfall jest to, że wszystkie wymagania muszą być jasno określone przed rozpoczęciem fazy rozwojowej. Klient może zmienić wymagania po pewnym czasie, ale iteracyjny model waterfall nie pozostawia możliwości włączenia żądań zmian, które są dokonywane po rozpoczęciu fazy rozwojowej.
- dostawa przyrostowa nie jest obsługiwana: w iteracyjnym modelu waterfall pełne oprogramowanie jest w pełni opracowane i przetestowane przed dostawą do klienta. Nie ma możliwości dostawy pośredniej. Tak, klienci muszą długo czekać na uzyskanie oprogramowania.
- nakładanie się faz nie jest obsługiwane: iteracyjny model wodospadu zakłada, że jedna faza może rozpocząć się po zakończeniu poprzedniej fazy, ale w rzeczywistych projektach fazy mogą się nakładać, aby zmniejszyć wysiłek i czas potrzebny na ukończenie projektu.
- obsługa ryzyka nie jest wspierana: projekty mogą być narażone na różne rodzaje ryzyka. Ale iteracyjny model wodospadu nie ma mechanizmu obsługi ryzyka.
- ograniczone interakcje z klientami: Interakcja z klientem odbywa się na początku projektu w momencie gromadzenia wymagań i na zakończenie projektu w momencie dostarczania oprogramowania. Te mniejsze interakcje z klientami mogą prowadzić do wielu problemów, ponieważ ostatecznie opracowane oprogramowanie może różnić się od rzeczywistych wymagań klientów.
