Proces utrzymania w Ğwietle dorobku literatury zagranicznej

Literatura obcojĊzyczna wiąĪe proces utrzymania z pojĊciem ewolucji.

Ewolucja oprogramowania (ang. software evolution) okreĞlana jest jako proces zmian zachodzących w oprogramowaniu w czasie jego Īycia i jako taki

nie-unikniony i naturalny. Pogląd ten dominuje w pracach amerykaĔskiego na-ukowca M.M. Lehmana, który w wyniku swoich wieloletnich badaĔ sformuáo-waá osiem praw dotyczących ewolucji systemów informatycznych¹. NaleĪy zauwaĪyü, Īe prawa Lehmana powstaáy na bazie obserwacji kilku duĪych sys-temów informatycznych (np. IBM OS/360-70), arbitralnie wybranych przez ich twórcĊ, prowadzonej od lat szeĞüdziesiątych do osiemdziesiątych ubiegáego wieku. Do ich stworzenia nie wykorzystano metod analizy statystycznej ani formalnych metod dowodzenia, stąd teĪ w chwili powstania nie byáy w peáni akceptowane jako prawa. Z czasem wyniki prac M.M. Lehmana zostaáy po-nownie zweryfikowane i potwierdzone w serii projektów FEAST (ang. Feed-back, Evolution and Software Technology) i nazwa „prawa” zostaáa utrzymana, a twierdzenia M.M. Lehmana weszáy na staáe do kanonu nauk związanych z in-Īynierią oprogramowania. NajwaĪniejsze z nich mówią o tym, Īe²:

a) program stosowany w rzeczywistym Ğrodowisku musi byü stale do niego adaptowany, w przeciwnym przypadku bĊdzie stopniowo coraz mniej uĪyteczny – prawo ciągáej zmiany (1974 rok);

b) wraz z ewolucją oprogramowania jego struktura staje siĊ coraz bar-dziej záoĪona, chyba Īe w wyniku dodatkowych prac (i nakáadów) na-stĊpuje jej uproszczenie – prawo wzrastającej záoĪonoĞci (1974 rok);

c) funkcjonalnoĞü oprogramowania musi rosnąü, aby satysfakcja odbior-ców systemu pozostaáa na tym samym poziomie – prawo ciągáego wzrostu (1991 rok);

d) procesy ewolucyjne oprogramowania są wielopoziomowe, mają naturĊ iteracyjną i wymagają informacji z wielu punktów widzenia. Wyko-rzystanie informacji zwrotnej pozwala osiągnąü istotną poprawĊ pro-cesu ewolucji – prawo przyrostowego rozwoju (1996 rok).

W kontekĞcie prac M.M. Lehmana utrzymanie (ang. software maintenan-ce) zawiera siĊ w ewolucji. Jest procesem zaplanowanym, mającym na celu kontrolĊ procesów ewolucyjnych i czynników, które je implikują. Proces utrzymania w literaturze obcojĊzycznej, podobnie jak i w krajowej, umiejsca-wiany jest po fazach analizy, projektowania, tworzenia i wdroĪenia, czyli w momencie, kiedy system przechodzi w fazĊ eksploatacji w danej organizacji.

1 M.M. Lehman, The Future of Software – Managing Evolution, inv.contr., vol. 15, no. 1, IEEE Softw., Jan-Feb 1998.

2 Ibidem.

Ponadto podobnie, jak w literaturze krajowej wielu autorów obcojĊzycznych ogranicza siĊ jedynie do umiejscowienia utrzymania w cyklu Īycia, koncentru-jąc swoje rozwaĪania na jego wczeĞniejszych faza. Sytuacja ta ulega zdecydo-wanej zmianie w ostatnim dziesiĊcioleciu, kiedy to zaczynają siĊ pojawiaü po-zycje koncentrujące swoje rozwaĪania na utrzymaniu systemu informatycznego.

Opracowywane są teĪ miĊdzynarodowe standardy takie, jak IEEE Stan-dard for Software Maintenance No. 1219 czy ISO/IEC 14764 (Software Engi-neering – Software Life Cycle Processes – Maintenance), które jednoznacznie definiują proces utrzymania jako „proces obejmujący: modyfikacjĊ oprogra-mowania po jego dostarczeniu i wdroĪeniu w celu korygowania báĊdów, podno-szenia efektywnoĞci lub innych atrybutów, adaptowania produktu do zmieniają-cych siĊ warunków otoczenia, w tym Ğrodowiska operacyjnego”³, czyli zarówno rozwój, jak i naprawĊ oprogramowania w zaleĪnoĞci od potrzeb. Ponadto w po-zycji Software Maintenance Management, Evolution and Continuous Improve-ment, mówi siĊ juĪ nie tylko o perspektywie uĪytkowników oprogramowania, lecz takĪe o perspektywie jego twórców⁴.

Literatura obcojĊzyczna obfituje w liczne definicje pojĊcia utrzymania.

WĞród przykáadowych moĪna wymieniü:

a) „utrzymanie obejmuje sprzĊt, oprogramowanie, dokumentacjĊ oraz procedury mające na celu eliminacjĊ ewentualnych báĊdów systemu, odpowiedĨ na nowe wymagania oraz podniesienie efektywnoĞci wspomaganych procesów biznesowych”⁵;

b) „utrzymanie to ogóá dziaáaĔ wymaganych do wsparcia oprogramowa-nia po najniĪszych kosztach; niektóre dziaáaoprogramowa-nia są inicjowane na etapie tworzenia oprogramowania, ale wiĊkszoĞü ma miejsce juĪ po jego do-starczeniu do odbiorcy”⁶;

3 Institute of Electrical and Electronics Engineers. IEEE Standard for Software Mainte-nance, Standard 1219, Institute of Electrical and Electronics Engineers, New York 1998.

4 A. April, A. Abran, Software Maintenance Management, Evolution and Continuous Improvement, John Wiley & Sons, Hoboken 2008.

5 K.C. Loudon, J.P. Loudon, Management Information Systems. Managing The Digital Firm, Prentice Hall, Upper Saddle River 2006.

6 A. Abran, J.W. Moore, Guide to the Software Engineering Body of Knowledge (SWE-BOK). 2005 Version. IEEE Computer Society: Los Alamos, California, 2005.

c) „utrzymanie to proces wprowadzenia do systemu niezbĊdnych zmian wynikających gáównie ze sprzĊĪenia zwrotnego miĊdzy otoczeniem a organizacją”⁷;

d) „utrzymanie to modyfikacje kodu i powiązanej dokumentacji w odpo-wiedzi na problemy lub potrzeby rozwojowe, celem jest modyfikowa-nie istmodyfikowa-niejącego oprogramowania bez naruszania jego integralnoĞci”⁸; e) „utrzymanie to zmiany, które są wprowadzane w oprogramowaniu po

jego uruchomieniu u odbiorcy”⁹.

Rys. 1. Udziaá utrzymania w stosunku do pozostaáych dziaáaĔ związanych z oprogra-mowaniem

ħródáo: J. Capers, Estimating Software Costs, McGraw-Hill 2007.

Autorzy anglojĊzyczni podkreĞlają ponadto znaczenie utrzymania z uwagi na koszty tego procesu, które znacząco przekraczają koszty związane z pier-wotnym stworzeniem systemu. W tym kontekĞcie moĪna rozpatrywaü utrzyma-nie jako najdáuĪszą i w Ğwietle badaĔ najkosztowutrzyma-niejszą fazĊ cyklu Īycia

7 P. Beynon-Davies, Information systems. An Introduction to Informatics in Organisa-tions. PALGRAVE. Houndmills–New York 2002.

8 International Standards Organization. Information Technology. Software Life Cycle Processes, ISO/IEC Standard 12207. International Organization for Standardization: Geneva, Switzerland, 1995.

9 J. Martin, C. McClure, Software Maintenance. The Problem and Its Solutions, Prentice Hall, Englewood Cliffs 1983.

mu. Ocenia siĊ, Īe koszty związane z utrzymaniem to okoáo 50–90% wszyst-kich kosztów ponoszonych na przestrzeni caáego cyklu Īycia oprogramowania, a na kaĪdego dolara wydanego na stworzenie systemu przypadają dwa wydane na jego utrzymanie¹⁰. Ponadto udziaá dziaáaĔ związanych z utrzymaniem opro-gramowania w stosunku do wszystkich przedsiĊwziĊü związanych z oprogra-mowaniem stale roĞnie z okoáo 10% w latach piĊüdziesiątych, do 60% obecnie i okoáo 70% w ciągu najbliĪszych 10 lat (patrz rysunek 1). W tym kontekĞcie P. Beynon-Davies zauwaĪa, Īe „dziaáalnoĞü związana z utrzymaniem SI powin-na byü traktowapowin-na priorytetowo gáównie ze wzglĊdu powin-na jej koszty, które zpowin-na- zna-cząco przekraczają koszty tworzenia i wdraĪania systemu”¹¹. Wskazuje na ko-niecznoĞü traktowania jej jako procesu i podjĊcia dziaáaĔ mających na celu za-rządzanie nim. WĞród dróg realizacji tego postulatu wymienia:

a) tworzenie komórek odpowiedzialnych za utrzymanie SI poprzez mo-dyfikowanie, naprawianie i uaktualnianie zastosowanych rozwiązaĔ;

b) projektowanie systemu z myĞlą o jego przyszáym rozwoju, czyli sto-sowanie elastycznych rozwiązaĔ, które uáatwią jego dostosowywanie do zachodzących zmian;

c) zarządzanie konfiguracją mające na celu identyfikowanie koniecznych zmian SI, kontrolowanie poprawnoĞci ich wprowadzania i dziaáania, informowanie o zmianach pozostaáych uĪytkowników;

d) aktualizowanie starzejących siĊ rozwiązaĔ poprzez planowanie i wpro-wadzanie zmian w zakresie zastosowanego sprzĊtu, oprogramowania oraz technologii teleinformatycznych.

Kontynuując rozwaĪania P. Beynon-Daviesa, naleĪy zauwaĪyü, Īe ZSI pomimo tego, Īe są rozwiązaniami ustabilizowanymi pod wzglĊdem programo-wym i funkcjonalnym na skutek nieustanych zmian otoczenia oraz samych podmiotów, w których zostaáy wdroĪone, podlegają procesom ciągáych modyfi-kacji. W tym kontekĞcie zmiana staje siĊ naturalną czĊĞcią cyklu ich Īycia i nie da siĊ jej uniknąü. Proces mający na celu kontrolĊ, planowanie i zorganizowanie dziaáaĔ podejmowanych w odpowiedzi na potrzeby wprowadzania zmian w sys-temie informatycznym (niezaleĪnie od ich Ĩródeá) jest w pracy definiowany jako proces utrzymania. O rozpoczĊciu procesu utrzymania naleĪy mówiü

10 A. April, A. Abran, op.cit., B.W. Boehm, Industrial Software Metrics Top 10 List, IEEE Software 1987.

11 P. Beynon-Davies, op.cit.

w kontekĞcie okreĞlonej perspektywy. Z perspektywy przedsiĊbiorstwa, które uĪytkuje dany system, utrzymanie systemu informatycznego rozpoczyna siĊ w momencie zakoĔczenia procesu wdroĪenia (na ogóá okreĞlanego formalnie podpisaniem protokoáu zakoĔczenia wdroĪenia) i rozpoczĊcia jego eksploatacji.

Z perspektywy dostawcy oprogramowania, wiodącej dla rozwaĪaĔ, o utrzyma-niu systemu moĪna mówiü od momentu zakoĔczenia jego pierwszego wdroĪe-nia. Eksploatacja systemu przez uĪytkowników obfituje bowiem w liczne wyda-rzenia, w wyniku których odkrywane są wczeĞniej niewykryte báĊdy, pojawiają siĊ nowe wymagania czy zmienia siĊ Ğrodowisko funkcjonowania systemu.