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

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 2 Zagadnienia Kryzys oprogramowania Najlepsze praktyki w rozwoju oprogramowania  Iteracyjny rozwój  Zarządzanie wymaganiami  Architektura oparta o komponenty  Wizualne modelowanie  Systematyczna weryfikacja jakości  Zarządzanie zmianami Proces wspierający rozwój oprogramowania Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 3 Kryzys oprogramowania (1) We współczesnym świecie informatyzacja ma miejsce w prawie wszystkich dziedzinach życia powszedniego – oprogramowanie to centralny składnik różnych, czasami bardzo złożonych systemów technicznych, jak np. aparatura medyczna, elektrownie jądrowe, samoloty, rakiety, satelity, systemy telefoniczne, systemy ekonomiczne, systemy produkcji przemysłowej, systemy handlowe, giełdy, banki, itp. Oprogramowanie ma wypełniać nie tylko potrzeby techniczne, ale też ekonomiczne czy społeczne. Jakość oprogramowania: Z jednej strony: Niska jakość oprogramowania może powodować dramatyczne konsekwencje. Z drugiej strony: Trudno sprecyzować na czym polega jakość oprogramowania i określić kiedy jest ono rzeczywiście wysokiej jakości. W pracach wielu autorów rozważane są bardzo różnorodne czynniki wspomagające ocenę jakości produktu programistycznego.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 4 Kryzys oprogramowania (2)  Poprawność: czy oprogramowanie wypełnia postawione przed nim zadania i czy jest wolne od błędów.  Łatwość użycia: miara stopnia łatwości korzystania z oprogramowania.  Czytelność: miarą jest wysiłek niezbędny do zrozumienia oprogramowania.  Ponowne użycie: przydatność oprogramowania (całego lub tylko pewnych jego fragmentów) do wykorzystania w innych produktach programistycznych.  Stopień strukturalizacji (modularność): jak łatwo oprogramowanie daje się podzielić na części składowe (moduły) o dobrze uchwyconej semantyce i dobrze wyspecyfikowanych wzajemnych interakcjach.  Efektywność: stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania.  Przenaszalność: łatwość przenoszenia oprogramowania na inne platformy sprzętowe czy programowe.  Skalowalność: zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników, itp.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 5 Kryzys oprogramowania (3)  Współdziałanie: zdolność oprogramowania do niezawodnej współpracy z innym, niezależnie skonstruowanym oprogramowaniem. Źródła kryzysu:  Złożoność współczesnych produktów programistycznych.  Kontrast pomiędzy odpowiedzialnością, jaka spoczywa na współcześnie tworzonych produktach programistycznych, a zawodnością wynikającą z ich złożoności.  Złożoność procesów wytwarzania, niedojrzałe metody zarówno tworzenia oprogramowania, jak i weryfikacji jego jakości.  Szybki rozwój technologii informatycznych. Philippe Krutchen: “There are no more small systems left to build”.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 6 Symptomy kryzysu oprogramowania  błędna identyfikacja potrzeb użytkownika: niezrozumienie “w ogóle” albo zrozumienie “nie do końca”,  źle współpracujące moduły oprogramowania, wadliwa architektura,  późne wykrywanie poważnych wad oprogramowania,  nieumiejętne zarządzanie zmianami: nie wiadomo “kto zmienił”, “co zmienił”, “kiedy zmienił”, “gdzie zmienił” i “dlaczego zmienił”,  niedojrzały proces budowy, niska efektywność procesu wytwarzania,  niska efektywność procesu wypuszczania produktu na rynek,  niska jakość produktu,  oprogramowanie trudne do pielęgnacji (w tym do rozszerzania). Symptomy kryzysu oprogramowania, wspólne dla większości projektów:

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 7 Przyczyny niepowodzeń projektów  brak odpowiedniego zarządzania wymaganiami,  nieprecyzyjna, niejednoznaczna komunikacja pomiędzy uczestnikami projektu,  “krucha” (niestabilna) architektura,  niezidentyfikowanie niespójności w wymaganiach, projekcie i implementacji,  niewystarczające testowanie,  subiektywna ocena statusu projektu,  niewłaściwe zarządzanie ryzykiem,  niekontrolowana propagacja zmian,  niewystarczająca automatyzacja prac. Główne przyczyny niepowodzeń projektów to z reguły kombinacja kilku z poniżej wymienionych czynników:

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 8 Kryzys oprogramowania a informatycy Kryzys oprogramowania a środowisko informatyków:  Dobra wiadomość: wzrost znaczenia oprogramowania we współczesnym świecie (wspomaganie tworzenia, przechowywania, dostępu i wizualizacji informacji w prawie każdej dziedzinie działalności człowieka) pociąga za sobą wzrost zapotrzebania na usługi informatyków.  Zła wiadomość: wzrost zarówno złożoności jaki i wagi oprogramowania przy jednoczesnym żądaniu wzrostu efektywności procesu wytwarzania i wzrostu jakości produktu musi skutkować wzrostem wysiłków na rzecz nabywania wiedzy o profesjonalnej budowie oprogramowania i wdrażania tej wiedzy do codziennej działalności środowiska informatycznego. Jak budować oprogramowanie wysokiej jakości w powtarzalny i przewidywalny sposób, w czasie możliwym do zaakceptowania przez klienta (lub rynek)?

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 9 Najlepsze praktyki 1. Iteracyjny rozwój 2. Zarządzanie wymaganiami 3. Architektura oparta o komponenty 4. Wizualne modelowanie 5. Systematyczna weryfikacja jakości 6. Zarządzanie zmianami Najlepsze praktyki w rozwoju oprogramowania: Powyższe praktyki, nazywane są “najlepszymi” nie dlatego, że ktokolwiek jest w stanie precyzyjnie oszacować ich wartość, ale dlatego, że zostały oparte o doświadczenia wytwórców oprogramowania i są powszechnie wykorzystywane przez organizacje uzyskujące wymierne sukcesy na tym polu. Innymi słowy: stanowią syntezę doświadczeń tysięcy ośrodków zajmujących się budową oprogramowania. Lata doświadczeń pokazały, że w rozwoju oprogramowania trudno jest mówić o stereotypie „od teorii do praktyki”.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 10 Iteracyjny rozwój (1) Określenie wymagań Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Określenie celów i specyfikacja szczegółowych wymagań na system Szczegółowy projekt systemu uwzględniający wcześniejsze wymagania Modyfikacje producenta: usuwanie błędów, wprowadzanie zmian i rozszerzeń Analiza Model kaskadowy, zwany też modelem sekwencyjnym lub wodospadowym.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 11 Iteracyjny rozwój (2) Analiza wymagań Analiza wymagań Kodowanie i testowanie jednostek Kodowanie i testowanie jednostek Testowanie podsystemów Testowanie podsystemów Testowanie systemu Testowanie systemu Projektowanie Ryzyko Czas

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 12 Iteracyjny rozwój (4) Zalety: model kaskadowy jest do pewnego stopnia niezbędny dla planowania, harmonogramowania, monitorowania i rozliczeń finansowych.  Długa przerwa w kontaktach z klientem.  Narzucenie twórcom oprogramowania ścisłej, określonej z góry, kolejności wykonywania prac.  Wysoki koszt błędów popełnionych we wczesnych fazach. Istnieją różne poglądy co do praktycznej przydatności modelu kaskadowego. Wady: Jeśli, od samego początku nie zostanie przyjęta aktywna postawa wobec ryzyka − a jest to trudne do zrealizowania w modelu kaskadowym − to w pewnym momencie może się okazać, że żadne rozwiązania nie będą już skuteczne. Tom Gilb, “Principles of Software Engineering Management, Harlow, UK: Addison-Wesley, 1988: “If do not actively attack the risks in your project, they will actively attack you”.  Problemy z mitygacją ryzyk.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 13 Iteracyjny rozwój () Analiza wymagań Projektowanie Implementacja (kodowanie, testowanie) Integracja Specyfikacja wymagań Specyfikacja projektu Kod Produkt programistyczny Wymagania użytkownika Model kaskadowy z iteracjami

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 14 Iteracyjny rozwój (5) Planowanie Analiza i projektowanie Wypuszczenie produktu Ewaluacja, np. atestowanie przez klienta Planowanie początkowe Specyfikacja wymagań Implementacja Testowanie Model spiralny Barry Bohem’a: proces iteracyjny i przyrostowy jako alternatywa dla modelu kaskadowego. Każdy kolejny cykl przebiega zgodnie z modelem kaskadowym.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 15 Iteracyjny rozwój (6)  Braki (błędy) o dużej wadze dla produktu finalnego mogą być wykrywane wcześniej (np. w początkowych cyklach), 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 członków zespołu projektowego − a w szczególności zespołu testującego − może być bardziej równomiernie rozłożona w czasie.  Dzięki iteracyjnemu (ciągłemu i systematycznemu) testowaniu łatwiej (bardziej obiektywnie) 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. Podejście iteracyjne i przyrostowe (Bohem’a) a podejście kaskadowe:

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 16 Zarządzanie wymaganiami (1) Wymagania dzielą się na funkcjonalne i niefunkcjonalne (warunki i ograniczenia). Wymagania zmieniają się przez całe życie systemu, nie tylko na skutek popełnionych błędów, ale także na skutek zmian zewnętrznych czy też wzrostu świadomości uczestników projektu w trakcie budowy systemu. Specyfikacja wymagań, tak by przyszły system spełniał rzeczywiste potrzeby użytkownika (techniczne, ekonomiczne i społeczne), to proces bez końca. Dla większości systemów, ustalenie wyczerpującego zestawu wymagań przed rozpoczęciem prac projektowych jest praktycznie niewykonalne. Aktywne zarządzanie wymaganiami opiera się na czynnościach przynależnych do trzech podstawowych grup: 1. pozyskiwanie, organizowanie i dokumentowanie wymagań, 2. zmiana wymagań (szacowanie ich wpływu na inne elementy projektu), 3. śledzenie oraz dokumentowanie wszelkich decyzji (w tym kompromisów) związanych ze zmianami wymagań.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 17 Zarządzanie wymaganiami (2) Korzyści z aktywnego zarządzania wymaganiami:  Można (i trzeba) narzucić bardziej zdyscyplinowane podejście do procesu obsługi wymagań.  Wymagania mogą być filtrowane, można im przypisywać priorytety, można śledzić ich zmiany.  Niespójności między wymaganiami mogą być wykrywane wcześniej.  Można oprzeć o wymagania komunikację pomiędzy uczestnikami projektu (klientem, użytkownikami końcowymi, analitykami, projektantami, implementatorami, testerami, menadżerami, itd.). Zmiany wymagań to główna przyczyna opóźnień projektów, niezadowolenia klientów i frustacji członków zespołu projektowego.  Wykorzystując wsparcie narzędziowe można zbudować repozytorium wymagań z linkami do odpowiednich dokumentów.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 18 Architektura oparta o komponenty Architektura oparta o komponenty umożliwia osiągnięcie powyższych własności. Można wykorzystywać elementy strukturalne z oferty rynkowej, takie jak np.: Microsoft Component Object Model (COM/DCOM), Common Object Request Broker Architecture (CORBA) z Object Management Group (OMG) czy Enterprise JavaBeans (EJB) z Sun Microsystems. Architektura systemu budowana jest w oparciu o zbiór decyzji związanych z organizacją systemu i dotyczących:  selekcji elementów strukturalnych (składowych systemu) i specyfikacji ich interfejsów,  specyfikacji sposobów współpracy elementów strukturalnych,  podziału na podsystemy (poprzez łączenie elementów strukturalnych). Architektura systemu jest związana także z efektywnością, ponownym użyciem, zdolnością do szybkiego podnoszenia się, łatwością użycia, itp.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 19 Wizualne modelowanie (1) Model stanowi opis systemu na pewnym poziomie szczegółowości z pewnej perspektywy. Pewne elementy mogą zostać ukryte, a pewne wyeksponowane. Budujemy model, aby lepiej zrozumieć system, nad którym pracujemy. Budujemy modele złożonych systemów, ponieważ nie jesteśmy w stanie objąć rozumowo wszystkich aspektów złożonego systemu jednocześnie. Korzyści z modelowania wizualnego:  Modelowanie wspomaga zespół projektowy w procesie specyfikowania, konstruowania i dokumentowania artefaktów tworzonego systemu.  Oparcie procesu budowania systemu o język do modelowania (np. UML) umożliwia jednoznaczną komunikację między członkami zespołu projektowego.  Narzędzia (wizualne) ułatwiają zarządzanie modelami, dbając o ich wzajemną spójność: ułatwiają wprowadzanie zmian, szacowanie ich wpływu na inne elementy projektu oraz informowanie członków zespołu o zmianach.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 20 Wizualne modelowanie (2) Model Diagram klas Diagram komponentów Diagram dynamiczny Diagram wdrożeniowy Diagram use case Scenariusz

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 21 Systematyczna weryfikacja jakości (1) Charakterystyczną cechą przedsięwzięć software’owych, a w szczególności tych opartych o model kaskadowy, jest to, że koszty naprawy błędów w fazie konserwacji są znacznie wyższe niż w fazach ją poprzedzających. Dlatego do systematycznej weryfikacji jakości przykłada się duże znaczenie, czego efektem jest umieszczenie jej, jako jednego z elementów, w sześcio-elementowym zbiorze najlepszych praktyk. Systematyczna weryfikacja jakości może odnosić się do funkcjonalności, niezawodności, wydajności, itd. Np. systematyczna weryfikacja funkcjonalności polega na budowie testów dla każdego z kluczowych scenariuszy (reprezentujących najbardziej pożądane aspekty zachowania systemu) i nieustannemu szacowaniu który ze scenariuszy został już przetestowany, który pracuje dobrze, który źle, gdzie źle, dlaczego źle, itd. koszt naprawy błędów czas

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 22 Systematyczna weryfikacja jakości (2) 1.Wszelkie defekty (błędy, braki) mogą być wykrywane wcześniej, co prowadzi do radykalnego zmniejszenia kosztów ich naprawy. 2.Testowanie i weryfikację można koncentrować na obszarach największego ryzyka w celu poprawienia jakości właśnie tych obszarów. 3.Można (i należy) wykorzystywać narzędzia wspomagające automatyzację procesu testowania. 4.Dzięki możliwości przeprowadzania bardziej obiektywnych szacunków, łatwiej uwidaczniają się wszelkie niespójności między wymaganiami, projektem implementacji a kodem. 5.Szacowanie statusu projektu może być bardziej obiektywne, w oparciu o wyniki testów, a nie o papierową dokumentację. Systematyczna weryfikacja jakości − wspomagana przez iteracyjny rozwój oprogramowania − ułatwia rozwiązanie niektórych problemów, utrudniających proces budowy oprogramowania, jak np.:

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 23 Zarządzanie zmianami Problemy: zespół projektowy złożony z dużej liczby osób, wiele iteracji, wiele produktów, wiele platform, często prace rozproszone geograficznie. Nie wiadomo kto, co, kiedy i gdzie zmienił,... Zarządzanie zmianami to rodzaj środka zaradczego na powyższe problemy. Można tu wprowadzić szereg rozwiązań pomocniczych, jak np. :  Dzięki izolowaniu przestrzeni prac członków zespołu (workspaces) można pozwolić na równoległą pracę.  Można specyfikować żądania (potrzeby) wprowadzania zmian, co ułatwia komunikację w zespole projektowym.  Zmiany należy przeprowadzać tylko w stabilnym (ang. robust) systemie.  Propagacje zmian powinny być szacowane i nadzorowane.  Przepływy prac związanych z zarządzaniem zmianami można zdefiniować w postaci umożliwiającej powtórzenia.  Statystyki, w oparciu o które można śledzić częstotliwość wprowadzanych zmian, mogą wspomóc szacowanie rzeczywistego statusu projektu.

E. Stemposz. Rational Unified Process, Wykład 1, Slajd 24 Proces wspierający rozwój oprogramowania Zadania procesu (metodyki ?) wspierającego rozwój oprogramowania: 1.Dostarczenie przewodnika dla aktywności realizowanych przez zespół projektowy w trakcie budowy oprogramowania. 2.Określenie, jakie artefakty powinny być rozwijane i kiedy powinny być rozwijane. 3.Zarządzanie zarówno całością projektu, jak i zadaniami przydzielonymi jego indywidualnym uczestnikom. 4.Ustalenie kryteriów dla pomiarów i monitorowania zarówno aktywności, jak i dla wytwarzanych w trakcie artefaktów. Bez dobrze zdefiniowanego procesu nie jest możliwe ani rozwijanie oprogramowania w powtarzalny, przewidywalny sposób ani wzrost efektywności i produktywności organizacji jako całości. Dobrze zdefiniowany proces nie tylko zezwala, ale wręcz zachęca do wykorzystywania “najlepszych praktyk”.