Transcript Starenje Softvera

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