starenje softvera
Post on 21-Mar-2017
42 Views
Preview:
TRANSCRIPT
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
top related