elektrotehnički fakultet u beogradu evolucija softvera

Elektrotehnički fakultet u Beogradu

Evolucija softvera

Modeli procesa u održavanju i evoluciji softvera

Mentor: dr Dragan Bojić

Autor: Marko Mitrović ([email protected])

februar 2009.

mailto:[email protected]?subject=Evolucija%20softvera

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


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

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

Code and fix

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


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

Waterfall (1/2)

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


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

Spiral (1/2)

15


• 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


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


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 modeliQuick 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


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


• 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


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


• 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


• 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


• 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


• 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


• 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


• 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


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. 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

http://www.agilemanifesto.org/

http://www.agilemanifesto.org/

http://users.jyu.fi/~koskinen/smcosts.htm

http://users.jyu.fi/~koskinen/smcosts.htm

http://www.wikipedia.org/

http://www.wikipedia.org/

elektrotehnički fakultet u beogradu evolucija softvera

Documents