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

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

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

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

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

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