Elektrotehnicki%20fakultet%20u%20Beogradu%20Evolucija%20softvera

1
Elektrotehnicki fakultet u BeograduEvolucija
softvera

• Modeli procesa u održavanju i evoluciji softvera
• Mentor dr Dragan Bojic
• Autor Marko Mitrovic (mitrovic_yu_at_yahoo.com)
• februar 2009.

2
Sadržaj

• Uvod
• Osnovni pojmovi i definicije
• Klasicni razvojni modeli
• Problem održavanja i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• Literatura

3
Uvod

• Softver je u savremenom svetu sveprisutan (posao,
  zabava, komunikacije, informisanje,
  infrastruktura...)
• U 2007. godini ukupan prihod 500 najvecih
  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 vecu upotrebu racunara i potrebu za sve bržim
  i pouzdanijim razvojem
• Osim potrebe za razvojem, postoji i sve veca
  potreba za održavanjem i stalnim unapredivanjem
  postojecih 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
• Klasicni razvojni modeli
• Problem održavanje i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• 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 nacina razvoja softvera
• Životni vek softvera (software lifecycle)
  period od nastanka ideje, preko razvoja, upotrebe
  i održavanja do prestanka korišcenja softvera

7
Osnovni pojmovi i definicije

• Životni vek podrazumeva ciklicno ponavljanje
  osnovnog razvojnog procesa sa svakom novom idejom
  za izmenu i proširenje postojeceg sistema
• Kasnije uvodimo pojmove održavanja i evolucije

8
Sadržaj

• Uvod
• Osnovni pojmovi i definicije
• Klasicni razvojni modeli
• Problem održavanja i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• Literatura

9
Klasicni 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
Klasicni razvojni modeli

• Sledi pregled sledecih modela razvoja
• Code and fix (Kodiraj i popravi)
• Waterfall (Vodopad)
• Spiral (Spiralni model)
• Agile (Agilni modeli)
• Ovo su samo neki od postojecih razvojnih modela
• Izabrani su jer se najcešce primenjuju i dobro
  ilustruju tendencije i osnovne principe

11
Klasicni razvojni modeli
Code and fix

• Dve faze koje se ciklicno 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
  unapredivanje brzo postaje nemoguce
• Još uvek se cesto koristi zbog nedovoljno resursa
  za primenu boljih modela (vremena, novca, ljudi)

12
Klasicni razvojni modeli
Waterfall (1/2)

• Najcešce korišceni model
• Sastoji se od pet jasno definisanih faza
• Svaka faza pocinje tek kad su sve prethodne
  završene i dokumentovane (document driven model)
• Dobre strane jasno definisan tok razvoja velika
  pažnja se posvecuje analizi i dizajnu pre samog
  kodiranja verifikacija i testiranje nakon
  implementacije dobra dokumentovanost
• Loše strane neophodno završiti sve prethodne
  faze pre pocetkanove (veliki timovi puno
  cekanja) jednosmeran model (nema povratne sprege
  medu fazama) otkrivanje greške je skuplje u
  kasnijim fazama (ali tada je i verovatnije!)
  neophodno je znati potpunu specifikaciju na
  pocetku razvoja

13
Klasicni razvojni modeli

• Waterfall (2/2)
• Waterfall model je osnov za mnoge druge modele
  (uvodenje povratne sprege medu fazama, zatvaranje
  u ciklus itd.)
• Najveci problemi kod ovog modela nastaju pri
  cestoj promeni zahteva, dodavanju novih u hodu
  itd.
• Problem cesto nije posledica greške u inicijalnoj
  specifikaciji i dizajnu vec prirode realnog
  sistema koji softver modelira (specifikacija može
  biti potpuno tacna u jednom trenutku, a netacna
  vec sutra dan!)
• Zbog toga se uvode fleksibilniji, iterativni,
  modeli koji rešavaju upravo problem evoluiranja
  korisnickih zahteva

14
Klasicni razvojni modeli
Spiral (1/2)

• Jedan od prvih Iterativnih modela
• Uvodi ga Barry Boehm 1988. u clanku A Spiral
  Model of Software Development and Enhancement
• 4 faze koje se ciklicno ponavljaju
• Odredivanje ciljeva, alternativa i ogranicenja
• Poredenje alernativa, procena i eliminacija
  rizika
• Implementacija i testiranje
• Praniranje sledecih iteracija

15
Klasicni 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 vec implementirani deo
• Rizici, ogranicenja i alternativna rešenja na
  nivou iteracije razmatraju se pri njenom pocetku,
  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 kriticna (pre npr. cene)

16
Klasicni razvojni modeli

• Agile (1/2)
• Skup srodnih razvojnih modela (nastao oko 2000.),
  ne samo jedan model
• Nastao kao odgovor na nedostatke waterfall i
  slicnih, previše krutih, modela
• Cilj je postici što vecu prilagodljivost na
  promene i što vece zadovoljstvo narucioca, 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
  ucestvuje u svakodnevom radu
• Umesto jasno definisanog procesa i cvrstog
  ugovora sa klijentima naglasak je na cestoj i
  otvorenoj komunikaciji

17
Klasicni 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 beskonacno održiv za
  sve ucesnike u njemu
• Agile modeli su najprimenljiviji za manje, slabo
  definisane projekte, sa velikom verovatnocom
  izmene zahteva i timove sa malim brojem iskusnih
  programera
• Tradicionalniji modeli bolji su kada se zahteva
  veca predvidljivost i mogucnost kontrole
  kvaliteta (bolja dokumentovanost), kao i kada se
  ne može obezbediti dugorocna posvecenost iskusnih
  programera
• Najveci broj kritika agile modelu upucuje se zbog
  nedostatka dugorocnog planiranja

18
Sadržaj

• Uvod
• Osnovni pojmovi i definicije
• Klasicni razvojni modeli
• Problem održavanja i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• Literatura

19
Problem održavanja i evolucije

• Kao što je vec 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 unapredivanju softvera najbolje se
  vidi kroz primere
• Udeo cene održavanja softvera u ukupnoj ceni
  životnog ciklusa prvo upada u oci on je uvek
  preko 50 (varira zavisno od vrste softvera i
  nacina merenja troškova). Interesantan je trend
  rasta ovog udela tokom vremena, tako da se smatra
  da sada iznosi preko 90 u vecini projekata!
• Grad Toronto je 2000. godine izgubio oko 700 000
  dolara zbog greške u kompjuterskom sistemu za
  naplatu kazni vlasnicima kucnih 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 cak oko 8,38 milijardi na
  otklanjanje Y2K problema

20
Problem održavanja i evolucije

• Održavanje softvera moguce je podeliti na 4 tipa
• Korektivno ispravljanje bagova nastalih u nekoj
  fazi razvoja (primer iz Toronta)
• Adaptivno prilagodavanje softvera promenama u
  okruženju (hardver, operativni sistem, pravna
  regulativa, Y2K problem spada ovde)
• Perfektivno prilagodavanje izmenjenim
  korisnickim zahtevima (nove funkcionalnosti,
  bolji interfejs, poboljšanje performansi)
• Preventivno aktivnosti ciji je cilj povecanje
  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 posvecenog održavanju
  je po tipovima sledeca (prosecno, orijentacione
  vrednosti) korektivno 20, adaptivno 25,
  perfektivno 50 i perfektivno svega 5
• Narocito je upadljiv mali udeo perfektivnog
  održavanja, iako je to jedini tip održavanja koji
  smanjuje kompleksnost koda i pozitivno utice na
  održivost i dužinu životnog veka sistema
• Neophodna je daleko veca svest o znacaju
  održavanja i održivosti softverskih projekata,
  kao i mogucnosti njihovog unapredivanja. Ovo
  moraju uvideti kako programeri, tako i klijenti,
  i narocito menadžment softverskih projekata

22
Problem održavanja i evolucije

• U softverskom inženjeringu su i dalje suviše
  ceste pojave koje su nezamislive u drugim
  inženjerskim oblastima (npr. gradevini ili
  mašinstvu)
• Nedovoljna pažnja se posvecuje dizajnu,
  planiranju i testiranju
• Cesto ne postoji adekvatna dokumentacija
• Održavanje gotovog proizvoda se zanemaruje dok ne
  postane kriticno, a i tada se sprovodi stihijski
• Tehnicke odluke i procene donose netehnicka lica,
  bez uvažavanja mišljenja inženjera
• Ovakve stvari dešavaju se najviše zbog
  specificne, 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 postojeci 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
• Klasicni razvojni modeli
• Problem održavanja i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• 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 obracaju na evoluciju
• Bice opisani sledeci 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šcenja)
• 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 fazeotkrivanje i
  ispravljanje problema
• Ne predvida analizu posledica izmene(moguci
  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 pokretac ciklusa
• Izmene se odobravaju na osnovu analize
  isplativosti i svakoj se dodeljuje poseban budžet
  koji utice na implementaciju
• Odredivanje prioriteta i budžeta na osnovu
  ciljeva i ogranicenja 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. neogranicene kolicine
  vremena ili potpune dokumentacije)
• Osborne tvrdi da vecina tehnickih 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 sledece mere
• Ukljucivanje zahteva za održavanje u svaki zahtev
  za izmenu
• Postojanje jasnog programa kontrole kvaliteta
  softvera
• Postojanje nacina 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 moguci propusti u
  prethodnim fazama razvoja i održavanja ciklus
  ukljucuje mnoštvo povratnih petlji
• Moguce je i više iteracija kroz pojedine petlje
• Na primer tokom implementacije mogu se uociti
  nedostaci u komentarima i dokumentaciji, tokom
  testiranja moguce 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 nacin
• Nastao od iterativnih razvojnih modela (spiral i
  slicnih)
• 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
  postojecu dokumentaciju, a redizajn sistema i
  implementacija izmene zapocinju 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, vec i uvek
  ažurnu dokumentaciju posle svake iteracije
• U realnosti ne postoji uvek potpuna i kvalitetna
  dokumentacija o postojecem sistemu, niti uvek ima
  vremena za njeno ažuriranje u iterativnom
  postupku održavanja
• U takvim slucajevima rešenje je Osborne-ov model

31
Modeli održavanja i evolutivni modeli

• Reuse oriented model
• Zasniva se na filozofiji ponovnog iskorišcavanja
  postojecih resursa
• Kandidati za re-upotrebu ne moraju biti samo
  komponente koda, vec 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 postojeceg sistema cija je
  re-upotreba moguca
• 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 (cesto oba, ali ne uvek, poenta nije u
  ceni, vec u slobodi)
• Model razvoja je najcešce neka vrsta iterativnog
  u okviru zajednice okupljene oko projekta
  (community), gde svako može postati clan
  zajednice i doprineti napretku projekta (sav kod
  mora ostati javno dostupan)
• Smanjen je znacaj release-ova, jer je celokupan
  kod dostupan i pre i posle zvanicnog
  objavljivanja neke verzije, a najcešce ne postoji
  jedan klijent za koga se razvija softver (tj.
  koji ceka sledecu verziju)
• Zbog toga ne postoji jasna granica izmedu razvoja
  i održavanja proizvod se stalno unapreduje
  (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 cesto nije tehnicki i organizaciono
  jednostavno (softverski sistemi su sve složeniji)
• Mnogi korisnici (kompanije, administracija, razne
  organizacije) ne žele da izdvajaju resurse za
  samostalno unapredivanje i održavanje koda
• Postoje razne kompanije koje se bave pružanjem
  podrške, unapredivanjem koda, obukom korisnika
  itd. za razne open source projekte (ove usluge su
  najcešce komercijalne)
• U smislu održavanja open source model je u
  prednosti utoliko što je svaki korisnik ne samo
  tester, vec i potencijalni programer, što dovodi
  do bržeg pronalaženja i otklanjanja nedostataka
• Takode, korisnici nisu više iskljucivo zavisni od
  proizvodaca softvera kada je održavanje u
  pitanju, jer imaju kompletan izvorni kod

34
Modeli održavanja i evolutivni modeli

• Open source model (3/3)
• Vecina velikih softverskih kompanija ima neku
  vrstu open source licenciranja nekih ili svih
  svojih proizvoda (Google, Sun, cak i Microsoft)
• Mnoge kompanije koriste open source projekte kao
  razvojne poligone za nove tehnologije koje
  ukljucuju 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
• Klasicni razvojni modeli
• Problem održavanja i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• Literatura

36
Zakljucak

• Prikazano je nekoliko razvojnih modela i modela
  održavanja softvera
• Razvoj ovih modela ide od pravolinijskih i
  rigidnih ka ciklicnim, 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
• Znacaja 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
Zakljucak

• Opisani modeli uglavnom se odnose na nacin i
  dinamiku uvodenja izmena u sistem, ne na izbor
  izmena koje treba uvesti
• Nisu sve predložene izmene tehnicki i ekonomski
  prihvatljive!
• Tokom životnog ciklusa softverskog sistema, sve
  manje izmena postaje prihvatljivo (ili cak
  izvodljivo)
• Uprkos svim naporima, ni evolucija softvera ne
  može trajati vecito i pre ili kasnije sistem
  umire, tj. neophodan je razvoj potpuno novog
  proizvoda

38
Zakljucak

• Može se ocekivati da ce znacaj održavanja i
  unapredivanja softverskih sistema u buducnosti
  još više rasti i da ce cena ovih procesa
  višestruko prevazici cenu razvoja
• Najveci deo prihoda softverskih kompanija
  dolazice od održavanja i podrške za postojece
  sisteme, dok ce sam inicijalni proizvod biti sve
  jeftiniji
• Open source razvojni model pruža dobru sliku
  moguce buducnosti u ekonomskom smislu sam
  proizvod je besplatan (ili vrlo jeftin), dok se
  zarade ostvaruju od održavanja, obuke,
  unapredivanja i svih drugih vidova podrške

39
Sadržaj

• Uvod
• Osnovni pojmovi i definicije
• Klasicni razvojni modeli
• Problem održavanja i evolucije
• Modeli održavanja i evolutivni modeli
• Zakljucak
• 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.o
  rg