Inżynieria oprogramowania

(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

(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

(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

(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

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

Określenie wymagań

Projektowanie

Implementacja

Testowanie

Konserwacja

Cele i szczegółowe wymagania wobec systemu.

Szczegółowy projekt systemu uwzględniający wcześniejsze

wymagania.

Modyfikacje producenta - usunięcie błędów, zmiany i rozszerzenia.

Analiza

Model kaskadowy

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

Określenie wymagań

Projektowanie

Implementacja

Testowanie

Konserwacja Analiza

Model kaskadowy z iteracjami

(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

Wersja początkow a

Ogólny opis

Specyfikacja

Tworzenie

Zatwierdzenie

Wersje pośrednie

Wersja końcowa Równolegle czynności

(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

(29)

Tworzenie ewolucyjne

• Problemy

– 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ż 100 000 wierszy kodu) lub średnich (do 500 000 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ę

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

Formalne transformacje

Formalna specyfikacja wymagań

Postać pośrednia

Postać

pośrednia Kod

...

(34)

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

(35)

Tworzenie z użyciem wielokrotnym

Specyfikacja wymagań

Zatwierdzenie systemu Tworzenie i

integracja

Projekt systemu z użyciem wielokrotnym Analiza

komponentów

Modyfikacja wymagań

(36)

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.

(37)

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ęść

(38)

Tworzenie przyrostowe

Zdefiniuj zarys wymagań

Wytwórz przyrost systemu

Przypisz wymagania do przyrostów

Zweryfikuj przyrost

Zaprojektuj

architekturę systemu

Zintegruj system Zweryfikuj system System końcowy

System nie ukończony

(39)

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

(40)

Model spiralny

Planowanie: Ustalenie planu kolejnej fazy

Identyfikacja i analiza ryzyka (ew. budowa prototypu)

Konstrukcja

(model kaskadowy)

Atestowanie (w tym przez klienta).

Jeżeli ocena nie jest w pełni pozytywna, rozpoczynany jest Przegląd: Ustalenie

celów, alternatywnych dróg i ograniczeń

(41)

Model spiralny procesu tworzenia oprogramowania

Określ cele, inne strategie i ograniczenia

Oceń inne strategie, rozpoznaj i zmniejsz zagrożenia

RECENZJA Plan wymagań

Plan cyklu życia Plan tworzenia

Plan testowania i integracji Zaplanuj następną

fazę

Analiza zagrożeń Analiza zagrożeń

Analiza zagrożeń

Prototyp 1

Prototyp 2

Prototyp 3

Działający prototyp

Sposób postępowania

Symulacje, modele, miary odniesienia

Zatwierdzenie wymagań

Wymagania

S/W Projekto- wanie produktu Weryfikacja i

zatwierdzenie Działanie

Testy akceptacji

Testy integracji

Testy jednostek

Kodowanie

Szczegółowe projektowanie

Utwórz, zweryfikuj produkt następnego

(42)

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

(43)

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

(44)

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

(45)

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

(46)