Rozwój iteracyjny i przyrostowy - Iterative and incremental development

Programowanie iteracyjne i przyrostowe to dowolna kombinacja zarówno projektowania iteracyjnego lub metody iteracyjnej, jak i przyrostowego modelu budowania dla rozwoju .

Używanie tego terminu rozpoczęło się w tworzeniu oprogramowania , przy czym długotrwała kombinacja dwóch terminów iteracyjny i przyrostowy była szeroko sugerowana w przypadku dużych wysiłków programistycznych. Na przykład dokument DOD-STD-2167 z 1985 r. wspomina (w sekcji 4.1.2): „Podczas tworzenia oprogramowania może być w toku więcej niż jedna iteracja cyklu rozwoju oprogramowania w tym samym czasie”. oraz „Proces ten można opisać jako podejście „ewolucyjnego przejmowania” lub „budowania przyrostowego”. W oprogramowaniu związek między iteracjami a przyrostami jest określany przez cały proces tworzenia oprogramowania .

Iteracyjny model rozwoju

Przegląd

Uproszczona wersja typowego cyklu iteracyjnego w zwinnym zarządzaniu projektami

Podstawową ideą tej metody jest rozwijanie systemu w powtarzanych cyklach (iteracyjnie) i w mniejszych porcjach na raz (przyrostowo), umożliwiając programistom wykorzystanie tego, czego nauczyli się podczas tworzenia wcześniejszych części lub wersji systemu. Nauka pochodzi zarówno z rozwoju, jak i użytkowania systemu, gdzie możliwe kluczowe etapy procesu rozpoczynają się od prostej implementacji podzbioru wymagań oprogramowania i iteracyjnego ulepszania ewoluujących wersji, aż do wdrożenia pełnego systemu. W każdej iteracji wprowadzane są modyfikacje projektowe i dodawane są nowe możliwości funkcjonalne.

Sama procedura składa się z etapu inicjalizacji, etapu iteracji oraz listy kontrolnej projektu. Etap inicjalizacji tworzy podstawową wersję systemu. Celem tego wstępnego wdrożenia jest stworzenie produktu, na który użytkownik może zareagować. Powinien oferować próbkę kluczowych aspektów problemu i dostarczać rozwiązania, które jest na tyle proste, aby można je było łatwo zrozumieć i wdrożyć. Aby poprowadzić proces iteracji, tworzona jest lista kontrolna projektu, która zawiera zapis wszystkich zadań, które należy wykonać. Zawiera elementy, takie jak nowe funkcje do wdrożenia oraz obszary przeprojektowania istniejącego rozwiązania. Lista kontrolna jest stale aktualizowana w wyniku fazy analizy.

Iteracja obejmuje przeprojektowanie, a implementacja iteracji ma być prosta, bezpośrednia i modułowa, wspierając przeprojektowanie na tym etapie lub jako zadanie dodane do listy kontrolnej projektu. Poziom szczegółowości projektu nie jest podyktowany podejściem iteracyjnym. W lekkim projekcie iteracyjnym kod może stanowić główne źródło dokumentacji systemu; jednak w krytycznym projekcie iteracyjnym można użyć formalnego dokumentu projektu oprogramowania . Analiza iteracji opiera się na informacjach zwrotnych od użytkowników i dostępnych funkcjach analizy programu. Polega na analizie struktury, modułowości, użyteczności , niezawodności, wydajności i realizacji celów. Lista kontrolna projektu jest modyfikowana w świetle wyników analizy.

Rozwój iteracyjny.

Fazy

Rozwój przyrostowy dzieli funkcjonalność systemu na przyrosty (porcje). W każdym przyroście część funkcjonalności jest dostarczana poprzez pracę międzybranżową , od wymagań do wdrożenia . W zunifikowany proces przyrosty grupy / iteracji na fazy: początku, opracowywaniu, konstrukcji i przejściowe.

• Inception identyfikuje zakres projektu, wymagania (funkcjonalne i niefunkcjonalne) oraz ryzyko na wysokim poziomie, ale wystarczająco szczegółowo, aby można było oszacować pracę.
• Opracowanie zapewnia działającą architekturę, która łagodzi główne zagrożenia i spełnia wymagania niefunkcjonalne.
• Konstrukcja stopniowo wypełnia architekturę gotowym do produkcji kodem wytworzonym na podstawie analizy, projektowania, implementacji i testowania wymagań funkcjonalnych.
• Przejście dostarcza system do produkcyjnego środowiska operacyjnego.

Każda z faz może być podzielona na 1 lub więcej iteracji, które zazwyczaj są ograniczone czasowo, a nie na funkcje. Architekci i analitycy pracują o jedną iterację przed programistami i testerami, aby utrzymać pełne zaległości dotyczące produktów.

Wykorzystanie/Historia

Wiele przykładów wczesnego użycia znajduje się w artykule Craiga Larmana i Victora Basili „Iterative and Incremental Development: A Brief History”, z jednym z najwcześniejszych z lat 60-tych NASA Project Mercury .

Niektórzy z tych inżynierów Mercury utworzyli później nowy dział w IBM , gdzie „innym wczesnym i uderzającym przykładem wielkiego sukcesu IID [było] serce oprogramowania wahadłowca kosmicznego NASA – podstawowy system oprogramowania awioniki, który [oni] budowali od 1977 roku do 1980 roku. Zespół zastosował IID w serii 17 iteracji w ciągu 31 miesięcy, średnio około ośmiu tygodni na iterację. Ich motywacją do uniknięcia cyklu życia kaskadowego było to, że wymagania programu wahadłowego zmieniły się podczas procesu tworzenia oprogramowania.

Niektóre organizacje, takie jak Departament Obrony Stanów Zjednoczonych, preferują metody iteracyjne, zaczynając od MIL-STD-498 „wyraźnie zachęcające do ewolucyjnego nabywania wiedzy i IID”.

Instrukcja DoD 5000.2 wydana w 2000 roku wyraźnie określa preferencje dla IID:

Istnieją dwa podejścia, ewolucyjne i jednoetapowe [wodospad], do pełnej zdolności. Preferowane jest podejście ewolucyjne. … [W tym] podejściu ostateczna zdolność dostarczana użytkownikowi jest podzielona na dwa lub więcej bloków, z rosnącym przyrostem możliwości… rozwój oprogramowania będzie przebiegał zgodnie z iteracyjnym spiralnym procesem rozwoju, w którym stale rozszerzane wersje oprogramowania opierają się na uczeniu się od wcześniejszy rozwój. Można to również zrobić etapami.

Ostatnie poprawki DoDI 5000.02 nie odnoszą się już do „rozwoju spiralnego”, ale zalecają ogólne podejście jako punkt odniesienia dla programów rozwoju/zamówień intensywnie korzystających z oprogramowania. Ponadto Agencja Stanów Zjednoczonych ds. Rozwoju Międzynarodowego (USAID) stosuje również iteracyjne i przyrostowe podejście rozwojowe do swojego cyklu programowania w celu projektowania, monitorowania, oceny, uczenia się i dostosowywania międzynarodowych projektów rozwojowych z podejściem zarządzania projektami, które koncentruje się na włączeniu współpracy, uczeniu się oraz strategie adaptacyjne służące do iteracji i dostosowywania programowania.

Kontrast z rozwojem wodospadu

Główną przyczyną niepowodzenia projektów programistycznych jest wybór modelu, dlatego należy go podejść z dużą starannością.

Na przykład paradygmat rozwoju Waterfall uzupełnia w jednym kroku produkty pracy dotyczące całego projektu w każdej dyscyplinie, zanim w kolejnym kroku przejdzie do kolejnej dyscypliny. Wartość biznesowa jest dostarczana od razu i tylko na samym końcu projektu, podczas gdy backtracking jest możliwy w podejściu iteracyjnym. Porównując te dwa podejścia, pojawiają się pewne wzorce:

• Zaangażowanie użytkownika : W modelu kaskadowym użytkownik jest zaangażowany w dwa etapy modelu, tj. testy wymagań i akceptacji oraz ewentualnie tworzenie materiałów edukacyjnych dla użytkowników. Natomiast w modelu przyrostowym klient jest zaangażowany na każdym etapie.
• Zmienność : Oprogramowanie jest dostarczane użytkownikowi dopiero po zakończeniu etapu kompilacji cyklu życia, w celu przeprowadzenia testów akceptacyjnych przez użytkownika. Z drugiej strony, każdy przyrost jest dostarczany do użytkownika i po zatwierdzeniu przez użytkownika deweloper może przejść do kolejnego modułu.
• Zasoby ludzkie : W modelu przyrostowym potencjalnie potrzeba mniej pracowników w porównaniu z modelem kaskadowym.
• Ograniczenie czasowe : Produkt działający jest dostarczany po miesiącach, natomiast w modelu przyrostowym produkt jest dostarczany użytkownikowi w ciągu kilku tygodni.
• Rozmiar projektu : Model wodospadu nie nadaje się do małych projektów, podczas gdy model przyrostowy jest odpowiedni zarówno dla małych, jak i dużych projektów.

Wytyczne wdrożeniowe

Wytyczne, które kierują wdrażaniem i analizą oprogramowania, obejmują:

• Wszelkie trudności w projektowaniu, kodowaniu i testowaniu modyfikacji powinny sygnalizować potrzebę przeprojektowania lub przekodowania.
• Modyfikacje powinny łatwo pasować do izolowanych i łatwych do znalezienia modułów. Jeśli tak się nie stanie, prawdopodobnie konieczne jest przeprojektowanie.
• Modyfikacje tabel powinny być szczególnie łatwe do wykonania. Jeśli jakakolwiek modyfikacja tabeli nie jest łatwa i szybka, wskazana jest zmiana projektu.
• W miarę postępu iteracji wprowadzanie zmian powinno być łatwiejsze. Jeśli tak nie jest, istnieje podstawowy problem, taki jak wada projektowa lub mnożenie się łatek .
• Poprawki powinny normalnie istnieć tylko przez jedną lub dwie iteracje. Mogą być konieczne poprawki, aby uniknąć przeprojektowania na etapie wdrażania.
• Istniejące wdrożenie powinno być często analizowane, aby określić, na ile dobrze spełnia cele projektu.
• W miarę możliwości należy korzystać z narzędzi do analizy programów, aby pomóc w analizie częściowych wdrożeń.
• Reakcja użytkownika powinna być wywoływana i analizowana pod kątem wskazań na braki w bieżącym wdrożeniu.

Zastosowanie w sprzęcie i systemach wbudowanych

Podczas gdy w branży oprogramowania pojawił się termin iteracyjny i przyrostowy rozwój, wiele działań na rzecz rozwoju sprzętu i oprogramowania wbudowanego wykorzystuje techniki iteracyjne i przyrostowe.

Przykłady tego można zobaczyć w wielu branżach. Jednym z sektorów, na który ostatnio znacząco wpłynęła ta zmiana myślenia, jest branża wystrzeliwania kosmosu w kosmos , w której działają znaczne nowe siły konkurencyjne spowodowane szybszymi i bardziej rozległymi innowacjami technologicznymi, które zostały wprowadzone przez tworzenie prywatnych firm dążących do wystrzelenia w kosmos. Firmy te, takie jak SpaceX i Rocket Lab , świadczą teraz komercyjne usługi wystrzeliwania orbitalnego w ciągu ostatniej dekady, co tylko sześć krajów zrobiło przed dekadą. Nowe innowacje w podejściu do rozwoju technologii, cenach i ofertach usług — w tym możliwość lotu w kosmos na wcześniej używanym (wielokrotnego użytku) etapie dopalacza — w tym istniejąca dopiero od 2016 r. — jeszcze bardziej obniżają cenę uzyskania dostępu do kosmosu.

SpaceX wyraźnie określił swoje wysiłki na rzecz wprowadzenia iteracyjnych praktyk projektowych do przemysłu kosmicznego i wykorzystuje tę technikę na statkach kosmicznych, pojazdach nośnych, elektronice i awionice oraz operacyjnych operacjach sprzętu lotniczego.

Ponieważ branża zaczęła się zmieniać, inni konkurenci zaczynają zmieniać swoje długoterminowe praktyki rozwoju również z agencjami rządowymi . Na przykład, duży amerykański dostawca usług startowych United Launch Alliance (ULA) rozpoczął w 2015 roku trwający dekadę projekt restrukturyzacji swojej działalności związanej z wystrzeliwaniem rakiet – redukując dwa pojazdy startowe do jednego – przy użyciu iteracyjnego i stopniowego podejścia, aby uzyskać częściowo wielokrotnego użytku. i znacznie tańszy system uruchamiania w ciągu następnej dekady.

Zobacz też

Uwagi

Bibliografia

• Dr Alistair Cockburn (maj 2008). „Korzystanie z rozwoju przyrostowego i iteracyjnego” (PDF) . Przesłuchanie STSC . Centrum Wsparcia Technologii Oprogramowania USAF . 21 (5): 27–30. ISSN  2160-1593 . Zarchiwizowane z oryginału (PDF) w dniu 26.05.2012 . Źródło 2011-07-20 .
• Craig Larman, Victor R. Basili (czerwiec 2003). „Rozwój iteracyjny i przyrostowy: krótka historia” (PDF) . Komputer IEEE . Stowarzyszenie Komputerowe IEEE. 36 (6): 47–56. doi : 10.1109/MC.2003.1204375 . ISSN  0018-9162 . S2CID  9240477 . Źródło 2009-01-10 .