odrzavanje softvera

7/27/2019 Odrzavanje softvera

1/76

DRAVNI UNIVERZITET U NOVOM PAZARUFAKULTET TEHNIKIH NAUKA

AVDOVI Azra

ODRAVANJE SOFTVERA

-diplomski rad-

Novi Pazar, 2013


2/76

Odravanje softvera Avdovi Azra, 02-514/08

Novi Pazar, 2013 2

Sadraj

1 UVOD U SOFTVERSKI ININJERING .......................................................................... 5

1.1 OSNOVNI POJMOVI I DEFINICIJE SOFTVERSKOG ININJERINGA.........................................5

1.2TIPINE FAZE SOFTVERSKOG ININJERINGA ...................................................................... 5

2 ODRAVANJE SOFTVERA .............................................................................................. 7

2.1OSNOVE ODRAVANJA SOFTVERA ..................................................................................... 7

2.2KANDIDATIZAREDIZAJNSOFTVERA ........................................................................ 10

2.2.1 esti sistemski otkazi .............................................................................................. 102.2.2 Kodovi stari vie od pet godina .............................................................................. 112.2.3 Previe kompleksne programske strukture i logiki tokovi..................................... 112.2.4 Kodovi pisani za prethodnu generaciju hardvera .................................................. 11

2.2.5 Sistemi koji rade po principu emulacije.................................................................. 122.2.6 Veoma veliki moduli ili podrutinske jedinice .......................................................... 12

2.2.7 Prekomerna zahtevanja resursa ............................................................................. 12

2.2.8 Tvrdo-kodirani parametri su subjekti za izmenu .................................................... 12

2.2.9 Podrka nisko-nivojskim jezicima ........................................................................... 132.2.10 Ozbiljni manjak dokumentacije............................................................................. 13

2.2.11 Fluktuacija znanja strunjaka............................................................................... 132.2.12 Nedostatak ili nekompletnost specifikacija za dizajn ............................................ 13

2.2.13 Zastarjela tehnologija ........................................................................................... 13

2.2.14 Obim testiranja u odnosu na veliinu izmena....................................................... 142.2.15 Neadekvatna test dokumentacija........................................................................... 14

3 VRSTE ODRAVANJA .................................................................................................... 14

3.1KATEGORIJE ODRAVANJA SOFTVERA............................................................................. 15

3.1.1 Korektivno odravanje softvera .............................................................................. 163.1.2 Adaptivno odravanje softvera ............................................................................... 183.1.3 Perfektivno odravanje softvera ............................................................................. 183.1.4 Preventivno Odravanje Softvera i Problem 2000 Godine..................................... 19

3.2AKTIVNOSTI ODRAVANJA .............................................................................................. 20

4 KLJUNI ASPEKTI SOFTVERSKOG ODRAVANJA ............................................. 21

4.1TEHNIKI ASPEKTI .......................................................................................................... 21

4.1.1 Ogranieno razumevanje ........................................................................................ 214.1.2 Analiza uticaja ........................................................................................................ 21

4.1.3 Lakoa odravanja.................................................................................................. 224.2MENADMENT ASPEKTI................................................................................................... 22

4.2.1. Usaglaavanje sa organizacionim ciljevima ......................................................... 224.2.2 Osoblje .................................................................................................................... 22

4.2.3 Organizacioni aspekti odravanja .......................................................................... 23


3/76


Novi Pazar, 2013 3

4.2.4 Usluge treih lica Outsourcing ............................................................................. 234.3PROCENA TROKOVA ...................................................................................................... 23

5 ANALIZA PROBLEMA ODRAVANJA ....................................................................... 24

5.1PERSONALNI PROBLEM .................................................................................................... 24

5.1.1 Ogranieno razumevanje ........................................................................................ 245.1.2 Prioriteti menadmenta........................................................................................... 255.1.3 Moral....................................................................................................................... 25

5.2TEHNIKI PROBLEMI ....................................................................................................... 25

5.2.1 Artefakti i paradigme .............................................................................................. 26

5.2.2 Tekoe sa testiranjem ............................................................................................ 265.3POTREBA ZA KOMPROMISOM........................................................................................... 26

6 TEHNIKE ODRAVANJA SOFTVERA ........................................................................ 28

6.1PODMLAIVANJE SOFTVERA ........................................................................................... 286.2REDOKUMENTOVANJE..................................................................................................... 29

6.3REVERZNI INENJERING .................................................................................................. 30

6.4REINENJERING............................................................................................................... 32

7 PROJEKAT PISA ............................................................................................................... 34

7.1CILJEVI TESTIRANJA ........................................................................................................ 35

7.2OPIS FUNKCIJA PISA-E:PROCES, ORGANIZACIJA, KOMPONENTE I ALATI ZA ODRAVANJESOFTVERA ............................................................................................................................. 36

7.3OPIS OQTMAINT FUNKCIJE.......................................................................................... 38

7.3.1 IOP Maintenance Engine ........................................................................................ 39

7.3.2 Defect Menagement Engine (Ureaj za upravljanje grekama)............................. 407.3.2.1 Proces upravljanja grekom ............................................................................. 41

7.3.3 Reliability eXpert (maina za Pouzdanost)............................................................. 437.3.4 Estimator eXpert ..................................................................................................... 45

7.4MODEL IVOTNOG CIKLUSA PISA-E ............................................................................... 47

7.4.1 W-model .................................................................................................................. 47

8 ESTIMACIJA TROKOVA ODRAVANJA: PRIMER U OQT MAINT REENJU.................................................................................................................................................. 49

8.1UDEO ODRAVANJA U UKUPNIM TROKOVIMA IVOTNOG CIKLUSA SOFTVERA ............... 49

8.1.1 Funkcija produkcije odravanja softvera ............................................................... 508.1.2 Distribucija napora za odravanje softvera po delatnostima................................. 51

8.2AKTIVNOSTI ODRAVANJAI TROKOVI ........................................................................... 53

8.2.1MERENJE FUNKCIONALNIH TAAKA............................................................................. 53

8.2.2 Izraunavanje broja linija koda .............................................................................. 568.3CAPERS JONES-OVA PRAVILA .......................................................................................... 57

8.4 Nominalne podrazumevane vrednosti za aktivnosti odravanja................................ 608.4.1 Popravke Kvara ...................................................................................................... 61


4/76


Novi Pazar, 2013 4

8.4.2 Moduli skloni greci................................................................................................ 638.4.3 Podrka korisnicima ............................................................................................... 638.4.4 Restruktuiranje koda ............................................................................................... 64

8.4.5 Migracije kroz platforme ........................................................................................ 64

8.4.6 Konverzija u nove arhitekture ................................................................................. 648.4.7 Obavezne promene .................................................................................................. 64

8.4.8 Optimizacija performansi ....................................................................................... 65

8.4.9 Proirenja ............................................................................................................... 65

9 PRIMER: ESTIMACIJA ODRAVANJA SOFTVERA ZA NASTAVU .................... 65

9.1OPIS SOFTVERA ZA UENJECOURSEWARE.................................................................... 659.2 Organizaciono planiranje ......................................................................................... 66

9.3TEHNIKE ESTIMACIJE ODRAVANJA................................................................................. 67

9.4 Dekompozicija faze razvoja ....................................................................................... 68

9.5 Upotreba istorijskih podataka ................................................................................... 689.6 Faktori prilagoavanja trokova ............................................................................... 70

10 ZAKLJUAK................................................................................................................... 73

LITERATURA ....................................................................................................................... 74


5/76


Novi Pazar, 2013 5

1 Uvod u softverski ininjering

1.1 Osnovni pojmovi i definicije softverskog ininjeringa

Termin softverski ininjering odnosi se na sistematsku proceduru koja se koristi ukontekstu opte prihvaenog seta ciljeva za analizu, dizajn, implementaciju, testiranje iodravanje softvera. Softverski proizvod treba da bude efikasan, pouzdan, da se moekoristiti, modifikovati, prenositi, testirati, ponovo koristiti, odravati, koristiti u drugimsoftverima i ispravljati. Ovi termini odnose se kako na softverske sisteme tako i na njihove

komponente. Mnogi od ovih termina su samoobjanjavajui; meutim radi kompletnosti mi uovom diplomskom radu dajemo i njihove definicije.

Efikasnost: Softver se proizvodi u oekivanom vremenu i u okviru obezbeenih resursa kojisu na raspolaganju. Softver koji se proizvodi treba da radi u okviru oekivanog vremena zarazliita izraunavanja koja treba da se zavre. Pouzdanost: Softver treba da funkcionie kao to se oekuje tokom zadatog vremena ili

broja misija koje treba da izvri bez otkaza. U multi-korisnikim sistemima obavlja svojefunkcije bez obzira na druga optereenja sistema. Upotrebljivost: Softvermora biti jednostavan za korienje. Ovo se obino odnosi na lakouupotrebe od strane korisnika, ali se takoe bavi i primjenjivou softvera kako naoperativnom sistemu tako i korisnikim funkcijama i aplikativnom okolinom. Izmjenjivost: Softver treba da bude tako projektovan da se moe lako promijeniti ako semijenjaju zahtjevi sistema.

Prenosivost: Softverski sistem treba da se prenosi na druge kompjutere ili sisteme bez veihizmjena softvera. Softver koji treba samo da se rekompajlira da bi pravilno radio na novoj

maini smatra se veoma prenosivim. Mogunost testiranja: Softver treba da se lako testira. Ovo znai da je softver pisan namodularni nain.Ponovna upotreba: Neki ili svi softveri treba da bude tako projektovani da se mogu koristiti

ponovo u drugim projektima. Ovo znai da je softver modularan, da svaki individualnisoftverski modul ima jasno definisan izlaz nakon njegovog izvrenja. Ovo esto znai da

postoji znaajan nivo apstrakcije i optosti u modulima koji e se ponovo koristiti. Odravanje: Softver treba da bude tako projektovan da se lako razumije i mijenja svremenom, ako se jave problemi. Ovaj termin se esto koristi da opie ivotni ciklusdugotrajnih sistema, kao to su npr. Softveri za upravljanje avionskim saobraajem, koji moraraditi decenijama.

Interoperabilnost: Softverski sistem treba da jednostavno radi u interakciji sa drugimsoftverskim sistemima. Ovo se moe odnositi na softver na jednom kompjuteru ili na softverkoji se koristi u mrei. Tanost: Program (Softver) treba da proizvodi taan izlaztj. sa unapred zadatom tanou,odnosno dozvoljenom grekom.

1.2 Tipine faze softverskog ininjeringa

Postoje nekoliko faza koji su deo svakog projekta softverskog inenjeringa: Analiza problema


6/76


Novi Pazar, 2013 6

Izrada zahteva Dizajn softvera Kodiranje softverskog reenja Testiranje i integracija koda Instaliranje i isporuka softvera

Dokumentacija softvera Odravanje Osiguranje kvaliteta Obuka Procena resursa Projektni menadment

Analiza problema se veoma esto izvodi od strane eksperata za odreeno podruje prim ene.Moramo obratiti panju da se ove faze obino ne izvode u vakumu. Umesto toga one seizvode kao deo organizovanih sekvenci aktivnosti poznatih kao ivotni ciklus softveraorganizacije.

Za sada se podrazumeva da svaka softverska razvojna organizacija ima svoj vlastiti iindividualni softverski ivotni ciklus u kome je redosled ovih aktivnosti specificiran.

Faza izrade zahteva organizacijskog softverskog ivotnog ciklusa ukljuuje preciznoodreivanje ta e biti funkcije softverskog sistema. Ako postoji jedan korisnik ili setkorisnika koji su unapred poznati, onda e faza izrade zahteva traiti znaajnu diskusijuizmeu korisnika i zahteva koje daju specijalisti u softverskom timu. Ovaj scenario bi semogao primenjivati na proces razvijanja softvera za kontrolu leta aviona. Ako ne postoji

korisnik koji se direktno identifikuje, nego potencijalni set individualnih korisnika, onda

mogu da se koriste drugi metodi kao to su analize trita i testiranje preferencije. Ovajpristup moe biti odgovarajui za razvoj softvera za internet.

Faza dizajna omoguuje prevoenje zahteva u izvorni kod. Softverski dizajner mora imatiiskustvo u metodologiji dizajna i u odreivanju trokova alternativnog dizajna. Dizajner moraznati karakteristike softverskog sistema kao to su baze podataka, operativni sistemi,korisniki grafiki interfejsi ili korisniki programi koji mogu pomoi u eventualnom procesukodiranja.

Aktivnost kodiranja je najblia studentima i ne treba je detaljno objanjavati. Meutim,mnoge odluke o kodiranju objektno orijentisanih ili proceduralnih jezika mogu se odloiti doove take u ivotnom ciklusu ratvoja softvera ili su moda napravljene namerno ili u fazi

izrade zahteva. Softverski inenjer- poetnik se verovatno moe prikljuiti testiranju iliodravanju softvera.

Softversko testiranje je aktivnost koja najee poinje poto je softver kreiran, ali mnogoranije nego to je spreman da se predstavi korisnicima. esto je ukljuen u fazu softverskeintegracije koja predstavlja proces kombinovanja odvojenih softverskih modula u veesoftverske sisteme.

Faza softverske integracije, takoe, esto zahteva integraciju prethodnih softverskih sistemada bi se napravili vei.Dokumentacija softverskog proizvoda ukljuuje mnogo vie od prostog komentarisanjaizvornog koda. Ona ukljuuje obrazloenja dizajna koji je zahtevan na osnovu dokumenta:


7/76


Novi Pazar, 2013 7

specifikacija ili zahtevi za izradu softvera, datoteke za pomo (help- fajlove), korisnikeprirunike, prirunike za obuku, tehnike vodie kao to su prirunici za programiranje iprirunici za instalacijui odravanje softvera. ak i interna dokumentacija izvornog koda jemnogo sadrajnija nego to izgleda programeru- poetniku. Nije neobino da fajl izvornogkoda ima dvaput vie dokumentacionih linija i komentara od aktuelnog koda.

Poto je softver dizajniran, kodiran, testiran i dokumentovan, on se mora isporuiti iinstalirati.

Termin softversko odravanje se koristi da opie one aktivnosti koje su obavljene poto jesoftver puten u promet. Odravanje ukljuuje isprvljanje greaka koje su naene u softveru;

premetanje softvera u nove okoline, kompjutere i operativne sisteme; omoguavanjesoftveru da povea funkcionalnost i performanse; i tako dalje. Za mnoge softverske sistemeodravanje je najskuplji zadatak koji zahteva najvie vremena u ivotnom ciklusu razvojasoftvera.

Naravno, sve ove aktivnosti moraju biti sistemski postavljene i koordinirane. Projekt

menadment po pitanju odravanja softvera je moda najkritinija aktivnost u softverskominenjeringu.Osiguranje kvaliteta, ili QA, bavi se utvrivanjem da softverski produkt koji se proizvede i

proces kojim je softver razvijen odgovara zahtevanim standardima kvaliteta. QA tim je estoodgovoran za poboljavanje standarda kvaliteta. U mnogim organizacijama QA tim jeodvojen od ostatka softverskog razvojnog tima. Naglaava se da se kvalitet ne moe dodati

blizu kraja razvoja softverskog projekta. Umesto toga kvalitet mora biti rezultat kompletnog

inenjerskog procesa koji se koristi za kreiranje softvera.

Uzimajui u obzir prethodno istaknut znaaj odravanja softvera u softverskom inenjerstvuu diplomskom radu treba opisati mesto, ulogu, ciljeve kao i kompletan proces Odravanjesoftvera. Opisati modele koji se koriste za Odravanje softvera u fazi planiranja,

projektovanja i nakon isporuke softverskog proizvoda sa posebnim osvrtom na:

1) Definicije pojmova, modele i aktivnosti Odravanje softvera.2) Analizu odgovarajuih reenja Odravanje softvera u praksi poznatih kompanija npr. IBM,HP, MICROSOFT i druge kompanije.

3) Opisati na konkretnom primeru softverskog proizvoda : a) zahteve za kvalitetom (broj

procenjenih softverskih greaka, tehnike otkrivanja i uklanjanja greaka tokom razvojasoftvera, broj isporuenih greaka i sl.), b) organizaciju procesa odravanja softvera ukompaniji i c) trokove Odravanje softvera.

2 Odravanje softvera

U ovom poglavlju razmatraemo deo procesa softverskog inenjeringa koji se odvija poto jesoftver isporuen. Moda e vas iznenaditi injenica da za mnoge dugotrajne sisteme cenaodravanja softvera iznosi vie od 75% ukupne cene softvera tokom njegovog veka trajanja.

2.1 Osnove odravanja softvera

Na prvi pogled izgleda udno da se termin odravanje odnosi na softver. Najzad, softverse ne troi na nain kako to ine kompjuteri pri paljenju i gaenju, odnosno, kako se troe


8/76


Novi Pazar, 2013 8

elektro-mehaniki delovi sistema. Medij na kome je softver pohranjen moe se menjati svremenom zbog promena na magnetnim esticama koje se istroe sa povrine diska ili trakeili savijanjem diska. Paljivi sistemski administratori uvae kopije svih osnovnih softvera (ikorisnikih fajlova), najbolje na izdvojenim lokacijama da bi izbjegli probleme sa vatrom i

poplavama.

Takoe uzmite u obzir da softver ne moe da ra ili da se oteti zato to je prljavtina ulaizmeu elektrinih spojeva. Glavne promene na napajanju kompjutera (110V, 60Hz u USA;220V, 50Hz u EVROPI) ne utiu na softver. Naravno, smanjenje napona moe da imauticaja, ali ovi problemi su dobro poznati. Oprezni administratori kompjuterskog sistema

koriste kombinaciju elektrinih zatitnih kola, podesivih izvora energije i neprekidnognapajanja da omogue odgovarajui, zahtevani nivo usluge. Ovi problemi su jasno povezanisa hardverom i ne predstavljaju nikakav problem za softverske inenjere.

Pouzdanost hardverskih sistema uglavnom prati poznatu krivu kade otkaza (Sl.2.1).Relativno visok broj nedostataka na poetku rada hardvera je uglavnom zbog tri faktora:

komponente koje otkazuju, greaka u instalaciji ovih komponenti i neodgovarajuoj upotrebiod strane neiskusnog operatora. Povean broj otkaza na desnoj strani grafika predstavljagreke koje se javljaju pri kraju veka trajanja hardvera uzrokovane pojaanim otkazivanjemkomponenti.

Sl.2.1 Intenzitet otkaza u ivotnom veku hardverskih sistema1

Odravanje hardvera je drugaije od njegovog testiranja. Na primer, oekujete da je nov autokoji ste skoro kupili sastavljan od strane eksperata koji koriste visoko kvalitetne delove i

podsisteme (kao to su oni za elektronske i koione operacije) testirane na sigurnost. Takoe,auto je trebalo imati i druge, osnovne, preglede kada je odveeno sa proizvodne linije i kadaje stiglo u izlobeni prostor. Ove aktivnosti se smatraju aktivnostima testiranja.

Odgovarajue odravanje hardvera ukljuuje odravanje istoe sa posebnim naglaskom napokretne delove, zamenu otkazalih komponenti i optim planiranjem zamene komponentikoje su stare, nedostajue, imaju greku ili postoji rizik od skorog otkaza. Analiza cena/dobittreba da se izvede da bi se odredilo da li je trud odravanja neophodan i predstavlja cilj

1M. Dorfman and R.H. Thayer, eds., Software Engineering (Vol. 1 & Vol. 2), IEEE Computer Society Press,

2002.


9/76


Novi Pazar, 2013 9

organizacije. Iznenaujue, ovaj prilaz je takoe dobar nain da se analizira softverskoodravanje.

Softversko odravanje moglo bi se opisati kao sistematski proces menjanja softvera koji jouvek radi, tako da se postigne prevencija sistemskih otkaza i da se poboljaju performanse.

Softversko odravanje ukljuuje dranje softverskog interfejsa prostim i standardnim,poklanjajui posebnu panju problematinim modulima, zameni neispravnih komponenti ioptim planiranjem za promenu komponenti koje su stare, funkcionalno zastarele i rizine pomogui otkaz. Procena trajanja preostalog ivotnog veka softvera takoe se mora uzeti uobzir pri odreivanju da li odravanje vredi dodatnih trokova.

Postoji nekolikofaktora2 koji zahtevaju da se softver odrava:

1. Hardverska platforma se menja ili postaje zastarela.

2. Operativni sistem se menja ili postaje zastareo.

3. Kompajler se menja ili postaje zastareo.

4. Softverski jeziki standardi se menjaju ili postaju zastareli.5. Komunikacioni standardi se menjaju ili postaju zastareli.

6. Grafiki interfejsi (GUI) se menjaju ili postaju zastareli.7. Spektar namene softverskih paketa se menjaju ili postaju zastareli.

8. Veze sa proizvoaima drugih aplikacija ili sistemskih softvera se menjaju.9. Softver moe biti defektan, a to postaje oigledno tek kada ga korisnik upotrebi. Ovidefekti moraju biti opravljeni.

10. Korisnici trae nove funkcionalne i nefunkcionalne (brzina, resursi, pouzdanost,bezbednost i sl.) karakteristike.

11. Softver mora biti poboljan da moe da se poredi sa novim konkurencijinim proizvodom.12. Postojee softverske greke moraju se spreiti primenom preventivnih mera za sluajnovog putanja u rad.

Ovi faktori moraju biti podeljeni u nekoliko razliitih grupa: Faktori od 1 do 9 mogu bitiklasifikovani kao faktori za adaptivno odravanje, i oni se koriste da se softver prilagodinovoj tehnologiji. Faktori od 10 do 11 mogu biti klasifikovani kao faktori za perfektivnoodravanje, i oni se koriste da softver bude korektiniji pod novim uslovima, u smislu da imato manje greaka. Termin perfekcionistiko odravanje se takoe koristi u ovom sluaju.Faktor 12 moe biti klasifikovan kao faktor za preventivno odravanje, i on se koristi dasmanji mogunost nastajanja greke na softveru.

Meutim postoji i zajednika nit. Bitan korak u svim tipovima softverskog odravanja jerazumevanje softverskog sistema koji odravamo. Pre nego to serviser pone da menjasoftver da bi ispravio problem ili ga okarakterisao, mora razumeti softver u celini, ali i

odreene module koji moraju biti modifikovani. Mnogi eksperimenti su pokazali darazumevanje programa, to ukljuuje razumevanje softverskih zahteva i dizajna, oduzimaotprilike pola napora na odravanju softvera.Razliiti prilazi softverskom odravanju e biti obraeni u ostatku ovog poglavlja. Meutimtreba imati na umu da nita u ivotu nije besplatno i svako odravanje softvera mora bitifinansirano kao deo sofverskog budeta organizacije.

2IEEE Std 1219-1998, IEEE Standard for Software Maintenance, IEEE, 1998.


10/76


Novi Pazar, 2013 10

Opisaemo tipian prilaz procesu odravanja softvera koji podrazumeva dve radnje:odreivanje gdje je problem nastao i njegovu opravku.

Mnogi problemi u softveru mogu se pronai na neki od ovih naina:

Neprivrenost softvera razvojnim standardima. Ovi problemi ukljuuju lo interfejs izmeumodula, kao to je prosleivanje pogrenog broja ili tipa argumenta funkcijama. Logike greke u programskim modulima, kao to su petlje, ravanje ili nekonzistentnastanja programa.

Neusklaenost izmeu zahteva, dizajna, koda i dokumentacije informacionog sistema.

Nakon faktora koji govore u kom sluaju se softver treba odravati na ovakav ili onakavnain, naveemo i neke tipine probleme koji ukazuju na potrebu redizajna softvera, odn.izrade novog.

2.2 KANDIDATI ZA REDIZAJN SOFTVERA

Mada je odravanje jedan neprekidan proces, ozbiljno razmatranje mora, eventualno, biti datoredizajniranju softverskog sistema. Glavna briga je kako odrediti da li je sistem nepovratno

otkazao ili se moe uspeno opraviti i odravati. Grupe za testiranje koje rade sa softveromsvo vreme treba da posmatraju opte stanje softvera i kada bude neophodno preporue da jesoftver bolje redizajnirati nego ga nastaviti korektivno odravati. Trokovi i povoljnostinastavka odravanja softvera kada postane sklon grekama, neefikasan i skup, moraju bitivagani sa onima za redizajniranje sistema ak i kada redizajniranje nije najbolje reenje.

Odluka o redizajniranju ili o zaustavljanju odavanja sistema moe biti izvrena na nekolikonaina. Podrka moe jednostavno biti uklonjena i dozvolie se da sistem postane zastario inekoristan; Mora se obezbijediti minimum podrke neophodne za funkcionisanje sistema doknovi sistem ne bude izgraen; ili sistem moe biti podmlaivan sektor po sektor, ime mu se

produava ivotni vek. Kako e se redizajn pokazati, zavisi od individualnih okolnostisistema, njegovog operativnog okruenja i potreba organizacije koja ga podrava.

Mada ne postoje apsolutna pravila kada je bolje redizajnirati sistem nego odravati postojei,neki faktori koji se uzimaju u obzir su razatrani u ovom odeljku. Glavni pokazatelji za

redizajn, suprostavljeni nastavku odravanja, direktno su proporcionalni broju karakteristikaizlistanih u narednim odeljcima. to je vei broj karakteristika, vei su pokazatelji za

redizajn.

3

2.2.1 esti sistemski otkazi

Aplikacija kojoj praktino stalno treba korektivno odravanje je kandidat za redizajn. Sastarenjem sistema potrebno je dodatno odravanje, sistem postaje sve nepostojaniji i osjetljivna promene. to stariji kod, sve su potrebnije modifikacije, novi zahtevi i proirenja moguizazvati pad sistema.

3Osnove odravanja softvera i virusi, doc. dr. Marinko Aleksi dipl.in., 2009
http://www.slideshare.net/marinkohttp://www.slideshare.net/marinkohttp://www.slideshare.net/marinko


11/76


Novi Pazar, 2013 11

Greke treba analizirati da bi se odredilo da li je ceo sistem odgovoran za otkaze ili suodgovorni neki moduli ili su delovi koda pogreni. Ako je ovo drugo krivac za otkaze ondae redizajniranje samo tih delova biti dovoljno.

2.2.2 Kodovi stari vie od pet godina

Predvieni ivotni ciklus velikog dela aplikacija je 3-5 godina. Pogoranje karakteristikasoftvera sa godinama je rezultat brojnih opravki i krpljenja. Ako je sistem starvie od petgodina, verovatno je zastareo i preskup za rad, ovo je stanje veine kdova koji su sada uupotrebi. Posle pet godina odravanja, mnogi sistemi su dovedeni do take kada dodatno

proirenje i opravke postaju vremenski vrlo duge. Deo kdova je verovatno loe struktuiranili loe napisan.Meutim kdovi koji su tani i adekvatni za originalno okruenje, promene u tehnologiji iaplikacijama mogu napraviti neefikasnim, tekim za proveru i u nekim sluajevimazastarelim. Meutim aplikacije koje su dizajnirane i razvijane sistemski, na nain lak za

odravanje, i ako je odravanje izvoeno paljivo i dokumentovano u skladu sauspostavljenim standardima i po direktivama, mogue je da rade efikasno i efektivno jomnogo godina.

2.2.3 Previe kompleksne programske strukture i logiki tokovi

Odrati jednostavnost trebalo bi biti zlatno pravilo svih standarda i putokaza uprogramiranju. Preesto programeri pokuavaju da piu delove kdova upotrebljavajuinajmanji broj iskaza ili zauzimajui najmanji mogui memorijski prostor. Ovaj prilazkodiranju je rezultirao kompleksnim, praktino nerazumljivim kdom. Siromana

programska struktura doprinosi kompleksnosti. Ako sistem sadri veliki deo kdova ovogtipa i dokumentacija je esto oskudna- on je kandidat za redizajn.

Kompleksnost se takoe odnosi na nivo donoenja odluka u kdu. to vei broj grananja(mogunost) odluke, kompleksniji e biti softver. Takoe to je vei broj linearno nezavisnihkontrolnih grana u programu vea je kompleksnost programa. Programi sa nekim ili svimnabrojanim karakteristikama su obino veoma teki za odravanje i kandidati su za redizajn: Preterana upotreba DO koraka Preterana upotreba IF iskaza Nepotrebni GOTO iskazi Ugraivanje konstanti i literala Nepotrebna upotreba globalnih promenjivih Samo-promenjivi kd Mnogostruki ulazni ili izlazni moduli Preterana interakcija izmeu modula Upotreba modula koji izvravaju iste ili sline funkcije

2.2.4 Kdovi pisani za prethodnu generaciju hardvera

Samo par industrija ima iskustvo sa tako brzim rastom kao kompjuterska industrija, naroitou oblasti hardvera. Ne samo da postoji znaajno tehnoloko napredovanje, ve je i cena


12/76


Novi Pazar, 2013 12

hardvera desetostruko opala tokom zadnje decenije. Ovaj fenomen je generisao raznovrsne

snane hardverske sisteme. Softver pisan za stariju generaciju hardvera je esto neefikasan unovijim sistemima. Pokuaji da se kdovi povrno modifikuju da dostignu noviji hardver sugeneralno uzaludni, skupi i dugotrajni.

2.2.5 Sistemi koji rade po principu emulacije

Svaki softverski proizvod ne moe bez odgovarajueg hardvera da izvri misiju i obrnuto,skoro da nema hardvera bez softvera. Jedna od tehnika koje se koriste za odravanje sistemau radu na novijem hardveru je emulacija- imitiranje originalnog hardvera i operativnog

sistema. Imitiranje se koristi kada zbog resursa nije mogue promeniti sistem ili su trokovipreveliki. Za ove sisteme linija izmeu korisnosti i zastarelosti je veoma tanka. Jedna odnajveih tekoa u odravanju ovakvih sistema je pronalaenje personala koji je upoznat saoriginalnim hardverom i voljni su da ga odravaju. Zato to je hardver koji se imitirazastareo, specifine vetine potrebne za odravanje ovakvih sistema imaju malu primenu

drugde, i perspektiva odravanja takvog sistema nije obeavajua.

2.2.6 Veoma veliki moduli ili podrutinske jedinice

Mega-sistemi koji su pisani kao jedan ili vie vrlo velikih programa ili podprograma (hiljadeili desetine hiljada redova kdova po programu) mogu biti ekstremno teki za odravanje.Veliina modula obino je direktno proporcionalna nivou napora neophodnom za njegovoodravanje. Ako veliki moduli mogu biti restruktuirani i podeljeni na manje, funkcionalno

povezane sektore, pogodnost za odravanje tih sistema e biti poboljana (unaprijeena).

2.2.7 Prekomerna zahtevanja resursa

Aplikativni sistem koji zahteva znatno vreme centralne procesorske jedinice, veliku

memoriju ili resurse drugih sistema moe da bude veoma ozbiljno optereenje za svekorisnike. Ovakvi sistemi spreavaju obavljanje drugih poslova i sniavaju nivo i kvalitetusluge za sve druge korisnike. U pitanja koja treba postaviti u pogledu ovih sistema treba

ukljuiti i pitanja da li je jeftinije dodati jo snage kompjuterima ili redizajnirati ireimplementirati sistem i da li e redizajn smanjiti zahteve za resursima. Ako zahtevi zaresursima nee biti smanjeni onda nema koristi od redizajna.

2.2.8 Tvrdo-kdirani parametri su subjekti za izmenu

Mnogi stariji sistemi su dizajnirani sa vrednostima parametara korienih za izvoenjespecifinih izraunavanja tvrdo-kodiranih u izvornom kdu umesto da se itaju iz tablica ilifajlova podataka. Kad su neophodne promene ovih parametara svaki program u sistemu mora

biti ispitan, izmenjen i ponovo sastavljen ako je neophodno. Ovo je dugotrajan i proces sklon

grekama koji troi vreme i resurse neophodne za ove izmene.Ako je mogue program bi trebalo modifikovati unosom parametara u jedan modul iliitanjem parametara iz centralne tabele vrednosti. Ako ovo ne moe biti uraeno, trebaozbiljno razmotriti redizajniranje sistema.


13/76


Novi Pazar, 2013 13

2.2.9 Podrka nisko-nivojskim jezicima

Programi pisani nisko-nivojskim jezicima, naroito ASSEMBLER-om, trae prekomernukoliinu vremena i napora za odravanje. Uopte takvi jezici nisu iroko ueni i poznavani u

praksi. Eto zato je programere koji ga ve znaju izuzetno teko nai. ak i kada takvi

programeribivaju pronaeni njihovo znanje ovih jezika je verovatno smanjeno.

2.2.10 Ozbiljni manjak dokumentacije

Jedan od najee zastupljenih problema softverskog odravanja je manjak adekvatnedokumentacije. U veini organizacija dokumentacija je ili zastarjela ili ne postoji. ak i kada

je dokumentacija obimna kad je dostavljena, ona se esto ne obnavlja i ubrzano postajeneupotrebljiva kako se modifikuje softver. U nekim sluajevima dokumentacija je moderna,ali neupotrebljiva (kada je dokumentacija pisana od strane nekog ko ne razume softver).

Moda je najgora dokumentacija koja je dobro struktuirana i oblikovana, ali netana izastarela. Ako nema dokumentacije programer je primoran da analizira kd da bi razumiosistem. Ako je dokumentacija loa programer joj nee verovati i proverie tanost. Ako jedokumentacija naizgled dobra, ali tehniki netana, programer e pogreno poverovati unjenu tanost i prihvatiti njen sadraj. Ovo e rezultirati ozbiljnim problemima, dodatimonima koje je trebalo opraviti.

Grupa za odravanje se ne moe osloniti na dokumentaciju i mora ispitati kd da bi odredilikakve izmene da izvre. Ovo uveava ne samo vreme za opravku, ve i mogunost uvoenjadodatnih defekata (softverskih greaka)nakon izvrenih izmena.

2.2.11 Fluktuacija znanja strunjaka

Strunjaci dodijeljeni projektu tokom faze odravanja moraju prostudirati aplikaciju i postatifamilijarni sa procedurom korienom za obradu podataka. Zbog dugotrajnog uenja zasloene projekte, neki strunjaci odravanja imaju neadekvatno znanje kako rade aplikacije;oni su moda sposobni da izvre izmene, ali nisu svesni potencijalnih efekata po sistem.Takoe, personal odravanja moda ne razume razloge za izvoenje projektnih aktivnosti nanain na koji se izvode.

2.2.12 Nedostatak ili nekompletnost specifikacija za dizajn

Poznavanje kako i zato sistem radi je osnovno za ispravno odravanje. Ako su zahtevi ispecifikacije za dizajn nekompletni ili nedostaju, zadatak odravanja e biti tei. Akospecifikacije nedostaju ili su nekompletne, softverski proizvod najverovatnije nee bitiizveden kako je nameravano i biemo opsednuti zahtevima za izmjenama i poboljavanjima.

2.2.13 Zastarjela tehnologija

Ranije razvijane aplikacije prvenstveno koriste tehnologije koje su sad zastarele. Tekuasistemska tehnologija e isto tako zastaretiza nekoliko godina. Eto zato personal odravanjamora biti upoznat sa starijim tehnologijama. Ovo moe jako ograniiti raspoloivi personal za


14/76


Novi Pazar, 2013 14

izvravanje odravanja i moe iziskivati potrebu da odravanje obavlja personal koji nepoznaje dobro staru tehnologiju.

2.2.14 Obim testiranja u odnosu na veliinu izmena

Mnoge izmene na aplikacijama sistema su zanemarljive (ukljuuju manje od 1% programskihiskaza). Da bi se osiguralo da aplikacija i dalje funkcionie kako je specificirano, itav sistemmora biti testiran. Testiranje 100% kda kada je manje od 1% promenjeno ne izgleda kao

ekonomianpristup. Meutim kada je testiranje sistema ogranieno, sistem je podloanregresionom defektima (problemi u ostatku kda izazvani kdom koji je izmijenjen).

2.2.15 Neadekvatna test dokumentacija

Programeri obino imaju adekvatno vreme i budet da izvre neophodne izmene delasoftvera, stvore uslove za testiranje, i testiraju izvrene izmjene, ali nemaju vremena da stvoreuslove za testiranje i pristupe testiranju itave aplikacije, naroito ako je dokumentacija za

testiranje aplikacija nekompletna ili netana.

3 Vrste odravanja

Postoji vie vrsta aktivnosti koje nazivamo odravanjem:

Odravanje u smislu ispravke softverskih greaka Odravanje u smislu prilagoavanja softvera razliitim operativnim okruenjima Odravanje u smislu dodavanja i modifikacija sistemskih funkcionalnosti.

Slika 3.1 Vrste odravanja4

4B. Lienz, E.B. Swanson, and G.E. Tompkins, Characteristics of Applications Software Maintenance,

Communications of the ACM, vol. 21, 1980.


15/76


Novi Pazar, 2013 15

Slika 3.2 Trokovi odravanja5

Sa slike se vidi da najvei deo odravanja, gotovo dve treine otpada na dodavanjefunkcionalnosti i modifikacije tj. Usavravanje softvera, dok manji deouzimaju korigovanja i

prilagoavanja.

3.1 Kategorije odravanja softvera

Generalno posmatrano,postoje tri kategorije odravanja: Korektivno odravanje Adaptivno odravanje Perfektivno odravanje

Ove definicije su kasnije aurirane u standardu za softversko odravanje, ISO/IEC 14764 iukljuuju 4 kategorije:

Korektivno odravanje;

Adaptivno odravanje; Perfektivno odravanje i Preventivno odravanje

Perfektivno odravanje predstavlja modifikacije softverskog proizvoda nakon isporuke radiunapreenja performansi.

5McClure, Cost management strategy, 1990


16/76


Novi Pazar, 2013 16

Preventivnoodravanje predstavlja modifikacije softverskog proizvoda nakon isporuke radidetektovanja ili korekcije skrivenih greaka u softverskom proizvodu pre nego to seaktiviraju.

ISO/IEC 14764 klasifikuje adaptivno i perfektivno odravanje kao unapreenja. Takoe,

grupie zajedno i korektivno i preventivno odravanje u kategoriju korekcije, kao to jeprikazano u sledeoj tabeli. Preventivno odravanje je najnovija kategorija i najee seizvodi na softverskim proizvodima gde je kljuno pitanje sigurnosti.

Tabela 3.1.

Korekcije UnapreenjaProaktivno Preventivno Perfektivno

Reaktivno Korektivno Adaptivno

3.1.1 Korektivno odravanje softvera

Prvi korak u korektivnom odravanju softvera je odreivanje ta treba da se popravi. Ukorektivnom odravanju softvera sve aktivnosti poinju sa identifikacijom problema u

postojeem softveru. Tano odreivanje modula koji prouzrokuje problem moe biti teko.Ovaj osnovni prilaz baziran je na tehnici pokuaja i greaka, voen serviserovim

poznavanjem sistema i njegovim osnovnim poznavanjem kompjuterske nauke i softverskog

inenjeringa.

Kad problem jednom bude odreen, odluka koja e biti donesena je koji, kako ili kada eproblem biti reen. Ovo obino zahteva nekoliko povezanih radnji: Zakljuak da problem postoji.

Dokumentovanje problema. Odreivanje vanosti problema. Odreivanje prioriteta problema po redu vanosti za opravku. Odreivanje koji problemi nee biti opravljani zbog nedostatka resursa.Reavanje problema. Testiranje sistema da vidimo da li reenje ovog problema moe da prouzrokuje greku udrugom dijelu softvera.

Dokumentovanje reenja kao dela izvornog kda. Dokumentovanje reenja u drugim formama ako su izvrene promjene originalnog dizajnasistema.

Auriranje baze podataka sa informacijama o softverskim grekama.

Moda ovo izgleda kao mnogo posla. Odravanje softvera zahteva, po svojoj prirodi, velikukoliinu rada sa dokumentima da bi se aurirala dokumentacija. Najzad, proizvoaisoftverskih sistema ili vlasnici projekta retko zauvek ostaju na istim projektima. Sa velikom

promenom (gubitkom) personala, pisana dokumentacija o svim izmenama mora biti

ostavljena buduim serviserima sistema.

Uoavanje softverskih problema moe se dogoditi na vie nivoa. U najidealnioj situacijiproblem je uoila osoba koja je upoznata sa kompletnim sistemskim zahtevima. U ovom


17/76


Novi Pazar, 2013 17

sluaju dokumentovanost problema je trenutna i odreivanje izvora problema je tada obino lako.

ea situacija je da je osoblje koje uoi problem potpuno neupoznato sa unutranjomstrukturom softvera. Zaista, osoblje koje uoi problem moe ak biti i neupoznato sa

operacijama koje se oekuju od softvera. Ovo je tipian primer problema koji su prvoprimetili novi korisnici koji su zatim telefonom pozvali tehniku podrku za upoznavanje saprocesima ili slinim primenama softvera. Tehniki, personal koji radi na tehnikomizvetavanju je odgovoran za voenje korisnika koji trai pomo kroz ovaj pretpostavljeni

problem, da trai problem u podeavanju i konfiguraciji softvera, ukratko da odredi da li jeproblem nastao grekom korisnika ili je greka u softveru. Tamo u osnovi postoje dvaproblema: korisnik nije razumeo objanjenja za instalaciju i rad ili je softver u otkazu.

Kad personal za tehniku podrku odredi da korisnik nije razumio dokumentaciju instalacijesistema ili sistemskih operacija, ostaje im da urade dva zadatka. Korisnik mora biti voen

pravilnim instrukcijama dok ne rei problem. I jo personal za tehniku podrku mora

dokumentovati problem tako da dokumentacija i korisniki interfejs budu poboljani. Ovo seesto radi u novoj verziji koja e se tek pojaviti. Personal za tehniku podrku treba da

potpuno opie i dokumentuje probleme i preda to osobama odgovornim za nove verzijesistema tako da e korisnici, nove verzije smatrati unaprijeenim. U prolosti je veinakompjuterske dokumentacije mogla biti unapreena upoljavanjem tehniki obrazovanih

pisaca.

U sluaju softverske greke, od korisnika se ne oekuje da obezbijedi detaljnu dokumentacijuo detaljima problema. Tipian korisnik nema toliko tehniko znanje i, u svakom sluaju tonije njegov posao. Personal za tehniku podrku je odgovoran da uzme informacije odkorisnika i organizuje ih na nain na koji mogu biti iskoritene u procesu opravke.

Cilj linog dokumentovanja softverskih problema je u sposobnosti ispunjavanja formulara zasoftversko odravanje ili formulara za izvetaj o odravanju. Formulari pomau u potpunomopisivanju problema i za procenu relevantne vanosti problema. Na osnovu tih formulara,rukovodilac softverskog odravanja e proceniti i odrediti prioritete na osnovu kojih e sevriti odravanje softvera.

Nakon to je problem reen, jo jedan formular treba da se ispuni. Ovaj formular pokazujeodgovor na formular sa pitanjima o softverskom odravanju i kao takav je esto nazivanformular sa odgovorima za softversko odravanje. Formular sa odgovorima uvek pokazuje

listu zahvaenih (zaraenih tim problemom) modula i vreme koje je bilo potrebno zareavanje problema.

Treba primetiti i vanost da se ovim formularima doda ekstra dokumentacija. Veoma jekorisno ako se kao prilog doda i odtampan sadraj ekrana, na kom se vidi manifestacijagreke. Ako nema ovih mogunosti, slika ekrana moe biti dovoljna. Oigledno, digitalnaslika je najbolja.

Svakako, nema potrebe za formularima pisanim na papiru. Formulari mogu biti uvani uelektronskoj formi sa automatskim unosom u bazu podataka. Idealno, serviserima treba da

budu dostupni softverski paketi koji podravaju aktivnosti u odravanju, automatski


18/76


Novi Pazar, 2013 18

stvarajui formulare i snimaju informacije u bazu podataka . U mnogim softverskimokruenjima nedostatak sposobnosti generisanja formulara je najkritiniji problem.

Najjednostavnije reenje je unos podataka o odravanju u tekst formatu direktno u tabelu ili ubazu podataka.

3.1.2 Adaptivno Softversko Odravanje

Adaptivno odravanje je proces menjanja softvera u skladu s novim trendovima na tritu.Oekivane promene hardvera, sistema, interoperatibilnosti aplikacionih paketa i novihkarakteristika nametnutih od strane konkurencije su vani u odreivanju potrebe zaadaptivnim odravanjem softvera.Poznat je svima primer MICROSOFT WORD-a koji je proao kroz mnoge verzije odnjegovog poetka. Neke od ovih promena su ukljuivale korisniki interfejs i lakoukorienja. Druge izmene su obezbedile dodatne karakteristike i zajedniki format fajlova.esto, dokumenta otvorena u jednoj od kasnijih verzija WORD-a ne mogu biti itana ilimenjana u ranijim verzijama istog softvera (ovaj problem nije jedinstven za MICROSOFT,

isti iskaz se moe primeniti na COREL WORD PERFECT, izmeu ostalih).

Za neke korisnike, prednost zajednikog formata fajlova u kojima dokumenti mogu biti itanii na PC-iju i MACINTOSH-u je vanija naspram sposobnosti stvaranja velikih fajlova zadokumente. Za druge korisnike su vanije mogunosti koje obezbeuju makro-i nego dodatnisigurnosni zahtevi za tretiranje makro-virusa koji se mogu prenositi sa PC-a na

MACINTOSH i obratno.

Kao kod korektivnog odravanja znatna testiranja softvera su neophodna, naroito regresionotestiranje.

To je podesno do te take da se pokau neki problemi koji nisu bili oekivani da e se otkritiak i tokom najiscrpnijih testiranja softvera.

Postoji jo jedan problem koji naroito uznemirava softverske servisere. Mnogi softverskiinenjeri, naroito oni sa prvobitnim iskustvom sa kompjutera koji su imali veliku koliinomfizike memorije, ne misle da njihovi sadanji sistemi imaju ikakva ogranienja. Naime,memorija moe biti potroena naroito ako je sastavljena od jeftinih proizvoda iji sumemorijski zahtevi nepoznati.

Treba biti svestan da je situacija naroito sloena za odravanje ako je softver koji trebaodravati u vezi sa jeftinim komponentama hardvera ija je unutranja struktura nepoznata.Jasno je da softverski serviser mora imati mnogo vie vetina od obinog iskustva u

programiranju.

3.1.3 Perfektivno odravanje softvera

Softver je roen da bi bio menjan, poboljavan.Perfektivno odravanje odnosi se napromene zahtevane od strane korisnika sistema iliprogramera koji usavravaju isti na nainkoji nee izmeniti njegovu funkcionalnost.Stara poslovica kae: Ne popravljaj ono to nije pokvareno. Perfektivno odravanjezapravo je ba to-popravljanje, odnosno usavravanje softvera koji radi. Ciljevi kojima setei su:

Smanjenje trokova za korienje sistema


19/76


Novi Pazar, 2013 19

Poveanje pogodnosti za odravanje (meintabilnosti) sistema Blie zadovoljavanje potreba korisnika

Perfektivno odravanje koristi sav napor na doterivanje softvera i preciziranje dokumentacije.

Vano je da potencijalna dobrobit perfektivnog odravanja nadjaava: trokove odravanja kao i oportunitetne trokove poboljanja na drugim mestima ili korienje resursa za nove

razvoje.

Zbog svega navedenog pre nego to se upustimo u perfektivno odravanje potrebno je daproemo kroz proces analize. U svakom sluaju, sasvim malo perfektivnog odravanja moeda donese veoma teatralne efekte.

3.1.4 Preventivno Odravanje Softvera i Problem 2000 Godine

Preventivno odravanje softvera treba da proaktivno sprei softverske probleme u postojeemsoftveru pre nego to oni nastanu.

Najverovatnije najbolji nain da se ilustruje preventivno odravanje na tematskom primeru-poznat kao Y2K6 problem 2000 godine.

Ova situacija je izgledala bezopasno: mnogi kompjuterski problemi prikazuju datume

koristei dva mesta za cifre i 2000. godina je traila novu interpretaciju ovih ve postojeihfajlova. Zato je ovaj problem tako vaan? Postoji zapravo dva dela za odgovor: prvi uveliini problema koji su razumele organizacije koje koriste softver ili su odgovorne za njega,i drugi mogui skriveni problemi iji opseg se moe samo nagaati. Svaki od ovih scenarijaima problem sa prekoraenjem (overflow) koji e morati da bude reen. Velika koliinasoftvera na koje se odrazioY2K problem je prouzrokavao nonu moru za odravanje, naroitozbog manjka kvalifikovanog personala.

Postoji mnogo scenarija za budue probleme sline problemu Y2K: Iscrpljivanje telefonskih pozivnih kdova u Americi do 2020 godine Tranzicija sa ASCII kda na internacionalni karakterni set kao to je UNICODE Telefonski brojevi koji se postavljaju u deset cifara (tri za kdpodruja i sedam za lokalni

broj) e biti iscrpljeni u Americi oko 2015 godine. Datumski i vremenski mehanizmi u UNIX operativnim sistemima baziranim na brojusekundi je startovao 01.01.1970 godine. Broj sekundi se uva u 32-bitnom integratoru koji ese prepuniti 19.01.2038 godine.

Devetocifreni brojevi socijalnog osiguranja e u Americi biti iscrpljeni otprilike u perioduod 2050 do 2075 godine.

Poto e se ovi problemi pojaviti u budunosti, preventivno odravanje je veoma vano.Softver koji je otporan na ove nezaobilazne probleme imae prednost kada se problemi

pojave.

6BSI Standard, 2000
http://parsifal.membrane.com/y2k/pd2000-4.htmhttp://parsifal.membrane.com/y2k/pd2000-4.htm


20/76


Novi Pazar, 2013 20

3.2 Aktivnosti odravanja

Aktivnosti u odravanju softvera, a koji slue i kao pokazatelji kvaliteta softverskogproizvoda su:

prerada softverskog kda, optimizacija performansi softvera, migracija na druge platforme, konverzija u nove arhitekture, uklanjanje neaktivnog kda, uklanjanje skrivenih aplikacija, povlaenje softvera iz upotrebe.

Ostale aktivnosti tokom procesa odravanja: kontakti sa klijentima pisana korespondencija izlasci na teren i dr.

Slika 3.3 Trokovi pri razvoju softvera7

Na slici su prikazani trokovi ivotnog ciklusa razvoja softvera. Relativno mali deo trokovasoftverskog razvoja, oko 5%, se troi na kdiranje. Najvei deo trokova otpada naodravanje.

7S. Schach, Object-Oriented and Classical Software Engineering, 5th ed., McGraw-Hill, 2002


21/76


Novi Pazar, 2013 21

4 Kljuni aspekti softverskog odravanja

Vei broj kljunih tema mora se razmotriti radi osiguranja efikasnog odravanja softvera.Vano je razumeti da softversko odravanje prua jedinstvene tehnike i menaderskeizazove softverskim inenjerima. Jedan od primera je pokuaj pronalaenja greke u softverusa 500 hiljada linija koje softver inenjer nije razvijao. Takmienje za neophodne resurse u

poreenju sa sredstvima za razvoj je stalna borba. Planiranje za budue verzije, dok sekodiraju sledee verzije i alju dopune i zakrpe za tekue verzije, takoe predstavlja izazov.U nastavku su date neke tehnike i menadment teme vezane sa softversko odravanje, kojesu grupisane u sledee kategorije:

Tehniki aspekti Menadment aspekti Procena trokova Merenja

4.1 Tehniki aspekti

Tehniki aspekti odravanja softvera su:

o Ogranieno razumevanjeo Testiranje

o Analiza uticaja (eng. Impact analysis)

o Lakoa odravanja

4.1.1 Ogranieno razumevanje

Ogranieno razumevanje odnosi se na to kako brzo softver inenjer moe razumeti gde danapravi promene ili korekcije u softveru koji nije razvijao. Istraivanja pokazuju da je 40%do 60% napora odravanja posveeno razumevanju softvera koji se modifikuje. Prema tome,tema sveobuhvatnog razumevanja softvera je od velikog interesa softver inenjerima.Razumevanje je tee u text-oriented reprezentacijama, u izvornom kdu, na primer, gde jeesto teko praenje i evolucija softvera tokom brojnih verzija, ako promene nisudokumentovane i kada programeri nisu na raspolaganju za objanjenje, toje najee i sluaju praksi.

4.1.2 Analiza uticaja

Analiza uticaja opisuje kako sprovesti kompletnu analizu uticaja promena u postojeemsoftveru. Odravaoci moraju posedovati sutinsko znanje strukture i sadraja softvera. Onikoriste to znanje radi izvoenja analize uticaja, koja identifikuje sve sistemske i softverske

proizvode pogoene zahtevima za softverskim promenama i razvija procenu resursapotrebnih za ispunjenje tih promena.

Kao dodatak, odreuje se i rizik pravljenja tih promena. Zahtev za promenama, nekada se naziva i modification request (MR), mora prvo biti analiziran i preveden u softverske

termine.

Neki autori navode da su ciljevi analize uticaja:

Odreivanje opsega promena u cilju planiranja i implementacije rada Odreivanje tanih procena resursa potrebnih radi izvoenja rada


22/76


Novi Pazar, 2013 22

Cost/benefit analiza zahtevanih promena Komunikacija sa ostalima uesnicima o kompleksnosti datih promena

4.1.3 Lakoa odravanja

IEEE [IEEE610.12-90]8 definie lakou odravanja (maintainability) kao jednostavnost sakojom se softver moe odravati, unapreivati, adaptirati i ispravljati radi zadovoljenjaspecificiranih zahteva. ISO/IEC definie lakou odravanja kao jednu od karakteristikakvaliteta.

Podkarakteristike lakoe odravanja mogu biti specificirane, pregledane, kontrolisane tokomaktivnosti softverskog razvoja u cilju smanjena trokova odravanja. Ako se to uradi uspeno,lakoa odravanja softvera e se unaprediti. Ovo je esto teko postii zato to ove

podkarakteristike nisu vane tokom procesa razvoja softvera.Developeri su zaokupljeni mnogim drugim stvarima i esto ne obraaju panju na zahteveodravaoca softvera. Ovo moe, a esto se i deava, rezultirati u nedostatku sistemske

dokumentacije, koji je vodei razlog za probleme u razumevanju programa i analizi uticaja.Moe se rei da prisustvo sistemskih i razvijenih procesa, tehnika i alata pomae unapreenjulakoe odravanja sistema.

4.2 Menadment aspekti

Menadment aspekti odravanja softvera su:

o Usaglaavanje sa organizacionim ciljevimao Osoblje

o Procesi

o Organizacioni aspekti odravanjao Outsourcing (usluge treih lica)

4.2.1. Usaglaavanje sa organizacionim ciljevima

Organizacioni ciljevi opisuju kako demonstrirati povraaj investicija od aktivnostisoftverskog odravanja. Inicijalni softverski razvoj je obino zavisni od tipa projekta (project-

based), sa definisanim vremenskim opsegom i budetom. Osnovni znaaj je isporuka navreme i unutar budeta za ispunjenje korisnikih potreba. Nasuprot tome, softverskoodravanje esto ima za cilj produavanje ivotnog ciklusa softvera koliko god je mogue.

Kao dodatak, moe biti voen potrebama korisnika radi ispunjenja korisnikih zahteva zaauriranja i unapreenja softvera. U oba sluaja, povraaj investicija je mnogo manje jasan,

pa je pogled na menadment nivou esto troenje znaajnih sredstava sa nejasnim merljivim(kvantitativnim) benefitom za organizaciju.

4.2.2 Osoblje

Ovaj aspektse odnosi na to kako zainteresovati i zadrati osoblje za softversko odravanje.Odravanje se ne posmatra kao privlaan posao. Suoavanje i reavanje problema koji su

8IEEE Std 610.12-1990 (R2002), IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990.


23/76


Novi Pazar, 2013 23

prouzrokovani radom drugih nije posebno primamljivo. Mnogi autori daju itavu listustaffing-related" problema zasnovanih na istraivanju. Osoblje za odravanje se najeevidi kao "second-class citizens", ime se sa moralnog stanovita otvaraju mnoga pitanja.

4.2.3 Organizacioni aspekti odravanja

Organizacioni aspekt opisuje kako identifikovati koja organizacija i/ili funkcija e bitiodgovorna za odravanje softvera. Tim koji razvija softver nije obavezno i dodeljen naodravanje softvera kada postane operativan. U odluivanju gde se locira funkcijasoftverskog odravanja, organizacija moe, na primer, ostati sa originalnim developerima, iliii na odvojeni tim (odravaoci). Poto postoji mnogo za i protiv za svaku od ovih opcija,odluka treba da se donese od sluaja do sluaja. Vana je delegacija ili dodeljivanjeodgovornosti odravanja jednoj grupi ili osobi, shodno organizacionoj strukturi.

4.2.4 Usluge treih lica Outsourcing

Outsourcing (izvan kompanije) odravanje je danas veoma masovna pojava. Velikekorporacije outsource-uju kompletan portfolio softverskog sistema, ukljuujui softverskoodravanje. Najee, outsourcing opcija se bira za manje "mission-critical" softvere, potokompanije nisu spremne da izgube kontrolu nad softverom koji se koristi u osnovnom

biznisu.

Mnoge firme e outsource-ovati samo ako pronau nain zadravanja strateke kontrole.Problem je meutim, to je teko pronai kontrolne mere u tom sluaju.Jedan od najveih izazova za outsourcing je odreivanje zahtevanog opsega odravanihservisa i detalji ugovora. McCracken9 navodi da 50% outsource-era obezbeuju servise bez

jasnog nivoa servisiranja prema ugovoru. Outsourcing kompanije tipino potroe nekolikomeseci procenjujui softver pre bilo kakvog ulaska u ugovorni sporazum. Jo jedan izazov jei tranzicija softvera outsource-eru.

4.3 Procena trokova

Shodno velikom udelu u trokovima poeljno je na vreme uraditi planiranje i predvideti:

koji delovi sistema e najverovatnije biti podloni zahtevima za promene koliki broj zahteva za promenama se moe oekivati koji delovi sistema e biti najskuplji za odravanje kako e izgledati trokovi odravanja prema vremenu korienja sistema koliki e biti trokovi odravanja sistema u narednom vremenskom periodu, npr. na

godinjem nivou analizom obuhvatiti i sredstva i vreme utroeno za odravanje (izlazak na teren,

vreme zadravanja i sl.)

Detaljnije analize pokazuju da se najvie vremena i sredstava troi na odravanju iprepravkama relativno malog broja sistemskih komponenti. U tim sluajevima, trokovizavise od kompleksnosti tih komponenti. Kompleksnost komponente zavisi od:

kompleksnosti kontrolnih struktura9B. McCracken, Taking Control of IT Performance, presented at InfoServer LLC, 2002.


24/76


Novi Pazar, 2013 24

kompleksnosti struktura podataka veliine procedura i modula

Poeljno je uraditi procenu broja zahteva za promenama pri odravanju, kao i procenuutroenog vremena na jednoj prosenoj promeni na osnovu zahteva. Takoe, znaajna stavka

je i provedeno vreme i broj izlazaka na teren radi odravanja.

5 Analiza problema odravanja

Odravanje sistema je teko. Imajui u vidu da je sistem ve u eksploataciji, tim zaodravanje uravnoteuje potrebu za izmenom sa potrebom da sistem ostane dostupankorisnicima. Na primer, nadogradnja sistema moe da zahteva da on bude nedostupankorisnicima vie sati. Meutim, ako je sistem kritian sa aspekta poslovanja ili rada korisnika,moe se desiti da vremenski okvir od nekoliko sati nedostupnosti jednostavno ne postoji. Na

primer, sistem za odravanje ivota ne moe da prekine vezu sa pacijentom da bi se obavilo

odravanje softvera. Tim za odravanje mora da pronae nain kako da implementira izmenebez ugroavanja korisnika.

5.1 Personalni problem

Postoji mnogo personalnih i organizacionih razloga koji odravanje ine tekim. Osobljemora da deluje kao posrednik izmeu problema i njegovog reenja, popravljajui i krojeisoftver da bi obezbedilo da reenje prati problem kako se on menja.

5.1.1 Ogranieno razumevanje

Pored uravnoteavanja korisnikih potreba sa potrebama softvera i hardvera, tim zaodravanje ima posla i sa ogranienjima ljudskog razumevanja. Postoji granica brzine kojomneko moe da prouava dokumentaciju i iz nje izvlai materijal relevantan za problem koji sereava. tavie, mi esto traimo vie kljueva nego to je stvarno potrebno za reenje

problema.

Parikh i Zvegintzov10 izvetavaju da je 47% rada u odravanju softvera posveenorazumevanju softvera koji treba da se modifikuje. Ova velika cifra je razumljiva kada

uzmemo u obzir interfejse koje treba proveriti kad god se menja komponenta. Na primer, ako

sistem ima m komponenti i treba da promenimo kod njih, postoji:

k x (m-k) + k x (k-1)/2

interfejsa koji treba da se ocene zbog uticaja i ispravnosti. Dakle, ak i izmena samo jednogreda u sistemu moe da zahteva stotine testova, da bismo se uverili da izmena nema direktnogili indirektnog efekta na neki drugi deo sistema.

10G.Parikh, N.Zvegintzov, Tutorial on Software Maintenance, IEEE Computer Society Press, Silver Spring, Maryland, 1983.


25/76


Novi Pazar, 2013 25

Korisniko razumevanje takoe predstavlja problem. Lientz i Swanson11su pronali da vieod polovine problema programera koji se bave odravanjem nastaje kao posledica nedovoljnevetine ili stepena razumevanja kod korisnika. Na primer, ako korisnici ne razumeju kakosistem funkcionie, oni mogu da daju nepotpune ili obmanjujue podatke kada izvetavaju oefektima problema.

Ovi rezultati ilustruju znaaj jasne i potpune dokumentacije i obuke. Timu za odravanje sutakoe potrebne dobre ljudske vetine". Tim za odravanje mora da razume kako ljudi sarazliitim stilovima misle i rade, a lanovi tima moraju da budu fleksibilni u komunikaciji.

5.1.2 Prioriteti menadmenta

Tim za odravanje odmerava elje rukovodeih ljudi na strani kupca prema potrebamasistema. Prioriteti rukovodilaca esto prevazilaze tehnike prioritete. Menaderi ponekad videodravanje i poboljanje kao vanije od izrade novih aplikacija. Drugim reima, kompanijemoraju ponekad da se usredsrede na poslovanje kao to je uobiajeno, umesto da istraujunove alternative. Ali, dok menadment ohrabruje servisere da popravljaju stari sistem,

korisnici vape za novim funkcijama ili novim sistemom. Slino tome, urba da proizvod doena trite moe da ohrabri projektante ili servisere da implementiraju brzu, neelegantnu,nedovoljno testiranu izmenu, a ne da dvoje vreme za sprovoenje dobre prakse softverskoginenjerstva. Rezultat je zakrpljeni proizvod koji se kasnije teko razume i popravlja.

5.1.3 Moral

Studije Lientza i Swansona pokazuju da je 11,9% problema u toku odravanja rezultat niskogmorala i produktivnosti. Glavni razlog za nizak moral je drugorazredni status koji se estododeljuje timu za odravanje. Programeri ponekad misle da je potrebno vie vetine da bi se

projektovao i razvio sistem, nego da se on odrava u radu. Meutim, kao to smo videli,

programeri iz odravanja bave se problemima koje projektanti nikada ne vide. Serviseri suobueni ne samo za pisanje kda, nego i za rad sa korisnicima, predvianje izmena i traganje.Potrebne su velika vetina i istrajnost da bi se problem pratio do njegovog uzroka, da serazume unutranji rad velikog sistema i da se modifikuju njegova struktura, kd idokumentacija.

Neke grupe rotiraju programere izmeu vie projekata odravanja i razvoja, da bi im dalipriliku da rade razliite stvari. Ta rotacija pomae da se izbegne etiketiranje programiranja zapotrebe odravanja. Meutim, od programera se esto trai da istovremeno rade na vieprojekata. Zahtevi za angaovanje vremena programera rezultuju sukobom prioriteta. U tokuodravanja, 8% problema su posledica injenice da se programeri razvlae na vie stranaodjednom i da zato nisu u stanju da se dovoljno dugo usredsrede na jedan problem da bi ga

reili.

5.2 Tehniki problemi

Tehniki problemi takode utiu na produktivnost odravanja. Ponekad su oni nasledstvoonoga to su projektanti i serviseri radili ranije. U drugim prilikama, oni su rezultat posebnih

platformi ili procesa koji su usvojeni za implementaciju.

11Bennet P. Lientz , E. Burton Swanson, Characteristics of application software maintenance, Univ. of California, Los Angele,1973.


26/76


Novi Pazar, 2013 26

5.2.1 Artefakti i paradigme

Ako logika konstrukcije nije oigledna, timza odravanje softverane moe lako da odredi dali konstrukcija moe da opslui predloene izmene. Pogrena ili nefleksibilna konstrukcijamoe da zahteva dodatno vreme za razumevanje, menjanje i testiranje. Na primer, projektanti

su mogli da ukljue komponentu za ulaz i izlaz koja opsluuje jedino traku. Potrebno jeuiniti velike izmene da se traka zameni diskom, zato to disk nije ogranien sekvencijalnim

pristupom kao traka. Slino tome, projektanti su mogli da ne predvide izmene. Veliine poljai tabele mogu da budu fiksne, to ih ini tekim za modifikaciju. Problem 2000. godine", gde

je veina projektanata predstavljala godinu sa samo dve cifre, dobar je primer kakojednostavne, ali ograniene odluke u projektu mogu da imaju veliki uticaj na procesodravanja.I odravanje objektno orijentisanih programa moe da bude problematino, zato to projekatesto obuhvata komponente koje su jako spregnute sloenim emama nasleivanja. Postepeneizmene moraju da se prave sa velikom panjom, zato to modifikacije mogu da rezultirajudugim lancima prikrivenih klasa ili klasa koje redefiniu objekte na konfliktan nain.

Uopte, na neodgovarajue specifikovane projekte i programe slabog kvaliteta odlazi skoro10% rada na odravanju. Slina koliina rada troi se zbog hardverskih zahteva: dobijanjeodgovarajueg prostora za skladitenje i vremena obrade. Problemi takoe nastaju kada suhardver, softver ili podaci nepouzdani.

5.2.2 Tekoe sa testiranjem

Testiranje izmena na softveru moe da bude problem ako je teko pronai vreme za njegovoizvoenje. Na primer, sistem za rezervaciju avionskih karata mora da bude stalno naraspolaganju. Teko je ubediti korisnike da ne mogu da koriste sistem zato to se on testirasat ili dva. Sisteme koji izvravaju kritine funkcije, kao to je kontrola vazdunog saobraajaili praenje stanja pacijenata, ponekad je nemogue dovesti u neaktivno stanje radi testiranja.U takvim sluajevima, testovi se obino izvravaju na rezervnim sistemima. Testirane izmenese zatim prenose na proizvodni (stvarni) sistem.

Pored problema sa vremenom kada je sistem raspoloiv, moe se dogoditi i da nema dobrihili odgovarajuih podataka za testiranje softverskih izmena koje treba uiniti. Na primer, akotreba da se izmeni sistem za predvianje zemljotresa da bi prihvatio signale sa senzorskogureaja koji se tek razvija, podaci za testiranje moraju da se simuliraju. Generisanje tanih

podataka za testiranje tada nije ba lako, jer naunici jo uvek ne znaju tano kako dolazi dozemljotresa.

to je najvanije, testerima nije uvek lako da predvide kakav e biti uticaj izmena nakonstrukciju ili kd i da se za njih pripreme. Takva nepredvidljivost postoji posebno ondakada razliiti lanovi tima za odravanje rade na razliitim problemima u isto vreme. Ako

jedna osoba menja komponentu da bi reila problem prekoraenja opsega podataka, dokdruga menja istu komponentu da bi reila problem interfejsa, kombinacija tih izmena moe da

prouzrokuje novu greku.

5.3 Potreba za kompromisom

Tim za odravanje se uvek bavi uravnoteavanjem razliitih ciljeva. Kao to smo videli,sukob moe da nastane izmeu raspoloivosti sistema za korisnike i implementacije izmena,


27/76


Novi Pazar, 2013 27

ispravki i poboljanja. Imajui u vidu da se otkazi pojavljuju u nepredvidljivim trenucima,osoblje za odravanje je stalno svesno tog sukoba.

Za profesionalce u raunarstvu, jedan drugi sukob nastaje kad god je potrebna izmena.Principi softverskog inenjerstva su u suprotnosti sa ekspeditivnou i trokovima. Problem

esto moe da se rei na jedan od dva naina: brzim, ali neelegantnim reenjem koje radi, aline odgovara dizajnu sistema ili strategiji kodiranja, ili zahtevnijim, ali elegantnijim nainomkoji je konsistentan sa vodeim principima korienim za projektovanje ostatka sistema. Kaoto smo ranije napomenuli, programeri mogu biti prinueni da prave kompromis izmeuelegancije i principa projektovanja, zato to je izmena trenutno potrebna.Kada se naprave takvi kompromisi, vie sa njima povezanih dogaaja moe da oteaodravanje u budunosti. Prvo, albu serviserima obino podnose korisnik ili operater. Oniverovatno ne razumeju problem u kontekstu konstrukcije i kda, nego samo u kontekstu

svakodnevnog rada. Drugo, reavanje takvog problema se svodi samo na ispravku dategreke. Ne dolazi do revizije sistemske ili programske konstrukcije da bi sistem u celini

postao razumljiviji ili da bi izmena bila konzistentna sa ostalim komponentama sistema. Zbog

ta dva inioca tim za odravanje ima ogranieni cilj -brzu popravku greke. Tim je primoranda usmeri svoje resurse na problem koji nedovoljno razume.

Tim mora da razrei jo jedan sukob. Kada se razvija sistem za reavanje poetnog problema,njegovi projektanti ponekad njime pokuavaju da ree i druge sline probleme ne menjajuikonstrukciju i kd. Takvi sistemi esto rade sporo, zato to je njihov kd opte namene i morada pregleda veliki broj sluajeva ili mogunosti. Da bi se poboljala performansa, treba

praviti sistem specijalne namene, odnosno optost se rtvuje zarad brzine. Komponentespecijalne namene su esto manje jer ne moraju da razmatraju svaku mogunost. Takodobijeni sistem moe lako da se menja, po cenu vremena koje je potrebno da bi semodifikovale ili poboljale konstrukcije sistema ili programa. Tim mora da odmeri optost

prema brzini kada odluuje kako i zato pravi modifikaciju ili ispravku.

Ostali inioci koji mogu da utiu napristup tima za odravanje su: Vrsta otkaza Kritinost ili ozbiljnost otkaza Teina potrebnih izmena Opseg potrebnih izmena Sloenost komponenti koje se menjaju Broj fizikih lokacija na kojima moraju da se izvre izmene.

Svi inioci koje smo ovde opisali ukazuju na to da osoblje za odravanje radi dvostrukiposao. Prvo, tim shvata dizajn sistema, kd i filozofiju testiranja i strukture. Drugo, on razvijafilozofiju odravanja i strukturisanja sistema. Uravnoteujui kratkorone i dugoroneciljeve, tim odluuje kada da rtvuje kvalitet radi brzine.


28/76


Novi Pazar, 2013 28

6 Tehnike odravanja softvera

6.1 Podmlaivanje softvera

U mnogim organizacijama koje koriste glomazan softver odravanje tih sistema predstavlja

pravi izazov. Npr. uzmimo osiguravajue drutvo koje nudi novu vrstu ivotnog osiguranja.Da bi podralo svoj proizvod, drutvo razvija softver za rad sa polisama osiguranja,informacijama o vlasnicima polisa i finansijskim i raunovodstvenim informacijama. Takve

polise treba da se odravaju desetinama godina. Rezultat svega toga je da osiguravajuedrutvo verovatno trebada podrava mnogo razliitih aplikacija na razliitim platformama, savelikim brojem implementacionih jezika. Organizacije koje su u takvoj situaciji moraju da

donose teke odluke o tome kako da uine svoje sisteme pogodnijim za odravanje. Njihovizbor se kree u opsegu od poboljanja do potpune zamene novom tehnologijom. Svaki izbortreba da sauva ili povea kvalitet softvera, uz istovremeno zadravanje trokova na to jemogue niem nivou.Podmlaivanje softvera odgovara na taj izazov odravanja pokuavajui da povea ukupankvalitet postojeeg sistema. Ono se vraa produktima rada sistema pokuavajui da dobijedodatne informacije ili da ih reformatira na razumljiviji nain. Postoji vie aspekatasoftverskog podmlaivanja, ukljuujui:

Redokumentovanje Restrukturisanje Reverzni inenjering Reinenjering.

Kada redokumentujemo sistem, izvodimo statiku analizu izvornog kda proizvodeidodatne informacije da bismo pomogli serviserima u razumevanju i referenciranju kda.

Analiza ne ini nita da bi transformisala aktuelni kd. Ona samo proizvodi informacije.Meutim, kada restrukturiemo, stvarno menjamo kd, transformiui loe strukturisani kdu dobro strukturisani. Obe ove tehnike bave se samo izvornim kdom. Da bismo izvrilireverzni inenjering sistema, vraamo se od izvornog kda ka proizvodima koji su mu

prethodili, ponovo stvarajui informacije o konstrukciji i specifikaciji iz kda.Reinenjeringje jo obuhvatniji jer se obavlja reverzni inenjering postojeeg sistema koji se zatimprojektuje unapred" radi izmena u specifikaciji i konstrukciji koje upotpunjuju logikimodel. Zatim se stvara novi sistem na osnovu revidirane specifikacije i konstrukcije. Na slici

6.1 ilustrovani su odnosi izmeu etiri vrste podmlaivanja.


29/76


Novi Pazar, 2013 29

Slika 6.1. Taksonomija podmlaivanja softvera [Bohner12]

Naravno, nemogue je oekivati da se ponovo stvore svi radni meuproizvodi iz delaizvornog kda. Takav zadatak je uporediv sa ponovnim stvaranjem slike deteta iz slike

odrasle osobe. Ipak, neka sutinska svojstvanekih produkata rada mogu da se poboljaju ili

doteraju. Stepen u kome informacija moe da se izdvoji iz finalnog proizvoda zavisi od vieinilaca [Bohner]12:

jezika koji se koriste; interfejsa baze podataka; korisnikih interfejsa; interfejsa ka sistemskim uslugama; interfejsa ka drugim jezicima; zrelosti i stabilnosti domena; raspoloivih alata.

Sposobnost servisera, njihovo znanje i iskustvo takoe igraju vanu ulogu kada je re ostepenu u kome informacije mogu uspeno da se interpretiraju i koriste.

6.2 Redokumentovanje

Redokumentovanje obuhvata statiku analizu izvornog kda da bi se proizvela dokumentacijasistema. Moemo da ispitamo upotrebu promenljivih, pozive komponenti, putanjeupravljanja, veliinu komponenti, pozivajue parametre, putanje testiranja i druge odnosne

12Bohner, S. And Arnold R. Software Change Impact Analysis. IEEEComputerSocietyPublications,

LosAngeles, CA, 1996.


30/76


Novi Pazar, 2013 30

mere koje nam pomau da razumemo ta i kako kd radi. Informacije koje proizvede statikaanaliza kda mogu da budu grafike ili tekstualne.

Na slici 6.2 ilustrovan je proces redokumentovanja. Uobiajeno je da serviser poinjeredokumentovanje analizirajui kd analitikim alatom. Izlaz moe da ukljui:

pozivne odnose izmeu komponenti; hijerarhije klasa; informacije o reniku u vezi s podacima; tabele ili dijagrame toka podataka; tabele ili dijagrame toka upravljanja; pseudokd; putanje testiranja; unakrsno referenciranje komponenti i promenljivih.

Grafike, tekstualne i tabelarne informacije mogu da se upotrebe za procenu da li sistemzahteva ili ne zahteva restrukturisanje. Meutim, kako nema preslikavanja izmeuspecifikacije i restrukturisanog kda, rezultujua dokumentacija odraava ono to jeste, a ne

ono to bi trebalo da bude.

Slika 6.2.Redokumentovanje [prilagoeno od Bohnera12]

6.3 Reverzni inenjering

Reverzni (obrnuti) inenjering se definie kao "proces analiziranja predmeta sistema u ciljuidentifikacije sistemskih komponenti, njihovih meusobnih odnosa i kreiranja prezentacije


31/76


Novi Pazar, 2013 31

sistema u drugom obliku ili na viem nivou apstrakcije". U skladu sa tim, reverzni inenjeringje proces ispitivanja, nije proces promena i zato ne ukljuuje menjanje softvera prilikomispitivanja.

Iako je softverski reverzni inenjering nastao u okviru softverskog odravanja, on se odnosina probleme i u mnogim drugim oblastima. Chikofsky i Cross13su identifikovali est kljunih

ciljeva reverznog inenjeringa:1. suoavanje sa kompleksnou,2. generisanje alternativnih pogleda,3. vraanje izgubljenih podataka,4. otkrivanje sporednih pojava,5. sinteza viih apstrakcija i6. omoguavanje ponovnog korienja.

Standard IEEE-121914 preporuuje reverzni inenjering kao kljunu tehnologiju za podrku,sa zadatkom da se bavi sistemima iji je izvorni kd jedina pouzdana predstava. Primeri

problema u oblastima gde je reverzni inenjering uspeno primenjen ukljuujuidentifikovanje elemenata za ponovno korienje15, pronalaenje objekata u proceduralnim

programima16, pronalaenje arhitekture17, izvoenje konceptualnih podataka modela18,otkrivanje duplikata19, transformisanje binarnih programa u izvorni kd20, obnavljanje

korisnikih interfejsa21, paralelizovanje sekvencijalnih programa22, prevoenje23 imigracije24.

Reverzni inenjering je teko definisati kao proces u strogim uslovima, jer je to nova oblastkoja se veoma brzo razvija. Tradicionalno gledano, reverzni inenjering je posmatran kao

proces iz dva koraka: ekstrakcija informacija i apstrakcija. Ekstrakcija informacija analizira

sistemske artifakte, prvenstveno izvorni kd, radi prikupljanja nesreenih podataka, dok

13Chikofsky, E. J., Cross II, J. H., "Reverse Engineering and Design Recovery: A Taxonomy", IEEE Software,

1990.14

IEEE Std. 1219-1998, "Standard for Software Maintenance", IEEE Computer Society Press, Los Alamitos,

CA, 1998.15

Canfora, G., Cimitile, A., Munro, M., "RE2: Reverse Engineering and Reuse Re-Engineering", Journal of

Software Maintenance - Research and Practice, 1994.16

Canfora, G., Cimitile, A., Munro, M., "An Improved Algorithm for Identifying Objects in Code", Software -

Practice and Experience, 1996.17

Lakhotia, A., "A Unified Framework for Expressing Software Subsystem Classification Techniques", The

Journal of Systems and Software, 1997.18

Blaha, M. R., Premerlani, W. J., "An Approach for Reverse Engineering of Relational Databases",

Communications of the ACM, 1994.19

Kontogiannis, K., De Mori, R., Merlo, E., Galler, M., Bernstein, M., "Pattern Matching for Clone and

Concept Detection", Journal of Automated Software Engineering, 1996.20

Cifuentes, C., Gough, K. J., "Decompilation of Binary Programs", Software -Practice and Experience, 1995.21

Merlo, E., Gagne, P.-Y., Girard, J.-F., Kontogiannis, K., Hendren, L., Panangaden, P.,De Mori, R., "Re-

engineering User Interfaces", IEEE Software, 12(1):64-73, 1995.22

Bhansali, S., Hagemeister, J. R., Raghavendra, C. S., Sivaraman, H., "Parallelizing Sequential Programs by

Algorithm-Level Transformations", Proceedings of the 3rd Workshop on Program Comprehension, Washington,

DC, IEEE Computer Society Press, Los Alamitos, CA, 1994.23

Byrne, E. J., "Software Reverse Engineering: A Case Study", Software - Practice and Experience,

21(12):1349-1364, 1991.24

Canfora, G., De Lucia, A., Di Lucca, G. A., "An Incremental Object-Oriented Migration Strategy for RPG

legacy Systems", International Journal of Software Engineering and Knowledge Engineering, 9(1):5-25, 1999


32/76


Novi Pazar, 2013 32

apstrakcija informacije kreira korisniki-orijentisana dokumenta i poglede. Tilley i Paul25predlau preliminaran korak koji se sastoji od izgradnje modela za specifine domenesistema, koristei konceptualne tehnike modelovanja.

IEEE standard za softversko odravanje14 ukazuje da se proces reverznog inenjeringa

evoluira kroz est koraka:1. ralanjavanje izvornog kda u formalne jedinice;2. semantiki opis formalne jedinice i kreiranje funkcionalnih jedinica;3. opis linkova za svaku jedinicu (dijagram ulazno / izlaznih jedinica);4. kreiranje mape svih jedinica i onoga to sledi od uzastopno povezanih jedinica

(linearni ciklusi);

5. deklaracije i semantiki opis sistemskih aplikacija6. stvaranje anatomije sistema.

Prva tri koraka se bave lokalnom analizom na nivou jedinica (u malom), dok se ostala tri

koraka odnose na globalnu analizu na sistemskom nivou (u velikom).

Benedusi26zagovara potrebu za uvoenjem visokog nivoa organizacionog obrasca prilikompostavljanja sloenih procesa u oblasti kao to je reverzni inenjering, u kojem metodologija ialati nisu stabilni, ali se stalno razvijaju. Uloga takvog obrasca nije samo da definie okvir ukojem se mogu koristiti dostupne metode i alati, nego i da dopustiti ponavljanje procesa u

cilju boljeg razumevanja istih i uenja iz njih. Predloen je obrazac, nazvanCiljevi/Modeli/Alati, koji deli postavljanje procesa reverznog inenjeringa u tri sekvencijalnefaze: Ciljevi, Modeli i Alati.

Ciljevi- Ovo je faza u kojoj se analizira motivacija za postavljanje procesa kako bi se

identifikovale potrebe za informacijama i apstrakcije koje treba uraditi.

Modeli- Ovo je faza u kojoj se apstrakcije identifikovane u prethodnoj fazi, analiziraju kako

bi se definisali modeli za prihvatanje informacija potrebnih za njihovu izradu.

Alati- Ovo je faza za utvrivanje, uzimanje, jaanje, integraciju ili izgradnju: Ekstrakcionih alata i procedura, koji slue za ekstrakciju (vaenje) sistemskih greaka

iz nesreenih podataka potrebnih za instalaciju modela definisanog u u fazi modela, Apstrakcionih alata i procedura, koji slue za transformaciju programskog modela u

apstrakcioni model definisanog u fazi "Ciljevi".

Obrazac Ciljevi/Modeli/Alatise opseno koristi za definisanje i izvravanje nekoliko realnihprocesa reverznog inenjeringa26.

6.4 Reinenjering

Praksa reinenjeringa softverskog sistema doprinosi boljem razumevanju tog softvera injegovom odravanju, dugo je ve prihvaena od strane zajednice softverskog odravanja.Chikofsky i Cross14definiu reinenjering kao "ispitivanje i izmenu predmeta sistema u cilju

25Tilley, S. R., Paul, S., "Towards a Framework for Program Understanding ",Proceedings of the 4th Workshop

on Program Comprehension, Berlin, Germany, IEEE Computer Society Press, Los Alamitos, CA, 199626

Benedusi, P., Cimitile, A., De Carlini, U., "Reverse Engineering Processes, Document Production and

Structure Charts", The Journal of Systems and Software, 16:225-245, 1992.


33/76


Novi Pazar, 2013 33

rekonstrukcije u novu formu, a zatim i implementaciju tih novih formi". Arnold27, daje

sveobuhvatnu definiciju:

"Softverski Reinenjering je aktivnost koja: (1) poboljava razumevanje softvera, ili (2)priprema i poboljava sam softver, obino za poveanu sposobnost odravanja, ponovnokorienje, ili evoluciju."

Evidentno je da reinenjering podrazumeva neki oblik reverznog inenjeringa za kreiranjevie apstraktnog pogleda sistema, a regeneracija ovog apstraktnog pogleda sledi iz naprednihinenjerskih aktivnosti za realizaciju sistema u novom obliku. Ovaj proces je prikazan na slici6.3.

Slika 6.3.Reverzni inenjering i reinenjering

Softverski reinenjering se pokazao kao vaan iz nekoliko razloga. Britcher 28, identifikujesedam glavnih razloga koji pokazuju relevantnost reinenjeringa:

1. Reinenjering moe pomoi pri smanjenju rizika evolucije2. Reinenjering moe pomoi organizaciji pri nadoknadi svojih ulaganja u softver3. Reinenjering moe doprineti lakem menjanju softvera4. Reinenjering je veliki biznis5. Reinenjering sposobnosti proiruju CASE alate6. Reinenjering je katalizator za automatsko odravanje softvera7. Reinenjering je katalizator za primenu tehnika vetake inteligencije

Primeri scenarija u kojima se reinenjering pokazao korisnim ukljuuje migraciju sistema sjedne na drugu platformu28, smanjenje veliine29, prevoenje23, smanjenje trokova

27Arnold, R. S., "A Road Map to Software Re-engineering Technology", Software Reengineering a tutorial,

IEEE Computer Society Press, Los Alamitos, CA, 1993, pp. 3-22.28

Britcher, R. N., "Re-engineering Software: A Case Study", IBM System Journal, 29(4):551-567, 1990.29

Sneed, H., Nyary, E., "Downsizing Large Application Programs", Proceedings of the InternationalConference on Software Maintenance, Montreal, Quebec, Canada, IEEE Computer Society Press, Los Alamitos,

CA, 1993.


34/76


Novi Pazar, 2013 34

odravanja30, poboljanje kvaliteta31, migraciju i reinenjering podataka32. Standard IEEE-121914pokazuje da reinenjering ne samo to moe revitalizovati sistem, ve i prua koristanmaterijal za budui razvoj, ukljuujui okvire za objektno-orijentisana okruenja.Softverski reinenjering je sloen proces koji reinenjering alati mogu samo da podre, ali ine da potpuno automatizuju. Postoji i dobar deo ljudske intervencije u bilo kom softverkom

reinenjering projektu.Uspeh softverskog reinenjeringa zahteva mnogo vie od kupovine jednog ili viereinenjerskih alata. Definisanje reinenjerskih ciljeva, formiranje tima i njihova obuka,

procena stepena do kojeg se alati mogu integrisati, samo su neki primeri aktivnosti koje

doprinose odreivanju uspeha reinenjering projekta. Sneed29 predlae pet koraka koje trebauzeti u obzir prilikom planiranja reinenjering projekta: opravdanost projekta, portfolioanalizu, procenu trokova, analizu koristi i trokova i ugovaranje.Da bi se ispravno shvatilo, gde i kako nastaju greke u projektovanju i izradi softvera, a toznaajno utie na proces odravanja softvera koji treba na optimalan nain uspostaviti isprovoditi u narednom poglavlju bie opisani elementi jednog modela procesa odravanjasoftvera koji je izuavan u okviru kursa iz Softverskog iz koga je i nastao ovaj rad.

7Projekat PISA

PISAje projekat koji finansira Ministarstvo prosvete, nauke i tehnolokog razvojaRepublike Srbije u okviru projekta tehnolokog razvoja:"OPTIMALNO UPRAVLJANJEPROCESOM RAZVOJA KVALITETNOG SOFTVERA ", od 2011-2014 broj TR 35026. U

ovom projektu razraen je proces testiranja i odravanja softvera koje omoguavajukvantitativnu procenu uspenosti ovog kritinog dela procesa razvoja softvera. Testiranjesoftvera ukljuuje proces otkrivanja neusaglaenosti softvera kako bi one bile ispravljene prenego budu instalirane u ivo okruenje od kojih zavisi svakodnevni rad poslovnih jedinicakompanije. Imajui to u vidu, testiranje nikada ne moe u potpunosti da utvrdi ispravnostraunarskog softvera. Samo proces formalne verifikacije moe dapokae da u softveru nemagreaka. Uspeno isplanirano i sprovedeno testiranje softvera od samog poetka dizajnasoftvera direktno utie na proces, organizaciju i trokove odravanja softvera.

Testiranje je aktivnost koja se sprovodi radi evaluacije kvaliteta proizvodnje softvera i

njegovog poboljanja. Ono nije aktivnost koja poinje samo nakon kompletiranja fazekodiranja. Softversko tes

odrzavanje softvera

Documents