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