Wykład 4 Dynamiczna struktura RUP Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 4 Dynamiczna struktura RUP Wykładowca: dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Zagadnienia Zagadnienia Dlaczego nie model wodospadowy? Recepta: iterować Fazy i kamienie milowe Aktywności a iteracje Faza początkowa Faza opracowywania Faza konstrukcji Faza wdrażania Korzyści z podejścia iteracyjnego Podsumowanie Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

Dlaczego nie model wodospadowy ? (1) Wymagania użytkownika W ten sposób, w 5 podstawowych krokach, rozwiązuje się większość problemów inżynierskich, np. buduje wieżowce i mosty. Specyfikacja wymagań Analiza wymagań 1 Specyfikacja projektu logicznego Projektowanie 2 Kod Implementacja (kodowanie, testowanie) 3 Integracja (weryfikacja) 4 Jeszcze w latach 80-tych model wodospadowy był uważany za jedyne rozsądne podejście do budowy oprogramowania. Wypuszczenie produktu 5

Dlaczego nie model wodospadowy ? (2) Błędne założenia: (a) wymagania mogą być zamrożone, (b) projekt logiczny będzie „odpowiedni od razu”. Błędna ocena kontekstu rozwoju oprogramowania. Błędna ocena czynnika ludzkiego. Błędna próba wykorzystania podejścia (sekwencyjnego). Inżynieria oprogramowania jest ciągle dziedziną niedojrzałą, zaledwie kilkadziesiąt lat doświadczenia - w przeciwieństwie do setek lat prób i błędów w innych dziedzinach, np. w budowie budynków czy mostów. Ad. 1. Błędne założenie (a): wymagania mogą być “zamrożone”. W modelu wodospadowym przyjmuje się założenie, że wymagania na system zostaną poprawnie zdefiniowane już w 1-szym kroku, co w praktyce prawie zawsze okazuje się niemożliwe do osiągnięcia. W większości przypadków, wymagania zmieniają się cały czas w trakcie rozwoju oprogramowania i fakt ten należy przyjąć do wiadomości.

Dlaczego nie model wodospadowy ? (3) Co może powodować zmiany wymagań? Zmiana środowiska pracy użytkownika: Zmiany wprowadzane przez użytkownika są tym bardziej prawdopodobne, im dłużej trwa projekt, np. nie tygodnie (czy miesiące) a lata. Wzrost świadomości użytkownika odnośnie rozwiązywanego problemu, czego efektem jest zmiana specyfikacji problemu. Użytkownik wie “dokładnie” czego chce nie na dwa lata przedtem, gdy oprogramowanie jest gotowe, ale kilka tygodni później, gdy przejdzie już fazę rozpoznawania - efekt IKIWISI (I’ll Know It When I See It). Ponadto, poważną przeszkodą na drodze do zamrażania wymagań jest niemożność zdefiniowania wymagań z dostateczną precyzją, na wystarczającym poziomie szczegółowości. Formalne specyfikacje wymagań nie sprawdziły się nigdzie, poza małymi, specjalizowanymi zastosowaniami. Są trudne do wykorzystania i nieprzyjazne dla użytkownika.

Dlaczego nie model wodospadowy ? (4) Ad. 1. Błędne założenie (b): Projekt logiczny oprogramowania - zbudowany w drugim kroku - będzie odpowiedni i to najlepiej „od razu”. Przez „odpowiedni” projekt logiczny rozumie się taki projekt, który zapewnia osiągnięcie pożądanych własności systemu, np. poprawności, wydajności, niezawodności, itp. Można wyprodukować tony papierowej dokumentacji, przeprowadzić tysiące przeglądów, co w praktyce wcale nie zabezpiecza przed uniknięciem błędów w projekcie. Inżynieria oprogramowania nie osiągnęła poziomu innych dyscyplin inżynieryjnych - być może nigdy nie osiągnie – dzięki czemu czasami przypomina gałąź psychologii czy filozofii. Być może powinna być częścią sztuki. Ad. 2. Błędna ocena kontekstu rozwoju oprogramowania Zmiany technologicze: Nowy software czy hardware, np. ten z którym rozpoczynano projekt, może już nie być wytwarzany w momencie wypuszczania produktu. Konkurencja na rynku: Nawet doskonały produkt, nie ma szans na rynku, który poszedł o krok dalej.

Dlaczego nie model wodospadowy ? (5) Ad. 3. Błędna ocena czynnika ludzkiego Jeśli projekt trwa krótko, ludzie szybko widzą namacalne rezultaty swojej działalności i pozostają przez cały czas skoncentrowani na pracy. Błędy, wykrywane w trakcie pracy, nie wymagają dalekich powrotów w celu przeprowadzenia korekty. Próba wykorzystania modelu sekwencyjnego, odpowiedniego dla małych projektów (kilka miesięcy), dla projektu trwającego np. kilka lat, naraża ten projekt na subtelne (ale znaczące efekty) związane z ludźmi, uczestnikami projektu: Progres jest widoczny w postaci rosnącego stosu papierów i diagramów - brakuje drobnego zastrzyku adrenaliny, by być odpowiednio zmotywowanym. Błędy są wykrywane poźno - dopiero podczas testowania czy integracji – w efekcie słabego sprzężenia zwrotnego cechującego proces sekwencyjny. Uczestnicy projektu mają mało okazji do ulepszania swojej pracy – ważne dla osób niedoświadczonych i przy pracy w nowym środowisku narzędziowym.

Dlaczego nie model wodospadowy ? (6) W podejściu sekwencyjnym każdy krok kończy się wyprodukowaniem zbioru artefaktów, które po przeglądzie, akceptacji i zamrożeniu są wykorzystywane jako punkt startowy dla następnej aktywności. W praktyce, w podejściu sekwencyjnym nacisk jest z reguły kładziony na produkcję i zamrażanie dokumentów. Ograniczone powroty w celu drobniejszych korekt są tolerowane, w przeciwieństwie do zmian, które wymagałyby powrotu do początkowych kroków, co mogłoby być przyczyną całkowitego niepowodzenia projektu. Stąd - dla długich projektów opartych o podejście sekwencyjne - często obserwuje się znaczący opór kierownictwa w sytuacji zaistnienia potrzeby zmian (wewnętrzni oponenci są często usuwani ze składu zespołu projektowego), co w efekcie skutkuje pogorszeniem jakości produktu finalnego.

Dlaczego nie model wodospadowy ? (7) Ad. 4. Model sekwencyjny jest nieodpowiedni dla dużych, złożonych projektów z dużą liczbą ryzyk? Dla projektów małych (czas realizacji: kilka tygodni czy miesięcy), czy też projektów z niewielką liczbą nowości (doświadczeni ludzie, znane narzędzia, znany problem, itp.) model sekwencyjny sprawdza się dobrze. Nie sprawdza się, gdy jest dużo niewiadomych, dużo nowości i dużo ryzyk. W modelu sekwencyjnym jedyne, co można zrobić dla obsługi przyszłych ryzyk, to pozostawienie zapasu czasu na obsługę wszelkich nieprzewidzianych wydarzeń. Ad. 5. Inżynieria oprogramownia – dziedzina niedojrzała Brak “fundamentalnych praw” rozwoju oprogramowania i tempo w jakim zmienia się rynek czyni produkcję oprogramowania dziedziną o dużym stopniu ryzyka. Ryzyka muszą być bezwzględnie brane pod uwagę przez organizacje zajmujące się wytwarzaniem oprogramowania.

Recepta: iterować (1) Podejście oparte o realizację kompletnego zbiór funkcjonalności kontra podejście oparte o realizację stopniową (volume-based versus time-based scheduling) “Wszystko czego potrzebujesz, zrobimy w ciągu dziewięciu miesięcy” kontra “w ciągu dwóch pierwszych miesięcy zrobimy trzy pozycje z twojej listy, w kolejnych trzech miesiącach zrobimy to i tamto, itd.”. To pierwsze podejście - typowe dla procesu sekwencyjnego - nie przynosi zbyt wielkich zysków, kiedy brakuje czasu: jak np. decyzja o nierealizowaniu własności X - podjęta w środku implementacji - gdy poświęciliśmy już czas na jej specyfikowanie, projekt i częściową implementację. Drugi sposób pracy - typowy dla podejścia iteracyjnego - wymusza dzisiejszy rynek: produkt zostaje wypuszczony z pewnym zbiorem własności, a potem tworzona jest następna, ulepszona i rozszerzona wersja. Jak można zjeść słonia? Kawałek po kawałku.

Recepta: iterować (2) Jak wykorzystać podejście sekwecyjne w procesie iteracyjnym? Jeśli proces sekwencyjny sprawdza się zarówno dla małych projektów, jak i dla tych z niewielką liczbą ryzyk, dlaczego nie realizować dużych projektów podzieliwszy je na małe, z których każdy będzie przeprowadzany w oparciu o model sekwencyjny. Można wybrać podzbiór wymagań, zrobić dla nich projekt logiczny i implementację, poddać weryfikacji, po czym rozpocząć pracę z następnym podzbiorem wymagań, i tak dalej aż do osiągnięcia kompletnego, stabilnego produktu finalnego. Jak się ustrzec przed zjawiskiem, by każda kolejna iteracja nie rozpoczynała się ponownie początkiem realizacji projektu? Jak dokonywać wyboru, co powinno być zrealizowane w kolejnych iteracjach - jaki podzbiór wymagań i jakie ryzyka rozpatrzyć? Jak rozwiązywać - w trakcie realizacji procesu iteracyjnego - problemy wynikające zarówno z natury produktu (różnego od np. budynku czy mostu), jak i z natury procesu sekwencyjnego?

Recepta: iterować (3) Aw P Im In Aw P Im In Aw P Im In Aw P Im In jedna iteracja Aw P Im In Aw P Im In Aw P Im In czas Aw - Analiza wymagań, P - Projektowanie, Im- Implementacja, In - Integracja

Fazy i kamienie milowe (1) Z perspektywy zarządzania projektem: trzeba zorganizować sekwencję iteracji - odpowiednio do krótko-terminowych celów. Postęp powinien być mierzony, np.: ilością zrealizowanych use-case, przeprowadzonych testów czy wyeliminowanych ryzyk. Należy zdefiniować punkty w czasie, kiedy będą podejmowane decyzje typu: kontynuujemy, kończymy prace czy też zmieniamy kurs. Takie punkty w inżynierii oprogramowania noszą nazwę kamieni milowych. Początkowa Opracowywanie Konstrukcja Wdrożenie czas Cel cyklu (LCO) Architektura (LCA) Początkowa zdolność operacyjna (IOC) Wypuszczenie produktu LCO - Life Cycle Objective , LCA - Life Cycle Architecture, IOC - Initial Operational Capability

Fazy i kamienie milowe (2) Faza początkowa (P): specyfikacja wizji produktu finalnego i związanego z nim przypadku biznesowego; określenie celów projektu (kamień milowy LCO) Faza opracowywania (O): planowanie niezbędnych aktywności wraz z określeniem niezbędnych dla ich zrealizowania zasobów; specyfikacja architektury (kamień milowy LCA) Faza konstrukcji (K): budowa produktu; rozwijanie wizji, architektury, planów – do momentu, gdy produkt będzie gotowy do oddania dla użytkowników (kamień milowy IOC) Faza wdrożenia (W): wdrożenie u użytkownika; trening i pielęgnacja (kamień milowy Wypuszczenie produktu) Cztery fazy (P, O, K, W) są ułożone w następujące po sobie cykle: cykl początkowy i kolejne cykle ewolucji.

Fazy i kamienie milowe (3) P O K W 1-sza generacja produktu Cykl początkowy P O K W 2-ga generacja produktu Cykl ewolucji P O K W 3-cia generacja produktu Cykl ewolucji Cykle mogą nieznacznie zachodzić na siebie. Cykl początkowy kończy się wytworzeniem pierwszej wersji produktu; następne cykle służące wytwarzaniu kolejnych generacji produktu są realizowane przez powtarzanie czterech faz, z różnym naciskiem na różne fazy.

Fazy i kamienie milowe (4) Następne generacje produktu mogą powstawać na skutek sugestii użytkownika, zmian w środowisku użytkownika, zmian w technologii, o którą oparto produkt czy też w odpowiedzi na współzawodnictwo istniejące na rynku. W kolejnych cyklach fazy mogą różnić się długościami (co nie zostało wyraźnie oznaczone na poprzednim rysunku) - długości faz są z reguły uzależnione od specyficznych potrzeb projektu. Ważna jest specyfikacja celu każdej fazy i wyznaczenie kamieni milowych. Np. dla projektu trwającego dwa lata (w cyklu początkowym) typowe długości faz to: Faza początkowa: 2.5 miesiąca, Faza opracowywania: 7 miesięcy, Faza konstrukcji: 12 miesięcy, Faza wdrożenia: 2.5 miesiąca. W każdej z faz projekt jest realizowany w oparciu o podejście iteracyjne (przepływy prac): liczba iteracji dla fazy waha się od jednej do kilku.

Fazy i kamienie milowe (5) Typowy rozkład czasu dla cyklu początkowego P O K W 10% 30% 50% czas Cykl wraz z iteracjami, wypuszczeniami produktu i kamieniami milowymi Początkowa Opracowywanie Konstrukcja Wdrażanie czas I #1 I #2 I #3 I #4 I #5 I #6 I #7 I #8 wypuszczenie wewnętrzne pomocniczy kamień milowy pierwsze wypuszczenie na zewnątrz, np. beta wypuszczenie produktu finalnego

Aktywności a iteracje (1) Początkowa Opracowywanie Konstrukcja Wdrożenie Planowanie Wymagania Architektura Projekt Implementacja Integracja Testowanie, weryfikowanie Iter. wstępna Iter. #1, Iter. #2 Iter.#n, Iter. #..., Iter.#m Iter. #m+1, Iter .#m+2 Każda iteracja przebiega zgodnie z modelem wodospadowym

Aktywności a iteracje (2) W każdej z faz położony jest różny nacisk na różne aktywności: Faza początkowa: tu wysiłek jest skoncentrowany na określeniu wymagań na oprogramowanie i ustaleniu zakresu odpowiedzialności systemu. Faza opracowywania: wymaganiom nadal poświęca się wiele uwagi, ale też prowadzone są prace projektowe i implementacyjne (w celu określenia projektu architektury i wytworzenia prototypu, stanowiącego podstawę dla dalszych prac) oraz planuje się mitygację technicznych ryzyk (niektórych) poprzez testowanie różnych technik i narzędzi. Faza konstrukcji: nacisk jest położony na prace projektowe i implementacyjne. W tej fazie prototyp jest rozwijany, do uzyskania pierwszego operacyjnego produktu. Faza wdrożenia: prace są skoncentrowane na zapewnieniu produktowi odpowiedniej jakości: usuwa się błędy, ulepsza lub uzupełnia o brakujące elementy, wypełnia bazę, trenuje użytkowników.

Faza początkowa (1) Podstawowe zadanie: osiągnąć konsensus wśród uczestników projektu Ustalić kontekst, zakres odpowiedzialności (najważniejsze wymagania), ograniczenia oraz kryteria akceptacji dla produktu finalnego. Wyróżnić krytyczne - z punktu widzenia projektu architektury - przypadki użycia (główne scenariusze). Zaproponować (nawet zademonstrować) architekturę umożliwiającą ich realizację. Oszacować ryzyka: źródła i prawdopodobieństwo wystąpienia. Opracować przypadek biznesowy, przygotować plan zarządzania ryzykiem, harmonogram, propozycje kadrowe - dla całości projektu (bardziej szczegółowo potraktować fazę opracowywania, następną w kolejności). W oparciu o analizę planów, kosztów i zasobów podjąć decyzje typu: co budować od nowa/ co kupić/ co ponownie wykorzystać ?

Faza początkowa (2) Podstawowe artefakty wytwarzane w fazie początkowej: Dokument wizji: główne wymagania, własności i ograniczenia Przegląd przypadków użycia (w postaci listy) Słownik pojęć Przypadek biznesowy - Kontekst biznesowy - Kryteria sukcesu (dochód, rozpoznanie rynku, itd.) - Prognoza finansowa Szacunki dla ryzyka Plan projektu, z uwzględnieniem faz oraz iteracji Dla produktów komercyjnych, przypadek biznesowy powinien zawierać zbiór założeń dotyczących projektu oraz rząd wielkości zwrotu poniesionych nakładów (ROI - Return on Investment), o ile te założenia okażą się prawdziwe. Np.: ROI będzie rzędu pięć, jeśli projekt zostanie ukończony w ciągu roku, dwa jeśli w ciągu dwóch lat i ujemny, jeśli dłużej. Założenia są sprawdzane ponownie, przy końcu następnej fazy.

Faza początkowa (3) Inne artefakty, wytwarzane w fazie początkowej: model przypadków użycia (10 -20% całości - dla cyklu początkowego), model dziedziny, model biznesowy (o ile potrzeba), specyfikacje procesów, jeden lub kilka prototypów. Kamień milowy: LCO Początkowa Opracowywanie Konstrukcja Wdrażanie LCO Kryteria oceny: stopień zrozumienia wymagań, rzetelność szacunków dla kosztów, priorytetów, ryzyk, procesów, itp., jakość pierwotnej architektury (prototypu), wydatki rzeczywiste kontra wydatki planowane.

Faza opracowywania (1) Podstawowe zadania: przeprowadzić bardziej szczegółową analizę, wypracować fundamenty dla architektury, zbudować plan projektu oraz wyeliminować te elementy, które są obarczone największym ryzykiem. Decyzje architektoniczne muszą bazować na zrozumieniu całości systemu: jego funkcjonalności i ograniczeń (“zrozumienie z perspektywy na milę szerokiej i na cal głębokiej”). Faza opracowywania - najbardziej krytyczna z czterech faz (wysoki koszt, wysokie ryzyko): wymagania, architektura, plany powinny osiągnąć stabilną postać, ryzyka muszą być zmitygowane, tak aby było możliwe określenie kosztów i czasu potrzebnego na ukończenie projektu. Bada się różne rozwiązania budując prototyp(y) - w jednej lub kilku iteracjach (zakres, rozmiar, nowości, inne ryzyka). Budowa prototypów ułatwia mitygowanie ryzyk oraz ustanawianie kompromisów między wymaganiami a możliwościami środowiska implementacji.

Faza opracowywania (2) Podstawowe aktywności: Solidne zrozumienie krytycznych przypadków użycia - stanowiących bazę dla decyzji architektonicznych i dla planowania. Przygotowanie procesów i infrastruktury niezbędnej dla ich realizacji. Wypracowanie fundamentów dla architektury: selekcja komponentów niezbędnych dla realizacji głównych scenariuszy (być może trzeba będzie dokonywać zmian w architekturze lub w wymaganiach); decyzje co budować od nowa/ co kupić/ co ponownie wykorzystać tak przemyślane, by dało się oszacować koszt i czas fazy konstrukcji. Artefakty: Model przypadków użycia (kompletny w 80%), co oznacza, że: wszystkie przypadki użycia znajdują się w przeglądzie, którego opracowanie rozpoczęto w poprzedniej fazie, wszyscy aktorzy są zidentyfikowani, dla większości przypadków są opracowane szczegółowe specyfikacje.

Faza opracowywania (3) Dodatkowe wymagania (funkcjonalne i niefunkcjonalne nie ujęte w żadnym z przypadków użycia) Opis architektury Prototyp Plan dla całości projektu (z uwzględnieniem iteracji i kryteriów przechodzenia między nimi) Specyfikacje procesów, które będą wykorzystywane Wstępną wersję podręcznika dla użytkownika (opcjonalnie) Kamień milowy: LCA Początkowa Opracowywanie Konstrukcja Wdrażanie LCA Kryteria oceny: Czy wizja produktu jest stabilna?

Faza opracowywania (4) Czy architektura jest stabilna? Czy zidentyfikowano i poprawnie rozwiazano problemy związane z głównymi ryzykami (bazując na demonstracji oprogramowania w oparciu o zbudowany prototyp)? Czy plan dla fazy konstrukcji jest odpowiedni i wystarczająco szczegółowy? Czy wszyscy uczestnicy projektu są zgodni, że o ile zostanie wykonany aktualny plan w oparciu o aktualną architekturę, to aktualna wizja produktu finalnego jest realna? Czy stosunek aktualnych wydatków do wydatków zaplanowanych jest akceptowalny? Jeśli projekt nie przejdzie pomyślnie kamienia milowego LCA, prace mogą zostać zakończone, a co najmniej poważnie przemyślane.

Faza konstrukcji (1) Podstawowe zadania: budowa i rozwój komponentów, integracja całości oraz testowanie. Faza konstrukcji - w podstawowym znaczeniu - jest poświęcona procesom wytwarzania; duży nacisk kładzie się tu na zarządzanie zasobami, optymalizację kosztów i planu oraz na ulepszanie jakości. Dla dużych projektów, można zrównoleglać procesy, co przyspiesza realizację, choć dodatkowo komplikuje zarządzanie dzięki konieczności synchronizowania przepływów prac. Stabilna (robust - krzepka) architektura i dobry plan znacząco wspierają zadania fazy konstrukcji - dlatego tak ważne jest to, co wypracowano w fazach porzedzających fazę konstrukcji.. Podstawowe aktywności: zarządzanie zasobami, optymalizacja procesów, budowa, rozwój i testowanie komponentów w oparciu o zdefiniowane kryteria,

Faza konstrukcji (2) budowa użytecznej wersji produktu (alfa, beta czy innej) - zgodnej z wizją produktu finalnego. Artefakty: produkt, zintegrowany na odpowiedniej platformie, podręcznik użytkownika, opis aktualnego wypuszczenia. Kamień milowy: IOC Początkowa Opracowywanie Konstrukcja Wdrażanie IOC Kryteria oceny: Czy wypuszczany produkt jest dostatecznie stabilny i dojrzały by można było przekazać go użytkownikowi? Czy wszyscy uczestnicy projektu są na to gotowi? Czy poziom wydatków jest akceptowalny w porównaniu do wydatków zaplanowanych?

Faza wdrażania (1) Podstawowe zadanie: przekazanie produktu do użytkowników końcowych, co z reguły pociąga za sobą korektę błędów, dokończenie elementów odłożonych, ulepszanie niektórych własności, itd. - budowę nowej wersji. W praktyce oznacza to z reguły, że pewien użyteczny - o akceptowalnej jakości - podzbiór własności systemu został ukończony, dokumentacja użytkownika jest przygotowana i przekazanie produktu jest korzystne dla wszystkich stron. Przekazanie produktu do użytkownika wymusza: przeprowadzenie beta testów, równoległe działanie do zastępowanego systemu spadkowego, przeniesienie bazy danych do nowego systemu, trenowanie użytkowników, przekazanie produktu do marketingu, dystrybucji i sprzedaży.

Faza wdrażania (2) Faza wdrożenia - w zależności od rodzaju produktu - może być prosta (np. wdrażanie nowej wersji produktu typu DTP) lub ekstremalnie złożona (np. zamiana starego systemu kontroli ruchu w powietrzu na nowy system). Podstawowe aktywności: typowo inżynierskie aktywności związane z wdrażaniem produktu, aktywności związane z poprawianiem błędów i ulepszaniem własności, oszacowanie wdrażanego produktu w oparciu o kryteria akceptacji i wizję dla produktu finalnego. Jeśli trzeba dodać nowe własności, iteracja przybiera charakter podobny do iteracji w fazie konstrukcji. Kamień milowy: Wypuszczenie produktu Początkowa Opracowywanie Konstrukcja Wdrażanie Wypuszczenie produktu

Faza wdrażania (3) Kryteria oceny: Czy użytkownik jest usatysfakcjonowany? Czy poziom wydatków jest akceptowalny w porównaniu do wydatków zaplanowanych? Czwarty, ważny kamień milowy w realizacji projektu oznacza taki punkt w czasie, gdy trzeba zadecydować czy oczekiwania użytkownika zostały zaspokojone i czy trzeba rozpoczynać kolejny cykl ewolucji. W niektórych przypadkach, czwarty kamień milowy zbiega się z końcem fazy początkowej następnego cyklu.

Korzyści z podejścia iteracyjnego Ryzyka mogą być mitygowane wcześniej, niż w podejściu sekwencyjnym: ostateczna integracja, nie jest jedynym momentem, w którym są wykrywane. Znacznie więcej możliwości do rozpoznawania problemu, ulepszania elementów projektu, poznawania narzędzi czy wyszukiwania gotowych komponentów. Łatwiej zarządzać zmianami związanymi z użytkownikami, konkurencją na rynku czy zmianami w technologiach, o które oparto projekt. Zmian w technologii powinno się dokonywać nie później niż w fazie opracowywania; należy unikać wprowadzania tego rodzaju zmian w fazie konstrukcji czy wdrażania, ponieważ jest to nieuchronnie związane z wysokim prawdopodobieństwem niepowodzenia projektu. Większe możliwości dla wprowadzania technologii ponownego użycia. Większe możliwości dla nabywania doświadczenia, a przez to podnoszenia kwalifikacji zespołu projektowego. Większe możliwości dla ulepszania procesu jako takiego. Lepsza jakość produktu finalnego.

Podsumowanie Proces sekwencyjny (jak w modelu wodospadowym) jest odpowiedni dla realizacji małych projektów, czy tych z niewielką liczbą ryzyk (mało nowości, znane technologie, znana dziedzina problemowa, doświadczeni ludzie), natomiast niezbyt nadaje się dla projektów dużych, z dużą liczbą ryzyk. Proces iteracyjny jest realizowany w oparciu o sekwencję iteracji. W trakcie każdej iteracji (stanowiącej miniaturę modelu wodospadowego) wykonywane są aktywności związane z wymaganiami, projektowaniem, implementacją i szacowaniem rezultatów. W celu ułatwienia zarządzania procesem realizacji, iteracje zostały pogrupowane w cztery fazy: początkową, opracowywania, konstrukcji i wdrożenia. W każdej z faz położono różny nacisk na różne aktywności. Podejście iteracyjne ułatwia dokonywanie zmian (związanych z użytkownikiem, rynkiem czy technologiami), mitygację ryzyk, wprowadzanie technologii ponownego użycia, podnoszenie umiejętności członków zespołu, ulepszanie procesu jako takiego – wszystko to w efekcie skutkuje uzyskaniem lepszej jakości produktu finalnego.