U ovoj lekciji obrađivaćemo vrste održavanja softvera sistema kroz:

  • Životni vek sistema
  • Trajanje evolucije sistema
  • Evolucija sistema prema prestanku rada
  • Zakoni evolucije softvera

 

Životni vek sistema

S obzirom na to da softverski inženjeri pokušavaju da isporuče proizvode koje je moguće održavati, osnovno pitanje koje se postavlja jeste da li je moguće iz prve izgraditi ispravan sistem. Drugim rečima, ako koristimo komponente veoma visokog stepena kohezije i niskim stepenom sprezanja, ako je dokumentacija kompletna i ažurna i ako je ceo sistem unakrsno referenciran, da li će održavanje biti uopšte potrebno? Nažalost, odgovor je potvrdan. Razlozi leže u prirodi samih sistema. Kao što smo videli, nema načina da se garantuje da P-sistemi ili E-sistemi neće zahtevati izmene. U stvari, moramo pretpostaviti da će se oni menjati i izgraditi ih tako da su njihove naknadne izmene jednostavne.

 

Naše sledeće pitanje mora da bude: Koja količina izmena može da se očekuje? Odgovor opet zavisi od prirode sistema. S-sistemi će se malo ili nimalo menjati. P-sistemi će se menjati više, a E-sistemi će se verovatno stalno menjati. Zato mnogi softverski inženjeri više vole da fazu održavanja u razvoju zovu fazom evolucije. Govorimo o nasleđenim sistemima, izgrađenim ranije, kada su naše potrebe i okruženje bili drugačiji. Nasleđene sisteme moramo procenjivati i pomagati im da evoluiraju kada tehnologije i poslovni razlozi zahtevaju evoluciju. U nekom trenutku možemo odlučiti da nasleđeni sistem u celosti zamenimo novim ili da ga jednostavno povučemo iz upotrebe zato što se više ne koristi.

 

Vreme za razvoj prema vremenu za održavanje

Da bismo stekli predstavu o tome koliko dugačku fazu evolucije treba da očekujemo, možemo pogledati vremena razvoja i održavanja drugih projekata. Prema Parikhu i Zvegincovu, tipičan razvojni projekat uzima od jedne do dve godine, ali zahteva vreme održavanja od još pet do šest godina. Izraženo u uloženom radu, više od polovine programerskih resursa se potroši na održavanje. U pregledu koji su dali Fjeldstad i Hamlen, izveštava se o sličnom odnosu: 25 organizacija za obradu podataka su izjavile da su u proseku uložile 39% rada u razvoj, a 61% u održavanje (ispravljanje grešaka, modifikacije i podrška korisnika). U skorašnjim pregledima se prikazuju slični rezultati, a mnogi projektanti primenjuju pravilo 80-20: 20% rada pripada razvoju, a 80% održavanju.

 

Evolucija sistema prema prestanku rada

Kada sistem zahteva značajne i stalne izmene, moramo da odlučimo da li je bolje da odbacimo stari sistem i zamenimo ga novim. Da bismo to utvrdili, moramo da postavimo nekoliko pitanja:

  • Da li su troškovi održavanja previsoki?
  • Da li je pouzdanost sistema neprihvatljiva?
  • Da li sistem više ne može da se prilagodi daljim izmenama u razumnom vremenu?
  • Da li su performanse sistema i dalje izvan propisanih ograničenja?
  • Da li su sistemske funkcije nedovoljno korisne?
  • Da li drugi sistemi mogu da urade isti posao bolje, brže ili jeftinije?
  • Da li su troškovi održavanja hardvera dovoljno visoki da opravdaju njegovu zamenu jeftinijim, novijim hardverom?

 

Pozitivan odgovor na sva ili samo na neka od ovih pitanja može da znači da je došao trenutak da se razmotri zamena starog sistema novim. Suma svih troškova vezanih za razvoj i održavanje sistema, od njegovog nastanka do prestanka korišćenja, naziva se cena životnog ciklusa. Odluku da li da održavamo, ponovo izgradimo ili zamenimo, često zasnivamo na poređenju troškova životnog ciklusa starih, revidiranih ili novih sistema.

 

Zakoni evolucije softvera

 

Odluke koje se tiču održavanja podržane su razumevanjem onoga što se dešava sistemima tokom vremena. Od interesa su izmene veličine, složenost, potrebni resursi i lakoća održavanja. O evolucionim trendovima možemo mnogo da naučimo testiranjem izmena u sklopu velikih sistema. U toku svoje karijere, Lehman je posmatrao ponašanje sistema tokom njihove evolucije. Svoja otkrića je sumirao u pet zakona evolucije programa:

  1. Stalna izmena - Program koji se koristi stalno doživljava izmene, ili postaje progresivno sve manje upotrebljiv. Izmene ili proces propadanja se nastavljaju dok ne postane isplativije da se sistem zameni novom verzijom.
  2. Povećavanje složenosti - Kako se program evolutivno menja, njegova struktura se remeti. To se ogleda u povećanju složenosti, sem ako se ne uloži rad u njeno održavanje ili smanjivanje.
  3. Fundamentalni zakon evolucije programa - Evolucija programa je podložna dinamici koja proces programiranja, a otud i mere globalnog projekta i sistemskih atributa, čini autonomno regulativnim, sa statistički definisanim trendovima i invarijantama.
  4. Konzervacija organizacione stabilnosti (nepromenljiva brzina rada) - Tokom aktivnog života programa, globalna brzina aktivnosti u projektu programiranja je statistički nepromenljiva.
  5. Konzervacija bliskosti (uočena složenost) - Tokom aktivnog života programa, sadržaj (izmene, dodaci, izbacivanja) uzastopnih izdanja programa koji evoluira je statistički nepromenljiv.

U prvom zakonu se kaže da veliki sistemi nisu nikada dovršeni; oni neprekidno evoluiraju. Sistemi se šire sa dodavanjem novih svojstava, primenom više ograničenja, sadejstvom sa drugim sistemima, podrškom za više korisnika itd. Oni se takođe menjaju zbog izmena u njihovim okruženjima: prenose se na druge platforme, ili preprogramiraju na drugim jezicima.

Drugi zakon nam kaže da kako evoluiraju, veliki sistemi postaju sve složeniji, sem ako ne preduzmemo mere da tu složenost smanjimo. Često se taj porast složenosti dešava zbog neophodnosti brzih popravki koje za cilj imaju otklanjanje problema. Jednostavno nemamo vremena da u kodu održavamo eleganciju dizajna ili konsistentnost pristupa.

Prema trećem zakonu, softverski sistemi pokazuju pravilnosti u ponašanju i trendovima koje možemo da merimo i predviđamo. Mnogi istraživači u oblasti softverskog inženjerstva posvetili su se pronalaženju tih „univerzalnih istina" razvoja i održavanja softvera, slično kao što fizičari traže vetiku objedinjavajuću teoriju.

U četvrtom zakonu se kaže da ne postoje neobuzdane i velike fluktuacije u svojstvima organizacije kao što je na primer, produktivnost. To znači da, u nekom trenutku, resursi i izlaz dostižu optimalni nivo i da dodavanje više resursa ne menja značajno izlaz.

Slično tome, peti zakon kaže da posle izvesnog vremena, efekti sledećih izdanja neznatno doprinose opštoj funkcionalnosti sistema.
U sledećem primeru opisana je evolucija velikog sistema u kompaniji Bell Atlantic.

 

Primer 1.  Bell atlantic menja tri sistema jednim koji evoluira

Godine 1993, kompanija Bell Atlantic (sada poznata kao Verizon) uvela je Sale Service Negotiation System (SSNS), kao zamenu za tri nasleđena sistema koji su podržavali operatere da preuzimaju porudžbine za nove telefonske usluge. Početni ciljevi sistema bili su minimizacija grešaka i smanjenje vremena koje predstavnici davaoca usluga provode u telefonskom razgovoru sa kupcima. Ali kako je komercijala koristila sistem, u rukovodstvu kompanije su uočili njegov veliki potencijal za promociju Bell Atlantic-ovih proizvoda koji bi mogli da zadovolje potrebe kupaca. Ciljevi su se promenili jer sistem više nije trebalo da služi za preuzimanje narudžbina, nego za prodaju zasnovanu na potrebama.

Proces naručivanja u sklopu SSNS-a veoma je sličan intervjuisanju od strane sistema. Kako kupac unosi sve više informacija o sebi, SSNS mu skreće pažnju na relevantne proizvode. Otuda je nužno da se SSNS na adekvatan način osnažuje kako Bell Atlantic proširuje svoju proizvodnu i uslužnu liniju. SSNS je već bio proširen rukovanjem informacijama vezanim za izdavanje računa, proveru adrese i kreditne sposobnosti uz oslonac na udaljene baze podataka, automatskim informisanjem kupaca o potvrdi usluge i snabdevanjem službenika informacijama i pitanjima vezanim za usluge.

U sistemu su takođe arhaične komande zamenjene jednostavnim engleskim jezikom, a mnogo toga što se ranije nalazilo u priručniku od 20 tomova, sada je postavljeno onlajn. Izvršeno je prilagođavanje sistema u nekim državama, zbog različitih propisa koji uređuju pružanje telefonskih usluga. Nadležne ustanove zahtevale su od Bell Atlantica da obelodani specifične informacije o proizvodima na početku intervjua, pa je sistem gde je to bilo potrebno, tako i podešen.

Prvobitno napisan na jezicima C i C++, sistem je modifikovan oslanjajaći se na programski jezik Java krajem 1990-ih godina, da bi se obezbedila intranet verzija dostupna mobilnim trgovačkim predstavnicima. Kako su pravilima, proizvodima, tehnologijama i poslovanju potrebne izmene, SSNS mora da evoluira sa njima.

 

Priroda održavanja

Kada razvijamo sisteme, u osnovi smo usredsređeni na izradu koda koji implementira zahteve i radi ispravno. U svakoj fazi razvoja, naš tim se stalno oslanja na rad obavljen u prethodnim fazama. Komponente dizajna se povezuju sa specifikacijom zahteva, komponente koda se unakrsno referenciraju i pregledaju radi usaglašavanja sa dizajnom, a testovi se zasnivaju na proveri da li funkcije i ograničenja deluju u skladu sa zahtevima i dizajnom. Dakle, razvoj obuhvata i osvrtanje unazad, na pažljiv i kontrolisan način.

Održavanje je drugačije. Ljudi iz održavanja vode računa o proizvodima procesa razvoja, ali i o sadašnjosti uspostavljajući spregu sa korisnicima i operaterima da bi utvrdili kako su oni zadovoljni načinom rada sistema. Takođe moraju gledati i unapred da bi predvideli stvari koje mogu da krenu loše, razmotrili izmene funkcionalnosti koje su posledica izmena u poslovanju i sagledali izmene sistema koje su posledica izmene hardvera, softvera ili interfejsa. Dakle, održavanje ima širi opseg, sa više elemenata koje je potrebno pratiti i kontrolisati. Ispitaćemo u narednoj lekciji aktivnosti koje su neophodne za ravnomeran rad sistema i identifikovati ko te aktivnosti treba da sprovodi.

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Evolucija softverskog sistema 1
  • Evolucija softverskog sistema 2
  • Evolucija softverskog sistema 3