Inżynieria oprogramowania
Pielęgnacja i ewolucja
oprogramowania I
Inżynieria oprogramowania
Pielęgnacja i ewolucja
oprogramowania I
Zawartość
Procesy ewolucji oprogramowania
Dynamika ewolucji oprogramowania
Pielęgnacja oprogramowania
Systemy dziedziczone
Definicje
Ewolucja oprogramowania
(ang. software
evolution): proces zmian zachodzących w
oprogramowaniu w czasie jego życia.
Pielęgnacja oprogramowania
(ang.
software maintenance): czynności
modyfikujące program po jego
dostarczeniu i wdrożeniu.
IEEE Standard for Software Maintenance No.
1219 (1993)
Zmiany w oprogramowaniu
Zmiany w oprogramowaniu są
nieuniknione:
Użytkowanie oprogramowania może
wymuszać nowe wymagania.
Następują zmiany w firmie używającej
oprogramowanie.
Istnieje potrzeba poprawy błędów.
Może nastąpić zmiana sprzętu.
Może istnieć potrzeba poprawy
efektywności.
Znaczenie pielęgnacji
oprogramowania
Duże firmy wkładają ogromne pieniądze w
oprogramowanie, niezbędne do ich
działania.
W celu sprostania wymaganiom,
oprogramowanie musi być ustawicznie
aktualizowane.
Budżet przeznaczony na oprogramowanie w
dużych firmach na pielęgnację istniejących
programów jest dużo większy niż budżet
przeznaczony na nowe systemy
informatyczne.
Model tworzenia i
ewoluowania
oprogramowania
Specyfikowanie
Specyfikowanie
Specyfikowanie
Projektowanie
i i
mplementacja
Projektowanie
i i
mplementacja
Projektowanie
i i
mplementacja
Zatwierdzanie
Zatwierdzanie
Zatwierdzanie
wersja 1
wersja 3
wersja 2
Działanie
Działanie
Działanie
Ewolucja, serwisowanie,
wycofywanie
Tworzenie
Ewolucja
Serwisowanie
Wycofywanie
Ewolucja, serwisowanie,
wycofywanie
Ewolucja
Stan cyklu życia oprogramowania, kiedy
implementowane są nowe wymagania.
Serwisowanie
Stan, w którym poprawiane są błędy i zmiany
związane ze środowiskiem oprogramowania (nowy
sprzęt, system operacyjny). Nie implementuje się
nowej funkcjonalności, gdyż jest to nieopłacalne.
Wycofywanie
Oprogramowanie jest używane, ale żadne zmiany
nie mają miejsca.
Proces ewolucji
oprogramowania
Proces ewolucji oprogramowania zależy
od:
Typu oprogramowania
Metodologii tworzenia oprogramowania
Umiejętności i doświadczenia personelu
Ewolucja jest wynikiem potrzeby zmian w
oprogramowaniu.
Identyfikacja potrzebnych zmian i proces
ewolucji przeplatają się w całym cyklu
życia oprogramowania.
Identyfikacja zmian i proces
ewolucji
Identyfikacja zmian
Nowy system
Propozycje zmian
Implementacja zmian
Szkic procesu ewolucji
Żądanie
zmian
Analiza
zmian
Planowanie
wydania
Implementacja
zmian
Wydanie
systemu
Naprawa
usterek
Dostosowanie
do platformy
Rozszerzenie
systemu
Implementacja zmian
Proponowane
zmiany
Analiza
wymagań
Aktualizacja
wymagań
Implementacja
wymagań
Implementacja zmian
Propozycja i analiza nowych wymagań. Następnie
przeprojektowanie, implementacja i testowanie
systemu.
Początkowa faza tego procesu może wymagać
analizy systemu podlegającemu pielęgnacji,
szczególnie jeśli zmiany implementuje zespół,
który nie tworzył tego systemu.
Analiza systemu podlegającego zmianom polega
na zrozumieniu jego struktury, funkcjonalności
oraz wpływu implementowanych zmian na
system.
Pilne żądania zmian
W pewnych przypadkach zmiany mogą być
zaimplementowane z ominięciem pewnych
kroków:
Jeśli wykryto usterkę uniemożliwiającą
poprawne działanie systemu.
Jeśli zmiana środowiska ma nieoczekiwany
wpływ na system
Jeśli mają miejsce niespodziewane zmiany
gospodarcze, przykładowo pojawienie się nowej
konkurencji lub zmiany przepisów prawnych.
Proces awaryjnej naprawy
Żądanie
zmian
Analiza
kodu
źródłoweg
o
Modyfikacja
kodu źródłowego
Zmodyfikowany
system
Uwaga: każda naprawa awaryjna może prowadzić do pogorszenia
się struktury systemu. Przyspiesza to proces starzenia się
systemu, a zatem wprowadzenie nowych zmian staje się coraz
trudniejsze, a koszty pielęgnacji rosną.
Programowanie zwinne, a
pielęgnacja
Filozofia programowania zwinnego opiera się
na ciągłej ewolucji konstruowanego systemu.
Z powodu niepełnej dokumentacji, proces
ewolucji oprogramowania zbudowanego
metodą zwinną jest trudny.
Automatyczne testowanie wykorzystywane w
programowaniu zwinnym może być
przydatne w procesie ewolucji systemów
tworzonych tradycyjnie.
Dynamika ewolucji
programów
Dynamika ewolucji programów to studium
stanu systemu.
Większość wyników w tej dziedzinie
przypisuje się Lehmanowi i Belady’emu
(1985), którzy sformułowali zbiór „praw”
zmiany systemu (prawa Lehmana).
Prawa Lehmana powstały z empirycznych
studiów związanych z wielkimi systemami
informatycznymi. Nie jest jasne, czy zasady
te obowiązują w przypadku małych i
średnich systemów.
Prawa Lehmana
Ustawiczna zmiana
Program użytkowany w rzeczywistym środowisku
nieuchronnie musi podlegać zmianom albo stawać się coraz
mniej użyteczny w tym środowisku.
Rosnąca złożoność
W miarę jak ewoluujący program zmienia się , jego struktura
staje się coraz bardziej złożona. Na zachowywanie i
upraszczanie struktury trzeba przeznaczyć dodatkowe zasoby.
Samoregulacja
Ewolucja programu jest samoregulującym się procesem.
Atrybuty systemu, takie jak wielkość, czas między wydaniami
i liczba zgłoszonych błędów, są w przybliżeniu takie same dla
wszystkich
Prawa Lehmana
Stabilność organizacyjna
W czasie ewolucji programu tempo jego rozwoju jest w
przybliżeniu stałe i niezależne od wielkości zasobów (liczby
wykonawców) przeznaczonych na zbudowanie systemu.
Stała zmiana
W czasie życia systemu przyrostowa zmiana jest stała w
każdym
wydaniu.
Nieustanny wzrost funkcjonalności
Funkcjonalność systemu musi ustawicznie rosnąć , aby
zadowolić użytkowników.
Prawa Lehmana
Spadek jakości
Wraz z dokonywaniem zmian pogarsza się struktura
oprogramowania.
Sprzężenie zwrotne
Każda zmiana systemu ma wpływ na dalsze zmiany
tego systemu.
Stosowalność praw Lehmana
Prawa Lehmana wydają się sensowne dla
wielkich systemów produkowanych przez
wielkie firmy.
Nie jest jasne, jak należy je zmodyfikować
dla:
Systemów wykorzystujących użycie
wielokrotne
Małych i średnich systemów
Systemów tworzonych przez małe firmy
Podsumowanie części I
Tworzenie oprogramowania i jego ewolucję
należy traktować jako zintegrowany, iteracyjny
proces.
Dla systemów zamkniętych koszty pielęgnacji
są na ogół wyższe niż koszty utworzenia.
Proces ewolucji oprogramowania sterowany jest
potrzebą zmian. Zawiera on analizę wpływu
zmian, planowanie nowego wydania systemu
oraz implementację zmian.
Prawa Lehmana są wynikiem analizy wielu
dużych systemów informatycznych, wykonanej
na przestrzeni wielu lat.
Inżynieria oprogramowania
Pielęgnacja i ewolucja
oprogramowania II
Pielęgnacja oprogramowania
Modyfikacja oprogramowania po oddaniu do
użytku.
Termin dotyczy na ogół produktów
zamkniętych. O programach otwartych mówi
się, że ewoluują tworząc kolejne wersje.
Pielęgnacja na ogół nie prowadzi do dużych
zmian architektonicznych.
Zmian dokonuje się modyfikując komponenty
systemu i ewentualnie dodając nowe.
Rodzaje pielęgnacji
Pielęgnacja w celu naprawy usterek
oprogramowania. (Błędy kodu, błędy
projektowe, błędy w wymaganiach.)
Pielęgnacja w celu dostosowania
oprogramowania do innego środowiska.
(Zmiana sprzętu, systemu operacyjnego lub
oprogramowania pomocniczego.)
Pielęgnacja w celu rozszerzenia lub
zmodyfikowania funkcjonalności systemu, w
odpowiedzi na zmiany gospodarcze lub
organizacyjne.
Podział kosztów przy
pielęgnacji
65%
17%
18%
Koszty pielęgnacji
Na ogół większe niż koszty wytworzenia. Dla
gospodarczych systemów użytkowych
porównywalne z kosztami wytworzenia. Dla
systemów wbudowanych około cztery razy
większe. (Skrajny przypadek to system tworzony
przez Boeinga dla sił zbrojnych USA: ponad 100
razy więcej!!)
Koszty pielęgnacji rosną wraz z wiekiem
oprogramowania. Dla bardzo starych systemów
rosną gwałtownie.
Pielęgnacja prewencyjna
Polega na zaprojektowaniu takiej
struktury programu, aby ułatwić jego
późniejszą pielęgnację, w szczególności
dodawanie nowych funkcjonalności.
Pielęgnacja prewencyjna pochłania na
ogół około 5% ogólnego kosztu
wytworzenia.
Czynniki wpływające na koszt
pielęgnacji
Stabilność zespołu
Koszt pielęgnacji maleje, jeśli przynajmniej
przez jakiś czas system pielęgnowany jest przez
zespół wytwarzający. Na ogół jednak zespół ten
rozwiązywany jest po zbudowaniu systemu.
Zobowiązania umowne
Często umowa pielęgnacyjna podpisana jest z
inną firmą. Wówczas zespół wytwórczy nie ma
motywacji, aby produkt był łatwy do
pielęgnacji.
Czynniki wpływające na koszt
pielęgnacji
Umiejętności personelu
Programiści często uważają pielęgnację za
czynność mniej ambitny niż tworzenie. W
konsekwencji, personel pielęgnacyjny ma
często małe doświadczenie.
Wiek i struktura programu
W miarę upływu czasu struktura programu
ulega degradacji. Ponadto stare programy
są często napisane w starych językach i
może brakować dokumentacji.
Przewidywanie pielęgnacji
Jakie części systemu sprawią największe
trudności personelowi pielęgnującemu i
jaki będzie ich koszt?
Akceptacja zmiany systemu zależy od
zdatności do pielęgnacji komponentów
systemu, których zmiana dotyczy.
Zmiany systemu degradują jego strukturę.
Koszty pielęgnacji zależą od liczby zmian, a
koszty zmian zależą od łatwości
pielęgnowania systemu.
Przewidywanie pielęgnacji
Przewidywanie
zdatności do
pielęgnacji
Przewidywanie
kosztów
pielęgnacji
Przewidywanie
zmian
systemu
Których części systemu
będą najczęściej
dotyczyły żądania zmian?
Jak dużo
spodziewamy się
żądań zmian?
Które części systemu
będą najdroższe
w pielęgnacji?
Jaki będzie koszt
pielęgnacji systemu
w czasie jego życia?
Jaki będzie koszt
pielęgnacji systemu
w następnym roku?
Przewidywanie zmian
Przewidywanie zmian wymaga znajomości
związku między systemem a jego
zewnętrznym środowiskiem. Jeśli związek ten
jest silny, zmiany w środowisku będą
wymuszać zmiany w systemie.
Czynniki wpływające na związek systemu i
środowiska:
Liczba i złożoność interfejsów systemu.
Liczba zmiennych wymagań systemu.
Procesy gospodarcze, w których używa się systemu.
Złożoność systemu i jego
pielęgnacja
Koszty pielęgnacji można przewidzieć szacując
złożoność systemu. Bardziej złożone systemy
są droższe w pielęgnacji. Dlatego główne
koszty pielęgnacji dotyczą na ogół niewielu
(złożonych) komponentów systemu
.
Złożoność komponentu zależy od
Złożoności struktury sterowania
Złożoności struktur danych
Rozmiaru komponentu
Metryki procesu pielęgnacji
Następujące metryki, związane z
dotychczasową pielęgnacją mogą być użyte do
przewidywania kosztów dalszej pielęgnacji:
Liczba zauważonych usterek.
Średni czas potrzebny na wykonanie analizy zmian.
Średni czas potrzebny na implementację zmiany.
Liczba niespodziewanych żądań zmian.
Jeśli któraś z tych metryk rośnie,
prawdopodobnie zmniejsza się zdolność
pielęgnacji systemu i rosną koszty.
Systemy odziedziczone
Systemy informatyczne używane przez
przedsiębiorstwo przez bardzo długi
czas.
Systemy odziedziczone zwykle mocno
odbiegają od swoich pierwowzorów.
Struktura systemów odziedziczonych, w
związku z wieloletnią pielęgnacją, jest
na ogół znacznie zdegradowana.
Restrukturalizacja
oprogramowania
Polega na ponownym zaimplementowaniu
systemów odziedziczonych w celu
zwiększenia ich zdatności do pielęgnacji.
Restrukturalizacja nie zmienia
funkcjonalności systemu.
Restrukturalizacja unika głębokich zmian
w architekturze systemu.
Restrukturalizacja może obejmować
ponowne dokumentowanie systemu.
Korzyści z
restrukturalizacji
Mniejsze ryzyko
.
Ponowne tworzenie oprogramowania jest
ryzykowne. Można popełnić błędy w
specyfikacji, mogą pojawić się kłopoty z
tworzeniem, mogą być problemy z ludźmi.
Mniejszy koszt
Przyjmuje się, że restrukturalizacja jest trzy
do czterech razy tańsza niż tworzenie od
nowa,
Proces restrukturalizacji
Pierwotny
program
Dokumentacja
programu
Zmodularyzowany
program
Pierwotne
dane
Tłumaczenie
kodu
źródłowego
Inżynieria
wstecz
Ulepszanie
struktury
programu
Modularyzacja
programu
Program
strukturalny
Restrukturalizacja
danych
Zrestrukturalizowane
dane
Czynności restrukturalizacji
Tłumaczenie kodu źródłowego
Kod programu jest tłumaczony na nowy język lub
nowszą wersję języka dotychczasowego.
Inżynieria wstecz
Program jest analizowany. Wydobywa się z niego
informacje, które pomogą w udokumentowaniu jego
struktury i funkcjonalności.
Ulepszanie struktury programu
Struktura sterowania programu jest analizowana i
modyfikowana tak, aby program był bardziej
czytelny.
Czynności restrukturalizacji
Modularyzacja programu
Grupuje się powiązane części programu i,
gdy jest to potrzebne, usuwa się
nadmiarowość. W pewnych przypadkach
można zmienić sprzętową architekturę
systemu (np. przejście od systemu
scentralizowanego na system rozproszony).
Restrukturalizacja danych
Zmienia się dane przetwarzane przez
program tak, aby odzwierciedlić zmiany
programu.
Koszty restrukturalizacji
Koszty restrukturalizacji zależą od
zakresu czynności. Najtańsze jest
tłumaczenie kodu źródłowego,
najdroższe są zmiany dotyczące
architektury sprzętowej. Ponadto należy
uwzględnić następujące czynniki:
Jakość strukturalizowanego oprogramowania
Wspomaganie narzędziowe strukturalizacji
Zakres niezbędnej konwersji danych
Dostępność ekspertów (dotyczy szczególnie
systemów wykorzystujących bardzo stare
języki oprogramowania).
Granice restrukturalizacji
Istnieją granice stopnia ulepszania
oprogramowania dzięki strukturalizacji.
Nie da się przekształcić systemu w ramach
różnych paradygmatów (np. z języka
funkcyjnego na obiektowy).
Nie da się automatycznie przeprowadzić
dużych zmian architektonicznych.
Faktoryzacja
Faktoryzacja jest ustawicznym procesem
ulepszania oprogramowania w trakcie jego
tworzenia i pielęgnacji. Jej celem jest
uniknięcie degradacji struktury i kodu
oprogramowania, a zatem zmniejszenie
kosztów pielęgnacji.
Faktoryzacja jest nieodłączną częścią
programowania zwinnego.
Typowe usterki kodu
Duplikacja kodu.
Bardzo długa metoda.
Bardzo rozbudowana klasa (reprezentuje kilka
klas logicznych).
Komentarze opisujące realizację kodu.
Niepotrzebnie złożony wzorzec projektowy.
Łańcuchy wywołań metod.
Pojemnik na dane (klasa nie posiada metod).
Podklasa w małym stopniu wykorzystuje
odziedziczone atrybuty i pola.
Zarządzanie systemami
odziedziczonymi
Firmy wykorzystujące systemy odziedziczone
muszą wybrać strategię pielęgnowania ich:
Całkowite zezłomowanie systemu.
Należy to
uczynić, jeśli system nie odwzorowuje dobrze
procesów gospodarczych firmy. Ma to na ogół
miejsce, jeśli procesy te ulegną istotnej zmianie.
Kontynuacja użytkowania systemu.
Należy to
uczynić, jeśli system jest potrzebny, stabilny i
jego użytkownicy nie zgłaszają dużej liczby
zmian.
Zarządzanie systemami
odziedziczonymi
Restrukturalizacja systemu.
Należy wybrać tę
opcję jeśli jakość systemu została zdegradowana
przez liczne zmiany pielęgnacyjne, a ciągle
pojawiają się żądania nowych zmian.
Zastąpienie systemu, lub jego części, przez
nowe oprogramowanie.
Tę opcję należy wybrać
jeśli nowe czynniki, przykładowo zmiana sprzętu,
powodują, że system nie może działać lub
można znacznie zwiększyć jego efektywność.
Ocena systemu
odziedziczonego
System odziedziczony należy oceniać z
dwóch punktów widzenia.
Gospodarczy punkt widzenia polega na ocenie
wartości systemu dla przedsiębiorstwa.
Systemowy punkt widzenia polega na jakości
oprogramowania.
Łącznie wartość gospodarcza i jakość
systemu pomagają w podjęciu decyzji, co
dalej robić z systemem odziedziczonym
Kategorie systemów
odziedziczonych
Niska jakość, mała wartość gospodarcza
Utrzymanie tych systemów w użyciu będzie
kosztowne, a stopa zwrotu dla przedsiębiorstwa
będzie mała. Są to kandydaci do złomowania.
Niska jakość, duża wartość gospodarcza
Wnoszą duży wkład w działanie przedsiębiorstwa,
a zatem nie można ich złomować. Niska jakość
oznacza jednak, że koszty ich działania są
wysokie. Są to kandydaci do restrukturalizacji lub
wymiany (jeśli są gotowe komponenty
wielokrotnego użycia).
Kategorie systemów
odziedziczonych
Wysoka jakość, mała wartość gospodarcza.
Nie warto podejmować ryzyka wymiany tych
systemów. Można kontynuować zwykłą
pielęgnację tych systemów; można też je
zezłomować.
Wysoka jakość, duża wartość gospodarcza
Systemy należy dalej użytkować, a ich wysoka
jakość oznacza, że nie ma potrzeby
inwestowania w ich restrukturalizację lub
wymianę. Należy kontynuować zwykłą
pielęgnację systemu.
Ocena wartości gospodarczej
systemu odziedziczonego
Punkty widzenia następujących podmiotów
powinny być wzięte pod uwagę:
Użytkownicy systemu. Jak oceniają skuteczność
systemu we wspomaganiu procesów gospodarczych?
Jak duża część funkcjonalności jest wykorzystywana?
Klienci biznesowi. Czy wyniki działania systemu są
przezroczyste dla klientów?
Menedżerowie liniowi. Czy system wnosi istotny
wkład w powodzenie ich działu? Czy dane
przechowywane w systemie są krytyczne w pracy
działu tego menedżera?
Ocena wartości gospodarczej
systemu odziedziczonego
Menedżerowie informatyki. Czy występują
trudności w znalezieniu ludzi do pielęgnacji
systemu? Czy system pochłania zasoby,
które można by lepiej wykorzystać w innych
systemach?
Wyżsi menedżerowie. Czy system i związane
z nim procesy gospodarcze wnoszą istotny
wkład w realizację celów gospodarczych
przedsiębiorstwa?
Oszacowanie technicznej
jakości systemu
Szacując techniczną jakość systemu
należy oszacować zarówno samą aplikację,
jak i środowisko, w którym aplikacja jest
używana. Na środowisko składa się sprzęt
oraz oprogramowanie pomocnicze
(kompilatory, narzędzia CASE, systemy
operacyjne, systemy baz danych itp.)
potrzebne do działania oraz pielęgnacji
i/lub restrukturalizacji systemu.
Czynniki wpływające na
ocenę środowiska
Stabilność dostawców
Czy dostawcy sprzętu i oprogramowania pomocniczego są
obecni na rynku? Jeśli tak, czy są finansowo stabilni, aby
kontynuować działanie? Jeśli nie, czy ktoś inny może przejąć
ich rolę?
Wskaźnik awarii
Czy wskaźnik awarii sprzętu jest wysoki? Jak często
występują awarie oprogramowania pomocniczego
wymagające ponownego
uruchomienia systemu?
Wiek
Jaki jest wiek sprzętu i oprogramowania pomocniczego?
Wydajność
Czy wydajność oprogramowania pomocniczego jest
wystarczająca?
Czynniki wpływające na
ocenę środowiska
Obsługa lokalna
Jaka obsługa lokalna jest wymagana w celu utrzymania
sprzętu i oprogramowania pomocniczego? Jaki jest koszt
obsługi?
Koszty pielęgnacji
Jakie są koszty serwisowania sprzętu i kupna kolejnych
licencji na oprogramowanie pomocnicze?
Zdolność do współpracy
Czy występują problemy związane ze współpracą w
ramach oprogramowania pomocniczego? Przykładowo,
czy aktualna wersja systemu operacyjnego umożliwia
działanie posiadanych kompilatorów?
Czynniki wpływające na
ocenę aplikacji
Zrozumiałość
Jak trudno zrozumieć kod źródłowy aplikacji? Jak
skomplikowane są struktury sterowania i struktury
danych
Dokumentacja
Jaka dokumentacja jest dostępna? Czy dostępna
dokumentacja jest spójna i aktualna?
Dane
W jakim stopniu dane są zduplikowane w różnych
plikach? Czy istnieje explicite model danych? Czy
zgromadzone dane są spóje i aktualne?
Czynniki wpływające na
ocenę aplikacji
Wydajność
Czy wydajność aplikacji jest wystarczająca? Czy
problemy z wydajnością rzeczywiście mają wpływ na
użytkowników systemu?
Język programowania
Czy istnieją nowoczesne kompilatory (interpretery)
dla języka użytego do napisania aplikacji? Czy ten
język jest nadal używany w nowych aplikacjach?
Czynniki wpływające na
ocenę aplikacji
Zarządzanie konfiguracjami
Czy kolejne wersje systemu były właściwie zarządzane?
Czy istnieją dokładne opisy wersji komponentów, z których
składa się aktualna wersja systemu?
Dane testowania
Czy istnieją dane testowe? Czy istnieją dane testów
regresywnych? (Testowanie regresywne: testowanie po
dodaniu nowej funkcjonalności w celu upewnienia się, że
zmiany w kodzie nie spowodowały błędów w jednej z
funkcji działającej poprawnie w poprzedniej wersji.
Umiejętności personelu
Czy w firmie pracuje osoba, która jest w stanie pielęgnować
aplikację? Czy w firmie pracują osoby znające system?
Metryczna ocena aplikacji
Oceniając aplikację, możemy dodatkowo
rozważać następujące miary:
Liczba żądań zmian. Im większa, tym niższa
jakość systemu.
Liczba interfejsów użytkownika. Im większa, tym
większe prawdopodobieństwo, że w interfejsach
wystąpią niespójności i redundancje.
Objętość danych. Im większa, tym większe
prawdopodobieństwo, że dane będą niespójne.
Podsumowanie części II
Istnieją trzy typy pielęgnacji
oprogramowania
W celu naprawy błędów
W celu dostosowania systemu do innego
środowiska
W celu dostarczenia lub zmodyfikowania nowej
funkcjonalności.
Restrukturalizacja polega na ponownym
zaimplementowaniu systemu w celu jego
łatwiejszej pielęgnacji.
Podsumowanie części II
Faktoryzacja jest ustawicznym procesem
ulepszania oprogramowania w trakcie
jego tworzenia i pielęgnacji. Jej celem jest
uniknięcie degradacji struktury i kodu
oprogramowania, a zatem zmniejszenie
kosztów pielęgnacji.
Wartość gospodarcza i jakość systemu
odziedziczonego decyduje czy system ten
należy zezłomować, zrestrukturalizować
czy dalej poddawać zwykłej pielęgnacji.