Inżynieria oprogramowania

Prezentacja na temat: "Inżynieria oprogramowania"— Zapis prezentacji:

1 Inżynieria oprogramowania
Halina Tańska

2 Literatura: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002 J. Górski, Inżynieria oprogramowania w projekcie informatycznym, MIKOM, Warszawa 1999 J. Cheesman, J. Daniels, Komponenty w UML, WNT, Warszawa 2004 G. Schneider, J. P. Winters, Stosowanie przypadków użycia, WNT, Warszawa 2004 I. Sommerville, Inżynieria oprogramowania, WNT, Warszawa 2003 A. Jaszkiewicz, Inżynieria oprogramowania, Helion, Warszawa 1997 M. Fowler, UML w kropelce, Oficyna Wydawnicza LTP, Warszawa 2005 St. Wrycza, B. Marcinkowski, K. Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych, Helion 2005 P. Beynon-Davies, Inżynieria systemów informatycznych, WNT, Warszawa 1999 St. Wrycza, Ćwiczenia z UML, Helion 2007 A. Cockburn, Jak pisać efektywnie przypadki użycia, WNT, Warszawa 2000 W. Dąbrowski, A. Stasiak, M. Wolski, Modelowanie systemów informatycznych w języku UML 2.1 w praktyce, MIKOM, Warszawa 2007

3 Przedmiot inżynierii oprogramowania
Inżynieria oprogramowania to wiedza techniczna dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby techniczne, ekonomiczne lub społeczne. Inżynieria oprogramowania to wiedza empiryczna, synteza doświadczenia tysięcy ośrodków zajmujących się budową oprogramowania.

4 Cechy dobrego oprogramowania:
zgodne z wymaganiami użytkownika, niezawodne, efektywne, łatwe w konserwacji, ergonomiczne.

5 Zagadnienia inżynierii oprogramowania:
sposoby prowadzenia przedsięwzięć informatycznych (PI), techniki planowania, szacowania kosztów, harmonogramowania i monitorowania PI, metody analizy i projektowania systemów, techniki zwiększania niezawodności oprogramowania, sposoby testowania systemów i szacowania niezawodności, sposoby przygotowania dokumentacji technicznej i użytkowej, procedury kontroli jakości, metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń), techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

6 Kryzys oprogramowania to:
sprzeczność pomiędzy odpowiedzialnością systemu informatycznego (SI) a jego zawodnością; ogromne koszty utrzymania oprogramowania; niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania (powtarzalność); długi i kosztowny cykl tworzenia oprogramowania; długi i kosztowny cykl życia SI oraz ciągłe zmiany; nieodpowiednie narzędzia i języki programowania; frustracje projektantów i programistów; uzależnienie organizacji od SI i przyjętych technologii; problemy współdziałania niezależnie zbudowanego oprogramowania; problemy przyswojenia istniejących systemów do nowych warunków.

7 Walka z kryzysem oprogramowania polega na:
stosowaniu technik i narzędzi ułatwiających pracę nad złożonymi systemami; korzystanie z metod wspomagających analizę nieznanych problemów i ułatwiających wykorzystanie wcześniejszych doświadczeń; usystematyzowanie procesu wytwarzania oprogramowania tak, aby ułatwić jego planowanie i monitorowanie; wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.

8 Źródła złożoności projektu oprogramowania:
Podstawowy powód kryzysu oprogramowania - złożoność produktów informatyki i procesów ich wytwarzania. Źródła złożoności projektu oprogramowania to: dziedzina problemowa obejmująca ogromną liczbę wzajemnie uzależnionych aspektów; zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji; środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia; potencjalni użytkownicy: czynniki psychologicznie, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

9 Złożoność - zasady postępowania
zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości; zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnienie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy; zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania; zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psycholog.

10 Modelowanie pojęciowe
projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle; pojęcia modelowania pojęciowego (conceptual modelling) oraz modelu pojęciowego (conceptual model) odnoszą się do procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem; modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnie. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.

11 Perspektywy w modelowaniu pojęciowym
percepcja rzeczywistego świata; analityczny model rzeczywistości; model struktur danych i procesów SI.

12 Metodyka Metodyka to spójny, logicznie uporządkowany zestaw metod i procedur technicznych oraz organizatorskich służących zespołowi wykonawczemu do analizy rzeczywistości a także projektowania pojęciowego, logicznego i/lub fizycznego; Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu (pośrednich, końcowych) jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientami.

13 Składniki metodyki to:
formalizmy, modele opisu rzeczywistości (dziedziny przedmiotowej), jej statyki i dynamiki; strukturalizacja procesu TSI (cykl życia); szczegółowe metody i techniki dokumentowania; narzędzia CASE; wymagania merytoryczne wobec poszczególnych twórców SI; kryteria oceny jakości projektu i systemu; zasady planowania i kierowania rozwojem systemu.

14 Proces tworzenia oprogramowania
Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego. Może to być tworzenie oprogramowania od zera, ale coraz częściej nowe oprogramowanie powstaje przez rozszerzanie i modyfikowanie istniejących systemów.

15 Cele Poznać pojęcie procesu tworzenia oprogramowania i modelu procesu tworzenia oprogramowania. Poznać kilka różnych modeli procesów tworzenia oprogramowania oraz wiedzieć, kiedy należy ich używać. Ogólnie rozumieć modele procesów inżynierii wymagań stawianych oprogramowaniu, tworzeniu oprogramowania, testowaniu i ewolucji. Wiedzieć czym jest technologia CASE wspomagająca proces tworzenia oprogramowania.

16 Zasadnicze czynności w procesie tworzenia oprogramowania
Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane. Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia specyfikację, musi być stworzone. Zatwierdzenie oprogramowania. Wytworzone oprogramowanie musi spełniać oczekiwania klienta. Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników.

17 Cykl życia oprogramowania (systemu) system life cycle
Cykl życia oprogramowania (systemu) to ciąg wyodrębnionych, wzajemnie spójnych faz i etapów, pozwalających na pełne, skuteczne zaprojektowanie, a następnie użytkowanie systemu informatycznego. Każda z faz korzysta z własnej grupy metod, technik i narzędzi wspomagania tworzenia oprogramowania.

18 Modele cyklu życia oprogramowania
Model kaskadowy W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu. Tworzenie ewolucyjne W tym procesie czynności specyfikowania, projektowania i zatwierdzania przeplatają się. Tworzenie formalne systemu To podejście jest oparte na budowaniu formalnych matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program za pomocą metod matematycznych. Tworzenie z użyciem wielokrotnym W tym podejściu zakłada się istnienie dużej liczby komponentów zdatnych do ponownego użycia.

19 Modele cyklu życia oprogramowania
model kaskadowy (wodospadowy) model spiralny prototypowanie montaż z gotowych komponentów

20 Model kaskadowy (wodospadowy)
Definiowanie wymagań Projektowanie systemu i oprogramowania Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja

21 Model kaskadowy Cele i szczegółowe wymagania wobec systemu.
Określenie wymagań Cele i szczegółowe wymagania wobec systemu. Analiza Projektowanie Szczegółowy projekt systemu uwzględniający wcześniejsze wymagania. Implementacja Testowanie Modyfikacje producenta - usunięcie błędów, zmiany i rozszerzenia. Konserwacja

22 Problemy modelu kaskadowego
Następnej fazy nie powinno się rozpoczynać, jeśli poprzednia się nie zakończy. Koszty opracowania i akceptacji dokumentów są wysokie i dlatego iteracje są również kosztowne oraz wymagają powtarzania wielu prac. Wadą modelu kaskadowego jest zawarty w nim nieelastyczny podział na rozłączne etapy. Model kaskadowy powinien być używany jedynie wówczas, gdy wymagania są jasne i zrozumiałe.

23 Ocena modelu kaskadowego
Wady modelu: narzucanie 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 Z drugiej strony, jest on do pewnego stopnia niezbędny do planowania, harmonogramowania, monitorowania i rozliczeń finansowych.

24 Model kaskadowy z iteracjami
Określenie wymagań Analiza Projektowanie Implementacja Testowanie Konserwacja

25 Zmodyfikowany model kaskadowy
Definiowanie wymagań Projektowanie systemu i oprogramowania Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja

26 Tworzenie ewolucyjne Tworzenie ewolucyjne polega na opracowaniu
wstępnej implementacji, pokazaniu jej użytkownikowi z prośbą o komentarze i udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu.

27 Tworzenie ewolucyjne Ogólny opis Równolegle czynności Wersja
początkowa Specyfikacja Ogólny opis Tworzenie Wersje pośrednie Zatwierdzenie Wersja końcowa

28 Typy tworzenia ewolucyjnego
Tworzenie badawcze Celem procesu jest praca z klientem, polegająca na badaniu wymagań i dostarczeniu ostatecznego systemu. Tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie nowych cech, które proponuje klient. Prototypowanie z porzuceniem Celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi. Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne.

29 Tworzenie ewolucyjne Problemy Stosowanie Proces nie jest widoczny
System ma złą strukturę Konieczne mogą być specjalne narzędzia i techniki Stosowanie W wypadku systemów małych (mniej niż wierszy kodu) lub średnich (do wierszy kodu) z krótkim czasem życia podejście ewolucyjne jest najlepsze. W wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego ujawniają się jednak z całą ostrością.

30 Tworzenie formalne systemów
Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny. W procesie przekształcania formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne reprezentacje systemu. Podejście z przekształceniem złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie zastosować, wymaga jednak dużych umiejętności. Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom, pierwotnie opracowany przez IBM (Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się każdy krok i dowodzi jego poprawności.)

31 Tworzenie formalne systemów
Definicja wymagań Specyfikacja formalna Przekształcenie formalne Integracja i testowanie systemu

32 Formalne transformacje
Wymagania na system są formułowane w pewnym formalnym języku, następnie poddawane są kolejnym transformacjom, aż do uzyskania działającego kodu. Transformacje są wykonywane bez udziału ludzi (czyli w istocie język specyfikacji wymagań jest nowym „cudownym” językiem programowania). Tego rodzaju pomysły nie sprawdziły się w praktyce. Nie są znane szersze ich zastosowania.

33 Przekształcenie formalne
2 3 P 4 T 1 R 1 Program wykonywalny Specyfikacja formalna P 1

34 Formalne transformacje
Formalna specyfikacja wymagań Postać pośrednia ... Postać pośrednia Kod

35 Tworzenie z użyciem wielokrotnym
W większości przedsięwzięć programistycznych występuje wielokrotne użycie oprogramowania. Etapy procesu: analiza komponentów, modyfikacja wymagań, projektowanie systemu z użyciem wielokrotnym, tworzenie i integracja. Zakłada się istnienie wielkiego zbioru dostępnych komponentów programowych użycia wielokrotnego oraz integrującej je struktury.

36 Tworzenie z użyciem wielokrotnym
Specyfikacja wymagań Modyfikacja wymagań Projekt systemu z użyciem wielokrotnym Analiza komponentów Tworzenie i integracja Zatwierdzenie systemu

37 Iteracja procesu Potrzebne jest także wspomaganie procesu tworzenia oprogramowania nazywane iteracjami, które polega na powtarzaniu fragmentu tego procesu w miarę ewolucji wymagań stawianych systemowi. Przykładowo prace projektowe i implementacyjne musza być ponownie wykonane, aby spełnić zmienione wymagania. Mamy tutaj dwa hybrydowe modele: tworzenie przyrostowe, tworzenie spiralne.

38 Tworzenie przyrostowe
Podejście przyrostowe do tworzenia zaproponował Mills (1980) jako sposób na ograniczenie powtarzania prac w procesie tworzenia oraz danie klientom pewnych możliwości odkładania decyzji o szczegółowych wymaganiach do czasu, aż zdobędą pewne doświadczenia w pracy z systemem. W procesie przyrostowym klienci identyfikują w zarysie usługi, które system ma oferować. Wskazują, które z nich są dla nich najważniejsze, a które najmniej ważne. Definiuje się następnie pewną liczbę przyrostów, które maja być dostarczone. Gdy przyrost jest już gotowy i dostarczony, klienci mogą go uruchomić. Oznacza to, że szybko otrzymują część funkcjonalności systemu

39 Tworzenie przyrostowe
Zdefiniuj zarys wymagań Przypisz wymagania do przyrostów Zaprojektuj architekturę systemu System końcowy Wytwórz przyrost systemu Zweryfikuj przyrost Zintegruj system Zweryfikuj system System nie ukończony

40 Model spiralny Składa się z czterech faz realizowanych w kolejnych fazach: Planowanie: ustalenie celów produkcji kolejnych wersji systemu Analiza ryzyka (ew. budowa prototypu) Konstrukcja (model kaskadowy) Atestowanie (przez klienta). Jeżeli ocena nie jest w pełni pozytywna rozpoczynany jest kolejny cykl

41 Model spiralny Przegląd: Ustalenie celów, alternatywnych dróg
i ograniczeń Identyfikacja i analiza ryzyka (ew. budowa prototypu) Ogólnie Konstrukcja (model kaskadowy) Atestowanie (w tym przez klienta). Jeżeli ocena nie jest w pełni pozytywna, rozpoczynany jest kolejny cykl. Planowanie: Ustalenie planu kolejnej fazy

42 Model spiralny procesu tworzenia oprogramowania
Oceń inne strategie, rozpoznaj i zmniejsz zagrożenia Określ cele, inne strategie i ograniczenia Analiza zagrożeń Analiza zagrożeń Działający prototyp Analiza zagrożeń Prototyp 3 Analiza zagrożeń Prototyp 2 RECENZJA Prototyp 1 Plan wymagań Plan cyklu życia Sposób postępowania Symulacje, modele, miary odniesienia Szczegółowe projekto- wanie Wymagania S/W Projekto- wanie produktu Plan tworzenia Kodowanie Zatwierdzenie wymagań Testy jednostek Plan testowania i integracji Weryfikacja i zatwierdzenie Testy integracji Zaplanuj następną fazę Testy akceptacji Utwórz, zweryfikuj produkt następnego poziomu Działanie

43 Każda pętla spirali jest podzielona na cztery sektory:
Ustalanie celów Definiuje się konkretne cele tej fazy przedsięwzięcia. Identyfikuje się ograniczenia, którym podlega proces i produkt. Rozpoznanie i redukcja zagrożeń Przeprowadza się szczegółową analizę każdego z rozpoznanych zagrożeń przedsięwzięcia. Tworzenie i zatwierdzanie Po ocenie zagrożeń wybiera się model tworzenia systemu. Planowanie Recenzuje się przedsięwzięcie i podejmuje decyzję, czy rozpoczynać następną pętlę spirali.

44 Prototypowanie (prototyping) - fazy
Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe. Fazy: ogólne określenie wymagań budowa prototypu weryfikacja prototypu przez klienta pełne określenie wymagań realizacja pełnego systemu zgodnie z modelem kaskadowym

45 Prototypowanie (prototyping) - cele
wykrycie nieporozumień pomiędzy klientem a twórcami systemu wykrycie brakujących funkcji wykrycie trudnych usług wykrycie braków w specyfikacji wymagań Zalety: możliwość demonstracji pracującej wersji systemu możliwość szkoleń zanim zbudowany zostanie pełny system

46 Metody prototypowania
niepełna realizacja: objęcie tylko części funkcji języki wysokiego poziomu: Smalltalk, Lisp, Prolog, 4GL, ... wykorzystanie gotowych komponentów generatory interfejsu użytkownika: wykonywany jest wyłącznie interfejs, wnętrze systemu jest „podróbką” szybkie programowanie (quik-and-dirty): normalne programowanie, ale bez zwracania uwagi na niektóre jego elementy, np. zaniechanie testowania. Często ewolucyjnie przechodzi się od prototypu do końcowego systemu

47 Montaż z gotowych komponentów
Kładzie nacisk na możliwość redukcji nakładów przez wykorzystanie podobieństwa tworzonego oprogramowania do wcześniej tworzonych systemów oraz wykorzystanie gotowych komponentów dostępnych na rynku. Temat jest określany jako ponowne użycie (reuse) Metody: zakup elementów ponownego użycia od dostawców przygotowanie elementów poprzednich przedsięwzięć do ponownego użycia

48 Montaż z gotowych komponentów
Zalety: wysoka niezawodność zmniejszenie ryzyka efektywne wykorzystanie specjalistów narzucanie standardów Wady: dodatkowy koszt przygotowania elementów ponownego użycia ryzyko uzależnienia się od dostawcy elementów niedostatki narzędzi wspomagających ten rodzaj pracy