©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 1 Systemy odziedziczone l Omówienie systemów odziedziczonych

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 2 Cele l Dowiedzieć, co kryje się pod pojęciem „systemu odziedziczonego” i dlaczego te systemy są krytyczne dla działania wielu przedsiębiorstw. l Poznać wspólne cechy struktur systemów odziedziczonych. l Rozumieć zasady projektowania funkcyjnego, tzn. najpowszechniej stosowanej strategii projektowania systemów aktualnie odziedziczonych. l Dowiedzieć, jak można ocenić system odziedziczony, aby stwierdzić, czy należy go złomować, pielęgnować, restrukturyzować albo zastąpić.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 3 Zawartość l Struktury systemów odziedziczonych l Projekty systemów odziedziczonych l Ocena systemów odziedziczonych

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 4 Systemy odziedziczone l Przedsiębiorstwa wydają bardzo dużo pieniędzy na systemy oprogramowania. Zwrot z takiej inwestycji jest możliwy tylko wówczas, gdy system będzie użytkowany przez wiele lat. l Niektóre firmy wciąż zależą od systemów oprogramowania, które maja więcej niż 20 lat. l Takie stare systemy otrzymały nazwę systemów odziedziczonych. l Systemy odziedziczone oczywiście nie są tymi samymi systemami, które pierwotnie dostarczono. Czynniki zewnętrzne i wewnętrzne, takie jak stan gospodarki narodowej i międzynarodowej, zmieniające się rynki i prawa, zmiany kierownictwa i strukturalne reorganizacje, powodowały ustawiczne zmienianie się przedsiębiorstwa.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 5 Przyczyny, dla których zastąpienie systemu odziedziczonego jest ryzykownym przedsięwzięciem l (1) Rzadko istnieje kompletna specyfikacja systemu odziedziczonego. Oryginalna specyfikacja mogła się zgubić. Jeśli jakaś specyfikacja istnieje, to szansa, że wprowadzono do niej szczegóły wszystkich zrobionych zmian systemu, jest niewielka. Nie ma więc prostego sposobu wyspecyfikowania nowego systemu, który pod względem funkcjonalności jest identyczny z systemem użytkowym. l (2) Procesy gospodarcze i sposób działania systemów odziedziczonych często są ze sobą nierozerwalnie splecione. Te procesy zaprojektowano tak, aby osiągnąć korzyści z usług oprogramowania i uniknąć jego słabości. Jeśli zastąpimy system, to te procesy również będą musiały się zmienić ze wszystkimi nieuchronnymi kosztami i konsekwencjami.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 6 Przyczyny, dla których zastąpienie systemu odziedziczonego jest ryzykownym przedsięwzięciem l (3) W oprogramowaniu mogą być utrwalone ważne reguły gospodarcze, których nigdzie nie udokumentowano. Reguła gospodarcza to ograniczenie, które dotyczy pewnych funkcji przedsiębiorstwa. Złamanie takiej reguły może mieć nieprzewidywalne konsekwencje dla przedsiębiorstwa. Firma ubezpieczeniowa ma zapisane w oprogramowaniu reguły oceny ryzyka proponowanych polis. Jeśli tych reguł się nie zachowa, to firma będzie akceptować polisy wysokiego ryzyka, których wynikiem będą w przyszłości kosztowne zgłoszenia szkód. l (4) Samo tworzenie nowego oprogramowania jest ryzykowne, ponieważ mogą pojawić się niespodziewane kłopoty z nowym systemem. System może być dostarczony z opóźnieniem i po cenie wyższej niż oczekiwana.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 7 Przyczyny dużych kosztów modyfikacji systemów odziedziczonych l (1) Różne części systemu mogły być zaimplementowane przez inne zespoły. W całym systemie nie ma więc jednego spójnego stylu oprogramowania. l (2) Część systemu może być zaimplementowana w przestarzałym języku programowania. Znalezienie pracowników, którzy znają taki język, może być trudne. Może tez zajść potrzeba kosztownego wynajęcia zewnętrznej firmy do pielęgnacji systemu. l (3) Dokumentacja systemu jest zwykle nieadekwatna i nieaktualna. W niektórych wypadkach jedyną dokumentacją jest kod źródłowy. Czasem kod źródłowy również zagubiono i do dyspozycji jest tylko wykonywalna wersja systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 8 Przyczyny dużych kosztów modyfikacji systemów odziedziczonych l ( 4) Wieloletnia pielęgnacja powoduje zwykle zniszczenie struktury systemu, co sprawia, że trudno jest go zrozumieć. Sposób dodawania nowych programów i sprzęgania ich z innymi częściami systemu mógł być przypadkowy. l (5) System mógł być zoptymalizowany pod względem użycia pamięci i szybkości działania. Nie napisano go więc z myślą o zrozumiałości. Oznacza to szczególne trudności dla programistów, którzy poznali nowoczesne metody inżynierii oprogramowania i nigdy nie spotkali się ze sztuczkami programistycznymi, których użyto w systemie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 9 Uwagi dot. systemów odziedziczonych l Systemy odziedziczone nie są po prostu starymi systemami oprogramowania, chociaż ten rozdział poświęcono głównie komponentom oprogramowanym takich systemów. l Systemy odziedziczone są socjotechnicznymi systemami komputerowymi, obejmują więc oprogramowanie, sprzęt, dane i procesy gospodarcze. l Zmiany w jednej części systemu nieuchronnie powodują następne zmiany innych komponentów. l Decyzje dotyczące tych systemów nie zawsze zależą jedynie od obiektywnych kryteriów inżynieryjnych. l Mają na to wpływ także szeroko rozumiane strategie firmowe i polityka.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 10 Komponenty systemu odziedziczonego Oprogramowanie pomocnicze Oprogramowanie użytkowe Reguły i strategie gospodarcze Sprzęt systemu Dane użytkowe Procesy gospodarcze Używa Obejmuje wiedzę o Używa Ogranicza Działa na

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 11 Model warstwowy systemu odziedziczonego Oprogramowanie pomocnicze Oprogramowanie użytkowe Procesy gospodarcze Sprzęt

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 12 Odziedziczone systemy użytkowe Program 1 Program 2 Program 4 Program 3 Program 5 Program 6 Program 7 Plik 1Plik 2Plik 3Plik 4Plik 5Plik 6

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 13 Systemy z centralną bazą danych Program 1 Program 2 Program 3 Program 4 System zarządzania Bazą danych Logiczny i fizyczny model danych Logiczny i fizyczny model danych opisuje

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 14 Przetwarzanie transakcyjne z użyciem monitora zdalnego przetwarzania Monitor zdalnego przetwarzania Monitor zdalnego przetwarzania Baza danych konta Uszeregowane transakcje Zapytania i aktualizacje stanu kont bankomaty

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 15 Struktury systemów odziedziczonych l Niemal wszystkie dzisiejsze systemy odziedziczone zaprojektowano, zanim w przemyśle powszechnie zaczęto stosować tworzenie obiektowe. l Programy nie są zbudowane jako zbiory oddziałujących obiektów. Mają zwykle strukturę kolekcji podprogramów lub funkcji. l Każdy podprogram realizuje część funkcjonalności systemu i jest w miarę potrzeby wywoływany przez inne podprogramy. l W niektórych językach podprogramy mają swoje prywatne dane, ale korzystają także ze współdzielonych obszarów danych. l W innych językach, takich jak starsze wersje języka COBOL, dane są współdzielone i dostępne wszystkim podprogramom.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 16 Funkcyjne widzenie projektu Pamięć dzielona F5 F4 F2 F3 F1

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 17 Rodzaje systemów gospodarczych l Systemy przetwarzania wsadowego. Dane są podawane i odbierane w postaci wsadów z plików, a nie z terminala użytkownika. Przykładami systemów przetwarzania wsadowego są systemy płacowe, systemy fakturowania itp. l Systemy przetwarzania transakcyjnego. Dane są podawane i odbierane w postaci ciągów transakcji w bazie danych. Transakcje są przekazywane z terminali użytkowników.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 18 Model wejście-przetwarzanie- wyjście Przetwarzanie System Wejście Wyjście

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 19 Diagram przepływu danych systemu płacowego Dane o miesięcznej płacy Dane o miesięcznej płacy Zapisz dane o ubezpieczeniach społecznych Zapisz dane o ubezpieczeniach społecznych Dane pracowników Dane pracowników Tabele podatkowe Tabele podatkowe Stawki miesięcznego wynagrodzenia Stawki miesięcznego wynagrodzenia Dane o ubezpieczeniach społecznych Dane o ubezpieczeniach społecznych Transakcje bankowe Transakcje bankowe Transakcje emerytalne Transakcje emerytalne Transakcje podatkowe Transakcje podatkowe Zapisz transakcję bankową Zapisz transakcję bankową Wydrukuj pasek płacowy Wydrukuj pasek płacowy Zapisz dane emerytalne Zapisz dane emerytalne Zapisz transakcje podatkowe Zapisz transakcje podatkowe Oblicz wynagrodzenie Oblicz wynagrodzenie Sprawdź dane pracownika Sprawdź dane pracownika Odczytaj dane o miesięcznej płacy Odczytaj dane o miesięcznej płacy Odczytaj dane pracownika Odczytaj dane pracownika Odszyfrowane dane pracownika Informacje o płacy Poprawne dane pracownika Obciążenia z tytułu ubezpieczeń społecznych + NIP Obciążenia podatkiem + NIP + urząd skarbowy DRUKARKA Obciążenia emerytalne + NIP Dane pracownika + obciążenia Płaca netto + numer konta w banku

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 20 Ocena systemów odziedziczonych l Firma zarządzająca wieloma systemami odziedziczonymi, która ma niewielki budżet na pielęgnację i ulepszanie systemów, musi podjąć decyzję, w jaki sposób otrzymać najlepszy zwrot ze swoich inwestycji. l Oznacza to, że musi ona dokonać realistycznej oceny swoich systemów odziedziczonych i zdecydować o wyborze najwłaściwszej strategii kierowania ewolucją tych systemów.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 21 Cztery warianty strategii l Całkowite złomowanie systemu l Kontynuacja użytkowania systemu l Przekształcenie systemu w sposób, który umożliwi uzdatnienie do pielęgnacji l Wymiana systemu na nowy system

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 22 Jakość systemu i wartość gospodarcza Wartość gospodarcza Jakość systemu Duża wartość gospodarcza Niska jakość Duża wartość gospodarcza Wysoka jakość Mała wartość gospodarcza Niska jakość Mała wartość gospodarcza Wysoka jakość

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 23 Ocena wartości gospodarczej l Ocena wartości gospodarczej systemu jest subiektywna. Nie istnieje niezawodna, obiektywna metoda, z której można korzystać. l Tak jak w wypadku wszystkich subiektywnych procesów, jeśli będzie się polegać na jednej opinii, to prawdopodobnie otrzyma się bardzo przekłamaną wartość. l Proponuje się więc, aby przyjąć podejście oparte na punktach widzenia, w którego ramach identyfikuje się w przedsiębiorstwie kilka punktów widzenia i ocenia się wartość z każdego z tych punktów widzenia.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 24 Punkty widzenia l Użytkownicy systemu. Jak oceniają skuteczność systemu we wspomaganiu procesów gospodarczych? l Klienci. Czy użycie systemu jest przezroczyste dla klientów lub czy ich interakcje są ograniczone przez system? l Menedżerowie liniowi. Czy menedżerowie uważają, że system wnosi istotny wkład w powodzenie ich działu? l Menedżerowie informatyki. Czy występują trudności przy poszukiwaniu ludzi do pracy z systemem? l Wyżsi menedżerowie. Czy system i związane z nim procesy gospodarcze wnoszą istotny wkład w realizację celów gospodarczych?

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 25 Ocena jakości systemu dziedziczonego l System odziedziczony to nie tylko oprogramowanie użytkowe, ale także procesy gospodarcze, sprzęt i środowisko oprogramowania pomocniczego systemu. Aby ocenić jakość systemu, trzeba przyjrzeć się wszystkim jego poziomom. l Po zgromadzeniu informacji o wszystkich aspektach systemu jest się już gotowym do wydania opinii o jakości systemu i jego miejscu. l Nie ma jednak żadnej systematycznej metody wypracowywania tej opinii. Wszystko zależy od konkretnego systemu i przedsiębiorstwa, które z niego korzysta.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 26 Ocena procesu gospodarczego l Ocena jakości procesu gospodarczego jest ściśle związana z oceną wartości gospodarczej systemu. l Wartość gospodarcza systemu to ocena skuteczności, z jaką system wspomaga realizację celów gospodarczych.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 27 Ocena środowiska l Środowisko systemu oprogramowania użytkowego obejmuje oprogramowanie pomocnicze (systemy operacyjne, kompilatory, udogodnienia itd.), z których system korzysta, i platformę sprzętową, na której działają wykonywalne elementy systemu użytkowego. l Należy ocenić to środowisko, ponieważ czynniki środowiskowe są często katalizatorami zmian oprogramowania użytkowego.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 28 Czynniki używane przy ocenie środowiska Czynnik Pytania Stabilność Czy firma wciąż istnieje? Czy sytuacja finansowa dostawcy jest stabilna i czy będzie on dostawcy dalej istniał? Jeśli dostawca wypadł z rynku, czy system jest pielęgnowany przez kogoś innego? Częstość Czy częstość zgłaszanych awarii system jest duża? Czy oprogramowanie pomocnicze awarii załamuje się i wymusza ponowne uruchomienie systemu? Wiek Jak stare są sprzęt i oprogramowanie? Im starsze jest oprogramowanie pomocnicze i sprzęt, tym szybciej będzie przestarzałe. Mogą ciągle poprawnie działać, ale korzyści ekonomiczne i gospodarcze z przeniesienia na bardziej nowoczesne systemy mogłyby być znaczące. Efektywność Czy efektywność systemu jest odpowiednia? Czy kłopoty z efektywnością mają istotny wpływ na pracę użytkowników systemu? Wspomagane Jakiego lokalnego wspomagania wymaga sprzęt i oprogramowanie? Jeśli z wspomaganiem wspomaganie wiążą się wysokie koszty, być może warto rozważyć wymianę systemu. Koszty Jakie są koszty konserwacji sprzętu i utrzymania licencji na oprogramowanie pomocnicze? utrzymania Starszy sprzęt może wymagać większych wydatków na konserwację niż nowoczesne systemy. Oprogramowanie pomocnicze może wiązać się z wysokimi rocznymi opłatami licencyjnymi. Współdziałanie Czy są kłopoty ze sprzęganiem systemu z innymi systemami? Czy kompilatory mogą być używane z obecną wersją systemu operacyjnego? Czy niezbędna jest emulacja sprzętu?

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 29 Ocena oprogramowania użytkowego l Ocenianie jakości oprogramowania użytkowego różni się od czynności związanych z zapewnianiem jakości, które wykonuje się w trakcie budowania oprogramowania. l Systemy odziedziczone mogły być zbudowane z użyciem metod i standardów, których już się nie stosuje. l Struktura systemu nieuchronnie uległa uszkodzeniu w wyniku zmian, dokumentacja jest więc prawdopodobnie nieaktualna.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 30 Czynniki używane przy ocenie oprogramowania użytkowego CzynnikPytania ZrozumiałośćJak trudno jest zrozumieć kod źródłowy obecnego systemu? Jak bardzo złożone są wykorzystane struktury sterowania? Czy zmienne mają znaczące nazwy, które odzwierciedlają ich funkcję? DokumentacjaJaka dokumentacja systemu jest dostępna? Czy dokumentacja jest pełna, spójna i aktualna? DaneCzy istnieje jawny model danych systemu? Do jakiego stopnia dane są powtarzane w różnych plikach? Czy dane używane przez system są spójne i aktualne? EfektywnośćCzy efektywność programu użytkowego jest odpowiednia? Czy kłopoty z efektywnością maja istotny wpływ na pracę użytkowników systemu? JęzykCzy są dostępne nowoczesne kompilatory języka programowania użyte do budowy programowaniasytemu? Czy tego języka ciągle używa się do tworzenia nowych systemów? ZarządzanieCzy wszystkie wersje wszystkich części systemu są przechowywane w systemie konfiguracjamizarządzania konfiguracjami? Czy istnieje jawny opis wersji komponentów wykorzystywanych w obecnym systemie? Dane testoweCzy istnieją dane testowe dla systemu? Czy istnieje rejestr testów regresywnych przeprowadzanych wówczas, gdy do systemu dodaje się nowe udogodnienia? UmiejętnościCzy są dostępne osoby, które maja umiejętności niezbędne do pielęgnacji programu personeluużytkowego? Czy liczba osób rozumiejących system jest ograniczona?

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 31 Główne tezy l System odziedziczony to stary system, który ciągle realizuje niezbędne usługi dla przedsiębiorstwa. l System odziedziczony to nie tylko system oprogramowania użytkowego. Jest to socjotechniczny system komputerowy, a zatem obejmuje procesy gospodarcze, oprogramowanie użytkowe, oprogramowanie pomocnicze i sprzęt. l Większość systemów odziedziczonych zawiera kilka różnych programów i współdzielone dane związane z tymi programami. Te dane mogą być przechowywane w plikach lub w przestarzałym systemie zarządzania bazą danych. l Większość systemów odziedziczonych zaprojektowano z funkcyjnego punktu widzenia. Takie systemy składają się z oddziałujących na siebie funkcji, które komunikują się przez parametry i globalne obszary współdzielonych danych.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 26Slide 32 Główne tezy l Wśród systemów gospodarczych większość systemów odziedziczonych zaprojektowano jako systemy przetwarzania wsadowego lub systemy przetwarzania transakcyjnego. W obu wypadkach ich budowę można ogólnie przedstawić za pomocą modelu wejście- przetwarzanie-wyjście. l Przy podejmowaniu decyzji o tym, czy wymienić, przekształcić, albo pielęgnować system, należy ocenić wartość gospodarczą systemu odziedziczonego oraz jakość oprogramowania użytkowego i jego środowiska. l Wartość gospodarcza systemu to ocena skuteczności, z jaką system wspomaga realizację celów gospodarczych. l Jakość systemu zależy od jakości procesów gospodarczych, jakości samego oprogramowania użytkowego oraz jakości oprogramowania i sprzętu, które wspomagają pracę systemu.