Starenje Softvera

Sadržaj Proces starenja softvera Uzroci za starenje softvera Posledice starenja softvera Ublažavanje efekta starenja Neizbežnost starenja softvera lemanovi zakoni starenja softvera Literatura

Proces starenja softvera (1) Programi, kao i ljudi, stare. Mi ne možemo

zaustaviti starenje, ali možemo da shvatimo uzroke starenja softvera, preduzmemo korake koji bi ogranicili efekte ovog procesa, privremeno popravimo neke od posledica koje je starenje uzrokovalo i pripremimo se za dan kada taj softver više nije održiv. Ne smemo da se koncentrišemo samo na prvu prdstavu softvera već i na dugoročno zdravlje našeg prizvoda.

D.L. Parnas

Proces starenja softvera (2) Da li ima smisla pricati o starenju softvera?

Softver je matematički proizvod, a matematika se ne menja vremenom

Ako je teorema bila tačna pre 200 godina ona će biti tačna i sutra

Ako program radi ispravno sada, radiće ispravno i za 100 godina

Ako se za 100 godina utvrdi da program ne radi ispravno, mora biti da nije radio ispravno ni kada je napisan

Ovi iskazi su tačni ali ne i relevantni

Proces starenja softvera (3) Starenje softvera je neizbežan proces U mnogome je sličan procesu starenja

ljudi Moguće je usporiti proces Ponekad, možemo čak da obrnemo

proces starenja (revitalizacija)

Starenje softvera (4) Sa vremenom raste značaj starenja

softvera Rast ekonomske važnosti softvera Softver predstavlja veliki deo kapitala

mnogih modernih kompanija Mnogi programi su postali oslonac

današnjeg društva Zastarevanje programa koči dalji razvoj

sistema koji ih koriste

Starenje softvera (5) Autori i vlasnici novog softvera na proces

starenja softvera često gledaju sa prezirom

Svaki program ima svoj vek Starenje softvera nije nov fenomen

Uzroci starenja softvera Postoje dva glavna razloga starenja softvera

Izostanak napredka – starenje kao posledica nemogućnosti programera da izvrši potrebne izmene programa kako bi išao u korak sa vremenom

Narušavanje dizajna – promene u kodu programa koje uzrokuju narušavanje originalnih pricipa dizajna

Rapidno dovode do degradacije vrednosti softvera

Izostanak napretka (1) Potreba za konstantnim izmenama

programa Dodavanje novih funkcionalnosti Praćenje trendova

Usled nedostatka izmena Smanjuje se konkurentnost softvera Smanjuje se zadovoljstvo korisnika Korisnik prelazi na novo rešenje

Izostanak napretka (2) Odličan softver napravljen šezdesetih

godina će raditi savršeno dobro i danas ali ga niko neće koristiti

Taj softver je zastareo iako ga niko nije menjao

Zapravo on je i zastareo jer ga niko nije menjao

Narušavanje dizajna (1) Iako neophodne, izmene softvera mogu

dovesti do starenja Svaka izmena zahteva izmenu

dokumentacije Ovaj korak se često preskače u praksi Dokumentacija vremenom postaje netačna

Izmene u kodu napravljene od strane ljudi koji u potpunosti ne razumeju koncept uglavnom dovode do degradacije strukture programa

Narušavanje dizajna (2) Nakon više ovakvih izmena skoro je

nemoguće razumeti koncept Programeri koji su dizajnirali i razvili originalni

koncept ne razumeju modifikovani proizvod Oni koji su pravili izmene i dalje ne razumeju

koncept Kod programa postaje “nečitljiv” Nove izmene dovode do pojavljivanja novih

grešaka (eng. bugs) Povećava se cena održavanja softvera

Posledice starenja softvera Neodrživost Gubitak performansi Smanjena pouzdanost

Neodrživost (1) Dok stari, softver postaje sve veći Najlakši način da se doda nova

funkcionalnost u već postojeći softver je dodavanje novog koda

Neodrživost (2) Modifikacije postaju sve teže sa

povećanjem veličine softvera Raste veličina koda koji treba promeniti Sve je teze naći delove koje treba promeniti

Kao rezultat dešava se to da se korisnik prebaci na mlađi softver u potrazi za novim funkcijama

Gubitak performansi (1) Kako se veličina programa povećava on

zahteva više memorije za rad Brzina izvršavanja opada zbog lošeg

dizajna dobijenog dugoročnim ad-hoc održavanjem, što podrazumeva brza rešenja koja nisu obavezno i najoptimalnija

Gubitak performansi (2) Korisnici moraju da poboljšaju svoje

računare kako bi od programa dobili prihvatljiv odziv

Mlađi softver će raditi brže i koristiti manje memorije

Smanjena pouzdanost Održavanje softvera dovodi do stvaranja

grešaka (eng. bugs) Jedna ispravljena greška može dovesti do

stvaranja više novih grešaka Može doći do narušavanja postojećih

funkcionalnosti Pokušaji smanjivanja broja grešaka

mogu da izazovu kontra efekat

Ublažavanje efekta starenja (1) Neiskusni programeri se polakome posle

prvog uspešnog kompajliranja ili demonstracije

Iskusni programeri znaju da je to tek početak… Svaki ozbiljan proizvod zahteva opsežno

testiranje i rigorozne recenzije

Ublažavanje efekta starenja (2) U razvoju softvera najviše značaja se

pridaje izbacivanju prve verzije softvera Stvari treba posmatrati iz ugla kada

softver zastari, tj. mnogo posle izbacivanja prve verzije

Ublažavanje efekta starenja softvera zahteva mnogo truda i iskustva

Mere prevencije Pametno projektovanje Pisanje dokumentacije Traženje drugog mišljenja (recenzija)

Pametno projektovanje (1) Softver treba projektovati tako da u

budućnosti bude pogodan za izmene (eng. design for change)

Ovaj princip je poznat i kao: Skrivanje informacija Apstrakcija Odvajanje kritičnih delova Skrivanje podataka Objektno orijentisani pristup

Pametno projektovanje (2) Da bi se primenio ovaj princip treba

prepoznati koje promene će se verovatno zahtevati u toku životnog veka programa.

Kako stvarne promene ne možemo da predvidimo, naša predviđanja delimo u klase: Promene u korisničkom interfejsu Promene u opisu podataka Promene vezane za prelazak na novi

operativni sistem

Pametno projektovanje (3) Pošto je nemoguće napisati takav kod da će

svaka izmena biti laka, najvažnije je da: Procenimo verovatnoću svake klase (tipa)

promene Organizujemo softver tako da delove za koje je

verovatno da će se menjati ograničimo na mali deo koda

Problem: udžbenici uglavnom ne objašnjavaju proces predviđanja učestalosti promena za razne klase promena

Pametno projektovanje (4)Ignorisanje loših uzora Programeri su nestrpljivi i željni da naprave

prvu radnu verziju softvera Dizajn koji je produkt ovog principa je

drugačiji od “prirodnog” rešenja Sklonost ka imitiranju postojećih (loših)

rešenja Mešanje principa dizajna sa programskim

jezicima Mnogi ljudi koji pišu programe nikad nisu

imali obuku iz razvoja softvera

Pisanje dokumentacije Inženjeri često ne dokumentuju glavne principe

i odluke donete tokom dizajniranja softvera Kada dokumentacija postoji, ona je često

Loše organizovana Nedosledna Nepotpuna Pisana od strane ljudi koji nisu razimeli dati sistem

Dokumentaciju ili ne koriste oni koji vrše dalje izmene u sistemu ili, još gore, dokumentacija nije ni napisana jer je usporavala prvi izlazak programa na tržiste

Traženje drugog mišljenja (1) U razvoju softvera, kao i u medicini,

traženje drugog mišljenja je neophodno U procesu dizajniranja zgrada, brodova,

vazduhoplovnih prevoznih sredstava, postoji uvek serija dokumentacije nad kojom se obavezno vrši precizna recenzija od strane drugih profesionalaca iz te oblasti

Svako rešenje mora da bude provereno od strane osobe koja je zadužena za dugotrajnost proizvoda

Traženje drugog mišljenja (2) Ovaj princip se često ne poštuje u

softverskoj industriji Mnogi programeri nisu imali nikakvu

profesionalnu obuku Teško je naći ljude unutar firme koji mogu

na kvalitetan nacin da izvrše recenziju, a skupo je unajmljivati ljude van firme

Zadati rokovi obmanjuju programere pa im se čini da nema nikad vremena za recenziju

Mnogi programeri ne žele da se nad njihovim radom vrši recenzija

Neizbežnost starenja softvera Naša sposobnost da napravimo softver koji

je lako menjati zavisi od naše sposobnosti da predvidimo budućnost

Napraviće se izmene koje će ugroziti originalne predpostavke na kojima se bazira rad sistema

Dokumentacija nikad neće biti savršena Recenzenti će sigurno prevideti neke mane Preventivne mere se sigurno isplate ali

svako ko misli da će uspeti da eliminiše starenje softvera nije u pravu

Softverska gerijatrija Retroaktivna dokumentacija – poboljšanje

kvaliteta dokumentacije starog softvera Retroaktivna modularizacija – promena

strukture tako da svaki modul sakriva delove dizajna koje će se verovatno menjati

Amputacija – ako je neki deo koda mnogo puta (nepromišljeno) modifikovan, nije vredan čuvanja

Restruktuiranje – identifikovati i eliminisati redundantne komponente i nepotrebne zavisnosti

Lemanovi zakoni evolucije Dinamika evolucije programa je

studija o procesima promene softverskih sistema

Posle značajnih empirijskih studija, Lehman i Beladi su predložili niz “zakona” koji se mogu primeniti na sve softverske sisteme koji evoluiraju

Lemanovi zakoni evolucije Bazirani su na evoluciji IBM 360

mainframe OS tokom perioda od 30 godina.

Odnose se na sisteme E tipa [leh80b] - softverski sistemi koji rešavaju neki problem ili implemetiraju kompijutersku aplikaciju u realnom svetu

Lemanovi zakoni evolucije 1. Zakon: Kontinualno menjanje 2. Zakon: Povećanje kompleksnosti 3. Zakon: Samoregulacija 4. Zakon: Očuvanje organizacione

stabilnosti 5. Zakon: Očuvanje upoznatosti 6. Zakon: Kontinualni rast 7. Zakon: Pad kvaliteta 8. Zakon: Povratna sprega

Lemanovi zakoni evolucije 1. Kontinualno menjanje: Softver E tipa

koji se koristi u realnom okruženju je nophodno kontinualno adaptirati. U suprotnom postaje neispravan

Softverski sistem zavisi od uticaja okruženja Analogija sa živim organizmom i biološkim

okruženjem Kao rezultat napredka (evolucije)

okruženja, povećava se neusaglašenost izmedju sistema i okruženja u kome radi

Lemanovi zakoni evolucije 2. Povećanje kompleksnosti: Ukoliko se ne

preduzmu odgovarajuće mere, evolucija softverskog sistema dovodi do povećanja njegove kompleksnosti

Razlozi: Nad sistemom se stalno vrše male promene kao bi

se prilagodio okruženju Svaka promena ima smisla sama za sebe ali

globalno ona uzrokuju povećanje kompleksnosti Ovim se povećava entropija (neuređenost) sistema

Stvara potrebu za optimizacijom i reorganizacijom (refactoring) koda

Lemanovi zakoni evolucije 3. Samoregulacija: Evolucija softverskog

sistema je samo-regulativni proces Atributi sistema kao što su veličina, vreme

između dve radne verzije i broj prijavljenih grešaka su približno isti za svaku radnu verziju istog softvera. Vrednosti ovi atributa zavise od tima koji se

bavi unapređenjem softvera Postavljaju se kao cilj od strane

menadžmenta kompanije

Lemanovi zakoni evolucije 4. Očuvanje organizacione stabilnosti:

Prosečna efektivna globalna stopa aktivnosti sistema koji evoluira je nepromenljiva tokom radnog veka sistema

Uprkos verovanju, praksa je pokazala da odluke menadžmenta nisu presudan faktor pri određivanju napora potrebnog za razvoj softvera

Najviše uticaja imaju spoljni faktori na koje menadžment nema uticaja Korisnički zahtevi Stručnost tima koji razvija/održava softver

Navedeno u kombinaciji sa uticajima okruženja dovodi do stabilne stope aktivnosti sistema tokom vremena

Lemanovi zakoni evolucije 5. Očuvanje upoznatosti: Tokom

aktivnog radnog veka sistema broj promena nad svakom radnom verzijom sistema je priblizno isti

Jedan od faktora koji uticu na progres razvoja softvera je upoznatos svih koji u tome ucestvuju sa krajnjim ciljem razvoja datog softvera.

Lemanovi zakoni evolucije 6. Kontinualni rast: Funkcionalni

aspekt softvera mora kontinualno da se povećava (poboljšava) u cilju održanja stope zadovoljstva korisnika

Proizilazi iz prvog zakona (Kontinualno menjanje), s tim što se odnosi na funkcionalne zahteve

Lemanovi zakoni evolucije 7. Pad kvaliteta: Kvalitet programa E tipa će

opasti ukoliko se rigoroznim održavanjem ne adaptira promenljivom operacionom okruženju

Proizilazi iz prvog zakona (Kontinualno menjanje), sa fokusom na pouzdanost sistema

Ranije uvedene ograničenja ne moraju više biti validna

Objasnjava pojavu kada posle dugotrajnog zadovoljavajućeg rada softver odjednom ispolji neočekivano, ranije nikad viđeno ponašanje

Lemanovi zakoni evolucije 8. Povratna sprega: Proces

programiranja sistema E tipa obrazuje višeslojni sistem sa povratnom spregom i petljama i mora se tretirati kao takav da bi mogao uspešno da se modifikuje i unapredjuje

Literatura Software Aging, David Lorge Pamas Laws of Software Evolution Revisited, M M

Lehman