Studia Podyplomowe IT w Biznesie Rational Unified Process
description
Transcript of Studia Podyplomowe IT w Biznesie Rational Unified Process
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 1 wrzesień 2002
Studia Podyplomowe IT w BiznesieRational Unified Process
Wykład 1Najlepsze 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 wrzesień 2002
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 wrzesień 2002
Kryzys oprogramowania (1)
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. – we współczesnym świecie informatyzacja ma miejsce w prawie wszystkich dziedzinach życia powszedniego.
Oprogramowanie to produkt, który ma speł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 wrzesień 2002
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ść: 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 o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji. 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 wrzesień 2002
Kryzys oprogramowania (3)
Współdziałanie: zdolność oprogramowania do niezawodnej współpracy z innym, niezależnie skonstruowanym oprogramowaniem.
Kontrast pomiędzy odpowiedzialnością, jaka spoczywa na współcześnie tworzonym oprogramowaniu, a zawodnością wynikającą z jego złożoności i niedojrzałych metod tworzenia oraz weryfikacji jakości.
Źródła kryzysu:
Złożoność produktów i procesów wytwarzania 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 wrzesień 2002
Symptomy kryzysu oprogramowania
niewłaściwa identyfikacja potrzeb użytkownika: niezrozumienie “w ogóle” lub zrozumienie “nie do końca”,
nieumiejętne zarządzanie zmianami: nie wiadomo “kto zmienił”, “co zmienił”, “kiedy zmienił”, “gdzie zmienił” i “dlaczego zmienił”,
źle współpracujące moduły oprogramowania, wadliwa architektura,
oprogramowanie trudne do pielęgnacji (w tym rozszerzania),
późne wykrywanie poważnych wad oprogramowania,
niedojrzały proces budowy i wypuszczania produktu na rynek,
niska efektywność procesu wytwarzania,
niska jakość produktu.
Wspólne dla większości projektów symptomy kryzysu oprogramowania:
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 7 wrzesień 2002
Przyczyny niepowodzeń projektów
brak odpowiedniego zarządzania wymaganiami, nieprecyzyjna, niejednoznaczna komunikacja między uczestnikami projektu, “krucha” (niestabilna) architektura, złożoność produktu, 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 jednego z poniżej wymienionych czynników:
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 8 wrzesień 2002
Rozwój oprogramowania a informatycy
Rozwoj 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 rozmiaru, złożoności i wagi oprogramowania wraz z żądaniami wzrostu efektywności procesu wytwarzania i wzrostu jakości produktu musi skutkować wzrostem wysiłków zarówno na rzecz nabywania wiedzy o profesjonalnej budowie oprogramowania, jak i na rzecz wdrażania najlepszych praktyk do codziennej działalności środowiska informatycznego.
Jak budować wysokiej jakości oprogramowanie w powtarzalny i przewidywalny sposób, w czasie możliwym do zaakceptowania przez klienta (czy rynek)?
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 9 wrzesień 2002
Najlepsze praktyki
Iteracyjny rozwój Zarządzanie wymaganiami Architektura oparta o komponenty Wizualne modelowanie Systematyczna weryfikacja jakości Zarządzanie zmianami
Najlepsze praktyki w rozwoju oprogramowania:
Nazywane “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 wymierny sukces na tym polu. Innymi słowy: stanowią syntezę doświadczenia tysięcy ośrodków zajmujących się budową oprogramowania. Praktyka pokazała, że w rozwoju oprogramowania trudno jest mówić o stereotypie „od teorii do praktyki”.
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 10 wrzesień 2002
Iteracyjny rozwój (1)
Określeniewymagań
Określeniewymagań
ProjektowanieProjektowanie
ImplementacjaImplementacja
TestowanieTestowanie
KonserwacjaKonserwacja
Określenie celów i specyfikacja szczegółowych wymagań na system
Szczegółowy projekt systemu uwzględniający wcześniejsze
wymagania
Modyfikacje producenta: usunięcie błędów, zmiany i rozszerzenia
AnalizaAnaliza
Model kaskadowy
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 11 wrzesień 2002
Iteracyjny rozwój (2)
Analizawymagań
Analizawymagań
Kodowaniei testowaniejednostek
Kodowaniei testowaniejednostek
Testowaniepodsystemów
Testowaniepodsystemów
Testowaniesystemu
Testowaniesystemu
ProjektowanieProjektowanie
Ryzyko
Czas
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 12 wrzesień 2002
Iteracyjny rozwój (4)
Zalety: model kaskadowy jest do pewnego stopnia niezbędny dla planowania, harmonogramowania, monitorowania i rozliczeń finansowych.
Jeśli, od samego początku nie zostanie przyjęta aktywna postawa wobec ryzyka (typowe dla podejścia sekwencyjnego w modelu wodospadowym), 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”.
Długa przerwa w kontaktach z klientem.
Narzucenie twórcom oprogramowania ścisłej 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:
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 13 wrzesień 2002
Iteracyjny rozwój ()
Analizawymagań
Projektowanie
Implementacja(kodowanie, testowanie)
Integracja
Specyfikacjawymagań
Specyfikacjaprojektu
Kod
Produktprogramistyczny
Wymagania użytkownika
Model kaskadowy z iteracjami
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 14 wrzesień 2002
Iteracyjny rozwój (5)
Planowanie
Analiza i projektowanie
Wypuszczenieproduktu
Ewaluacja,np. atestowanie
przez klienta
Planowaniepoczątkowe
Specyfikacja wymagań
Implementacja
Testowanie
Model spiralny Barry Bohem’a: specyfikuje proces iteracyjny i przyrostowy jako alternatywę dla modelu sekwencyjnego.
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 15 wrzesień 2002
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 ciągłemu, iteracyjnemu 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 a podejście sekwencyjne:
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 16 wrzesień 2002
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 użytkowników w trakcie używania systemu.
Specyfikacja wymagań, które spełniają rzeczywiste potrzeby użytkownika (techniczne i ekonomiczne), to proces bez końca. Dla większości systemów, ustalenie kompletnego, 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 wrzesień 2002
Zarządzanie wymaganiami (2)
Korzyści z aktywnego zarządzania wymaganiami:
Można 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 mogą być wykrywane wcześniej. Można oprzeć o wymagania komunikację pomiędzy uczestnikami projektu (użytkownikami końcowymi, analitykami, projektantami, implementatorami, testerami, menadżerami).
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 wrzesień 2002
Architektura oparta o komponenty
Architektura oparta o komponenty umożliwia ponowne użycie elementów z szerokiej oferty rynkowej: Microsoft Component Object Model (COM), 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, dotyczących:
selekcji elementów strukturalnych i specyfikacji ich interfejsów, specyfikacji współpracy elementów strukturalnych, podziału na podsystemy (poprzez łączenie elementów strukturalnych).
Architektura jest związana nie tylko ze strukturą i zachowaniami systemu, ale też z jego efektywnością, strukturalizacją, ponownym użyciem, spójnością, zdolnością do szybkiego podnoszenia się, łatwością użycia, itp.
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 19 wrzesień 2002
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 architektury systemu.
Wykorzystanie języka do modelowania (np. UML’a) 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 i informowanie członków zespołu o zmianach.
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 20 wrzesień 2002
Wizualne modelowanie (2)
Model
Diagramyklas
Diagramykomponentów
Diagramystanu
Diagramywdrożeniowe
Diagramyuse case
Diagramyscenariuszy
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 21 wrzesień 2002
Systematyczna weryfikacja jakości (1)
Dla przedsięwzięć software’owych, koszty naprawy błędów w fazie konserwacji są znacznie wyższe niż w fazach poprzedzających. Dlatego duże znaczenie ma tu systematyczna weryfikacja jakości, w odniesieniu do funkcjonalności, niezawodności, wydajności, itd. Np. systematyczna weryfikacja funkcjonalności polega na budowie testów dla każdego z kluczowych scenariuszy: każdy ze scenariuszy reprezentuje jeden z pożądanych aspektów zachowania systemu. Szacowanie funkcjonalności polega na sprawdzaniu który ze scenariuszy został już przetestowany, który pracuje dobrze, który źle, gdzie źle, dlaczego źle, itd.
koszt
czas
Systematyczna weryfikacja jakości - wspomagana przez iteracyjny rozwój oprogramowania - umożliwia rozwiązanie niektórych z wymienianych wcześniej problemów:
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 22 wrzesień 2002
Systematyczna weryfikacja jakości (2)
1. Szacowanie statusu projektu może być bardziej obiektywne, w oparciu o wyniki testów, a nie o papierową dokumentację.
2. Dzięki możliwości przeprowadzania bardziej obiektywnych szacunków, łatwiej uwidaczniają się wszelkie niespójności między wymaganiami, projektem implementacji a kodem.
3. Testowanie i weryfikację można koncentrować na obszarach największego ryzyka w celu poprawienia jakości właśnie tych obszarów.
4. Wszelkie defekty (błędy, braki) mogą być wykrywane wcześniej, co prowadzi do radykalnego zmniejszenia kosztów ich naprawy.
5. Można wykorzystywać narzędzia wspomagające automatyzację procesu testowania.
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 23 wrzesień 2002
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ń, jak np. :
Przepływy prac związanych z zarządzaniem wymaganiami można zdefiniować w postaci umożliwiającej powtórzenia. Można specyfikować żądania (potrzeby) wprowadzania zmian, co ułatwia komunikację w zespole projektowym. Izolowanie przestrzeni prac członków zespołu (workspaces) umożliwia pracę równoległą. Statystyki, w oparciu o które można śledzić częstotliwość wprowadzanych zmian, mogą wspomóc szacowanie statusu projektu. Propagacje zmian powinny być szacowane i nadzorowane. Zmiany powinny być przeprowadzane w stabilnym (ang. robust) systemie.
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 24 wrzesień 2002
Proces wspierający rozwój oprogramowania
Zadania procesu (metodyki ?) wspierającego rozwój oprogramowania:
1. Dostarczenie przewodnika dla aktywności realizowanych przez zespół projektowy.
2. Określenie, jakie artefakty powinny być rozwijane i kiedy.
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 artefaktów wytwarzanych w trakcie ich realizacji.
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”.