O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Starenje softvera

229 visualizações

Publicada em

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

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

Publicada em: Software
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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

×