Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

E. Stemposz. Rational Unified Process, Wykład 4, Slajd 1 wrzesień 2002 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 4 Dynamiczna struktura.

Podobne prezentacje


Prezentacja na temat: "E. Stemposz. Rational Unified Process, Wykład 4, Slajd 1 wrzesień 2002 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 4 Dynamiczna struktura."— Zapis prezentacji:

1 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 1 wrzesień 2002 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 4 Dynamiczna struktura RUP Wykładowca: dr inż. Ewa Stemposz Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

2 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 2 wrzesień 2002 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.

3 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 3 wrzesień 2002 Dlaczego nie model wodospadowy ? (1) Analiza wymagań Projektowanie Implementacja (kodowanie, testowanie) Integracja (weryfikacja) Specyfikacja wymagań Specyfikacja projektu logicznego Kod Wypuszczenie produktu 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. Jeszcze w latach 80-tych model wodospadowy był uważany za jedyne rozsądne podejście do budowy oprogramowania

4 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 4 wrzesień 2002 Dlaczego nie model wodospadowy ? (2) 1.Błędne założenia: (a) wymagania mogą być zamrożone, (b) projekt logiczny będzie odpowiedni od razu. 2.Błędna ocena kontekstu rozwoju oprogramowania. 3.Błędna ocena czynnika ludzkiego. 4.Błędna próba wykorzystania podejścia (sekwencyjnego). 5.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. Dlaczego nie model wodospadowy? 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.

5 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 5 wrzesień 2002 Dlaczego nie model wodospadowy ? (3) 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 (Ill Know It When I See It). Co może powodować zmiany wymagań? 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.

6 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 6 wrzesień 2002 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. 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. Ad. 2. Błędna ocena kontekstu rozwoju oprogramowania

7 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 7 wrzesień 2002 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.

8 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 8 wrzesień 2002 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.

9 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 9 wrzesień 2002 Dlaczego nie model wodospadowy ? (7) 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. 4. Model sekwencyjny jest nieodpowiedni dla dużych, złożonych projektów z dużą liczbą ryzyk? 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.

10 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 10 wrzesień 2002 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.

11 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 11 wrzesień 2002 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 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? Jak dokonywać wyboru, co powinno być zrealizowane w kolejnych iteracjach - jaki podzbiór wymagań i jakie ryzyka rozpatrzyć? Jak się ustrzec przed zjawiskiem, by każda kolejna iteracja nie rozpoczynała się ponownie początkiem realizacji projektu?

12 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 12 wrzesień 2002 Recepta: iterować (3) Aw P Im In Aw - Analiza wymagań, P - Projektowanie, Im- Implementacja, In - Integracja Aw P Im In Aw P Im In Aw P Im In jedna iteracja czas

13 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 13 wrzesień 2002 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ątkowaOpracowywanieKonstrukcjaWdroż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

14 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 14 wrzesień 2002 Fazy i kamienie milowe (2) Kamienie milowe 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.

15 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 15 wrzesień 2002 Fazy i kamienie milowe (3) POKW 1-sza generacja produktu POKW 2-ga generacja produktu POKW 3-cia generacja produktu Cykl początkowy Cykl ewolucji Cykle mogą nieznacznie zachodzić na siebie. Cykl ewolucji 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.

16 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 16 wrzesień 2002 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.

17 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 17 wrzesień 2002 Fazy i kamienie milowe (5) POKW 10%30%50%10% czas Typowy rozkład czasu dla cyklu początkowego PoczątkowaOpracowywanie Konstrukcja Wdrażanie czas I #1I #2I #3I #4I #5I #6I #7I #8 wypuszczenie wewnętrzne pomocniczy kamień milowy pierwsze wypuszczenie na zewnątrz, np. beta wypuszczenie produktu finalnego Cykl wraz z iteracjami, wypuszczeniami produktu i kamieniami milowymi

18 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 18 wrzesień 2002 Aktywności a iteracje (1) PoczątkowaOpracowywanie Planowanie Wymagania Architektura Projekt Implementacja Testowanie, weryfikowanie KonstrukcjaWdrożenie Integracja Iter. wstępna Iter. #1, Iter. #2Iter.#n, Iter. #..., Iter.#mIter. #m+1, Iter.#m+2 Każda iteracja przebiega zgodnie z modelem wodospadowym

19 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 19 wrzesień 2002 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.

20 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 20 wrzesień 2002 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ć ?

21 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 21 wrzesień 2002 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.

22 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 22 wrzesień 2002 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ątkowaOpracowywanie 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.

23 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 23 wrzesień 2002 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.

24 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 24 wrzesień 2002 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.

25 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 25 wrzesień 2002 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ątkowaOpracowywanie Konstrukcja Wdrażanie LCA Kryteria oceny: Czy wizja produktu jest stabilna?

26 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 26 wrzesień 2002 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.

27 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 27 wrzesień 2002 Faza konstrukcji (1) Podstawowe zadania: budowa i rozwój komponentów, integracja całości oraz testowanie. zarządzanie zasobami, optymalizacja procesów, budowa, rozwój i testowanie komponentów w oparciu o zdefiniowane kryteria, 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:

28 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 28 wrzesień 2002 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ątkowaOpracowywanie 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?

29 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 29 wrzesień 2002 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.

30 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 30 wrzesień 2002 Faza wdrażania (2) 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. Podstawowe aktywności: 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). Kamień milowy: Wypuszczenie produktu PoczątkowaOpracowywanie Konstrukcja Wdrażanie Wypuszczenie produktu Jeśli trzeba dodać nowe własności, iteracja przybiera charakter podobny do iteracji w fazie konstrukcji.

31 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 31 wrzesień 2002 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.

32 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 32 wrzesień 2002 Korzyści z podejścia iteracyjnego 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. 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.

33 E. Stemposz. Rational Unified Process, Wykład 4, Slajd 33 wrzesień 2002 Podsumowanie 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. 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.


Pobierz ppt "E. Stemposz. Rational Unified Process, Wykład 4, Slajd 1 wrzesień 2002 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 4 Dynamiczna struktura."

Podobne prezentacje


Reklamy Google