Podstawy Inżynierii Oprogramowania

Prezentacja na temat: "Podstawy Inżynierii Oprogramowania"— Zapis prezentacji:

1 Podstawy Inżynierii Oprogramowania
WYKŁAD 10 Modele cyklu życia oprogramowania MODEL KASKADOWY Faza Konserwacji Oprogramowania Dr hab. inż. Barbara Dębska, prof. PWSZ Dr hab. inż. Barbara Dębska, prof. PWSZ

2 FAZA KONSERWACJI OPROGRAMOWANIA
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Konserwacja Analiza Instalacja Faza strategiczna Dokumentacja Po zakończeniu fazy instalacji klient rozpoczyna użytkowanie systemu. Z punktu widzenia klienta jest to faza eksploatacji, a z punktu widzenia producenta jest to faza konserwacji systemu (pielęgnacji, utrzymania). Jest to najdłuższa faza cyklu życia oprogramowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

3 Klasy modyfikacji wprowadzanych do oprogramowania:
Konserwacja oprogramowania polega na wprowadzaniu modyfikacji. Klasy modyfikacji wprowadzanych do oprogramowania: modyfikacje poprawiające – polegają na usuwaniu z oprogramowania błędów, modyfikacje ulepszające – polegają na poprawie jakości oprogramowania, modyfikacje dostosowujące – polegają na dostosowaniu oprogramowania do zmian zachodzących w środowisku jego pracy. Poprawa może dotyczyć błędów popełnionych w fazach określania wymagań, analizy, projektowania i implementacji. Im wcześniejsza jest faza, w której popełniono błąd, tym większy jest spodziewany koszt poprawy tego błędu. Przykłady modyfikacji ulepszających: poprawa wydajności pewnych funkcji, poprawa ergonomii i interfejsu użytkownika, poprawa przejrzystości raportów. Dr hab. inż. Barbara Dębska, prof. PWSZ

4 Modyfikacje dostosowujące wynikają ze:
zmiany wymagań użytkowników, zmian w przepisach prawnych dotyczących dziedziny problemu, zmian organizacyjnych po stronie klienta, oraz zmian sprzętu i oprogramowania systemowego. Część modyfikacji prowadzi do niewielkich zmian kodu, które nie wymagają zmiany dokumentacji technicznej (np. typowe błędy programistyczne, takie jak, np. błąd w instrukcji warunkowej). Inne modyfikacje prowadzą do przebudowy oprogramowania, które to zmiany muszą zostać uwzględnione w dokumentacji technicznej. Dr hab. inż. Barbara Dębska, prof. PWSZ

5 Jeżeli modyfikacja nie zmienia wymagań wobec systemu, lecz zmienia związki miedzy klasami składowej dziedziny problemu, to należy zmodyfikować model, projekt i kod. Przykład PITy: Dr hab. inż. Barbara Dębska, prof. PWSZ

6 PIT indywidualnego podatnika
Schemat związków generalizacji-specjalizacji oraz zmodyfikowanych związków klas istniejących w systemie PITy 2002 : PIT PIT indywidualnego podatnika PIT małżeństwa 2 2 Podatnik ROK ROK Roczne przychody Dr hab. inż. Barbara Dębska, prof. PWSZ

7 PIT indywidualnego podatnika PIT osoby samotnie wychowującej dziecko
Schemat związków generalizacji-specjalizacji oraz zmodyfikowanych związków klas istniejących w systemie PITy 2003 : PIT PIT indywidualnego podatnika PIT osoby samotnie wychowującej dziecko PIT małżeństwa 2 Roczne przychody 2 Podatnik ROK Podatnik ROK ROK Podatnik ROK Powyższa zmiana zaowocowała wprowadzeniem dodatkowej klasy: osoba samotnie wychowująca dziecko. Dr hab. inż. Barbara Dębska, prof. PWSZ

8 Osoby dokonujące modyfikacji często mają tendencję do:
szybkiego dokonania modyfikacji polegającej jedynie na zmianie kodu, skracania czasu potrzebnego na dokonanie modyfikacji, zapominania o dokonaniu koniecznych zmian w dokumentacji technicznej, oraz zapominania o konieczności cofania się do wcześniejszych faz budowy aplikacji. Powody modyfikacji systemu: żądania użytkowników, lub porównanie możliwości oferowanego oprogramowania z ofertą konkurencji. Uwaga: Żądana zmiana, przed jej wprowadzeniem powinna być oceniona pod kątem sensowności jej wprowadzenia. Dr hab. inż. Barbara Dębska, prof. PWSZ

9 Analiza wpływu rozważanej zmiany powinna uwzględniać:
znaczenie wprowadzenia zmiany dla użytkowników, koszt wprowadzenia zmiany, wpływ zmiany na poszczególne składowe systemu, oraz wpływ zmiany na istniejące składowe dokumentacji technicznej (opis funkcjonalny, podręcznik administratora systemu i użytkownika, opis instalacji oraz opis systemu dostępny w formie elektronicznej) Rodzaje modyfikowanej dokumentacji elektronicznej systemu: dokumentacja przeznaczona dla doświadczonych użytkowników Powinna umożliwiać szybkie odnalezienie informacji na temat interesujący użytkowników. Należy projektować ją z wykorzystaniem właściwości hipertekstu, zapewniającego szybkie dotarcie do informacji. dokumentacja przeznaczona dla początkujących użytkowników Pozytywne skutki osiąga się przez opracowanie specjalnych programów – przewodników, które asystują użytkownikowi podczas pracy z systemem. Dr hab. inż. Barbara Dębska, prof. PWSZ

10 Decyzje o wprowadzaniu zmian poprzedza:
dokonanie oceny przewidywanej zmiany, zaakceptowanie wprowadzenia zmiany, grupowanie tych zmian, których wykonanie prowadzi do powstania nowej wersji systemu, oraz oszacowanie kosztów konserwacji systemu. Decyzje o konieczności wprowadzenia zmian powinna podejmować jedna uprawniona osoba lub specjalna komisja (w przypadku dużych przedsięwzięć). Charakterystyka procesu konserwacji: praca nad konserwacją oprogramowania jest często niżej ceniona niż nad jego wytwarzaniem, kierownictwo powinno właściwie motywować i doceniać osiągnięcia osób zajmujących się wprowadzaniem zmian w aplikacji, koszty konserwacji są duże i często przekraczają koszty budowy systemu, złe oszacowanie nakładów pracy na fazę konserwacji systemu jest jedną z głównych przyczyn opóźnień przedsięwzięć programistycznych (van Genuchtena, 1991) Dr hab. inż. Barbara Dębska, prof. PWSZ

11 Czynniki wpływające na redukcję kosztów konserwacji systemu:
Czynniki obiektywne, wpływające na koszty konserwacji (kierownictwo przedsięwzięcia ma na nie znikomy wpływ): stabilność środowiska w którym pracuje system (zmiany zachodzące w przepisach prawnych, zmiany struktury organizacyjnej i sposobów działania po stronie klienta prowadzą do zmian wymagań wobec systemu), stabilność platformy sprzętowej i oprogramowania systemowego, oraz czas użytkowania systemu (całkowite koszty konserwacji rosną wraz ze wzrostem czasu użytkowania systemu). Czynniki wpływające na redukcję kosztów konserwacji systemu: znajomość dziedziny problemu (analitycy mają mniej trudności z właściwym zebraniem wymagań oraz budową oddającego rzeczywistość modelu), wysoka jakość modelu i projektu (w szczególności spójność, stopień powiązań składowych i przejrzystość), oraz wysoka jakość dokumentacji technicznej (dokumentacja powinna w pełni odpowiadać systemowi, być wystarczająco szczegółowa i zgodna z przyjętymi w firmie standardami), Dr hab. inż. Barbara Dębska, prof. PWSZ

12 Czynniki wpływające na redukcję kosztów konserwacji systemu (c.d.):
stabilność personelu (pewne aspekty systemu znane są najlepiej osobom uczestniczącym w jego realizacji), środowisko implementacji (zaawansowane środowiska implementacji, obejmujące języki wysokiego poziomu i możliwość dialogowego projektowania i wytwarzania fragmentów oprogramowania, np. narzędzia RAD, wpływają na skrócenie czasu niezbędnego na wprowadzenie modyfikacji), niezawodność oprogramowania (wysoka niezawodność oprogramowania w momencie przekazania systemu do użytkowania zmniejsza liczbę modyfikacji, w tym również o charakterze poprawiającym), inżynieria odwrotna (odtwarzanie dokumentacji technicznej na podstawie istniejącego oprogramowania), zarządzanie wersjami (każda modyfikacja powoduje wygenerowanie nowej wersji systemu i najlepiej jest, jeśli przekazanie nowej wersji systemu wiąże się z usunięciem z eksploatacji poprzedniej wersji). Dr hab. inż. Barbara Dębska, prof. PWSZ

13 Wiele działań zmierzających do redukcji kosztów konserwacji musi być podejmowanych w trakcie budowy systemu. Całkowity koszt ponoszony w trakcie budowy oprogramowania zależy w dużej mierze od kosztów konserwacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

14 ZARZĄDZANIE WERSJAMI Każda modyfikacja systemu powoduje powstanie nowej, mniej (drobne zmiany) lub bardziej różniącej się od poprzedniej (zrealizowano całkiem nowe przedsięwzięcie) wersji systemu. Z punktu widzenia formy programistycznej najlepiej jest, jeżeli przekazanie do eksploatacji nowej wersji systemu wiąże się z usunięciem z eksploatacji wersji poprzedniej. W praktyce nie zawsze użytkownik jest zainteresowany nabyciem nowej wersji. Firma programistyczna może ją udostępnić nieodpłatnie (co zawsze wtedy powinno mieć miejsce, gdy firma zastępuje wersję, w której wykryto błędy, wersją poprawioną). Przyczyny istnienia kilku wersji systemu : (1) opracowanie nowej wersji systemu, ale wykorzystywanie poprzednich wersji przez pewną grupę użytkowników. (2) zbudowanie kilku wersji systemu dla użytkowników o innych wymaganiach, np korzystających z wersji zawierającej jedynie część modułów kompletnego systemu, (3) to samo oprogramowanie może być przygotowane do pracy w zróżnicowanych środowiskach. Dr hab. inż. Barbara Dębska, prof. PWSZ

15 ZARZĄDZANIE WERSJAMI c.d.
Zadaniem kierownictwa firmy programistycznej jest zorganizowanie odpowiedniego systemu zarządzania wersjami. Narzędzia wspomagające zarządzanie wersjami wchodzą w skład niektórych pakietów CASE. W przypadku, gdy firma korzysta z narzędzia, które nie ma takiej możliwości, musi stworzyć własny program (lub zakupić komercyjny) do zarządzania wersjami systemu. Podstawą takich systemów jest baza danych, zbudowana np. zgodnie ze schematem : Klient Wersja systemu System Wersja składowej systemu 1+ Dr hab. inż. Barbara Dębska, prof. PWSZ

16 ZARZĄDZANIE WERSJAMI c.d.
Baza danych o eksploatowanych wersjach systemu powinna zawierać: (1) informacje o wszystkich oddanych do eksploatacji wersjach, między innymi daty oddania do eksploatacji, (2) informacje o klientach, którzy nabyli daną wersję, (3) informacje o składowych (np. klasach, encjach, modułach) wchodzących w skład danej wersji, (4) informacje o pozostających do realizacji żądaniach zmian, oraz (5) informacje o błędach wykrytych w poszczególnych wersjach, Dr hab. inż. Barbara Dębska, prof. PWSZ

17 INŻYNIERIA ODWROTNA. W wielu wypadkach zachodzi konieczność wprowadzenia zmian w oprogramowaniu, które nie jest opisane dokumentacją techniczną. Inżynieria odwrotna jest procesem polegającym na odtworzeniu dokumentacji technicznej na podstawie istniejącego kodu, a czasami na podstawie struktury bazy danych. Proces ten nazywany jest w ten sposób, gdyż jest on swego rodzaju odwróceniem kolejności czynności wykonywanych podczas budowania oprogramowania. W fazie implementacji następuje transformacja projektu do kodu. Opis projektu staje się po zakończeniu implementacji dokumentacją techniczną. Inżynieria odwrotna jest próbą odtworzenia projektu, na bazie którego mogłoby powstać istniejące oprogramowanie. Dr hab. inż. Barbara Dębska, prof. PWSZ

18 INŻYNIERIA ODWROTNA c.d.
Podczas próby odtworzenia dokumentacji technicznej na podstawie kodu może się okazać, że wiele konstrukcji zastosowanych w programie nie da się zapisać w przyjętej notacji. Dotyczy to w szczególności programów napisanych w językach hybrydowych, w których możliwe jest zastosowanie zarówno konstrukcji obiektowych jak i strukturalnych. Inżynieria odwrotna jest procesem, który daje się zautomatyzować. Uwaga: Moduły inżynierii odwrotnej są częstymi składowymi narzędzi CASE. Może się okazać, że automatycznie odtworzona dokumentacja będzie wymagała dalszej ręcznej korekty. Typowym przykładem inżynierii odwrotnej jest odtwarzanie modelu związków encji na podstawie struktury bazy danych. Dr hab. inż. Barbara Dębska, prof. PWSZ

19 Przykład. Odtwórz model związków encji z instrukcji w języku SQL.
CREATE TABLE Relacja1 ( Pole1 TEXT NOT NULL, Pole2 TEXT NOT NULL, PRIMARY KEY (Pole1) CREATE TABLE Relacja2 ( Pole3 TEXT NOT NULL, Pole4 TEXT NOT NULL, PRIMARY KEY (Pole3) ) ALTER TABLE Relacja 2 ( ADD FOREIGN KEY (Pole1) REFERENCES Relacja1 (Pole1 ) ON DELETE CASCADE ) Relacja 1 Key data Pole1 Non-Key Data Pole2 Relacja 2 Pole3 Pole4 Dr hab. inż. Barbara Dębska, prof. PWSZ

20 Przykład. Odtwórz model związków klas z fragmentu kodu w języku C++.
W przypadku technik obiektowych trudniejsze jest odtworzenie informacji o związkach klas, gdyż należy brać pod uwagę różne sposoby ich implementacji. Przykład. Odtwórz model związków klas z fragmentu kodu w języku C++. class Klasa1 { private; long Pole1; double Pole2; public: void Metoda1 ( ); void Metoda2 ( ); protected; vector<Klasa2*> vKlasa2; }; class Klasa2 { private; unsigned short Pole3; float Pole4; public: void Metoda3 ( ); void Metoda4 ( ); protected; Klasa1* pKlasa }; Klasa1 Pole1 Pole2 Metoda1 Metoda2 Klasa2 Pole3 Pole4 Metoda3 Metoda4 Dr hab. inż. Barbara Dębska, prof. PWSZ

21 INŻYNIERIA ODWROTNA c.d.
Odtworzona dokumentacja techniczna może zostać zmodyfikowana. Jeżeli następnie na podstawie odtworzonej dokumentacji modyfikowany jest kod programu, to proces taki nazywa się reinżynierią oprogramowania. Schemat tego procesu przedstawia rysunek: Kod Kod źródłowy Inżynieria odwrotna Dokumentacja techniczna/ Projekt Kod Modyfikacja projektu Implementacja Dokumentacja techniczna/ Projekt Dr hab. inż. Barbara Dębska, prof. PWSZ

22 Przykład Narzędzia CASE dla procesu inżynierii odwrotnej:
Umbrello - importowanie gotowych źródłowych plików do postaci klas Program Umbrello pozwala na importowanie kodu plików źródłowych, do postaci diag-ramu klas W chwili obecnej obsługuje on import plików zapisanych w języku C++. W celu zaimportowania pliku zawierającego klasy wybiera się polecenie: Kod->Importuj klasy... Dr hab. inż. Barbara Dębska, prof. PWSZ

23 Okno dialogowe importowania gotowych źródłowych plików klas
Lista widokowa plików nagłów-kowych klas języka C++. Nazwa wybranego do importu pliku nagłówkowego zawierają-cego zdefiniowane klasy, zakodowane w języku C++. Dr hab. inż. Barbara Dębska, prof. PWSZ

24 Diagram zaimportowanych klas z pliku źródłowego
Widok diagramu utworzonego na podstawie kodu zawartego w pliku nagłówkowym zawie-rającym definicje klas, zapisane w języku C++. Diagram został utworzony auto-matycznie. Uwidocznione zosta-ły relacje pomiędzy zaimporto-wanymi klasami. Dr hab. inż. Barbara Dębska, prof. PWSZ

25 Faza konserwacji to ostatni etap przedsięwzięcia programistycznego.
Po pewnym czasie użytkowania systemu narasta potrzeba tak istotnych zmian, że możliwe są tylko dwa wyjścia: zaprzestanie korzystania z systemu, lub rozpoczęcie prac nad nowa wersją, czyli rozpoczęcie nowego przedsięwzięcia programistycznego !!! Dr hab. inż. Barbara Dębska, prof. PWSZ

26 Czynniki wpływające na sukces fazy konserwacji:
Podsumowanie Czynniki wpływające na sukces fazy konserwacji: wysoka jakość definicji wymagań, modelu i projektu, dobra znajomość środowiska implementacji, właściwa motywacja osób wykonujących konserwację oprogramowania, właściwe oszacowanie kosztów konserwacji. Podstawowe rezultaty fazy konserwacji: poprawiony kod, projekt, model i specyfikacja wymagań. (kierunek poprawy) Dr hab. inż. Barbara Dębska, prof. PWSZ

27 Dziękuję za uwagę Dr hab. inż. Barbara Dębska, prof. PWSZ