Elektrotehnički fakultet u Beogradu Evolucija softvera

1. Modeli procesa u održavanju i evoluciji softvera Mentor: dr Dragan Bojić Autor: Marko Mitrović (mitrovic_yu@yahoo.com) februar 2009. Elektrotehnički fakultet u BeograduEvolucija softvera

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 2007. godini ukupan prihod 500 najvećih softverskih kompanija iznosio je 451,8 milijardi dolara (Software Magazine) • Procene su da je 1997. 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četkanove (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 1988. 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 2000. godine izgubio oko 700 000 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 • 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) Quick fix • 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 • 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. Osborne's model (2/2)

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. Uvod Osnovni pojmovi i definicije Klasični razvojni modeli Problem održavanja i evolucije Modeli održavanja i evolutivni modeli Zaključak Literatura Sadržaj

40. Literatura • [1] Penny Grubb, Armstrong A. Takang, Software Maintenance: Concepts and Practice, Second Edition, World Scientific, 2003, p. 59-90 • [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, http://www.agilemanifesto.org • [5] Jussi Koskinen, Software Maintenance Costs, Information Technology Research Institute, University of Jyväskylä, 2003, http://users.jyu.fi/~koskinen/smcosts.htm • [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, http://www.wikipedia.org