Inżynieria oprogramowania Halina Tańska

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

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.

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

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.

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.

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.

Ź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ść.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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

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

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.

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

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.

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ż 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ę jednak z całą ostrością.

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

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

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.

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

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

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.

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

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.

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

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

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

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

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

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.

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

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

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

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

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