Presentation is loading. Please wait.

Presentation is loading. Please wait.

Elektrotehnički fakultet u Beogradu Evolucija softvera

Similar presentations


Presentation on theme: "Elektrotehnički fakultet u Beogradu Evolucija softvera"— Presentation transcript:

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,


Download ppt "Elektrotehnički fakultet u Beogradu Evolucija softvera"

Similar presentations


Ads by Google