U ovoj lekciji obrađivaćemo:
Jedan od načina da se smanji rad u procesu održavanja jeste da se kvalitet ugradi od samog početka. Pokušaj da se dobra konstrukcija i struktura sprovede na već izgrađenom sistemu manje je uspešan od pravilne gradnje sistema od početka. Međutim, pored dobre prakse, postoji više drugih tehnika koje podižu razumljivost i kvalitet.
Prema tradicionalnom shvatanju životnog veka softvera, održavanje počinje po završetku razvoja softvera. Međutim, održavanje softvera zavisi od korisničkih zahteva i počinje još sa njima. Prema tome, principi razvoja dobrog softvera primenjuju se i na proces razvoja i na proces održavanja. S obzirom na to da razvoj dobrog softvera podržava njegovu izmenu, o njoj treba razmišljati u toku celog životnog veka softverskog proizvoda. Štaviše, naizgled minorna izmena je često obimnija (i zato skuplja za implementaciju) nego što se to očekuje. Analiza uticaja je procena stepena rizika u vezi sa promenom, uključujući procenu uticaja na resurse, rad i vremenske rokove.
Efekti mnogostrukih izmena u sistemu mogu da se vide u neodgovarajućoj ili zastareloj dokumentaciji koja nastaje u nepravilno ili nepotpuno popravljanom softveru, loše strukturisanom dizajnu ili kodu, arftefaktima koji ne podležu standardima i još mnogo čemu. Problem je mešavina usložnjavanja, dužeg vremena potrebnog da bi projektanti razumeli kod koji je pretrpeo izmene i više sporednih uticaja koje izmene mogu da imaju na druge delove sistema. Ti problemi povećavaju troškove održavanja, a rukovodstvo bi želelo da te troškove drži pod kontrolom. Analizu uticaja možemo da koristimo da bismo podržali upravljanje troškovima održavanja.
Pfleeger i Bohner su istraživali načine za merenje uticaja koji predložena izmena ima na razne aspekte softvera da bi odredili rizike i odmerili različite opcije. Oni opisuju model održavanja softvera koji uključuje merenje povratne sprege. Na slici 1 ilustrovane su aktivnosti koje se izvode kada se zahteva izmena, a natpisi uz strelice u donjoj polovini dijagrama predstavljaju merenja koja daju informacije koje menadžeri mogu da koriste pri donošenju odluke kada i kako da se napravi izmena.
Produkt je svaki artefakt razvoja čija izmena je značajna. Dakle, zahtevi, konstrukcija i komponente koda, test slučajevi i dokumentacija su proizvodi rada. Kvalitet jednog od njih može da utiče na kvalitet ostalih, pa njihova izmena može da ima značajne posledice. Uticaj izmene možemo da procenimo za sve produkte. Za svaki od njih, vertikalna pratljivost izražava odnose između delova proizvoda. Na primer, vertikalna pratljivost opisuje međusobne zavisnosti zahteva i sistema. Horizontalna pratljivost bavi se odnosima komponenti u kolekciji produkata. Na primer, svaka komponenta konstrukcije prati se do nivoa komponenti koda koje implementiraju taj deo konstrukcije. Obe vrste pratljivosti su potrebne za razumevanje potpunog skupa odnosa u postupku analize uticaja.
Slika 1. Aktivnosti održavanja softvera
I horizontalnu i vertikalnu pogodnost za praćenje možemo da prikažemo koristeći usmerene grafove. Usmereni graf je jednostavno zbirka objekata koji se zovu čvorovi i pridružena zbirka uređenih parova čvorova, koji se zovu grane. Prvi čvor grane zove se čvor izvor, a drugi je čvor određište. Čvorovi predstavljaju informacije koje se nalaze u dokumentima, člancima i drugim artefaktima. Svaki artefakt sadrži čvor za svaku komponentu. Na primer, možemo da predstavimo projekat kao zbirku čvorova, sa po jednim čvorom za svaku komponentu konstrukcije, a specifikaciju zahteva tako da ima po jedan čvor za svaki zahtev. Usmerene grane predstavljaju odnose unutar jednog produkta i između produkata.
Na slici 2 ilustrovano je kako se određuju grafički odnosi i pratljive veze između odgovarajućih produkata. Ispitujemo svaki zahtev i crtamo vezu izmedu zahteva i komponenti konstrukcije koje ga implementiraju. Zatim, povezujemo svaku komponentu konstrukcije sa komponentama koda koje je implementiraju. Najzad, povezujemo svaki modul koda sa skupom slučajeva za testiranje. Povezanost koja se tako dobije formira graf koji prikazuje odnose između produkata.
Slika 2. Horizontalna pratljivost u softverskim proizvodima rada
Na slici 3 prikazano je kako bi mogao da izgleda graf ukupne pratljivosti. Svaki artefakt glavnog procesa (zahtevi, konstrukcija, kod i test) prikazan je kao pravougaonik oko konstitutivnih čvorova. Pune grane unutar svakog pravougaonika su odnosi vertikalne pratljivosti komponenti u pravougaoniku. Isprekidane grane između pravougaonika prikazuju veze horizontalne pratljivosti u sistemu.
Slika 3. Prateći graf održavanja
Postoji više dokaza da su neke mere složenosti dobri indikatori potrebnog rada i učestalosti grešaka. Ti pojmovi mogu da se prošire na karakteristike grafa pratljivosti, da bi se procenio uticaj predložene izmene. Uzmimo, na primer, graf vertikalne pratljivosti unutar svakog pravougaonika na slici 3. Ukupan broj čvorova, broj grana čije je odredište u čvoru (ulazni stepen čvora) i grana čiji je izvor u čvoru (izlazni stepen), zatim mere kao što je ciklomatski broj, mogu da se izračunaju pre i posle izmene. Ako izgleda da se veličina i složenost grafa sa izmenom povećavaju, verovatno je da će se veličina i složenost odgovarajućih produkata takođe povećavati. Koristeći tu informaciju, odbor za upravljanje konfiguracijom može da odluči da implementira izmenu na drugačiji način, ili da to uopšte ne radi. Čak i ako rukovodstvo odluči da uvede predloženu izmenu, rizik koji ide uz nju može bolje da se razume pomoću slike zasnovane na merenjima.
Mere vertikalne pratljivosti su one mere proizvoda koje pokazuju dejstvo izmene na svaki produkt koji se održava. Izmerene karakteristike na grafu horizontalne pratljivosti daju procesni pogled na izmenu. Za svaki par produkata, možemo da formiramo podgrafove sledećih odnosa: prvi podgraf sa odnosima između odgovarajućeg zahteva i konstrukcije, drugi sa odnosima između odgovarajuće konstrukcije i koda, i treći koji pokazuje odnose između koda i test slučajeva.
Nakon toga merimo veličinu i složenost da bismo odredili veličinu štetnosti uticaja. Možemo da sagledamo ukupnu horizontalnu pratljivost da bismo videli da li ukupna pratljivost posle izmene postaje otežana ili olakšana. Pfleeger i Bohner su tražili minimalni skup putanja koje obuhvata taj graf. Ako se broj putanja povećava posle izmene, onda će sistem verovatno biti nezgrapniji i teži za održavanje. Slično tome, ako se ulazni i izlazni stepeni značajno povećaju, sistem će se u budućnosti teže održavati.
Praćenje statusa svih komponenti i testova je veliki posao. Postoji više automatizovanih alata koji nam pomažu u održavanju softvera. Ovde opisujemo neke vrste takvih alata.