Wykład 1 Najlepsze praktyki

Prezentacja na temat: "Wykład 1 Najlepsze praktyki"— Zapis prezentacji:

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

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.

3 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 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 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ść produktów i procesów wytwarzania Szybki rozwój technologii informatycznych Philippe Krutchen: “There are no more small systems left to build”. 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.

6 Symptomy kryzysu oprogramowania
Wspólne dla większości projektów 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.

7 Przyczyny niepowodzeń projektów
Główne przyczyny niepowodzeń projektów to z reguły kombinacja jednego z poniżej wymienionych czynnikó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.

8 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 Najlepsze praktyki Najlepsze praktyki w rozwoju oprogramowania:
Iteracyjny rozwój Zarządzanie wymaganiami Architektura oparta o komponenty Wizualne modelowanie Systematyczna weryfikacja jakości Zarządzanie zmianami 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 Iteracyjny rozwój (1) Określenie wymagań Analiza Projektowanie
Określenie celów i specyfikacja szczegółowych wymagań na system Określenie wymagań Analiza Szczegółowy projekt systemu uwzględniający wcześniejsze wymagania Projektowanie Implementacja Testowanie Konserwacja Modyfikacje producenta: usunięcie błędów, zmiany i rozszerzenia Model kaskadowy

11 Iteracyjny rozwój (2) Analiza wymagań Projektowanie Kodowanie
i testowanie jednostek Ryzyko Testowanie podsystemów Testowanie systemu Czas

12 Iteracyjny rozwój (4) 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”. Istnieją różne poglądy co do praktycznej przydatności modelu kaskadowego. Wady: Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac. Wysoki koszt błędów popełnionych we wczesnych fazach. Długa przerwa w kontaktach z klientem. Zalety: model kaskadowy jest do pewnego stopnia niezbędny dla planowania, harmonogramowania, monitorowania i rozliczeń finansowych.

13 (kodowanie, testowanie)
Iteracyjny rozwój () Wymagania użytkownika Specyfikacja wymagań Analiza wymagań Specyfikacja projektu Projektowanie Kod Implementacja (kodowanie, testowanie) Integracja Produkt programistyczny Model kaskadowy z iteracjami

14 Iteracyjny rozwój (5) Specyfikacja wymagań Analiza i projektowanie
Planowanie Implementacja Planowanie początkowe Ewaluacja, np. atestowanie przez klienta Wypuszczenie produktu Testowanie Model spiralny Barry Bohem’a: specyfikuje proces iteracyjny i przyrostowy jako alternatywę dla modelu sekwencyjnego.

15 Iteracyjny rozwój (6) Podejście iteracyjne i przyrostowe a podejście sekwencyjne: 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.

16 Zarządzanie wymaganiami (1)
Wymagania dzielą się na funkcjonalne i niefunkcjonalne (warunki i ograniczenia). 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. 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. 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 Zarządzanie wymaganiami (2)
Wykorzystując wsparcie narzędziowe można zbudować repozytorium wymagań z linkami do odpowiednich dokumentów. 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.

18 Architektura oparta o komponenty
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. 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.

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

20 Wizualne modelowanie (2)
Diagramy klas Diagramy stanu Diagramy scenariuszy Model Diagramy komponentów Diagramy use case Diagramy wdrożeniowe

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

22 Systematyczna weryfikacja jakości (2)
Szacowanie statusu projektu może być bardziej obiektywne, w oparciu o wyniki testów, a nie o papierową dokumentację. Dzięki możliwości przeprowadzania bardziej obiektywnych szacunków, łatwiej uwidaczniają się wszelkie niespójności między wymaganiami, projektem implementacji a kodem. Testowanie i weryfikację można koncentrować na obszarach największego ryzyka w celu poprawienia jakości właśnie tych obszarów. Wszelkie defekty (błędy, braki) mogą być wykrywane wcześniej, co prowadzi do radykalnego zmniejszenia kosztów ich naprawy. Można wykorzystywać narzędzia wspomagające automatyzację procesu testowania.

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ń, 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 Proces wspierający rozwój oprogramowania
Zadania procesu (metodyki ?) wspierającego rozwój oprogramowania: Dostarczenie przewodnika dla aktywności realizowanych przez zespół projektowy. Określenie, jakie artefakty powinny być rozwijane i kiedy. Zarządzanie zarówno całością projektu, jak i zadaniami przydzielonymi jego indywidualnym uczestnikom. 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”.