1. Elektrotehnički fakultet u Beogradu Evolucija softvera
Modeli procesa u održavanju i evoluciji softvera
Mentor: dr Dragan Bojić
Autor: Marko Mitrović
februar 2009.

2. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanja i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

3. Uvod
Softver je u savremenom svetu sveprisutan (posao, zabava, komunikacije, informisanje, infrastruktura...)
U godini ukupan prihod 500 najvećih softverskih kompanija iznosio je 451,8 milijardi dolara (Software Magazine)
Procene su da je na svetu postojalo oko 240 milijardi linija aktivnog koda samo u COBOL-u (Gartner Group)

4. Uvod
Modeli razvoja softvera nastaju kao odgovor na sve veću upotrebu računara i potrebu za sve bržim i pouzdanijim razvojem
Osim potrebe za razvojem, postoji i sve veća potreba za održavanjem i stalnim unapređivanjem postojećih programa
Deo ranije pomenutog COBOL koda u produkciji je i više desetina godina – bez održavanja brzo bi postao neupotrebljiv

5. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanje i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

6. Osnovni pojmovi i definicije
Proces – niz akcija preduzetih da bi se razvio neki konkretan program (ili, uopšteno, postigao nekakav cilj)
Model procesa – uopštena reprezentacija procesa, apstraktni opis nekog načina razvoja softvera
Životni vek softvera (software lifecycle) – period od nastanka ideje, preko razvoja, upotrebe i održavanja do prestanka korišćenja softvera

7. Osnovni pojmovi i definicije
Životni vek podrazumeva ciklično ponavljanje osnovnog razvojnog procesa sa svakom novom idejom za izmenu i proširenje postojećeg sistema
Kasnije uvodimo pojmove održavanja i evolucije

8. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanja i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

9. Klasični razvojni modeli
Neophodno je najpre upoznati razvojne modele da bi se razumeli njihovi nedostaci i potreba za posebnim evolutivnim modelima
Osnovni ciklus razvoja i života softvera:

10. Klasični razvojni modeli
Sledi pregled sledećih modela razvoja:
Code and fix (Kodiraj i popravi)
Waterfall (Vodopad)
Spiral (Spiralni model)
Agile (Agilni modeli)
Ovo su samo neki od postojećih razvojnih modela
Izabrani su jer se najčešće primenjuju i dobro ilustruju tendencije i osnovne principe

11. Klasični razvojni modeli
Code and fix
Dve faze koje se ciklično ponavljaju (kodiranje i ispravka bagova)
Najjednostavniji, prvi u upotrebi
Sve faze osnovnog ciklusa osim implementacije kondezovane u fix fazu
Veoma loš model; zbog ad-hoc pristupa i nedostatka planiranja, procene rizika i uticaja pojedinih izmena na ostatak koda održavanje i unapređivanje brzo postaje nemoguće
Još uvek se često koristi zbog nedovoljno resursa za primenu boljih modela (vremena, novca, ljudi)

12. Klasični razvojni modeli
Waterfall (1/2)
Najčešće korišćeni model
Sastoji se od pet jasno definisanih faza
Svaka faza počinje tek kad su sve prethodne završene i dokumentovane (document driven model)
Dobre strane: jasno definisan tok razvoja; velika pažnja se posvećuje analizi i dizajnu pre samog kodiranja; verifikacija i testiranje nakon implementacije; dobra dokumentovanost
Loše strane: neophodno završiti sve prethodne faze pre početka nove (veliki timovi – puno čekanja); jednosmeran model (nema povratne sprege među fazama); otkrivanje greške je skuplje u kasnijim fazama (ali tada je i verovatnije!); neophodno je znati potpunu specifikaciju na početku razvoja

13. Klasični razvojni modeli
Waterfall (2/2)
Waterfall model je osnov za mnoge druge modele (uvođenje povratne sprege među fazama, zatvaranje u ciklus itd.)
Najveći problemi kod ovog modela nastaju pri čestoj promeni zahteva, dodavanju novih u hodu itd.
Problem često nije posledica greške u inicijalnoj specifikaciji i dizajnu već prirode realnog sistema koji softver modelira (specifikacija može biti potpuno tačna u jednom trenutku, a netačna već sutra dan!)
Zbog toga se uvode fleksibilniji, iterativni, modeli koji rešavaju upravo problem evoluiranja korisničkih zahteva

14. Klasični razvojni modeli
Spiral (1/2)
Jedan od prvih Iterativnih modela
Uvodi ga Barry Boehm u članku “A Spiral Model of Software Development and Enhancement”
4 faze koje se ciklično ponavljaju:
Određivanje ciljeva, alternativa i ograničenja
Poređenje alernativa, procena i eliminacija rizika
Implementacija i testiranje
Praniranje sledećih iteracija

15. Klasični razvojni modeli
Spiral (2/2)
Iteracije se mogu odnositi na razvoj novog sistema, ali i na evolutivno dodavanje funkcionalnosti sistemu i ispravljanje nedostataka
Na kraju svake iteracije dobija se manje ili više funkcionalan sistem (ili bar prototip) – nije neophodno da sve funkcionalnosti budu gotove da bi se evaluirao i koristio već implementirani deo
Rizici, ograničenja i alternativna rešenja na nivou iteracije razmatraju se pri njenom početku, a globalno u prvoj iteraciji – smanjuje se potreba za velikim regresivnim izmenama kao kod waterfall modela (gde problem može biti otkriven tek pri implementaciji)
Zahteva veliko iskustvo (u proceni rizika, planiranju, dizajnu, integraciji)
Najpogodniji za velike projekte kod kojih je pouzdanost kritična (pre npr. cene)

16. Klasični razvojni modeli
Agile (1/2)
Skup srodnih razvojnih modela (nastao oko 2000.), ne samo jedan model
Nastao kao odgovor na nedostatke waterfall i sličnih, previše krutih, modela
Cilj je postići što veću prilagodljivost na promene i što veće zadovoljstvo naručioca, pa se dokumentacija pravi po potrebi i zahtevu, a osnovna mera uspešnosti je funkcionalan softver
Razvoj se radi u malim timovima (do 10 ljudi) i kroz puno kratkih iteracija (svaka prolazi kroz sve faze, od analize zahteva do testiranja)
Bez obzira na namenu softvera, tim uvek sadrži bar jednog predstavnika klijenta koji aktivno učestvuje u svakodnevom radu
Umesto jasno definisanog procesa i čvrstog ugovora sa klijentima naglasak je na čestoj i otvorenoj komunikaciji

17. Klasični razvojni modeli
Agile (2/2)
Agile nije koncipiran specijalno za proces održavanja softvera, ali najviše od svih razvojnih pristupa priznaje potrebu za promenama
Jedan od osnovnih ciljeva je postizanje tempa razvoja softvera koji bi bio beskonačno održiv za sve učesnike u njemu
Agile modeli su najprimenljiviji za manje, slabo definisane projekte, sa velikom verovatnoćom izmene zahteva i timove sa malim brojem iskusnih programera
Tradicionalniji modeli bolji su kada se zahteva veća predvidljivost i mogućnost kontrole kvaliteta (bolja dokumentovanost), kao i kada se ne može obezbediti dugoročna posvećenost iskusnih programera
Najveći broj kritika agile modelu upućuje se zbog nedostatka dugoročnog planiranja

18. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanja i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

19. Problem održavanja i evolucije
Kao što je već više puta spomenuto, softver stalno evoluira, jer evoluiraju problemi koje on rešava i realni sistemi koje modeluje
Potreba za posebnom pažnjom koju treba posvetiti održavanju i unapređivanju softvera najbolje se vidi kroz primere
Udeo cene održavanja softvera u ukupnoj ceni životnog ciklusa prvo upada u oči: on je uvek preko 50% (varira zavisno od vrste softvera i načina merenja troškova). Interesantan je trend rasta ovog udela tokom vremena, tako da se smatra da sada iznosi preko 90% u većini projekata!
Grad Toronto je godine izgubio oko dolara zbog greške u kompjuterskom sistemu za naplatu kazni vlasnicima kućnih ljubimaca, jer je jedini inženjer koji je u potpunosti razumeo sistem otpušten nešto ranije u sklopu akcije smanjenja gradske administracije!
Korporacija Nokia je potrošila oko 90 miliona dolara, a vlada SAD čak oko 8,38 milijardi na otklanjanje Y2K problema

20. Problem održavanja i evolucije
Održavanje softvera moguće je podeliti na 4 tipa:
Korektivno – ispravljanje bagova nastalih u nekoj fazi razvoja (primer iz Toronta)
Adaptivno – prilagođavanje softvera promenama u okruženju (hardver, operativni sistem, pravna regulativa, Y2K problem spada ovde)
Perfektivno – prilagođavanje izmenjenim korisničkim zahtevima (nove funkcionalnosti, bolji interfejs, poboljšanje performansi)
Preventivno – aktivnosti čiji je cilj povećanje održivosti softverskog sistema (poboljšanje dokumentacije, komentarisanje i refaktorisanje koda)
Samo je korektivno održavanje održavanje u bukvalnom smislu, ostali tipovi se mogu podvesti pod evoluciju softvera

21. Problem održavanja i evolucije
Raspodela vremena i truda posvećenog održavanju je po tipovima sledeća (prosečno, orijentacione vrednosti): korektivno 20%, adaptivno 25%, perfektivno 50% i perfektivno svega 5%
Naročito je upadljiv mali udeo perfektivnog održavanja, iako je to jedini tip održavanja koji smanjuje kompleksnost koda i pozitivno utiče na održivost i dužinu životnog veka sistema
Neophodna je daleko veća svest o značaju održavanja i održivosti softverskih projekata, kao i mogućnosti njihovog unapređivanja. Ovo moraju uvideti kako programeri, tako i klijenti, i naročito menadžment softverskih projekata

22. Problem održavanja i evolucije
U softverskom inženjeringu su i dalje suviše česte pojave koje su nezamislive u drugim inženjerskim oblastima (npr. građevini ili mašinstvu):
Nedovoljna pažnja se posvećuje dizajnu, planiranju i testiranju
Često ne postoji adekvatna dokumentacija
Održavanje gotovog proizvoda se zanemaruje dok ne postane kritično, a i tada se sprovodi stihijski
Tehničke odluke i procene donose netehnička lica, bez uvažavanja mišljenja inženjera
Ovakve stvari dešavaju se najviše zbog specifične, apstraktne, prirode softvera, koja stvara privid jednostavnosti realizacije bilo koje ideje u bilo kom stadijumu razvoja softvera
Pošto razvojni modeli nisu primenljivi u održavanju softvera (nije isto nešto napraviti od nule ili dodati na postojeći sistem), a da bi se prevazišli opisani problemi, razvijeni su mnogi modeli procesa održavanja i evolucije softvera

23. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanja i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

24. Modeli održavanja i evolutivni modeli
Sledi opis nekih od najvažnijih (istorijski i u praksi) modela održavanja softvera i razvojnih modela koji posebnu pažnju obraćaju na evoluciju
Biće opisani sledeći modeli:
Quick fix (Brza popravka)
Boehm's model (Boehm-ov model)
Osborne's model (Osborne-ov model)
Iterative enhancement model (Model iterativnog poboljšanja)
Reuse oriented model (Model ponovnog iskorišćenja)
Open source model (Model otvorenog izvornog koda)

25. Modeli održavanja i evolutivni modeli
Quick fix
Odgovara code and fix razvojnom modelu
Jednostavan i brz – samo dve faze: otkrivanje i ispravljanje problema
Ne predviđa analizu posledica izmene (mogući ripple effect na ostatak sistema)
I dalje se koristi zbog nedostatka vremena i resursa za primenu boljih modela
Iako može biti efikasan za male sisteme, treba ga izbegavati i koristiti samo za privremena, brza rešenja, koja treba detaljno proveriti kasnije u sklopu nekog ozbiljnijeg modela

26. Modeli održavanja i evolutivni modeli
Boehm's model
Model zasnovan na ekonomskim principima
Odluke menadžmenta su pokretač ciklusa
Izmene se odobravaju na osnovu analize isplativosti i svakoj se dodeljuje poseban budžet koji utiče na implementaciju
Određivanje prioriteta i budžeta na osnovu ciljeva i ograničenja je posao menadžera održavanja, pa on ima centralnu ulogu u ovom modelu
Definišu se 3 faze u životu softverskog sistema:
Investment – niska isplativost softvera, uglavnom se ispravljaju defekti
High payoff – softver donosi veliku dobit, dodaju se nove funkcionalnosti
Diminishing returns – sve manja dobit, isplativost izmena opada

27. Modeli održavanja i evolutivni modeli
Osborne's model (1/2)
Za razliku od ostalih modela, uzima u obzir realnost softverske industrije
Ne pretpostavlja postojanje idealnih uslova i svih neophodnih preduslova za uspešno održavanje softverskog sistema (npr. neograničene količine vremena ili potpune dokumentacije)
Osborne tvrdi da većina tehničkih problema u održavanju softvera nastaje zbog loše komunikacije sa menadžmentom i loše kontrole projekta (upravo zbog loše komunikacije) i predlaže sledeće mere:
Uključivanje zahteva za održavanje u svaki zahtev za izmenu
Postojanje jasnog programa kontrole kvaliteta softvera
Postojanje načina za proveru ispunjenosti zahteva za održavanje
Stalan uvid menadžmenta u stanje projekta kroz redovne prikaze (performance reviews)

28. Modeli održavanja i evolutivni modeli
Osborne's model (2/2)
Slika prikazuje predloženi životni ciklus jedne izmene (od otkrivanja potrebe za izmenom do pojave izmene u produkcionoj verziji softvera)
Da bi se uzeli u obzir mogući propusti u prethodnim fazama razvoja i održavanja ciklus uključuje mnoštvo povratnih petlji
Moguće je i više iteracija kroz pojedine petlje
Na primer: tokom implementacije mogu se uočiti nedostaci u komentarima i dokumentaciji, tokom testiranja moguće je otkrivanje nepoznatih problema koji dovode do novih zahteva za izmenu itd.

29. Modeli održavanja i evolutivni modeli
Iterative enhancement model (1/2)
Bazira se na ideji da izmene tokom životnog veka softvera treba dodavati na iterativan način
Nastao od iterativnih razvojnih modela (spiral i sličnih)
Svaka iteracija (implementacija jedne izmene) se sastoji od 3 faze:
Analize
Karakterizacije predloženih izmena
Redizajna sistema i implementacije izmena
Ovaj model može “obuhvatiti” neki jednostavniji (npr. quick fix) koji se može primeniti kada postoji potreba za hitnom izmenom, dok se detaljnija analiza izmene i eventualne prepravke, kao i ažuriranje dokumentacije, ostavljaju za narednu iteraciju

30. Modeli održavanja i evolutivni modeli
Iterative enhancement model (2/2)
U svakoj iteraciji analiza se oslanja na postojeću dokumentaciju, a redizajn sistema i implementacija izmene započinju njenim izmenama, i to od vrha (tj. najopštijeg dokumenta) naniže, do samog koda
U idealnom svetu, ovo bi funkcionisalo savršeno i ostavljalo ne samo prepravljen kod, već i uvek ažurnu dokumentaciju posle svake iteracije
U realnosti ne postoji uvek potpuna i kvalitetna dokumentacija o postojećem sistemu, niti uvek ima vremena za njeno ažuriranje u iterativnom postupku održavanja
U takvim slučajevima rešenje je Osborne-ov model

31. Modeli održavanja i evolutivni modeli
Reuse oriented model
Zasniva se na filozofiji ponovnog iskorišćavanja postojećih resursa
Kandidati za re-upotrebu ne moraju biti samo komponente koda, već to može biti i deo dokumentacije, deo test podataka, skup znanja o domenu problema itd.
Postoje 4 glavna koraka u primeni ovog modela:
Identifikacija delova postojećeg sistema čija je re-upotreba moguća
Potpuno razumevanje tih delova
Njihova modifikacija u skladu sa novim zahtevima
Integracija modifikovanih delova u novi sistem

32. Modeli održavanja i evolutivni modeli
Open source model (1/3)
Više je u pitanju filozofija nego model razvoja softvera
Izvorni kod je dostupan uz binarnu verziju
“Free as in free speech” vs “Free as in free beer” (često oba, ali ne uvek, poenta nije u ceni, već u slobodi)
Model razvoja je najčešće neka vrsta iterativnog u okviru zajednice okupljene oko projekta (community), gde svako može postati član zajednice i doprineti napretku projekta (sav kod mora ostati javno dostupan)
Smanjen je značaj release-ova, jer je celokupan kod dostupan i pre i posle zvaničnog objavljivanja neke verzije, a najčešće ne postoji jedan klijent za koga se razvija softver (tj. koji čeka sledeću verziju)
Zbog toga ne postoji jasna granica između razvoja i održavanja – proizvod se stalno unapređuje (Linux filozofija “release early, release often”)

33. Modeli održavanja i evolutivni modeli
Open source model (2/3)
Iako svako može izmeniti kod i dodati željene izmene, to često nije tehnički i organizaciono jednostavno (softverski sistemi su sve složeniji)
Mnogi korisnici (kompanije, administracija, razne organizacije) ne žele da izdvajaju resurse za samostalno unapređivanje i održavanje koda
Postoje razne kompanije koje se bave pružanjem podrške, unapređivanjem koda, obukom korisnika itd. za razne open source projekte (ove usluge su najčešće komercijalne)
U smislu održavanja open source model je u prednosti utoliko što je svaki korisnik ne samo tester, već i potencijalni programer, što dovodi do bržeg pronalaženja i otklanjanja nedostataka
Takođe, korisnici nisu više isključivo zavisni od proizvođača softvera kada je održavanje u pitanju, jer imaju kompletan izvorni kod

34. Modeli održavanja i evolutivni modeli
Open source model (3/3)
Većina velikih softverskih kompanija ima neku vrstu open source licenciranja nekih ili svih svojih proizvoda (Google, Sun, čak i Microsoft)
Mnoge kompanije koriste open source projekte kao razvojne poligone za nove tehnologije koje uključuju u svoje (komercijalne) proizvode (Fedora - Red Hat Enterprise Linux, OpenSuse - Suse, OpenSolaris – Solaris itd.)
Neki od najuspešnijih open source projekata: Linux, Firefox, OpenOffice

35. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanja i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

36. Zaključak
Prikazano je nekoliko razvojnih modela i modela održavanja softvera
Razvoj ovih modela ide od pravolinijskih i rigidnih ka cikličnim, iterativnim, sve fleksibilnijim, modelima koji sve više prepoznaju evolutivnu prirodu savremenog softvera
Izbor modela održavanja zavisi od mnogo faktora:
Vrste i namene softvera
Primenjenog razvojnog modela
Veštine i iskustva ljudi koji se bave održavanjem
Značaja softvera za klijente
Raspoloživih resursa (vremena, novca, alata)
Ne postoji najbolji model za održavanje softvera, kao što ne postoji ni za razvoj - najbolji rezultati postižu se kombinovanjem više modela

37. Zaključak
Opisani modeli uglavnom se odnose na način i dinamiku uvođenja izmena u sistem, ne na izbor izmena koje treba uvesti
Nisu sve predložene izmene tehnički i ekonomski prihvatljive!
Tokom životnog ciklusa softverskog sistema, sve manje izmena postaje prihvatljivo (ili čak izvodljivo)
Uprkos svim naporima, ni evolucija softvera ne može trajati večito i pre ili kasnije sistem “umire”, tj. neophodan je razvoj potpuno novog proizvoda

38. Zaključak
Može se očekivati da će značaj održavanja i unapređivanja softverskih sistema u budućnosti još više rasti i da će cena ovih procesa višestruko prevazići cenu razvoja
Najveći deo prihoda softverskih kompanija dolaziće od održavanja i podrške za postojeće sisteme, dok će sam inicijalni proizvod biti sve jeftiniji
Open source razvojni model pruža dobru sliku moguće budućnosti u ekonomskom smislu – sam proizvod je besplatan (ili vrlo jeftin), dok se zarade ostvaruju od održavanja, obuke, unapređivanja i svih drugih vidova podrške

39. Sadržaj Uvod Osnovni pojmovi i definicije Klasični razvojni modeli
Problem održavanja i evolucije
Modeli održavanja i evolutivni modeli
Zaključak
Literatura

40. Literatura
[1] Penny Grubb, Armstrong A. Takang, Software Maintenance: Concepts and Practice, Second Edition, World Scientific, 2003, p
[2] Kagan Erdil et al., Software Maintenance As Part of the Software Life Cycle, Department of Computer Science, Tufts University, 2003.
[3] Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer Society Press, 1988.
[4] Kent Beck et al., Agile Manifesto, 2003,
[5] Jussi Koskinen, Software Maintenance Costs, Information Technology Research Institute, University of Jyväskylä, 2003,
[6] Various articles from Wikipedia, The Free Encyclopedia: Software maintenance; Software evolution; Waterfall model; Spiral model; Agile software development etc., Wikipedia, The Free Encyclopedia, 2009,