Podejście przyrostowe wykorzystuje określoną liczbę kroków i rozwój idzie od początku do końca w liniowej ścieżki progresji.
Rozwój przyrostowy odbywa się w etapach od projektu, wdrożenia, testowania / weryfikacji, konserwacji. Można je podzielić dalej na podetapy, ale większość modeli przyrostowych ma ten sam wzór. Waterfall model jest tradycyjne podejście przyrostowe rozwój.
Iteracyjne podejście ma zadaną liczbę kroków, raczej rozwój odbywa się w cyklach.
Rozwój iteracyjny jest mniej zainteresowany śledzeniem postępu poszczególnych funkcji. Zamiast tego skupiono się na stworzeniu działającego prototypu i dodaniu funkcji w cyklach programistycznych, w których kroki tworzenia przyrostów są wykonywane dla każdego cyklu. Modelowanie zwinne jest typowym podejściem iteracyjnym.
Model inkrementalny został pierwotnie opracowany zgodnie z tradycyjnym modelem linii montażowej stosowanym w fabrykach. Niestety projektowanie i tworzenie oprogramowania ma niewiele wspólnego z wytwarzaniem dóbr fizycznych. Kod jest planem, a nie gotowym produktem rozwoju. Dobre wybory projektowe są często „odkrywane” podczas procesu programowania. Zablokowanie programistów w zestawie założeń bez odpowiedniego kontekstu może prowadzić do złych projektów w najlepszym przypadku lub całkowitego wykolejenia rozwoju w najgorszym.
Podejście iteracyjne staje się obecnie powszechną praktyką, ponieważ lepiej pasuje do naturalnej ścieżki postępu w rozwoju oprogramowania. Zamiast inwestować dużo czasu / wysiłku w pogoń za „perfekcyjnym projektem” opartym na założeniach, iteracyjne podejście polega na stworzeniu czegoś, co „jest wystarczająco dobre”, aby rozpocząć i ewoluować w celu dopasowania do potrzeb użytkownika.
tl; dr - Jeśli piszesz esej w Modelu Przyrostowym, próbowałbyś napisać go idealnie od początku do końca jednego zdania na raz. Jeśli napisałeś to w modelu iteracyjnym, wybiłbyś szybki wstępny szkic i pracujesz nad ulepszeniem go poprzez zestaw faz rewizji.
Aktualizacja:
Zmodyfikowałem definicję „podejścia przyrostowego”, aby pasowała do bardziej praktycznego przykładu.
Jeśli kiedykolwiek miałeś do czynienia z kontraktowaniem, podejście przyrostowe jest sposobem wykonywania większości kontraktów (szczególnie dla wojska). Pomimo wielu subtelnych odmian typowego „modelu wodospadu” większość / wszystkie są stosowane w praktyce w ten sam sposób.
Kroki są następujące:
- Udzielenie zamówienia
- Wstępny przegląd projektu
- Krytyczny przegląd projektu
- Zamrożenie specyfikacji
- Rozwój
- Fielding / Integration
- Weryfikacja
- Testy niezawodności
PDR i CDR to miejsca, w których specyfikacja jest tworzona i poprawiana. Po zakończeniu specyfikacji należy ją zamrozić, aby zapobiec pełzaniu zakresu. Integracja ma miejsce, jeśli oprogramowanie jest używane do rozszerzenia istniejącego systemu. Weryfikacja służy do sprawdzenia, czy aplikacja jest zgodna ze specyfikacją. Wiarygodność jest testem, który ma udowodnić, że aplikacja będzie niezawodna w długim okresie, można to określić podobnie jak SLA (Service Level Agreement), w której system musi utrzymywać pewien procent czasu sprawności (np. 99% czasu pracy przez 3 miesiące ).
Ten model działa doskonale w przypadku systemów, które są łatwe do określenia na papierze, ale trudne do wyprodukowania. Oprogramowanie jest bardzo trudne do określenia na papierze z jakimkolwiek znaczącym stopniem szczegółowości (np. UML). Większość „typów biznesowych” odpowiedzialnych za zarządzanie / zawieranie umów nie zdaje sobie sprawy, że - jeśli chodzi o rozwój oprogramowania - sam kod jest specyfikacją. Specyfikacje papierowe często wymagają tyle samo lub więcej czasu / wysiłku na napisanie co sam kod i zwykle okazują się niekompletne / gorsze w praktyce.
Podejścia przyrostowe próbują zmarnować czas / zasoby, traktując sam kod jako specyfikację. Zamiast uruchamiać specyfikację papieru w wielu krokach weryfikacji, sam kod przechodzi wiele cykli weryfikacji.