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