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

[email protected]

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Warszawa


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.


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.



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.



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”.


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:


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:


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)?


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”.


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



Analizawymagań

Analizawymagań

Kodowaniei testowaniejednostek

Kodowaniei testowaniejednostek

Testowaniepodsystemów

Testowaniepodsystemów

Testowaniesystemu

Testowaniesystemu

ProjektowanieProjektowanie

Ryzyko

Czas



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:


Iteracyjny rozwój ()

Analizawymagań

Projektowanie

Implementacja(kodowanie, testowanie)

Integracja

Specyfikacjawymagań

Specyfikacjaprojektu

Kod

Produktprogramistyczny

Wymagania użytkownika

Model kaskadowy z iteracjami



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.



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:


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ń.


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.


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.


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.


Wizualne modelowanie (2)

Model

Diagramyklas

Diagramykomponentów

Diagramystanu

Diagramywdrożeniowe

Diagramyuse case

Diagramyscenariuszy


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:


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.


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.


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”.

studia podyplomowe it w biznesie rational unified process

Documents