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.
Jak w przypadku każdego przymiotnika i większości rzeczy w tworzeniu oprogramowania ... to zależy!
Zależy to od kontekstu i sposobu użycia tego terminu. Pytasz więc o różnicę między przyrostowym a iteracyjnym podejściem do tworzenia oprogramowania, ale cytat dotyczy iteracyjnego projektu, który jest czymś innym (choć podobnym).
Odpowiadając w szczególności na podejście do tworzenia oprogramowania ...
Pytanie jest niewłaściwe. To nie jest jedno lub drugie. Nie można ich bezpośrednio porównać, ponieważ odnoszą się one do różnych części procesu.
Iteracyjne tworzenie oprogramowania jest z natury przyrostowe. Tworzenie oprogramowania przyrostowego nie musi być iteracyjne.
Przyrost jest niewielkim ruchem, miejmy nadzieję do przodu. Jest to sposób odniesienia do każdego kroku wykonywanej pracy.
Iteracja to cykl pracy.
Tak więc iteracja odnosi się do całego zastosowanego cyklu programowania. Przyrost odnosi się do każdego poszczególnego etapu pracy. Iteracja spowoduje przyrost, który składa się z jednego lub więcej rzeczywistych przyrostów w oprogramowaniu (zwykle więcej).
Podsumowując ...
Iteracyjne tworzenie oprogramowania jest szczególnym rodzajem podejścia do tworzenia oprogramowania, działającym w iteracjach, w przeciwieństwie do tradycyjnego podejścia do wodospadu. Scrum jest dobrym przykładem.
Przyrostowe tworzenie oprogramowania jest bardziej ogólne i odnosi się do stopniowej pracy do przodu, co jest cechą większości (być może wszystkich?) Podejść. To powiedziawszy, termin ten jest częściej używany w odniesieniu do nowoczesnych, zwinnych podejść, co prawdopodobnie wyjaśnia zamieszanie między tymi dwoma bardzo podobnymi terminami.
I w końcu, oczywiście, zależy od tego, jak należy rozumieć ten termin, kiedy to często się różni, w zależności od głośnika, pory miesiąca itp.!
Bardziej interesujące jest pytanie, w jaki sposób wpasowuje się w to empiryczne podejście do tworzenia oprogramowania. Piękno iteracyjnego podejścia polega na tym, że umożliwia ono empiryzm, czyli tam, gdzie dzieje się magia.
Mam nadzieję że to pomoże.
W tym artykule opisano to dobrze wraz z przykładami.
źródło