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.