Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


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

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

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

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

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

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

6 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:

7 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:

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

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

10 E. Stemposz. Rational Unified Process, Wykład 1, Slajd 10 wrzesień 2002 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: usunięcie błędów, zmiany i rozszerzenia Analiza Model kaskadowy

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

12 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:

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

14 E. Stemposz. Rational Unified Process, Wykład 1, Slajd 14 wrzesień 2002 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 Bohema: specyfikuje proces iteracyjny i przyrostowy jako alternatywę dla modelu sekwencyjnego.

15 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:

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

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

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

19 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. UMLa) 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.

20 E. Stemposz. Rational Unified Process, Wykład 1, Slajd 20 wrzesień 2002 Wizualne modelowanie (2) Model Diagramy klas Diagramy komponentów Diagramy stanu Diagramy wdrożeniowe Diagramy use case Diagramy scenariuszy

21 E. Stemposz. Rational Unified Process, Wykład 1, Slajd 21 wrzesień 2002 Systematyczna weryfikacja jakości (1) Dla przedsięwzięć softwareowych, 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:

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

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

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


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

Podobne prezentacje


Reklamy Google