Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Starenje softvera

147 views

Published on

Predavanje sa beogradskog ETF-a, iz predmeta evolucija softvera.

Svi materijali su javno dostupni i nalaze se ovde: http://rti.etf.bg.ac.rs/

Published in: Software
  • Be the first to comment

  • Be the first to like this

Starenje softvera

  1. 1. Starenje Softvera
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Posledice starenja softvera  Neodrživost  Gubitak performansi  Smanjena pouzdanost
  14. 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. 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. 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. 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. 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. 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. 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. 21. Mere prevencije  Pametno projektovanje  Pisanje dokumentacije  Traženje drugog mišljenja (recenzija)
  22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 42. Literatura  Software Aging, David Lorge Pamas  Laws of Software Evolution Revisited, M M Lehman

×