Predavanje sa beogradskog ETF-a, iz predmeta evolucija softvera. Svi materijali su javno dostupni i nalaze se ovde: http://rti.etf.bg.ac.rs/

1. Starenje Softvera

2. 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

3. Proces starenja softvera (1)
 Pro g ram i, kao i ljudi, stare . Mi ne m o ž e m o
z austaviti stare nje , ali m o ž e m o da shvatim o
uz ro ke stare nja so ftve ra, pre duz m e m o ko rake
ko ji bi o g ranicili e fe kte o vo g pro ce sa,
privre m e no po pravim o ne ke o d po sle dica ko je
je stare nje uz ro ko valo i pripre m im o se z a dan
kada taj so ftve r više nije o drž iv. Ne sm e m o da
se ko nce ntriše m o sam o na prvu prdstavu
so ftve ra ve i na dug o ro no z dravlje naše gć č
priz vo da.
 D.L. Parnas

4. 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

5. 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)

6. 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

7. 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

8. 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

9. Izostanaknapretka (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

10. Izostanaknapretka (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

11. 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

12. 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

13. Posledice starenja softvera
 Neodrživost
 Gubitak performansi
 Smanjena pouzdanost

14. 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

15. 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

16. Gubitakperformansi (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

17. Gubitakperformansi (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

18. 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

19. 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

20. 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

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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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.

39. 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

40. 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

41. 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

42. Literatura
 Software Aging, David Lorge Pamas
 Laws of Software Evolution Revisited, M M
Lehman