UNIVERZA V LJUBLJANI
EKONOMSKA FAKULTETA
MAGISTRSKO DELO
OCENJEVANJE OBSEGA DELA
PRI PROJEKTIH RAZVOJA PROGRAMSKE OPREME
Ljubljana, oktober 2011 SAVO ŽIVKOVIĆ
IZJAVA
Študent Savo Živković izjavljam, da sem avtor tega magistrskega dela, ki sem ga napisal v
soglasju s svetovalcem prof. dr. Talibom Damijem, in da v skladu s 1. odstavkom 21. člena
Zakona o avtorskih in sorodnih pravicah dovolim njegovo objavo na fakultetnih spletnih
straneh.
V Ljubljani, dne 21.10.2011 Podpis:
i
KAZALO
UVOD ................................................................................................................................... 1
1 OCENJEVANJE PROJEKTOV RAZVOJA PROGRAMSKE OPREME ............. 3 1.1 Opredelitev ocenjevanja ........................................................................................ 3
1.2 Opredelitev ocenjevanja projektov razvoja programske opreme .......................... 3
1.2.1 Verjetnost pri ocenjevanju projektov razvoja programske opreme ............... 4
1.2.2 Negotovost pri ocenjevanju projektov razvoja programske opreme ............. 5
1.3 Proces ocenjevanja projektov razvoja programske opreme .................................. 6
1.4 Razlogi za ocenjevalne napake pri projektih razvoja programske opreme ........... 8
2 OCENJEVANJE VELIKOSTI PROJEKTOV RAZVOJA PROGRAMSKE
OPREME ........................................................................................................................ 9 2.1 Opredelitev velikosti programske opreme ............................................................. 9
2.2 Merjenje fizične velikosti programske opreme ................................................... 11
2.3 Merjenje funkcijske velikosti programske opreme ............................................. 12
2.3.1 Analiza funkcijskih točk .............................................................................. 12
2.3.2 Ostale metode merjenja funkcijske velikosti ............................................... 15
2.4 Povezava med fizično in funkcijsko velikostjo programske opreme .................. 16
3 OCENJEVANJE OBSEGA DELA PROJEKTOV RAZVOJA PROGRAMSKE
OPREME ...................................................................................................................... 17 3.1 Razlaga ocenjevanja obsega dela ........................................................................ 17
3.1.1 Povezava med obsegom dela in trajanjem projekta ..................................... 18
3.1.2 Povezava med obsegom dela in stroški projekta ......................................... 19
3.2 Dejavniki produktivnosti ..................................................................................... 20
3.2.1 Velikost programske opreme ....................................................................... 21
3.2.2 Vrsta programske opreme, razvojno okolje in programski jezik................. 22
3.2.3 Značilnosti projektnega tima ....................................................................... 23
3.2.4 Ostali dejavniki produktivnosti ................................................................... 24
4 METODE IN TEHNIKE OCENJEVANJA OBSEGA DELA PROJEKTOV
RAZVOJA PROGRAMSKE OPREME ................................................................... 24 4.1 Razvrstitev metod in tehnik ocenjevanja projektov razvoja programske opreme25
4.2 Ocenjevanje s pomočjo ekspertne presoje ........................................................... 27
4.2.1 Analogna metoda ......................................................................................... 29
4.2.2 Tehnika »od zgoraj navzdol« ...................................................................... 30
4.2.3 Tehnika »od spodaj navzgor« ...................................................................... 31
4.2.4 Tehnika Delfi ............................................................................................... 32
4.3 Ocenjevanje s pomočjo formalnih modelov ........................................................ 34
4.3.1 Parametrični modeli ..................................................................................... 35
4.3.2 Modeli, temelječi na strojnem učenju ......................................................... 36
4.4 Kombiniranje pristopov ....................................................................................... 38
5 RAZISKAVA OCENJEVANJA OBSEGA DELA PROJEKTOV RAZVOJA
PROGRAMSKE OPREME ....................................................................................... 39 5.1 Cilj raziskave ....................................................................................................... 39
5.2 Metoda raziskave ................................................................................................. 39
5.3 Predstavitev podatkovne zbirke projektov ISBSG .............................................. 40
5.4 Priprava proučevanega podatkovnega vira projektov ......................................... 41
5.5 Analiza proučevanega podatkovnega vira projektov........................................... 44
5.5.1 Glavni projektni kazalci............................................................................... 44
5.5.2 Številčni projektni parametri ....................................................................... 46
5.5.3 Kategorijski projektni parametri .................................................................. 46
ii
5.6 Izbor in uporaba ocenjevalnih metod .................................................................. 52
5.6.1 Regresijske enačbe ...................................................................................... 52
5.6.2 Primerjalna metoda ..................................................................................... 55
5.6.3 Analogna metoda ......................................................................................... 56
5.6.4 Industrijsko povprečje ................................................................................. 59
5.6.5 Računalniški ocenjevalni model .................................................................. 60
5.6.6 Kombiniranje metod .................................................................................... 62
5.7 Izbor metrik natančnosti ocenjevalnih metod ..................................................... 64
5.8 Analiza rezultatov raziskave ............................................................................... 65
5.8.1 Rezultati ocenjevanja pri preizkusnem naboru projektov ........................... 66
5.8.2 Rezultati ocenjevanja pri validacijskem naboru projektov ......................... 68
5.8.3 Rezultati ocenjevanja pri proučevanem podatkovnem viru projektov ........ 70
5.8.4 Ugotovitve analize ....................................................................................... 72
5.9 Omejitve raziskave .............................................................................................. 73
SKLEP ................................................................................................................................ 75
LITERATURA IN VIRI ................................................................................................... 77
KAZALO TABEL
Tabela 1: Razpon intervala ocen v odvisnosti od razvoja projekta ....................................... 6
Tabela 2: Množitelji pri izračunu neporavnanih funkcijskih točk ...................................... 14
Tabela 3: Pretvorba funkcijskih točk v vrstice izvorne kode .............................................. 16
Tabela 4: Stopnja projektne produktivnosti v odvisnosti od programskega jezika in
razvojnega okolja ................................................................................................................ 22
Tabela 5: Razmerje funkcionalnosti na vrstico kode v primerjavi s programskim jezikom C
............................................................................................................................................. 23
Tabela 6: Primer kontrolnega seznama pri ekspertni presoji .............................................. 29
Tabela 7: Statistične lastnosti glavnih projektnih kazalcev ................................................ 44
Tabela 8: Porazdelitev vrednosti glavnih projektnih kazalcev ............................................ 45
Tabela 9: Delež osamelcev in ekstremnih osamelcev pri glavnih projektnih kazalcih ....... 46
Tabela 10: Pogostnost vrednosti projektnega parametra »Vrsta razvoja« .......................... 48
Tabela 11: Pogostnost vrednosti projektnega parametra »Programska arhitektura« .......... 49
Tabela 12: Pogostnost vrednosti projektnega parametra »Razvojno okolje« ..................... 50
Tabela 13: Pogostnost vrednosti projektnega parametra »Vrsta programskega jezika« ..... 50
Tabela 14: Pogostnost vrednosti projektnega parametra »Primarni programski jezik« ...... 51
Tabela 15: Točkovanje analognih projektov ....................................................................... 58
Tabela 16: Primer vrednosti kazalca Pred(l) ....................................................................... 65
Tabela 17: Natančnost ocenjevalnih metod pri preizkusnem naboru projektov ................. 66
Tabela 18: Natančnost ocenjevalnih metod pri validacijskem naboru projektov ............... 68
Tabela 19: Natančnost ocenjevalnih metod pri proučevanem podatkovnem viru projektov
............................................................................................................................................. 70
iii
KAZALO SLIK
Slika 1: Primer porazdelitve verjetnosti pri ocenjevanju projektov ...................................... 4
Slika 2: Stožec negotovosti.................................................................................................... 5
Slika 3: Tok ocenjevanja projektov razvoja programske opreme ....................................... 10
Slika 4: Primer porazdelitve verjetnosti pri ocenjevanju obsega dela ................................. 17
Slika 5: Razmerje med obsegom dela in trajanjem projekta ............................................... 18
Slika 6: Razmerje med obsegom dela, trajanjem projekta in številom projektnih članov .. 19
Slika 7: Enostavni model produktivnosti............................................................................. 20
Slika 8: Razvrstitev ocenjevalnih metod in tehnik »Myrtveit in drugi« ............................. 26
Slika 9: Jakost ocenjevalne napake obravnavanih metod pri preizkusnem naboru projektov
............................................................................................................................................. 67
Slika 10: Pred(10) in Pred(25) obravnavanih metod pri preizkusnem naboru projektov .... 67
Slika 11: Jakost ocenjevalne napake obravnavanih metod pri validacijskem naboru
projektov .............................................................................................................................. 69
Slika 12: Pred(10) in Pred(25) obravnavanih metod pri validacijskem naboru projektov .. 69
Slika 13: Jakost ocenjevalne napake obravnavanih metod pri proučevanem podatkovnem
viru projektov ...................................................................................................................... 71
Slika 14: Pred(10) in Pred(25) obravnavanih metod pri proučevanem podatkovnem viru
projektov .............................................................................................................................. 71
1
UVOD
Informacijska znanost se z ocenjevanjem projektov ukvarja že več kot štiri desetletja.
Začetki segajo v leto 1966, ko je bilo objavljeno raziskovalno delo ameriškega avtorja
Nelsona, v katerem so predstavljeni izsledki študije ocenjevalnih parametrov, ki je
zajemala 169 programskih projektih (Boehm, Abts & Chulani, 2000, str. 1). V zadnjih 40
letih je bilo razvitih mnogo različnih modelov ocenjevanja, vendar raziskave kažejo, da
kljub temu ni bilo bistvenega napredka pri izboljšanju natančnosti ocen obsega dela
(Software development effort estimation, 2009). Številne študije nakazujejo, da so ocene
obsega dela pri projektih razvoja programske opreme pogosto preoptimistične in manj
natančne, kot velja splošno prepričanje. Glavne ugotovitve opravljenih raziskav so
(Moløkken-Østvold & Jørgensen, 2003, str. 223):
1. Večina projektov (60–80 %) se zaključi kasneje oziroma z višjimi stroški, kot je
načrtovano. Kljub temu pa je dejansko odstopanje od načrtovanega obsega dela in
stroškov manjše, kot ga prikazujejo nekatere svetovalne družbe. Primer je družba
Standish Group, ki v svojem poročilu »Chaos Report« navaja povprečno preseganje
stroškov za 89 %, medtem ko je v primeru drugih raziskav ta vrednost bistveno nižja,
tj. 30–40 %.
2. Najpogosteje uporabljena metoda za ocenjevanje obsega dela in stroškov je ekspertna
presoja. Možen razlog za pogosto uporabo ekspertne presoje je pomanjkanje dokazov,
da formalni modeli za ocenjevanja obsega dela zagotavljajo natančnejše ocene.
3. Ugotovljeno je pomanjkanje raziskav, ki podrobno obravnavajo vzroke za prekoračenje
obsega dela pri projektih razvoja programske opreme.
Uporaba različnih metod in pristopov ocenjevanja prinaša razlike v natančnosti ocen. To
namiguje na dejstvo, da ni enotnega oziroma »najboljšega pristopa«, temveč da je
natančnost enega pristopa v primerjavi z drugim v največji meri odvisna od okoliščin
(Shepperd & Kadoda, 2001, str. 1014). Iz tega sledi, da različnim organizacijam ustrezajo
različni pristopi ocenjevanja obsega dela.
Najodmevnejša ugotovitev številnih raziskav je, da je mogoče s pomočjo kombinacije
ocen, ki so pridobljene z uporabo različnih pristopov, v povprečju izboljšati natančnost
ocenjevanja obsega dela pri projektih razvoja programske opreme (Jørgensen, 2007, str.
449).
Namen magistrskega dela je s pomočjo domače in predvsem tuje strokovne literature
proučiti in kritično oceniti različne pristope za ocenjevanje obsega dela pri projektih
razvoja programske opreme. Raziskavo v praktičnem delu magistrske naloge bom izvedel,
2
da preverim teoretična dejstva in ugotovitve drugih raziskovalcev in da s tem spodbudim
tudi zanimanje v slovenskih in tujih podjetjih ter opozorim na pomembnost ocenjevanja pri
projektih razvoja programske opreme.
Osrednji cilj magistrskega dela je spoznati različne pristope pri ocenjevanju projektov
razvoja programske opreme in ugotoviti, ali je mogoče s kombiniranjem ocen, pridobljenih
z različnimi metodami in tehnikami, izboljšati natančnost ocenjevanja obsega dela.
Raziskati želim, kako ocenjevanje obsega dela vpliva na planiranje projektov razvoja
programske opreme, zakaj se večina projektov razvoja programske opreme zaključi
kasneje oziroma z višjimi stroški, kot je načrtovano, in kateri so ključni dejavniki, ki
vplivajo na ocenjevanje obsega dela.
V teoretičnem delu sem kot metodo uporabil sistematično analizo preučevanega področja.
Ugotavljal sem, kaj je ocena, kakšen je proces ocenjevanja projektov razvoja programske
opreme, kakšne so povezave med ocenjevanimi projektnimi parametri idr. V praktičnem
delu sem se naslonil na statistične metode. Preverjal sem natančnost posameznih
ocenjevalnih metod in jo primerjal z natančnostjo kombiniranih metod. Pri preučevanju
raziskave sem se opiral na teoretične osnove iz prvega sklopa magistrskega dela.
Magistrsko delo je razdeljeno na pet poglavij. V prvem poglavju je opredeljen splošen
pomen ocenjevanja, pojasnjene so značilnosti ocenjevanja projektov razvoja programske
opreme. Temu sledi predstavitev ocenjevalnega procesa. Prvo poglavje je sklenjeno z
opisom osrednjih razlogov za ocenjevalno napako.
V drugem poglavju je opredeljena velikost programske opreme, predstavljeni sta glavni
vrsti merjenja velikosti, to sta fizično in funkcijsko merjenje velikosti programske opreme.
Podrobno je predstavljena najbolj razširjena metoda merjenja funkcijske velikosti
programske opreme in opredeljena povezava med fizično in funkcijsko velikostjo
programske opreme.
V tretjem poglavju je natančno pojasnjeno ocenjevanje obsega dela projektov razvoja
programske opreme in opisana povezanost obsega dela s trajanjem in stroški projektov.
Temu sledi razlaga produktivnosti pri projektih razvoja programske opreme in pregled
ključnih dejavnikov, ki vplivajo na obseg dela.
V četrtem poglavju so natančno predstavljene najbolj razširjene metode in tehnike
ocenjevanja obsega dela, njihove prednosti in pomanjkljivosti. Predlagana je členitev
metod in tehnik v različne skupine.
V petem poglavju je natančno predstavljena raziskava. Opisani so cilj, metoda in postopek
raziskave. Temu sledita obširna analiza rezultatov in opis omejitev raziskave. V zaključku
magistrskega dela so povzeta vsa poglavitna spoznanja in ugotovitve.
3
1 OCENJEVANJE PROJEKTOV RAZVOJA PROGRAMSKE OPREME
1.1 Opredelitev ocenjevanja
Razlag, kaj je ocenjevanje in kaj ocena, je veliko. Najbolj splošno opredelitev najdemo v
Slovarju slovenskega knjižnega jezika (1993), ki ocenjevanje pojmuje kot približno
določanje količine, oceno pa kot približno določitev količine.
Zanimivo razlago vsebuje angleška različica Wikipedije (Estimation, 2010), ki pojem
ocena (angl. estimation) razlaga kot izračunani približek rezultata, ki je uporaben tudi v
primeru nepopolnih ali negotovih vhodnih podatkov.
Podrobnejšo razlago podaja nemška različica Wikipedije (Schätzung, 2010), in sicer pojem
ocenjevanje (nem. Schätzung) pojasnjuje kot približno določanje številčnih vrednosti,
količin ali parametrov s pomočjo ogleda, izkustva ali statistično-matematičnih metod.
Za pričujoče delo najbolj relevantno in popolno razlago ponuja Vodnik po znanju
projektnega vodenja (2008, str. 362), ki oceno opredeljuje kot:
»Količinsko izraženi verjetni izid. Največkrat ocenjujemo stroške in trajanje projekta, pri
čemer moramo vedno podati oceno natančnosti (npr. ±x odstotkov). Izraz običajno dodatno
opredelimo, npr. predhodna ocena, konceptualna ocena, ocena izvedljivosti. Nekatera
področja uporabe imajo lastna določila, ki obenem določajo tudi območje natančnosti
(npr. ocena velikostnega reda, ocena planiranih stroškov, pri tehničnih in gradbenih
projektih pa tudi dokončna ocena).«
1.2 Opredelitev ocenjevanja projektov razvoja programske opreme
Ocenjevanje projektov razvoja programske opreme (angl. software project estimation)1 je
proces določanja najverjetnejšega trajanja, stroškov, števila potrebnih virov in drugih
količin pri razvoju programske opreme.
Ocenjevanje projektov razvoja programske opreme je običajno povezano z veliko stopnjo
negotovosti. Bolj kot je oddaljena točka, za katero oblikujemo oceno, manj je ta ocena
natančna in večji je razpon možnih vrednosti. Ko projekt začnemo izvajati in se ta
približuje zaključku, se zmanjšuje verjetnost, da projektni cilji ne bodo doseženi. Pogosto
se zato med potekom projekta v določenih stalnih časovnih intervalih oziroma ob
projektnih mejnikih oblikujejo nove ocene (Šušteršič, 2003, str. 16).
1 V tuji literaturi se kot različica pojma software project estimation uporablja tudi pojem software estimation.
4
1.2.1 Verjetnost pri ocenjevanju projektov razvoja programske opreme
Ocenjevanje ni deterministično, temveč je pogojeno z verjetnostjo. Iz tega sledi, da imajo
ocene različno verjetnost (Grimstad, Jørgensen & Moløkken-Østvold, 2006, str. 308).
Porazdelitev verjetnosti na Sliki 1 opisuje območje, ki ga ocena lahko zavzame, in
verjetnost, da je vrednost ocene v tem območju.
Slika 1: Primer porazdelitve verjetnosti pri ocenjevanju projektov
Ver
jetn
ost
Ocena
Najmanjša
možna ocena
Najverjetnejša
ocena
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 8.
Iz Slike 1 so razvidne naslednje lastnosti:
Območje vrednosti, ki jih ocena lahko zavzame, je široko.
Območje ima določeno najverjetnejšo vrednost.
Območje ima določeno najmanjšo vrednost.
Vrednosti niso simetrično porazdeljene.
Če si za boljšo predstavo ogledamo primer ocenjevanja trajanja projekta, potem vsaka
točka na grafu predstavlja verjetnost, da se bo projekt zaključil v točno določenem času.
Ker na trajanje projekta vplivajo številni dejavniki, obstaja širok razpon možnosti, kdaj bo
projekt zaključen. Točka, kjer je verjetnost najvišja, je najverjetnejše trajanje projekta. Vsi
projekti imajo določeno najkrajše možno trajanje, ki ga je zelo težko doseči, zato je
verjetnost v tej točki izredno majhna. Za vse ocene, katerih trajanje je krajše od te točke, je
verjetnost enaka 0. Nasprotno pa trajanje projekta navzgor teoretično ni omejeno. Ob
neustreznem vodenju se lahko trajanje projekta precej podaljša, zato vrednosti na levi in
desni polovici grafa niso simetrično porazdeljene (McConnell, 2006, str. 7).
5
1.2.2 Negotovost pri ocenjevanju projektov razvoja programske opreme
Razvoj programske opreme je proces postopnega izpopolnjevanja. Običajno se prične s
splošnim konceptom (vizijo) novega izdelka, ki se postopoma razvija do končnega izdelka
v skladu s projektnimi cilji. Ker ob samem začetku izdelek ni jasno določen, obstaja velika
negotovost v zvezi s stroški, trajanjem projekta in značilnostmi (funkcijami) izdelka. Bolj
kot je novi izdelek določen, manjša je negotovost (McConnell, 2006, str. 34–35). To
lastnost lahko slikovno ponazorimo z grafom v obliki stožca, ki ga imenujemo »stožec
negotovosti« (angl. cone of uncertainty).
Slika 2: Stožec negotovosti
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 37.
Kot je razvidno iz Slike 2, je negotovost največja v začetni fazi projekta, ko lahko ocena
izrazito odstopa navzgor ali navzdol. Ko so projektne zahteve določene, približno po 30 %
trajanja projekta, se negotovost in s tem odstopanje ocene bistveno zmanjšata in nato
postopoma zmanjšujeta do konca projekta.
Ocene lahko podamo na dva načina: točkovno (na primer 340 človek.ur) ali intervalno (na
primer 100–500 človek.ur), pri tem pa moramo vedno navesti stopnjo zaupanja (na primer
90 %), tj. verjetnost, da bo ocena točna. Ker veljajo projekti razvoja programske opreme za
izredno nepredvidljive, je zgodnje ocene primernejše podati intervalno in na ta način
povečati stopnjo zaupanja.
Interval ocene moramo prilagoditi negotovosti. Manjša, kot je negotovost, manjši je lahko
interval ocene. Večja, kot je negotovost, večji mora biti interval ocene. Ker se negotovost z
6
razvojem projekta manjša, se manjša tudi razpon intervala. Na primer, če prve analize
pokažejo, da bo ocenjevani obseg dela projekta znašal okoli 7.000 človek.ur, je zaradi
velike negotovosti smiselno podati širši interval (na primer 5.000–10.000 človek.ur). Ko pa
analize pred koncem projekta pokažejo, da bo obseg dela znašal 8.670 človek.ur, lahko
zaradi majhne negotovosti podamo ožji interval (na primer 8.500–8.800 človek.ur).
Razpon intervala (spodnjo in zgornjo mejo) lahko glede na razvojno fazo projekta
določimo s pomočjo Tabele 1.
Tabela 1: Razpon intervala ocen v odvisnosti od razvoja projekta
Množitelji nominalne ocene
(obseg dela in stroški)
Projektni mejniki Spodnja meja Zgornja meja
Začetna opredelitev produkta 0,25x 4,00x
Potrjena opredelitev produkta 0,50x 2,00x
Potrjene projektne zahteve 0,67x 1,50x
Potrjen uporabniški vmesnik 0,80x 1,25x
Potrjen podrobni načrt 0,90x 1,10x
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 39.
Določanje preozkih intervalov je pogosto posledica notranjih oziroma zunanjih pritiskov.
Notranji pritiski so navadno povezani z zmotnim prepričanjem, da je ožji interval znak
večje strokovnosti. Zunanje pritiske običajno ustvarjajo vodstvo in kupci, ko zahtevajo
pretirano natančnost ocen v zgodnjih fazah projekta (McConnell, 2006, str. 18).
Pri ocenjevanju je priporočljivo ločiti dve veščini, in sicer »kako veliko« in »kako
negotovo«. Jørgensen predlaga, da interval ocene določi prvi ocenjevalec, stopnjo
negotovosti (verjetnosti) pa drugi ocenjevalec (2004a, str. 49). Oseba, ki določa interval
ocene, mora dobro poznati projekt, ki ga ocenjuje, in različne metode ocenjevanja. Oseba,
ki določa stopnjo negotovosti, mora dobro poznati različna tveganja, jih znati ovrednotiti in
prenesti na konkreten projekt.
1.3 Proces ocenjevanja projektov razvoja programske opreme
Standardizirani proces ocenjevanja projektov opredeljuje vrsto in zaporedje aktivnosti, ki
so potrebne za ustvarjanje natančnih projektnih ocen. Galorath (2006, str. 1–10) predlaga
desetstopenjski proces, ki vključuje naslednje aktivnosti:
1. Opredelitev področja in namena ocenjevanja. Prva aktivnost ocenjevanja je
določanje in dokumentiranje pričakovanj v zvezi z oceno in dokumentiranje
uporabniških, sistemskih in poslovnih zahtev. Cilj aktivnosti je poskrbeti, da
7
udeleženci projekta točno razumejo, kaj se ocenjuje in kakšen je namen ocenjevanja.
Ker se z napredovanjem projekta pričakovanja in zahteve spreminjajo, moramo vse
spremembe dosledno beležiti.
2. Opredelitev tehnične podlage, pravil in predpostavk. Druga aktivnost ocenjevanja
je opredelitev funkcionalnosti, ki je vključena v oceno. Če funkcionalnost ni podrobno
določena, moramo ustvariti pravila, ki pomagajo določiti, kaj je zajeto v oceni in česa
ni. Vse predpostavke, kot je ponovna uporaba programske kode, morajo biti
dokumentirane. Tehnična podlaga, pravila in predpostavke so osnova, na kateri temelji
ocena. Čeprav so te informacije v začetnih fazah projekta povezane z veliko
negotovostjo, jih moramo natančno določiti in z napredovanjem projekta dosledno
dopolnjevati.
3. Zbiranje podatkov. Tretja aktivnost ocenjevanja je zbiranje ključnih podatkov, ki
zagotavljajo ustreznost ocene. Vse ocene so povezane z negotovostjo, zato jih
zapisujemo v obliki intervalov (optimistična, najverjetnejša, pesimistična ocena). Ker
vsi podatki ne prihajajo iz istega vira in niso dostopni ob istem času, si moramo
pomagati z obsežno zbirko podatkov. Sistematično organizirani podatki olajšajo
kasnejše dokumentiranje.
4. Merjenje velikosti programske opreme. Četrta aktivnost ocenjevanja je merjenje
velikosti programske opreme. Velikost programske opreme je izhodiščni parameter, ki
omogoča vse nadaljnje ocene projekta. Obseg programske opreme določa nova
programska oprema kot tudi vsa obstoječa programska oprema, ki bo vključena v novi
sistem. Oceno velikosti programske opreme moramo izraziti intervalno.
5. Ustvarjanje izhodiščne ocene. Peta aktivnost ocenjevanja je ustvarjanje izhodiščne
ocene, na podlagi katere se določijo trajanje in stroški projekta. Pri merjenju velikosti
programske opreme in ustvarjanju izhodiščne ocene morajo sodelovati izkušeni in
usposobljeni projektni člani, ki jim morajo biti na voljo vsa potrebna programska
orodja. Projektni vodja mora pripraviti uveljavljen, dokumentiran in ponovljiv proces
ocenjevanja.
6. Vrednotenje in analiziranje tveganj. Šesta aktivnost ocenjevanja je vrednotenje in
analiziranje tveganj. Težave, povezane z ocenjevanjem programske opreme, lahko
imajo resne posledice, če ne predvidimo možnih tveganj. Naloga projektnega tima je
prepoznati tveganja, jih ovrednotiti in pripraviti načrt, kako tveganja odpraviti ali
zmanjšati in kako ravnati v primeru težav.
7. Preverjanje ocene. Sedma aktivnost ocenjevanja je preverjanje ocene. Formalno
preverjanje je pomemben del ocenjevanja, s čimer lahko povečamo zanesljivost
ustvarjenih ocen. Pri preverjanju ocen ugotavljamo tako pravilnost ocene kot tudi
8
ustreznost ocenjevalnega procesa. Natančno preverjanje pomaga ugotoviti napačne
predpostavke, nezanesljive podatke in pristranskost ocenjevalca ter prispeva k
boljšemu razumevanju tveganj. Zato je priporočljivo, da preverjanje opravi neodvisen
zunanji ocenjevalec.
8. Pripravljanje projektnega plana. Osma aktivnost ocenjevanja je pripravljanje
projektnega plana. Gre za uporabo ustvarjenih ocen pri določanju trajanja in stroškov
posameznih funkcij izdelka in projektnih aktivnosti. Pri tej aktivnosti igra ključno
vlogo izkušenost projektnega vodje. Dober projektni vodja se zaveda, kaj je mogoče
realno doseči, tudi če so pričakovanja višjega vodstva drugačna.
9. Dokumentiranje rezultatov ocenjevanja. Deveta aktivnost ocenjevanja je
dokumentiranje rezultatov. Ob vsakem zaključku projekta moramo dokumentirati
informacije in novo pridobljena znanja, povezana z ocenjevanjem. Gre za manjkajoče
in nepopolne informacije, glavne odločitve, tveganja in težave, ki so se pojavila med
ocenjevanjem projekta. Na ta način lahko zagotovimo dobro podlago za vsa nadaljnja
ocenjevanja in izboljšamo proces ocenjevanja.
10. Sledenje projektnemu dogajanju. Deseta aktivnost je sledenje projektnemu
dogajanju. Med projektom moramo slediti dogajanju in dejanske rezultate primerjati z
načrtovanimi. Pri tem zasledujemo naslednje projektne parametre: obseg dela
projektnega tima, odkrite programske napake in obseg dela za njihovo odpravljanje,
razvojne značilnosti, kot so programski jezik, razvojni model in tehnologija,
spremembe uporabniških zahtev, programske kode in trajanja, hitrost napredovanja
projekta, velikost in kompleksnost programske opreme. Če se med rezultati in
načrtovanimi ocenami pojavijo razlike, moramo ustvariti nove ocene.
1.4 Razlogi za ocenjevalne napake pri projektih razvoja programske opreme
Natančno ocenjevanje je ključni dejavnik, ki vpliva na uspešnost projektov. Nenatančne
ocene imajo lahko škodljive posledice: preveč optimistične ocene lahko povzročijo velike
finančne izgube, preveč pesimistične ocene pa lahko povzročijo odpovedi pogodb.
Raziskave kažejo, da ima večina projektov razvoja programske opreme težave s preveč
optimističnimi ocenami, ki odstopajo v povprečju za 30–40 % (Grimstad, 2006, str. 14).
Razlogov za ocenjevalne napake pri projektih razvoja programske opreme je veliko, v
splošnem pa jih lahko razdelimo v pet skupin:
Netočne ali nepopolne informacije o projektu in izvajalcih. Projekti razvoja
programske opreme so povezani z negotovostjo, ki je največja v začetku projekta, ko
9
projekt ni natančno določen. Ocene, ki so podane v zgodnjih fazah projekta, lahko
odstopajo za štirikrat in več (McConnell, 2006, str. 36).
Spremenljive projektne zahteve. Spremenljive projektne zahteve vplivajo na stožec
negotovosti tako, da se ta ne zoža, ko bi se moral. Ker se projektne zahteve vseskozi
spreminjajo, ostaja negotovost visoka, kar pomeni večjo možnost napake (McConnell,
2006, str. 42).
Pretiran optimizem in pristranskost ocenjevalcev. Pretiran optimizem je težava
razvijalcev, ki običajno dokaj točno ocenijo svoje delo, vendar pozabijo upoštevati 20–
30 % opravil, kar prinese 20–30 % odstopanje. Podobna težava je tudi na strani
projektnega vodstva, ki želi, da bi bili projekti zaključeni hitreje in ceneje, kar vodi do
nerealnih ocen (McConnell, 2006, str. 46).
Neustrezen proces ocenjevanja. Podjetja ocenjevanja običajno ne obravnavajo
celovito in ločeno od ostalih procesov, temveč ga izvajajo večkrat v okviru različnih
procesov (pri načrtovanju dela, pri določanju proračuna idr.). To pripelje do različnih
interpretacij, pogledov in nenazadnje do različnih ocen (Grimstad et al., 2006, str. 308).
Med ostalimi razlogi za ocenjevalne napake se pojavljajo tudi pomanjkanje znanja o
ocenjevanju programskih projektov, neskladnost projektnih ciljev, hitre spremembe v
programski industriji idr.
2 OCENJEVANJE VELIKOSTI PROJEKTOV RAZVOJA PROGRAMSKE OPREME
2.1 Opredelitev velikosti programske opreme
Velikost projektov razvoja programske opreme je v največji meri odvisna od velikosti
programske opreme. Angleška različica Wikipedije velikost programske opreme (angl.
software size) opredeljuje kot inherentno lastnost vsakega računalniškega programa,
podobno kot je teža inherentna lastnost fizičnega predmeta (Software Sizing, 2010).
V kontekstu ocenjevanja programskih projektov je velikost programske opreme neodvisna
spremenljivka (Mendes & Mosley, 2006, str. 30) in eden izmed najpomembnejših vložkov
procesa ocenjevanja projektov, na podlagi katerega lahko določimo obseg dela, trajanje in
stroške projekta (McConnell, 2006, str. 173).
Tok ocenjevanja projektov razvoja programske opreme je predstavljen na Sliki 3.
10
Slika 3: Tok ocenjevanja projektov razvoja programske opreme
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 173.
Oceno velikosti programske opreme ustvarimo na podlagi formalnega zapisa zahtev.
Priročnik ISBSG2 opisuje tri vrste zahtev (2005, str. 4–5):
Funkcionalne (uporabniške) zahteve, ki določajo, katere uporabniške funkcije bodo
vključene v programsko opremo. Funkcionalne zahteve so poslovni procesi, ki jih bo
izvajala oziroma podpirala programska oprema, in opisujejo delovanje programske
opreme.
Nefunkcionalne zahteve, ki določajo, kako mora programska oprema delovati oziroma
kakšnim kakovostnim zahtevam mora ustrezati z vidika varnosti, zmogljivosti,
zanesljivosti, prilagodljivosti idr.
Tehnične (izvedbene) zahteve, ki določajo, kako bo programska oprema razvita (s
katerimi orodji, metodami), kakšen bo razvojni proces, kakšna bo izkušenost projektnih
članov idr.
Ko so projektne zahteve znane, lahko velikost programske opreme ocenimo bodisi z
analogno metodo bodisi z uporabo modelov. Pri analogni metodi oceno načrtovane
programske opreme določimo na podlagi analognega projekta. Pri ocenjevanju z uporabo
modelov pa ocena velikosti temelji na štetju elementov (funkcij, objektov, razredov ipd.),
ki jih model pretvori v oceno velikosti programske opreme (Živkovič, 2004, str. 10).
Neodvisno od tehnike ocenjevanja programske opreme je temeljno vprašanje, kaj najbolje
odraža velikost programske opreme. Zavedati se moramo, da velikost programske opreme
ni enodimenzijska mera (McConnell, 2006, str. 199), temveč jo določajo različni atributi,
in sicer (Fenton & Pfleeger, 1997, str. 245):
Dolžina (angl. length) je fizična velikost programske opreme. Koristno je meriti dolžino
uporabniške specifikacije, razvojnega načrta in izvorne kode. Na primer, merjenje
2 ISBSG je kratica za Mednarodno skupino za standarde primerjalnega preizkušanja programske opreme
(angl. International Software Benchmarking Standards Group).
Velikost
programske opreme Obseg dela
Stroški
Trajanje
11
dolžine uporabniške specifikacije lahko pomaga napovedati dolžino razvojnega načrta,
kar lahko pomaga napovedati dolžino izvorne kode. Po drugi strani pa dolžina ne odraža
funkcionalnosti in kompleksnosti programske opreme. Ena vrstica izvorne kode,
napisane v programskem jeziku SQL, na primer select * from , omogoča isto
funkcionalnost, kot jo omogoča okoli 20 vrstic izvorne kode napisane v C++ ali Javi, in
okoli 500 vrstic izvorne kode, napisane v Cobolu (Abu Talib, 2007, str. 5).
Funkcionalnost (angl. functionality) je opredeljena s številom funkcij, ki jih vključuje
programska oprema. Pri merjenju količine funkcij programske opreme nas ne zanima,
kako bodo funkcije razvite, temveč kaj bodo omogočale uporabnikom. Funkcionalne
uporabniške zahteve se nanašajo na procese, ki jih bo izvajala oziroma podpirala
programska oprema, in opisujejo delovanje programske opreme. Področje merjenja
količine funkcij natančneje določa standard ISO/IEC3 14143 (ISBSG, 2005, str. 4, 27).
Kompleksnost (angl. complexity) je širok pojem, ki ima lahko več pomenov, na primer
problemska, algoritemska, strukturna in kognitivna kompleksnost. V grobem ločujemo
med algoritemsko in kognitivno kompleksnostjo. Algoritemska kompleksnost se nanaša
na časovno in pomnilniško učinkovitost algoritma, ki je potrebna za izvajanje programa.
Kognitivna kompleksnost se nanaša na človeški napor, potreben za razumevanje ali
opravljanje določene računalniške naloge. Kompleksnost ni odvisna zgolj od atributov
programske opreme, temveč je odvisna tudi od sposobnosti in izkušenosti razvijalcev.
Kar se zdi izkušenemu razvijalcu enostavno, je lahko za manj izkušenega razvijalca
kompleksno (Tran-Cao, Lévesque & Menuier, 2003, str. 1; Curtis & Carleton, 1994, str.
102).
Mnenja o tem, kaj natančno predstavlja velikost programske opreme, so deljena. Iz tega
razloga obstajajo številne mere velikosti programske opreme, kot so: funkcije, objekti,
razredi, spletne strani, podatkovne tabele, primeri uporabe, uporabniške zahteve idr.
(McConnell, 2006, str. 198). Kot najbolj uveljavljeni meri veljata vrstice izvorne kode in
funkcijske točke.
2.2 Merjenje fizične velikosti programske opreme
Merjenje fizične velikosti programske opreme temelji na vrsticah izvorne kode (angl.
source lines of code – SLOC). Merska enota vrstice izvorne kode je opredeljena kot število
nepraznih, nekomentiranih programskih stavkov, vključno z vmesniki in deklaracijami
podatkov (McConnell, 2006, str. 96). Uporabljati se je pričela v času luknjanih kartic, ko
so bile te glavni način kodiranja. Vsaka luknjana kartica je običajno predstavljala eno
vrstico kode. Štetje vrstic izvorne kode v današnji obliki se je pričelo uporabljati s pojavom
prvih vrstično-usmerjenih jezikov, kot sta Fortran in zbirni jezik, in velja za najstarejšo in
3 ISO/IEC je kratica za Mednarodno organizacijo za standardizacijo/Mednarodno elektrotehniško komisijo
(angl. International Organization for Standardization/International Electrotechnical Commission).
12
izredno priljubljeno tehniko merjenja velikosti. Njeni največji prednosti sta preprostost
uporabe in razširjenost. Njene poglavitne težave so: neenotnost definicije, kaj predstavlja
vrstico izvorne kode, odvisnost od programskega jezika in težavnost merjenja v zgodnjih
fazah projekta (Source lines of code, 2010).
Obstajata dva načina štetja izvornih vrstic kode: štetje fizičnih vrstic in štetje logičnih
vrstic kode. Pri štetju fizičnih vrstic kode šteje vsaka neprazna in nekomentirana vrstica.
Pri štetju logičnih vrstic upoštevamo le logične stavke, neodvisno od fizične strukture.
Prednost štetja logičnih vrstic je manjša odvisnost od stila programiranja, vendar pa ima
veliko pomanjkljivost, tj. neenotnost definicije, kaj predstavlja logično vrstico izvorne
kode. Zaradi omenjene težave SEI4 priporoča uporabo štetja fizičnih vrstic kode (Park,
1996, str. 101).
2.3 Merjenje funkcijske velikosti programske opreme
Merjenje funkcijske velikosti (angl. functional size measurement) je najbolj uveljavljen
način ocenjevanja velikosti programske opreme. Obstaja mnogo različnih metod merjenja
funkcijske velikosti, kot so na primer: IFPUG5, COSMIC
6, NESMA
7, Mk II, FiSMA
8 idr.
(ISBSG, 2005, str. 27). Osnova vsem je metoda analize funkcijskih točk, ki temelji na
merjenju obsega funkcij programske opreme s funkcijskimi točkami. Funkcijska točka
(angl. function point) velja za najbolj razširjeno mersko enoto funkcijske velikosti
programske opreme. Standard štetja funkcijskih točk dopolnjuje in vzdržuje organizacija
IFPUG (McConnell, 2006, str. 200).
Največji prednosti funkcijskih točk sta neodvisnost od programskega jezika in možnost
merjenja v zgodnjih fazah projekta. Največje slabosti so: pristranskost in zamudnost
merjenja, diskretna zasnova funkcije in sintetičnost vrednosti, ki nimajo neposrednega
fizičnega pomena (Function point, 2010).
2.3.1 Analiza funkcijskih točk
Analiza funkcijskih točk (angl. function point analysis) je strukturirana metoda, ki temelji
na členitvi sistema v manjše sestavne dele ali komponente z namenom lažjega razumevanja
in proučevanja. Metodo je iznašel Allan J. Albrecht, da bi premostil težave s štetjem vrstic
4 SEI je kratica za Inštitut za programski inženiring (angl. Software Engineering Institute).
5 IFPUG je kratica za Mednarodno skupino uporabnikov funkcijske točke (angl. International Function Point
Users Group). 6 COSMIC je kratica za Mednarodni konzorcij za enotno merjenje programske opreme (angl. Common
Software Measurement International Consortium). 7 NESMA je kratica za Nizozemsko zvezo uporabnikov merjenja programske opreme (angl. Netherlands
Software Metrics users Association). 8 FiSMA je kratica za Finsko zvezo za merjenje programske opreme (angl. Finnish Software Measurement
Association).
13
izvorne kode in izboljšal ocenjevanje obsega dela pri projektih razvoja programske opreme
(Longstreet, 2005, str. 1–2).
Funkcijska točka je mera, ki je neodvisna od tehnologije. Število funkcijskih točk bo ostalo
enako ne glede na to, kateri programski jezik, metoda razvoja ali strojna oprema bodo
uporabljeni. Analiza funkcijskih točk lahko služi za ugotavljanje razlik v produktivnosti
med različnimi razvojnimi orodji, okolji in jeziki znotraj in med organizacijami. S pomočjo
analize funkcijskih točk lahko ugotavljamo, kako se število funkcijskih točk spreminja ob
zaključku vsake faze projekta. Če je število funkcijskih točk ob zaključku projekta večje,
kot je bilo sprva načrtovano, to kaže na možnost, da faza ugotavljanja uporabniških zahtev
ni bila dovolj dobro opravljena. Stopnja rasti funkcijskih točk med projektom je torej
pokazatelj uspešnosti ugotavljanja uporabniških zahtev. Štetje funkcijskih točk mora
opraviti usposobljeno in izkušeno osebje. Pred štetjem funkcijskih točk je potrebno
natančno opredeliti sistem in ugotoviti, katere komponente so del sistema in katere niso
(Longstreet, 2005, str. 2).
Postopek uporabe metode analize funkcijskih točk obsega sedem korakov (Živkovič, 2004,
str. 13–17):
Določitev področja uporabe. Ločimo tri področja štetja funkcijskih točk: pri razvojnih
projektih, pri projektih prenove in pri obstoječih aplikacijah.
Določitev mej programskega sistema. Meje ogradijo projekt ali aplikacijo glede na
druge uporabniške domene ali aplikacije.
Določitev podatkovnih funkcij in njihove kompleksnosti. Obstajata dva tipa
podatkovnih funkcij, interne logične zbirke in zunanje vmesniške datoteke, za katere
moramo določiti kompleksnost s pomočjo tabele, kjer se upošteva število enostavnih
podatkovnih elementov in število sestavljenih podatkovnih elementov.
Določitev vseh transakcijskih funkcij in njihove kompleksnosti. Obstajajo tri
kategorije transakcijskih funkcij: zunanji vhodi, zunanji izhodi in zunanje poizvedbe, za
katere moramo določiti kompleksnost s pomočjo tabele, kjer se upošteva število
enostavnih podatkovnih elementov, število sestavljenih podatkovnih elementov in
število podatkov, na katere se sklicujemo.
Izračun neporavnanih funkcijskih točk. Vsako izmed podatkovnih in transakcijskih
funkcij (interne logične zbirke, zunanje vmesniške zbirke, zunanji vhodi, zunanji izhodi
in zunanje poizvedbe) ovrednotimo z nivojem zahtevnosti: nizka, srednja ali visoka.
Vsakemu nivoju priredimo ustrezno utež, s katero pomnožimo število posameznih
atributov ter seštejemo vse zmnožke. Skupna vrednost je velikost programske opreme
izražena s funkcijskimi točkami, ki jih imenujemo »neporavnane« funkcijske točke
(angl. unadjusted function points), ker vpliv tehnične kompleksnosti sistema pri njih še
ni bil upoštevan. Množitelje pri izračunu neporavnanih funkcijskih točk prikazuje
Tabela 2.
14
Določitev vrednosti prilagoditvenega faktorja – vpliva značilnosti sistema. Število
neporavnanih funkcijskih točk pomnožimo s prilagoditvenim faktorjem. Prilagoditveni
faktor (angl. value adjustment factor – VAF) upošteva tehnične in delovne značilnosti
sistema.
Izračun števila funkcijskih točk. V zadnjem koraku moramo upoštevati še področje
uporabe, ki smo ga določili v prvem koraku. Glede na področje uporabe imamo tri
različne načine določanja končnega števila funkcijskih točk in s tem velikosti projekta.
Tabela 2: Množitelji pri izračunu neporavnanih funkcijskih točk
Funkcijske točke
Funkcijski tipi Nizka
kompleksnost
Srednja
kompleksnost
Visoka
kompleksnost
Zunanji vhodi ___ × 3 ___ × 4 ___ × 6
Zunanji izhodi ___ × 4 ___ × 5 ___ × 7
Zunanje poizvedbe ___ × 3 ___ × 4 ___ × 6
Notranje logične
zbirke ___ × 4 ___ × 10 ___ × 15
Zunanje vmesniške
zbirke ___ × 5 ___ × 7 ___ × 10
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 201.
Razlaga funkcijskih tipov (Longstreet, 2005, str. 3–5):
Zunanji vhodi (angl. external inputs – EI) predstavljajo proces, v katerem podatki iz
okolja vstopajo v sistem.
Zunanji izhodi (angl. external outputs – EO) predstavljajo proces, v katerem podatki
izstopajo iz sistema v okolje.
Zunanje poizvedbe (angl. external inquiry – EQ) predstavljajo proces, v katerem se
podatki črpajo iz notranje logične zbirke in/ali zunanje vmesniške zbirke, na podlagi
zunanjih vhodov in zunanjih izhodov.
Notranje logične zbirke (angl. internal logical files – ILF) predstavljajo zbirko logično
povezanih podatkov znotraj sistema, ki se polni prek zunanjih vhodov.
Zunanje vmesniške zbirke (angl. external interface files – EIF) predstavljajo zbirko
logično povezanih podatkov zunaj sistema.
V strokovni literaturi sem zasledil kritike glede uporabe prilagoditvenega faktorja in
vrednotenja kompleksnosti funkcijskih tipov. McConnel (2005, str. 201) izpostavlja študiji,
pri katerih je bilo ugotovljeno, da so neporavnane funkcijske točke v večji korelaciji z
dejansko velikostjo programske opreme kot poravnane funkcijske točke. Obenem tudi
navaja, da nekateri strokovnjaki predlagajo, da naj se pri vrednotenju funkcijskih tipov
15
uporabi zgolj srednja kompleksnost, s čimer se zmanjša pristranskost. Standard ISO/IEC
20926:2003 temelji na uporabi neporavnanih funkcijskih točk. V raziskavi, ki jo je opravil
Lokan je prilagoditveni faktor v 46 % vseh primerov pozitivno učinkoval na končno oceno,
v 31 % vseh primerov je prilagoditveni faktor negativno učinkoval na končno oceno in v
23 % vseh primerov prilagoditveni faktor ni imel nobenega vpliva na končno oceno. Na
podlagi opravljene raziskave Lokan odsvetuje uporabo prilagoditvenega faktorja
(Živkovič, 2004, str. 17–18).
2.3.2 Ostale metode merjenja funkcijske velikosti
Poleg analize funkcijskih točk so uveljavljene in standardizirane tudi druge metode
merjenja funkcijske velikosti (Živkovič, 2004, str. 18–21):
Metoda celovite funkcijske točke (angl. full function points) COSMIC FPP odpravlja
pomanjkljivost osnovne metode funkcijskih točk pri merjenju velikosti sistemov, za katere
je potrebno zajeti vso podporno programsko opremo.
Metoda funkcijske točke značilnosti (angl. feature points), ki jo je razvil Caper Jones,
temelji na funkcijskih točkah z določenimi prilagoditvami za uporabo pri projektih razvoja
sistemov v realnem-času. Točke značilnosti vpeljujejo dodatno komponento, ki obravnava
kompleksnost in jo imenujemo algoritmi.
Metoda Mk II FPA, ki jo je razvil Charles Symons, je metoda za kvantitativno analizo in
merjenje obsega procesiranja informacij. Metoda je po navedbah avtorjev neodvisna od
metode projektnega vodenja kot tudi od razvojne metode.
Metoda NESMA je podobna osnovni različici analize funkcijskih točk in uporablja enake
koncepte. Metoda vpelje tri tipe štetja:
1. podrobno štetje,
2. groba ocenitev,
3. statistična ocenitev.
Prvi tip štetja predvideva upoštevanje vseh funkcijskih tipov in določitev njihove
kompleksnosti, kot to opredeljuje osnovna metoda analize funkcijskih točk. Groba ocenitev
izpusti določanje kompleksnosti posamezne funkcije in uporabi za vse podatkovne funkcije
nizko kompleksnost in za vse transakcijske funkcije vrednost srednje kompleksnosti. Na ta
način poenostavimo postopek ocenitve obsega, ocenitev pa lahko izvedemo prej, v procesu
razvoja. Pri tretjem načinu štetja izračun neporavnanih funkcijskih točk opravimo zgolj na
podlagi podatkovnih funkcij s pomočjo matematične zveze med številom podatkovnih
funkcij in številom pripadajočih transakcijskih funkcij.
16
Kot zaključuje Živkovič (2004, str. 20), je nastanek opisanih metod pogojen z odpravo
pomanjkljivosti osnovne različice metode, ki je na določenih področjih uporabe manj
učinkovita kot na drugih. Iz tega sledi, da moramo metodo merjenja funkcijske velikosti
izbrati glede na področje uporabe in pri tem upoštevati njene prednosti in slabosti.
2.4 Povezava med fizično in funkcijsko velikostjo programske opreme
Albrecht in Gaffney (1983) sta ugotovila, da so funkcijske točke v močni korelaciji z
vrsticami izvorne kode. Pri pretvarjanju funkcijskih točk v vrstice izvorne kode si lahko
pomagamo z industrijskim povprečjem. Tabela 3 podaja pretvorbo funkcijskih točk v
vrstice izvorne kode glede na programski jezik.
Tabela 3: Pretvorba funkcijskih točk v vrstice izvorne kode
Število vrstic izvorne kode na funkcijsko točko
Programski jezik Najnižja
Vrednost
Najpogostejša
vrednost
Najvišja
vrednost
C 60 128 170
C# 40 55 80
C++ 40 55 140
Cobol 65 107 150
Java 40 55 80
Macro Assembly 130 213 300
Perl 10 20 30
Druga generacija
(Fortran 77, Cobol, Pascal ipd.) 65 107 160
Smalltalk 10 20 40
SQL 7 13 15
Tretja generacija
(Fortran 90, Ada 83 ipd.) 45 80 125
Microsoft Visual Basic 15 32 41
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 202.
17
3 OCENJEVANJE OBSEGA DELA PROJEKTOV RAZVOJA PROGRAMSKE OPREME
3.1 Razlaga ocenjevanja obsega dela
Ocenjevanje obsega dela (angl. effort estimation) je določanje najverjetnejše količine dela,
ki je potrebna za dokončanje aktivnosti. Ocenjevanje obsega dela je eno ključnih opravil
planiranja in kontroliranja projektov. Na podlagi ocene obsega dela se lahko določijo
stroški in trajanje celotnega projekta (McConnell, 2006, str. 173).
V praksi se pogosto pojavlja problem razumevanja, kaj je obseg dela in kako ga meriti.
Vodnik po znanju projektnega vodenja (2008, str. 362) obseg dela9 (angl. effort)
opredeljuje kot število enot dela, ki je potrebno za dokončanje neke aktivnosti ali drugega
elementa projekta. Običajno se izraža v enotah mere »človek.ura« ali »človek.dan«.
»Človek.ura« je enota za obseg dela, ki ga opravi povprečno usposobljen delavec v
normalnih razmerah v eni uri.
Ocenjevanje obsega dela ni deterministično, temveč je pogojeno z verjetnostjo (Slika 4). Iz
tega sledi, da imata na primer načrtovani in najverjetnejši obseg dela različno verjetnost
(Grimstad et al., 2006, str. 308).
Slika 4: Primer porazdelitve verjetnosti pri ocenjevanju obsega dela
Ver
jetn
ost
Najverjetnejši
obseg dela
Načrtovani
obseg dela
Vir: Povzeto po S. Grimstad, M. Jørgensen in K. Moløkken-Østvold,
Software effort estimation terminology: The tower of Babel, 2006, str. 307.
9 V slovenski literaturi s področja projektov razvoja programske opreme se kot različica pojma obseg dela
uporablja tudi pojem trud.
18
Potrebno je razločevati med obsegom dela in trajanjem, kot tudi med različnimi
vrednostmi obsega dela: najverjetnejšim (angl. most likely), načrtovanim (angl. planned) in
dejanskim obsegom dela (angl. actual effort).
3.1.1 Povezava med obsegom dela in trajanjem projekta
Številne študije projektov razvoja programske opreme nakazujejo, da med obsegom dela in
trajanjem obstaja nelinearna povezava (McConnell, 2006, str. 221). Približek te povezave
lahko ponazorimo z enačbo (1).
3 ObsegDela3Trajanje * (1)
Kjer je:
Trajanje – trajanje projekta v mesecih
ObsegDela – obseg dela projekta v človek.mesecih
Kot je razvidno iz grafikona (Slika 5), obseg dela v odvisnosti od trajanja projekta narašča
eksponentno. Pri manjših projektih je razlika med obsegom dela in trajanjem majhna, pri
večjih projektih pa je ta razlika precejšnja.
Slika 5: Razmerje med obsegom dela in trajanjem projekta
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 3 6 9 12 15 18 21 24 27 30 33 36
Trajanje [mesec]
Ob
seg
del
a [č
lov
ek.m
esec
]
Večji projekti zahtevajo nesorazmerno več dela kot manjši. Razloge za to lahko iščemo v
dejstvu, da so večji projekti kompleksnejši in da pri večjih projekti običajno sodeluje več
ljudi (McConnell, 2006, str. 57).
19
Če želimo skrajšati nominalno trajanje projekta, moramo povečati število projektnih
članov. Večje število projektnih članov pomeni večji obseg dela projekta. Velja tudi
obratno, manjše število projektnih članov pomeni manjši obseg dela in s tem daljše
nominalno trajanje projekta (McConnell, 2006, str. 227–228).
V raziskavi projektov razvoja poslovnih informacijskih sistemov srednje velikosti Putnam
ugotavlja, da se z večanjem števila projektih članov skrajšuje trajanje, vendar le do
določene točke. Ko presežemo optimalno število članov, se trajanje prične povečevati,
bistveno se poveča tudi obseg dela. Če še dodatno povečujemo število članov, se trajanje
ustali, obseg dela pa strmo narašča (McConnell, 2006, str. 229). Opisana dinamika je
grafično predstavljena na Sliki 6.
Slika 6: Razmerje med obsegom dela, trajanjem projekta in številom projektnih članov
Ob
seg
del
a/T
raja
nje
Število projektnih članov
Obseg dela
Trajanje
Vir: Povzeto po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 229.
3.1.2 Povezava med obsegom dela in stroški projekta
Med obsegom dela in stroški projekta obstaja močna povezava. To lahko razložimo s tem,
da stroške projekta v največji meri določajo stroški dela, ki temeljijo na obsegu dela
(ISBSG, 2005, str. 21). Močna povezanost obsega dela in stroškov je razlog, da se v
strokovni literaturi s področja projektov razvoja programske opreme kot sinonim za
ocenjevanje obsega dela uporablja izraz ocenjevanje stroškov (angl. cost estimation).
McConnell (2006, str. 241) opozarja, da je pri ocenjevanju stroškov na podlagi obsega dela
potrebno upoštevati številne dejavnike. Organizacije različno vrednotijo prekomerno delo
(nadure), imajo različen sistem obračuna urnih postavk glede na to, ali delo opravljajo
20
notranji ali zunanji izvajalci idr. Poleg tega je potrebno pri obračunu projektnih stroškov
upoštevati tudi druge stroške, kot so potni stroški, obratovalni stroški, stroški osnovnih
sredstev, stroški režije ipd.
3.2 Dejavniki produktivnosti
Kadar govorimo o dejavnikih produktivnosti, s tem mislimo na dejavnike, ki vplivajo na
obseg dela. Produktivnost je opredeljena kot razmerje med proizvedeno količino
proizvodov in zanje vloženim delovnim časom (Pučko & Rozman, 1998, str. 260). V
kontekstu razvoja programske opreme je produktivnost razmerje med velikostjo
programske opreme in obsegom dela (Kitchenham & Mendes, 2004, str. 1023).
delaobseg
velikostostproduktivn
_ (2)
Produktivnost lahko izrazimo tudi s številom delovnih obdobij, ki je potrebno za izdelavo
ene enote velikosti programske opreme (ISBSG, 2005, str. 13). Ta kazalec imenujemo
stopnja projektne produktivnosti (angl. project delivery rate – PDR):
velikost
delaobsegPDR
_ (3)
Ker je stopnja projektne produktivnosti recipročna produktivnosti, velja, da nižje vrednosti
pomenijo večjo produktivnost (na primer 5 človek.ur/FT10
je »boljše« kot 15
človek.ur/FT).
Pri merjenju in ocenjevanju produktivnosti nastopajo različne entitete. Med procesom
razvoja programske opreme se iz vložkov tvorijo izložki, pri tem pa se porabljajo viri
(Slika 7).
Slika 7: Enostavni model produktivnosti
PROCESvložek Programska
oprema
Uporabniške
zahteve
VIRI
(obseg dela)
izložek
STROŠKIVREDNOST
Vir: Prirejeno po D. N. Card, The Challenge of Productivity Measurement, 2006, str. 3.
10
FT je kratica za funkcijsko točko.
21
Proces je lahko razvoj celotne programske opreme ali zgolj pripojitev določene funkcije,
izdelava izvedbenega načrta rešitve, testiranje programske opreme idr. Vložek v proces so
lahko uporabniške zahteve, funkcionalna specifikacija, tehnični načrt ipd. Izložek iz
procesa je lahko celotna programska oprema, del programske opreme, izvedbeni načrt ali
drug soroden produkt. Kot vidimo, obstajajo različni vložki in izložki in s tem različne
mere produktivnosti. Katere izložke in vložke merimo, je odvisno od proučevanega
procesa in potreb. Najpogosteje se za merjenje produktivnosti uporabljata splošna mera
velikosti programske opreme (na primer vrstice kode) in količina vloženega dela (Card,
2006, str. 3).
Pri primerjavi produktivnosti med različnimi projekti velja previdnost. Ker organizacije
različno merijo produktivnost, in ker na produktivnost vpliva mnogo dejavnikov, so lahko
primerjave zavajajoče. Če želimo primerjati produktivnost med različnimi projekti,
moramo ugotoviti, na kakšen način je bila produktivnost izmerjena, za kakšno vrsto
programske opreme gre, katera razvojna orodja in tehnike so bila uporabljena, kakšna je
kakovost programske opreme, koliko članov je sodelovalo pri projektu, kakšna je
izkušenost projektih članov, kolikšen je delež večkrat uporabljene programske kode idr.
(ISBSG, 2005, str. 13). Neupoštevanje naštetih lastnosti lahko pripelje do primerjanja
»hrušk z jabolki«, torej do popolnoma napačnih ocen produktivnosti, ki lahko odstopajo
tudi desetkrat ali več (McConnell, 2006, str. 207).
Na produktivnost projektov razvoja programske opreme vpliva veliko dejavnikov.
Razdelimo jih lahko v štiri glavne skupine: dejavniki osebja, kot sta izkušenost in velikost
projektnega tima; procesni dejavniki, kot sta programski jezik in programska orodja;
dejavniki izdelka, kot sta kompleksnost in vrsta programske opreme; in dejavniki
računalniškega sistema, kot sta pomnilniška in časovna omejitev.
Raziskovalci so ugotovili, da le manjše število dejavnikov pomembno vpliva na
produktivnost v določenem okolju. Raziskovalca Mukhopadhyay in Kekre sta pri razvoju
metode za zgodnje ocenjevanje obsega dela kontrolno-procesnih aplikacij prišla do dobrih
rezultatov z upoštevanjem zgolj dveh dejavnikov produktivnosti. Rezultati Bankerja et al.
kažejo, da lahko razmeroma majhno število ključnih dejavnikov pojasni velik del razlik v
produktivnosti v specifičnem okolju (Maxwell, Van Wassenhove & Dutta, 1995, str. 3).
V nadaljevanju sledi pregled ključnih dejavnikov, ki vplivajo na produktivnost projektov
razvoja programske opreme.
3.2.1 Velikost programske opreme
Dejavnik, ki najbolj vpliva na produktivnost, je velikost programske opreme (McConnell,
2006, str. 55). Velikost programske opreme v veliki meri določa velikost projekta. Večina
22
raziskav je pokazala, da večji programski projekti zahtevajo nesorazmerno več dela kot
manjši projekti. To lastnost imenujemo disekonomija obsega (angl. diseconomy of scale).
Z večanjem projektnega tima se eksponentno povečuje koordinacija in s tem komunikacija
med projektnimi člani, zaradi česar se eksponentno povečuje tudi obseg dela. Na primer,
projekt s 100.000 vrsticami kode zahteva okvirno 13-krat večji obseg dela kot projekt z
10.000 vrsticami kode, medtem ko projekt z 1.000.000 vrsticami kode zahteva 160-krat
večji obseg dela kot projekt z 10.000 vrsticami kode (McConnell, 2006, str. 57–60).
3.2.2 Vrsta programske opreme, razvojno okolje in programski jezik
Naslednji dejavnik, ki vpliva na produktivnost je vrsta programske opreme. McConnell
(2006, str. 62) primerja produktivnosti med projekti razvoja različne programske opreme.
Projekti razvoja intranetne poslovne programske opreme beležijo deset- do dvajsetkrat
manjšo produktivnost kot primerljivi projekti razvoja vgrajene (angl. embedded)
programske opreme ali programske opreme v realnem času (angl. real-time).
Priročnik ISBSG (2005, str. 16–18) navaja različne stopnje projektne produktivnosti z
vidika razvojnega okolja. Iz Tabele 4 je razvidno, kako na stopnjo projektne produktivnosti
vplivata programski jezik in razvojno okolje.
Tabela 4: Stopnja projektne produktivnosti* v odvisnosti od programskega jezika in
razvojnega okolja
Programski jezik/
Razvojno okolje C JAVA VISUAL BASIC
Centralni računalniški sistem
(angl. mainframe) 13 18 28
Osebni računalnik
(angl. PC) 6 10 8–9
Večokoljski računalniški
sistem (angl. multi-platform) 5 7 8
Legenda: * Stopnja projektne produktivnosti je pridobljena statistično v okviru podatkovne zbirke
ISBSG R9, 2005.
Vir: Povzeto po ISBSG, Practical Project Estimation 2
nd Edition, 2005, str. 16–18.
V Tabeli 4 je podana srednja vrednost (v nadaljevanju mediana) stopnje projektne
produktivnosti, merjena v človek.urah na funkcijsko točko (človek.ura/FT). Pri tem je
potrebno opozoriti na precejšni razpon, ki ga imajo projekti znotraj iste skupine. Na
primer, projekti razvoja programske opreme za osebne računalnike, ustvarjene s
programskim jezikom C, imajo razpon stopnje projektne produktivnosti 1–30
človek.ur/FT, vendar ima večina teh projektov stopnjo projektne produktivnosti 2–9
človek.ur/FT, mediano pa 6 človek.ur/FT (ISBSG, 2005, str. 18).
23
Kot je razvidno, obstajajo precejšnje razlike v stopnji projektne produktivnosti v odvisnosti
od razvojnega okolja. Projekti razvoja programske opreme za centralne računalniške
sisteme beležijo občutno manjšo produktivnost kot ostali projekti (ISBSG, 2005, str. 18).
Razlike v produktivnosti se pojavljajo tudi pri uporabi različnih programskih jezikov. Na
podlagi podatkov iz Tabele 5 lahko sklepamo, da je uporaba programskih jezikov kot so
Java, C# ali Visual Basic bolj produktivna kot na primer uporaba jezikov C, Cobol ali
Macro Assembly (McConnell, 2006, str. 65).
Tabela 5: Razmerje funkcionalnosti na vrstico kode v primerjavi s programskim jezikom C
Programski jezik Razmerje v primerjavi s C
C 1 : 1
C# 1 : 2,5
C++ 1 : 2,5
Cobol 1 : 1,5
Fortran 95 1 : 2
Java 1 : 2,5
Macro Assembly 2 : 1
Perl 1 : 6
Smalltalk 1 : 6
SQL 1 : 10
Visual Basic 1 : 4,5
Vir: S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 64–65.
3.2.3 Značilnosti projektnega tima
Tretjo najvplivnejšo skupino dejavnikov predstavljajo dejavniki, ki se nanašajo na osebje
oziroma projektni tim. Med te dejavnike uvrščamo (McConnell, 2006, str. 63):
Sposobnosti analitika (angl. requirements analyst capability). Gre za sposobnosti pri
specifikaciji zahtev in načrtovanju produkta, sposobnosti analitičnega razmišljanja,
učinkovitost, temeljitost, sposobnost komuniciranja in sodelovanja.
Sposobnosti programerja (angl. progammer capability). Gre za programerske
sposobnosti, učinkovitost, temeljitost, sposobnost komuniciranja in sodelovanja.
Stalnost osebja (angl. personnel continuity, turnover). Gre za delež projektnih članov, ki
se letno izmenjajo.
Izkušnje z aplikacijo (angl. application, business area experience). Gre za izkušenost
projektnih članov pri delu z načrtovano programsko opremo.
24
Izkušnje s programskim jezikom in orodji (angl. language and tools experience). Gre
izkušenost projektnih članov pri uporabi programskih jezikov in orodij.
Izkušnje z razvojnim okoljem (angl. platform experience). Gre za izkušenost projektnih
članov pri delu v določenem razvojnem okolju.
Usklajenost projektnega tima (angl. team cohesion). Gre za stopnjo sodelovanja med
projektnimi člani.
Številne študije so pokazale, da lahko razlike v osebju bistveno vplivajo na obseg dela, in
sicer za faktor deset- do dvajsetkrat. Iz tega sledi, da je nemogoče natančno oceniti projekt,
če ne poznamo osebja (McConnell, 2006, str. 64).
3.2.4 Ostali dejavniki produktivnosti
V strokovni literaturi lahko zasledimo najrazličnejše dejavnike produktivnosti. Poleg že
opisanih dejavnikov produktivnosti, ki lahko pomembno vplivajo na obseg dela, so tudi
(McConnell, 2006, str. 67–70):
kompleksnost programske opreme (angl. product complexity),
omejitev izvajalnega časa (angl. time constraint),
večlokacijski razvoj (angl. multi-site development),
pričakovana zanesljivost (angl. required realiability),
količina potrebne dokumentacije (angl. extent of documentation reqiured),
uporaba programskih orodij (angl. use of software tools),
spremenljivost tehnologije (angl. platform volatility),
pomnilniška omejitev (angl. storage constraint).
Celovito analizo dejavnikov produktivnosti in njihovega vpliva na projektno okolje
omogočajo t. i. parametrični ocenjevalni modeli. Ocenjevalni modeli, med njimi tudi
parametrični ocenjevalni modeli, so predmet naslednjega poglavja, in sicer metod in tehnik
ocenjevanja projektov razvoja programske opreme.
4 METODE IN TEHNIKE OCENJEVANJA OBSEGA DELA PROJEKTOV RAZVOJA PROGRAMSKE OPREME
Informacijska znanost se z ocenjevanjem projektov ukvarja že več kot štiri desetletja.
Začetki segajo v leto 1966, ko je bilo objavljeno raziskovalno delo ameriškega avtorja E.A.
Nelsona, v katerem so predstavljeni izsledki študije ocenjevalnih atributov, opravljene na
169 programskih projektih. Študija je pomembno vplivala na razvoj prvih uporabnih
modelov ocenjevanja projektov, ki so se pojavili proti koncu '60 in v začetku '70 let.
Razvoj se je nadaljeval v '70 in '80 letih, ko je dosegel svoj vrhunec. V tem času so bili
razviti nekateri najbolj znani parametrični ocenjevalni modeli, kot sta COCOMO in SLIM,
25
ki sta v posodobljenih različicah v uporabi še dandanes. Parametrični ocenjevalni modeli
temeljijo na regresijski analizi in metodi najbližjih kvadratov (Boehm et al., 2000, str. 1).
Glavna težava, s katero so se soočali razvijalci parametričnih ocenjevalnih modelov, je bila
nenehna rast velikosti in s tem kompleksnosti programske opreme. Hitro se spreminjajoča
računalniška industrija je oteževala natančno ocenjevanje, zaradi česar so se v '90 letih
pojavili novi ocenjevalni modeli, temelječi na strojnem učenju in umetni inteligenci. Med
temi so precejšnjo pozornost vzbudili modeli, ki uporabljajo mehanizem sklepanja na
osnovi primerov, in modeli, zgrajeni na osnovi nevronskih mrež. Po navedbah nekaterih
avtorjev naj bi ti modeli v določenih okoliščinah zagotavljali boljše rezultate kot
parametrični modeli (Mair et al., 2000, str. 27).
V zadnjih dveh desetletjih so bili razviti številni drugi ocenjevalni modeli, zasnovani na:
regresijskih in klasifikacijskih drevesih, genetskih algoritmih, genetskem programiranju,
linearnem programiranju, mehkem računanju, Bayesovih mrežah, asociativnih pravilih,
razvrščanju v skupine, mehki logiki in drugih modelih, temelječih na statističnih metodah,
umetni inteligenci ali na kombinaciji ene ali več metod (Jørgensen, 2007, str. 450).
Danes lahko izbiramo med različnimi metodami in tehnikami ocenjevanja projektov, vse
pa se srečujejo s problemom dinamičnega razvoja programske opreme. Eden izmed
glavnih ciljev raziskav ocenjevanja obsega dela projektov je ustvariti ocenjevalno metodo,
s katero bo mogoče zanesljivo zajeti načrtovano projektno delo in natančno napovedati
obseg dela razvoja produkta.
4.1 Razvrstitev metod in tehnik ocenjevanja projektov razvoja programske opreme
V strokovni literaturi lahko zasledimo različne razvrstitve metod in tehnik ocenjevanja
projektov razvoja programske opreme. V nadaljevanju je opisanih pet značilnih razvrstitev:
Jørgensenova razvrstitev. Jørgensen (2007, str. 450) v svojih raziskavah razlikuje
med tremi pristopi: ocenjevanje s pomočjo ekspertne presoje, ocenjevanje s pomočjo
formalnih modelov in kombinirano ocenjevanje. Kot pravi Jørgensen, gre za razvrstitev
glede na vrsto miselnega procesa v »koraku določanja količine«, ko se razumevanje
ocenjevalnega problema pretvori v merljivo količino, tj. oceno obsega dela. V tem
smislu ekspertna presoja temelji na intuiciji, formalni modeli pa na avtomatizmu.
Ocenjevalni procesi ekspertne presoje se bistveno ločijo od ocenjevalnih procesov
formalnih modelov, zato jih moramo obravnavati ločeno. Kadar kombiniramo rezultate
(ocene) dveh ali več procesov, govorimo o kombiniranem ocenjevanju, pri tem pa
moramo opisati, za kakšno kombiniranje gre.
26
Razvrstitev ISBSG. Priročnik ISBSG (2005, str. 6–8) loči med dvema pristopoma,
»makro« ocenjevanje in »mikro« ocenjevanje. Značilnost »makro« ocenjevalnih metod
je, da omogočajo okvirno ocenjevanje v začetnih fazah projekta. Primer makro
ocenjevalnih metod so regresijske enačbe, primerjalna metoda in analogna metoda.
Značilnost »mikro« ocenjevalnih metod je, da omogočajo natančno ocenjevanje, ko so
znane podrobnosti o ocenjevanem projektu. Primer »mikro« ocenjevalne tehnike je
ocenjevanje »od spodaj navzgor«.
Razvrstitev »Shepperd in drugi«. Raziskovalci Shepperd, Schofield in Kitchenham
(1996, str. 170) predlagajo razvrstitev ocenjevalnih pristopov v tri skupine: ocenjevanje
s pomočjo ekspertne presoje, ocenjevanje s pomočjo parametričnih modelov in
analogno ocenjevanje.
Razvrstitev »Myrtveit in drugi«. Raziskovalci Myrtveit, Stensrud in Shepperd
(2005, str. 381–382) ločijo med dvema skupinama ocenjevalnih pristopov, in sicer
metode neobsežnih podatkov in metode obsežnih podatkov. Metode neobsežnih
podatkov potrebujejo malo ali nič zgodovinskih podatkov, medtem ko potrebujejo
metode obsežnih podatkov veliko količino podatkov. Metode neobsežnih podatkov
obsegajo ocenjevanje s pomočjo ekspertne presoje, ocenjevanje s pomočjo analitično-
hierarhičnega procesa (AHP) in ocenjevanje s pomočjo sklepanja na osnovi primerov.
Metoda obsežnih podatkov obsega dve podskupini, to sta: arbitrarni funkcijski
aproksimatorji (AFA) in funkcije. Funkcije predvidevajo matematično povezavo med
spremenljivkami enačbe, medtem ko metode AFA tega ne predvidevajo. Podskupina
AFA obsega analogno ocenjevanje, ocenjevanje s pomočjo nevronskih mrež in
ocenjevanje s pomočjo klasifikacijskih in regresijskih dreves. Podskupina funkcije
obsega ocenjevanje s pomočjo regresijske analize. Razvrstitev »Myrtveit in drugi« je
grafično predstavljena na Sliki 8.
Slika 8: Razvrstitev ocenjevalnih metod in tehnik »Myrtveit in drugi«
OCENJEVALNE
METODE
Metode
obsežnih
podatkov
Metode
neobsežnih
podatkov
Ekspertna presoja Funkcije
Regresijska
analiza
Sklepanje na
osnovi primerovNevronske mreže
Regresijska in
klasifikacijska
drevesa
Analogno
ocenjevanje
AHP AFA
Vir: Povzeto po I. Myrtveit, E. Stensrud in M. Shepperd, Reliability and Validity in Comparative Studies of
Software Prediction Models, 2005, str. 382.
27
Razvrstitev »Boehm in drugi«. Raziskovalci Boehm, Abts in Chulani (2000, str. 2)
predlagajo razvrstitev ocenjevalnih pristopov v šest skupin: ocenjevanje s pomočjo
modelov, ocenjevanje s pomočjo ekspertnih tehnik, ocenjevanje s pomočjo tehnik
učenja, ocenjevanje s pomočjo dinamičnih tehnik, ocenjevanje s pomočjo regresijskih
tehnik in ocenjevanje s pomočjo sestavljenih tehnik.
Razlog, da obstaja veliko razvrstitev ocenjevalnih metod in tehnik, je njihovo različno
obravnavanje. Raziskovalci proučujejo ocenjevalne metode in tehnike z različnih vidikov.
Jørgensena zanimajo razlike med metodami v odvisnosti od ocenjevalnega procesa. ISBSG
se ukvarja z metodami in tehnikami zgodnjega ocenjevanja projektov. Shepperd in
sodelavci raziskujejo analogno metodo. Myrtveit in sodelavci preiskujejo točnost že
opravljenih raziskav ocenjevalnih metod, ki potrebujejo veliko količino podatkov.
Razvrsititev »Boehm in drugi« je dober primer razmejitve lastnosti različnih metod in
tehnik. Manjša težava te razvrstitve je prekrivanje prve skupine (ocenjevanje s pomočjo
modelov) z drugimi skupinami ocenjevalnih metod. Boehm in soavtorja med ocenjevanje s
pomočjo modelov štejejo le parametrične modele, medtem ko modele, temelječe na
strojnem učenju in regresijski analizi, razvrščajo v druge skupine. V tem smislu se zdi
Jørgensenova razvrstitev primernejša, saj v tem primeru skupina formalnih modelov
obsega vse vrste ocenjevalnih modelov. To je razlog, da sem podobno razvrstitev privzel v
magistrskem delu.
4.2 Ocenjevanje s pomočjo ekspertne presoje
Ocenjevanje s pomočjo ekspertne presoje velja za najbolj priljubljeno, obenem pa tudi za
redko proučevano ocenjevalno metodo. Jørgensen (2004a, str. 39) ekspertno ocenjevanje
opredeli kot ocenjevanje, ki zajema celotni spekter ocenjevalnih strategij, od popolne
intuicije (»ocenjevanje po občutku«) do ekspertne presoje (»strukturirano ocenjevanje«),
podprte z zgodovinskimi podatki, znanim procesom in kontrolnimi seznami. Glavni
značilnosti ekspertne presoje sta, da jo opravlja strokovnjak z ocenjevanega področja, in da
temelji na nedoločljivem in neponovljivem miselnem procesu, tj. intuiciji.
Izraz »ekspertno ocenjevanje« je opredeljen široko. Ekspertno ocenjevanje lahko zajema
različne metode in tehnike, in sicer analogno metodo, tehniko od zgoraj navzdol, tehniko
od spodaj navzgor, tehniko Delfi idr. Večji del ocenjevalnega procesa lahko temelji na
analitičnih metodah (na primer razčlenitev projekta v aktivnosti), vendar pa korak
oblikovanja ocene v največji meri temelji na intuiciji, in je le redko razložljiv. To je glavna
značilnost, po kateri se ekspertno ocenjevanje razlikuje od ocenjevanja s pomočjo
formalnih modelov (Jørgensen, 2007, str. 450–451).
28
Jørgensen (2004a, str. 39) in McConnell (2006, str. 105) poročata, da je večina projektov
razvoja programske opreme ocenjenih s pomočjo ekspertne presoje. Jørgensen (2004, str.
39) možna razloga za priljubljenost ekspertne presoje vidi v nezaupanju organizacij do
ocenjevalnih modelov, in v pomanjkanju dokazov, da so ocenjevalni modeli natančnejši
kot ekspertna presoja.
Primerjava ekspertne presoje in formalnih modelov ne daje jasnega odgovora na vprašanje,
katera metoda je natančnejša, temveč nakazuje, da je natančnost ocenjevalnih metod
odvisna od okoliščin. Na podlagi opravljenih raziskav je mogoče sklepati, da (Jørgensen,
2007, str. 453):
ekspertna presoja omogoča natančnejše ocene v situacijah, kjer je izjemno veliko
konceptualnih informacij (specifične lastnosti projekta, ki jih pozna ocenjevalec),
ekspertna presoja omogoča natančnejše ocene v nepredvidljivih in spremenljivih
razmerah, medtem ko se uporaba formalnih modelov izkaže za boljšo v predvidljivih
situacijah.
Natančnost ocenjevanja s pomočjo ekspertne presoje se poveča, če je metoda strukturirana.
To pomeni, da se ocenjevalec opira na zgodovinske podatke, sledi določenemu procesu,
uporablja kontrolne sezname, opravi analizo tveganj idr. Jørgensen (2004a, str. 38)
predlaga 12 načel dobre prakse ocenjevanja s pomočjo ekspertne presoje:
1. ovrednotenje natančnosti ocenjevanja brez velikega ocenjevalnega pritiska,
2. izogibanje nasprotujočim se ocenjevalnim ciljem,
3. utemeljitev in presoja izraženih ocen,
4. izogibanje nepomembnim in nezanesljivim podatkom pri ocenjevanju,
5. uporaba dokumentiranih dejstev s preteklih ocenjevanj,
6. izbira strokovnjakov z ustreznim znanjem in dobrimi rezultati z ocenjevanega
področja,
7. uporaba tehnik »od zgoraj navzdol« in »od spodaj navzgor«, neodvisno ene od druge,
8. uporaba kontrolnih seznamov pri ocenjevanju,
9. kombiniranje ocen različnih strokovnjakov in ocenjevalnih pristopov,
10. določitev negotovosti ocenjevanja,
11. zagotovitev povratnih informacij o natančnosti ocenjevanja,
12. zagotovitev šolanja ocenjevalcev.
McConnell (2006, str. 106–110) vidi možnost za izboljšanje natančnosti ekspertne presoje
v členjenju projektnih nalog, uporabi intervalnih ocen, uporabi tehnike PERT11
in uporabi
kontrolnih seznamov. Členjenje projektnih nalog na način, da je njihov obseg dela največ 2
človek.dneva, omogoča večjo obvladljivost in s tem manjšo negotovost. Uporaba intervala
11
PERT je kratica za tehniko vrednotenja in pregledovanja programov (angl. program evaluation and review
technique).
29
od–do (optimistična in pesimistična ocena) omogoča realnejše ocenjevanje in spodbuja
proučitev tveganj. Tehnika PERT omogoča realnejši izračun pričakovanega obsega dela na
podlagi uteženih vrednosti optimistične, pesimistične in najverjetnejše ocene. Uporaba
kontrolnih seznamov odpravlja težavo »prezrtih nalog« in zagotavlja sistematičen pristop k
ocenjevanju. Primer kontrolnega seznama podaja Tabela 6.
Tabela 6: Primer kontrolnega seznama pri ekspertni presoji
Kontrolni seznam
1. Ali je ocenjevani projekt jasno opredeljen?
2. Ali so v oceno vključene vse vrste aktivnosti za dokončanje projekta?
3. Ali so v oceno vključene vse funkcije načrtovane programske opreme?
4. Ali je ocena dovolj podrobno proučena, da vključuje tudi »skrito« delo?
5. Ali ocena temelji na dokumentiranih dejstvih preteklih projektov?
6. Ali je ocena potrjena s strani izvajalcev projekta?
7. Ali ocena temelji na podobni produktivnosti, kot je bila dosežena pri primerljivih aktivnostih?
8. Ali ocena upošteva optimistično, pesimistično in najverjetnejšo vrednost?
9. Ali je pesimistična vrednost ocene dovolj dobro utemeljena?
10. Ali je pričakovana vrednost ocene ustrezno izračunana v primerjavi z drugimi projekti?
11. Ali so domneve, na katerih temelji ocena, dokumentirane?
12. Ali je prišlo do sprememb, odkar je bila ocena pripravljena?
Vir: Prirejeno po S. McConnell, Software Estimation: Demystifying the Black Art, 2006, str. 120.
Ena večjih pomanjkljivosti ekspertne presoje je neponovljivost. Ker je težko ugotoviti in
ovrednotiti dejavnike, ki so bili upoštevani pri oceni, to otežuje ponovitev ocenjevanja.
Kljub temu raziskave kažejo, da je ekspertna presoja lahko učinkovita ocenjevalna metoda,
kadar je kombinirana z manj subjektivnimi tehnikami (Mendes & Mosley, 2006, str. 31).
4.2.1 Analogna metoda
Analogna metoda (angl. estimation by analogy) temelji na iskanju enega ali več projektov,
ki so podobni ocenjevanemu projektu, in na podlagi katerih se določi obseg dela
ocenjevanega projekta. Projekt, ki je podoben ocenjevanemu, imenujemo analogni projekt
(ISBSG, 2005, str. 47).
Analogna metoda v splošnem obsega naslednje korake (Mendes & Mosley, 2006, str. 31):
1. Strokovnjak oceni velikost programske opreme in ovrednoti dejavnike produktivnosti,
ki najbolj vplivajo na obseg dela proučevanega projekta.
2. Na podlagi podatkov iz prvega koraka strokovnjak pridobi podatke preteklih projektov,
za katere je znan obseg dela.
3. Na podlagi pridobljenih podatkov strokovnjak subjektivno oceni obseg dela
proučevanega projekta.
30
Pri analogni metodi sta težavna dva koraka: izbira ustreznega analognega projekta in
prilagoditev ocene novim razmeram. Kot navaja ISBSG (2005, str. 48), ni jasno, kako
najbolje izbrati ustrezen analogni projekt. Strokovnjaki se pri tem lahko zanesejo na
intuicijo ali pa uporabijo orodja, ki analogne projekte razvrstijo po stopnji ujemanja z
ocenjevanim projektom na podlagi algoritmov, kot je na primer metoda najbližjih sosedov.
Ko je ustrezen analogni projekt izbran, je na vrsti prilagoditev ocene. Ker se analogni in
ocenjevani projekt običajno razlikujeta, je te razlike potrebno upoštevati in oceno ustrezno
prilagoditi. Tudi pri tem se strokovnjaki lahko zanesejo na intuicijo ali pa uporabijo
strukturiran pristop.
Analogna metoda se pogosto uporablja v neformalni obliki (ocenjevanje »po občutku«).
Na primer, projekt A je obsegal 100 človek.ur, projekt B mu je podoben, vendar je
nekoliko večji, zato bo obsegal med 100 in 150 človek.ur. Raziskave so pokazale, da je
neformalno ocenjevanje običajno zelo nenatančno, medtem ko je strukturirano ocenjevanje
bistveno natančnejše (McConnell, 2006, str. 106).
Glavne prednosti analogne metode so (ISBSG, 2005, str. 48–49):
razumljivost in enostavnost,
možnost uporabe pri kompleksnih projektih,
možnost uporabe v primeru nepopolnih informacij o projektu,
možnost učenja na podlagi preteklih izkušenj.
Glavne pomanjkljivosti analogne metode so (ISBSG, 2005, str. 49):
metoda je odvisna od razpoložljivosti analognega projekta,
metoda je odvisna od ustreznosti analognega projekta,
metoda je odvisna od možnosti in ustreznosti ugotavljanja razlik med analognim in
proučevanim projektom.
Analogna metoda je namenjena ocenjevanju celotnega projekta ali posameznih aktivnosti.
Ocenjevanje celotnega projekta po projektnih fazah omogoča tehnika »od zgoraj navzdol«.
4.2.2 Tehnika »od zgoraj navzdol«
Pri ocenjevanju s tehniko »od zgoraj navzdol« (angl. top-down estimation) skušamo oceniti
celotni obseg dela projekta, potem pa to oceno razdeliti med posamezne projektne faze.
Jørgensen (2004b, str. 4) tehniko »od zgoraj navzdol« opiše kot iskanje podobnih
projektov, na podlagi katerih se oblikuje ocena za proučevani projekt. Proučevani projekt
ne členimo, temveč ga obravnavamo in primerjamo s podobnimi projekti kot celoto. Ocena
celotnega projekta se nato razdeli po znanih deležih med projektne faze (na primer
planiranje 15 %, snovanje 25 %, razv