Projektowanie systemów informacyjnych Wykład 1 Model przypadków użycia, cd. Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Zagadnienia Zagadnienia Rational Unified Process Model kaskadowy Dlaczego nie model kaskadowy ? Recepta: rozwój iteracyjny Korzyści z podejścia iteracyjnego Aktywności a fazy i iteracje Planownie z uwzględnianiem iteracji Podsumowanie

Rational Unified Process (RUP) Rational Unified Process − produkt firmy Rational Software, poprzez promowanie zdyscyplinowanego podejścia do rozwoju oprogramowania, ułatwia produkcję oprogramowania wysokiej jakości, w przewidywalnym dla klienta czasie i budżecie. RUP oparty został o zbiór sześciu najlepszych praktyk: iteracyjny rozwój, zarządzanie wymaganiami, architektura oparta o komponenty, modelowanie wizualne, systematyczna weryfikacja jakości i zarządzanie zmianami. RUP był wykorzystywany w małych i dużych projektach (dla różnych zastosowań) przez więcej niż 1000 organizacji − dane z końca 1999 roku: Telekomunikacja: Ericsson, Alcatel, MCI Transport, lotnictwo, obrona: Lockheed-Martin, British Aerospace Produkcja: Xerox, Volvo, Intel Finanse: Visa, Merrill Lynch, Schwab Inne: Ernst & Young, Oracle, Deloitte & Touche.

(kodowanie, testowanie) Wypuszczenie produktu Model kaskadowy 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 implementacji Projektowanie 2 Kod Implementacja (kodowanie, testowanie) 3 Integracja (weryfikacja) 4 Jeszcze w latach 80-tych model kaskadowy był uważany za jedyne rozsądne podejście do budowy oprogramowania. Model kaskadowy Inne nazwy: model wodospadowy, model sekwencyjny Wypuszczenie produktu 5

Dlaczego nie model kaskadowy ? (1) Błędne założenia: (a) wymagania mogą być zamrożone po przeprowadzeniu analizy, (b) projekt implementacji będzie „ od razu” dobry. Błędna ocena kontekstu rozwoju oprogramowania. Błędna ocena czynnika ludzkiego. Błędna ocena możliwości wykorzystania podejścia sekwencyjnego. Niedojrzałość inżynierii oprogramowania – zaledwie kilkadziesiąt lat doświadczenia, w przeciwieństwie do tysięcy 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 kaskadowym przyjmuje się założenie, że wymagania na system zostaną poprawnie zdefiniowane po przeprowadzeniu fazy analizy, 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 kaskadowy ? (2) Co może powodować zmiany wymagań? Zmiany w środowisku pracy użytkownika: Zmiany wprowadzane w środowisku pracy 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 może być i z reguły jest zmiana specyfikacji wymagań. Użytkownik wie “dokładnie” czego chce nie na dwa lata przed datą, kiedy oprogramowanie ma być gotowe, ale kilka tygodni po tej dacie (po oddaniu systemu), gdy oprogramowanie 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 kaskadowy ? (3) Ad. 1. Błędne założenie (b): Projekt implementacji – zbudowany w drugim kroku – będzie dobry (i to najlepiej „od razu”). Przez „dobry” projekt implementacji rozumie się taki projekt, który zapewnia realizację nie tylko oczekiwanej funkcjonalności, ale też osiągnięcie własności systemu takich jak np. poprawność, odpowiednia wydajność czy niezawodność, itp. Można wyprodukować tony papierowej dokumentacji, przeprowadzić tysiące przeglądów, a w praktyce i tak nie zabezpiecza to przed uniknięciem błędów w projekcie logicznym. Inżynieria oprogramowania nie osiągnęła jak dotąd poziomu innych dyscyplin inżynieryjnych. Być może nigdy nie osiągnie i być może powinna częścią sztuki, ponieważ wytwarzanie oprogramowania czasami przypomina działalność na pograniczu psychologii, filozofii czy socjologii. Ad. 2. Błędna ocena kontekstu rozwoju oprogramowania Zmiany technologicze: Software czy hardware, z którym rozpoczynano projekt, może już nie być wytwarzany w momencie wypuszczania produktu. Konkurencja na rynku: Tu na niekorzyść projektu działa czas jego realizacji – nawet doskonały produkt nie ma szans na rynku, który poszedł już o krok dalej.

Dlaczego nie model kaskadowy ? (4) 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ą zbyt dalekich powrotów w celu przeprowadzenia korekty. Próba wykorzystania modelu kaskadowego odpowiedniego dla małych projektów (kilka tygodni czy 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 lub jeśli praca odbywa się w nowym środowisku narzędziowym.

Dlaczego nie model kaskadowy ? (5) 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 kaskadowy ? (6) 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 ryzyk, np. dużo niewiadomych czy dużo nowości. 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” w rozwoju oprogramowania i tempo w jakim zmienia się rynek czyni produkcję oprogramowania dziedziną o dużym stopniu ryzyka. Dlatego ryzyka muszą być bezwzględnie brane pod uwagę przez organizacje zajmujące się wytwarzaniem oprogramowania.

Recepta: rozwój iteracyjny (1) Podejście oparte o realizację kompletnego zbioru 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 nie realizowaniu własności X, podjęta w środku implementacji, gdy poświęciliśmy już czas na jej specyfikowanie, projekt implementacji 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/lub rozszerzona wersja.

Recepta: rozwój iteracyjny (2) Jak wykorzystać podejście sekwencyjne 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 kaskadowy. Można wybrać podzbiór wymagań, zrobić dla nich projekt logiczny i implementację, poddać weryfikacji, po czym rozpocząć pracę z kolejnym 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 brać pod uwagę?

Recepta: rozwój iteracyjny (3) 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

Korzyści z podejścia iteracyjnego Korzyści wynikające z wykorzystania podejścia iteracyjnego Braki (błędy) o dużej wadze dla produktu finalnego mogą być wykrywane wcześniej, co umożliwia wcześniejszą reakcję. Łatwiej (bo częściej) można uzyskiwać informacje zwrotne od użytkownika, dzięki czemu wzrastają szanse na prawidłową specyfikację wymagań. Niespójności między wymaganiami, projektem implementacji i kodem mogą być wykrywane wcześniej. Zespół projektowy może poświęcić większą uwagę elementom krytycznym w aktualnej fazie projektu. Praca, wykonywana przez różne grupy członków zespołu projektowego może być bardziej równomiernie rozłożona w czasie. Dzięki iteracyjnemu (ciągłemu i systematycznemu) testowaniu łatwiej szacować statusu projektu. Cały czas są dostępne ” niezbite dowody” ułatwiające to zadanie − ważne dla wszystkich uczestników projektu. Doświadczenia, nabyte w jednym cyklu, można z powodzeniem wykorzystywać w następnych cyklach, czy w ogóle − do ulepszania całości procesu.

Aktywności a fazy i iteracje (1) Początkowa Opracowywanie Konstrukcja Wdrażanie 10% 30% 50% 10% Planowanie Wymagania Architektura Projekt implementacji 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 w oparciu o model kaskadowy; 4 fazy tworzą jeden cykl

Aktywności a fazy i iteracje (2) W każdej z faz położony jest różny nacisk na różne aktywności: Faza początkowa: tu wysiłki koncentrują się na określeniu kontekstu systemu (aktorów), wymagań funkcjonalnych, zakresu odpowiedzialności (głównych wymagań), ograniczeń (wymagań niefunkcjonalnych), kryteriów akceptacji dla produktu finalnego oraz zgrubnego planu projektu. 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 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, aż do uzyskania pierwszego operacyjnego produktu. Faza wdrażania: prace są skoncentrowane na zapewnieniu produktowi odpowiedniej jakości: usuwa się błędy, ulepsza i/lub uzupełnia o brakujące elementy, wypełnia bazę, trenuje użytkowników.

Aktywności a fazy i iteracje (3) Faza opracowywania Podstawowe zadania: (1) przeprowadzić „bardziej dokładną” analizę, (2) wypracować fundamenty dla architektury, (3) wyeliminować elementy obarczone największym ryzykiem, (4) uszczegółowić plan projektu (czyli skonstruować szczegółowe plany dla iteracji). 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ła możliwa realna werfikacja zaplanowanych 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.

Planowanie z uwzględnieniem iteracji (1) Planowanie projektu z uwzględnieniem iteracji wymaga rozstrzygnięcia kwestii, które nie istniały przy zastosowaniu tradycyjnego podejścia kaskadowego, jak np.: Jak wiele iteracji będzie potrzebne? Jak długo powinna trwać każda z nich? W jaki sposób należy ustalić cele i „zawartość” każdej iteracji? Jak należy śledzić postęp prac w trakcie realizacji iteracji? Planowanie dużych, złożonych projektów Ambitne próby planowania realizacji całości dużych, złożonych projektów z dokładnością „co do minuty”, wyróżniania aktywności i przypisywania osób do zadań na kilka miesięcy czy kilka lat do przodu, jak wykazała praktyka − są z góry skazane na niepowodzenie. Tworzono diagramy Gantt’a (czy semantyczne sieci aktywności), które pokrywały całe ściany, a mimo to projekty kończyły się niepowodzeniem. Skuteczna realizacja szczegółowych planów wymaga posiadania zarówno dobrego zrozumienia problemu, jak i stabilnych wymagań, stabilnej architektury oraz ukończony choć jeden podobny projekt, tak by w oparciu o niego można było ustalić szczegółowy WBS.

Planowanie z uwzględnieniem iteracji (2) Innymi słowy, jak można planować zbudowanie przez osobę X w tygodniu n modułu Y skoro w momencie planowania, w żaden sposób nie da się w tym czasie w ogóle wydedukować potrzeby posiadania modułu Y? Planowanie szczegółowe jest możliwe w tych dziedzinach inżynieryjnych, gdzie WBS jest mniej lub bardziej zestandaryzowane i stabilne, gdzie kolejność zadań jest wystarczajaco uporządkowana. Np. budując budynek nie można wznosić jednocześnie piętra pierwszego i czwartego. Po pierwszym musi powstać drugie, potem trzecie, aby można było zająć się czwartym. RUP rekomenduje, by realizacja projektu była opierana na dwóch rodzajach planów, różniących się stopniem szczegółowości: plan faz (zgrubny – nie więcej niż jedna, dwie strony opisu) i seria planów dla iteracji (szczegółowych). Plan faz Tworzony jest jeden plan faz, jeden na potrzeby całego projektu. Plan faz obejmuje z reguły jeden cykl − czasami, stosownie do potrzeb, kilka kolejnych cykli. Tworzony jest bardzo wcześnie, w fazie początkowej. W każdej momencie, może być poddawany modyfikacji.

Planowanie z uwzględnieniem iteracji (3) Plan faz zawiera poniższe elementy: Daty głównych kamieni milowych: LCO – określenie celów danego cyklu rozwijania projektu (koniec fazy początkowej; projekt ma dobrze określony zakres odpowiedzialności i zapewnione środki na realizację). LCA – specyfikacja architektury (koniec fazy opracowywania; stabilizacja architektury). IOC – osiągnięta początkowa zdolność operacyjna (koniec fazy konstrukcji; pierwsze beta). Wypuszczenie produktu (koniec fazy wdrażania i koniec danego cyklu). Profile zespołowe --> jakie zasoby ludzkie są wymagane na poszczególnych etapach cyklu. Specyfikację mniej ważnych kamieni milowych --> data zakończenia każdej iteracji wraz ze specyfikacją jej celów (o ile można je zidentyfikować).

Planowanie z uwzględnieniem iteracji (4) Plan iteracji Tworzony jest jeden plan dla każdej iteracji (plan szczegółowy). Projekt z reguły posiada dwa plany iteracji aktywne w danym momencie: Plan dla bieżącej iteracji: jest wykorzystywany do śledzenia postępów prac w trakcie realizacji iteracji. Plan dla następnej iteracji: jest tworzony począwszy od połowy bieżącej iteracji i jest prawie (?) gotowy przy jej końcu. Plan iteracji tworzony jest za pomocą tradycyjnych technik (diagramy Gantt’a, itp.) i narzędzi do planowania (Microsoft Project, itp.). Cel – definiowanie zadań, przypisanie zadań do osób i zespołów. Plan zawiera ważne daty, takie jak np.: zakończenie budowy „czegoś”, dostarczenie komponentów z innej organizacji czy terminy głównych przeglądów. RUP – przyjmując za podstawę proces iteracyjny i niekończącą się akomodację zmian celów i taktyki – zakłada tym samym, że nie istnieją racjonalne powody, by marnować czas na przygotowywanie szczegółowych planów dla dłuższych horyzontów czasowych: takie plany są trudne do zarządzania, szybko stają się nieaktualne oraz z reguły są ignorowane przez organizacje wykonawcze).

Planowanie z uwzględnieniem iteracji (5) Iteracje w fazie początkowej W fazie początkowej często uważa się, że iteracji nie ma, tzn. nie ma czegoś, co można by nazwać „prawdziwą iteracją” (mini-projektem): żaden kod nie jest produkowany, wykonywane są przede wszystkim aktywności związane z rozpoznawaniem, planowaniem i marketingiem. Czasami jednak iteracja jest potrzebna, po to by: Zbudować prototyp, by przekonać siebie czy sponsora, że proponowane rozwiązanie (lepiej: pomysł na rozwiązanie) jest dobre. Zbudować prototyp, w celu mitygowania ryzyk technicznych (np. eksploracja nowych technologii czy nowych algorytmów) czy udowodnienia, że cele wydajnościowe są osiągalne. Przyspieszyć wdrażanie narzędzi i procesów w organizacji.

Planowanie z uwzględnieniem iteracji (6) Iteracje w fazie opracowywania Plany dla iteracji w fazie opracowywania muszą być budowane w oparciu o trzy, najważniejsze w tej fazie elementy: ryzyka, własności krytyczne dla osiągnięcia sukcesu i pokrycie : Plany powinny być budowane tak, by większość ryzyk została zmitygowana lub „wysłana na emeryturę” właśnie w fazie opracowywania. Ryzyka są bardzo ważne, ale to nie mitygacja ryzyk jest celem ostatecznym. Ostatecznym celem jest uzyskanie produktu, posiadającego własności uznane za krytyczne dla osiągnięcia sukcesu. Ponieważ podstawowym celem fazy opracowywania jest budowa stabilnej architektury, plany muszą być konstruowane tak, by architektura adresowała wszystkie aspekty oprogramowania (pokrycie). Jest to ważne, bo architektura stanowi bazę dla dalszego planowania.

Podsumowanie (1) Proces sekwencyjny 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, opartej o model kaskadowy, wykonywane są aktywności związane z wymaganiami, tworzeniem projektu implementacji, 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 wdrażania. 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.

Podsumowanie (2) RUP − jako proces “prowadzony” w oparciu o przypadki użycia − uczynił z przypadków bazę dla całego procesu budowania produktu tworząc w oparciu o nie rodzaj języka stanowiącego podstawę do komunikacji między wszystkimi osobami zaangażowanymi w realizację projektu. W RUP, przypadki użycia wspomagają członków zespołu przy: planowaniu iteracji, budowie i walidacji stabilnej architektury systemu, definiowaniu przypadków i procedur testowych w modelu testów, tworzeniu dokumentacji użytkownika, rozmieszczaniu aplikacji (ang. deployment).