U ovoj lekciji obrađivaćemo:
Aktivnosti u održavanju su slične aktivnostima razvoja: analiza zahteva, evaluacija dizajna sistema i programa, pisanje i revizija programskog koda, testiranje izmena i ažuriranje dokumentacije. Otuda ljudi koji se bave održavanjem - analitičari, programeri i projektanti - imaju slične uloge. Međutim, zbog toga što izmene često zahtevaju detaljno poznavanje strukture i sadržaja programskog koda programeri imaju mnogo značajniju ulogu u procesu održavanja nego što su je imali u procesu razvoja.
Održavanje se istovremeno usredsređuje na četiri glavna aspekta evolucije sistema:
Radi kontrole svakodnevnog funkcionisanja sistema, tim za održavanje reaguje na probleme koji nastaju usled grešaka. Rešavanje tih problema je poznato kao korektivno održavanje. Tim za korektivno održavanje pronalazi uzrok otkaza i vrši korekcije i izmene u zahtevima, konstrukciji, kodu, testovima i dokumentaciji, već prema potrebi. Početna popravka je često privremena: nešto što održava sistem u radu, ali ne predstavlja najbolje rešenje. Trajne izmene mogu kasnije da se implementiraju, da bi rešile opštije probleme koji su posledica konstrukcije ili koda.
Na primer, korisnik može da pokaže uzorak izveštaja sa suviše mnogo odštampanih redova na stranici. Programeri utvrđuju da je problem rezultat neispravnosti u konstrukciji upravljačkog programa za štampač. Tim za korektivno održavanje postupa po hitnoj intervenciji i pokazuje korisniku kako da ponovo postavi broj redova po stranici podešavanjem parametra u meniju za izveštaj pre štampanja. Na kraju tim redizajnira, ponovo kodira i testira upravljački program štampača, da bi on radio ispravno bez intervencije korisnika.
Izmena uvedena u jednom delu sistema ponekad zahteva izmene u njegovim drugim delovima. Adaptivno održavanje je implementacija tih sekundarnih izmena. Na primer, pretpostavimo da se postojeći sistem za upravljanje bazom podataka, kao deo većeg hardverskog i softverskog sistema, nadograđuje novom verzijom. U tom procesu, programeri otkrivaju da rutine za pristup disku zahtevaju dodatni parametar. Adaptivne izmene učinjene da bi se uveo dodatni parametar ne ispravljaju greške. One samo dozvoljavaju sistemu da evoluira i da se prilagođava tokom te evolucije.
Slično tome, pretpostavimo da pojačavamo kompajler dodavanjem programa za otkrivanje i ispravljanje grešaka. Potrebno je promeniti menije, ikone ili funkcijske tastere da bismo dozvolili korisnicima da biraju opciju programa za otkrivanje i otklanjanje grešaka.
Adaptivno održavanje može da se primeni nakon izmena hardvera ili okruženja. Ako se sistem, inicijalno projektovan za rad u suvom, stabilnom okruženju, premesti u rezervoar ili podmornicu, neophodno ga je prilagoditi na kretanje, magnetne uticaje i vlažnost.
Kada održavamo sistem, ispitujemo dokumente, konstrukciju, kod i testove, tražeći moguća poboljšanja. Na primer, kada se dodaju nove funkcije, prvobitna, originalna konstrukcija zasnovana na tabelama odlučivanja može da postane konfuzna i teško se prati. Preprojektovanje na pristup na osnovu pravila može da poboljša proces održavanja u budućnosti i pojednostavi dodavanje novih funkcija. Održavanje radi usavršavanja obuhvata izmene koje poboljšavaju neki aspekt sistema, čak i kada one nisu posledica grešaka. Izmene u dokumentaciji radi pojašnjenja nekih delova, izmene u skupu testova da bi se poboljšali stepen obuhvatnosti testova i izmene koda i konstrukcije radi bolje čitljivosti su primeri održavanja radi usavršavanja.
Slično održavanju radi usavršavanja, preventivno održavanje obuhvata izmenu nekog aspekta sistema da bi se sprečili otkazi. Ono može da uključi dodavanje provere tipova, poboljšano rukovanje greškama, ili proširenje iskaza Case iskazom „catch-all", da bismo obezbedili da sistem opsluži sve mogućnosti. Preventivno održavanje obično nastaje kada programer ili analitičar koda pronade stvarnu ili moguću grešku koja još nije dovela do otkaza i preduzme akciju da ispravi grešku pre nego što ona prouzrokuje štetu.
Tim koji razvija sistem nije uvek onaj koji ga i održava nakon njegovog uvođenja u eksploataciju. Često se angažuje poseban tim za održavanje, čija je namena obezbeđenje ispravnog rada sistema. Razvojni tim je upoznat sa kodom, konstrukcijom i filozofijom na kojoj se on zasniva, kao i sa ključnim funkcijama sistema.
Ako su projektanti svesni da grade nešto što će oni održavati, tada će izgraditi sistem na način koji olakšava održavanje.
Međutim, ponekad projektanti imaju toliko poverenja u svoje razumevanje sistema da su skloni da ne ažuriraju dokumentaciju. Nebriga u pisanju i reviziji dokumentacije može da rezultira većim angažovanjem resursa i ljudi za rešavanje problema. Ta situacija dovodi do dugog intervala između trenutka kada se problem pojavi i trenutka njegovog rešavanja. Mnogi kupci neće tolerisati takvo kašnjenje.
Često se posebna grupa analitičara, programera i projektanata (ponekad uključujući jednog ili dva člana razvojnog tima) promoviše u tim za održavanje. Svež, novi tim može da bude objektivniji od prvobitnih projektanata. Poseban tim može da otkrije da je lakše razlikovati šta bi sistem trebalo da radi od toga kako to sistem radi. Ako znaju da će drugi raditi na osnovu njihove dokumentacije, projektanti su skloni da budu pažljiviji kada je u pitanju dokumentovanje i primena standarda programiranja.
Održavanje sistema uključuje sve članove tima. Korisnici, operateri ili predstavnici kupca obično pristupaju timu za održavanje sa nekim komentarom ili problemom. Analitičari ili programeri određuju na koje delove koda se problem odnosi, njegov uticaj na dizajn i verovatne resurse (uključujući vreme i rad) neophodne za realizaciju izmene. Tim se bavi mnogim aktivnostima, kao što su:
Pored toga, članovi tima za održavanje rade sa korisnicima, operaterima i kupcima. Prvo, oni pokušavaju da shvate problem iskazan jezikom korisnika. Nakon toga se problem transformiše u zahtev za izmenu. Zahtev za izmenu sadrži opis sadašnjeg načina rada, načina na koji korisnik želi da sistem radi i koje su izmene neophodne za tu izmenu. Kada se konstrukcija ili kod jednom modiflkuju i testiraju, tim za održavanje ponovo obučava korisnika, ako je to potrebno. Dakle, održavanje uključuje interakciju sa ljudima, kao i sa softverom i hardverom.
Postoje različiti izveštaji o tome na koje vrste održavanja odlazi najviše serviserskog vremena. Linc i Svanson su pratili rad izvršilaca u 487 organizacija za obradu podataka i otkrili raspodelu poslova po vrstama održavanja prikazanu na slici 1. Najveći rad ulaže se u adaptivno održavanje i održavanje radi usavršavanja. Slične podele su pokazala i druga istraživanja istog tipa. Raspodela vremena za datu organizaciju zavisi od više činilaca, uključujući i da li je sistem tipa S, P ili E i koliko brzo se poslovanje menja.
Slika1. Raspodela rada na održavanju