Josip Nadih
Autor:
Josip Nadih

Specijalist za BI rješenja

O znanosti poznatoj kao Procjenjivanje

Procjenjivanje posla u softverskoj industriji

Procjenjivanje izvedbe projekta ili faze projekta je kritična disciplina vođenja projekta koja može uzrokovati ozbiljne probleme u kasnijim fazama projekta ukoliko nije kvalitetno napravljena. Uobičajena (ali kriva) praksa je raditi samo jednu, vrlo ranu procjenu metodom iskustvenog prosuđivanja (kao što je prikazano na slici 1), koja nije bazirana na mjerljivim parametrima i izračunima.

Slika 1. Procjenjivanje bez statističke vjerojatnosti

Uvođenje pojma vjerojatnosti

Ispravniji način razmišljanja je uvođenje pojma vjerojatnosti u proces procjenjivanja. Tada procjena posla postaje sličnija Gaussovoj raspodjeli kao što je prikazano na slici 2, s obzirom da postoji samo određena vjerojatnost da će se projekt realizirati u određenom vremenu ili trošku. Najvjerojatniji ishod prema toj raspodjeli, za koji postoji 50%-tna vjerojatnost za realizaciju, zove se još i nominalni ishod.

Slika 2. Procjenjivanje je slično Gaussovoj raspodjeli

Međutim, u stvarnosti procjena izgleda više kao graf prikazan na slici 3 s obzirom da postoji vremenski limit koliko brzo je moguće završiti određeni posao, ali ne postoji limit koliko posao može kasniti u izvedbi.

Slika 3. Ispravan način procjenjivanja

Porazna statistika točnosti procjenjivanja u softverskoj industriji

U odnosu na nominalnu procjenu moguće je napraviti procjenu koja je manje ili više optimistična ili pesimistična. Prema statistici u softverskoj industriji (slika 4) puno je opasnije podcijeniti nego precijeniti posao s obzirom na rizike i nelinearne negativne učinke koji se mogu dogoditi tijekom realizacije posla, tako da je preporuka raditi pesimističnije procjene ukoliko nije moguće dati pouzdanu optimalnu procjenu.

Slika 4. Negativni učinci optimističnih i pesimističnih procjena

Statistika točnosti procjene u odnosu na realizaciju u softverskoj industriji i uspješnosti projekata uopće je poražavajuća, kao što se može vidjeti na slici 5. koja se odnosi na 10-godišnji period od 1994. do 2004. godine.

Slika 5. Statistika uspješnosti projekata u softverskoj industriji

Tendencija greške u procjeni je značajno na strani optimističnog procjenjivanja kao što se može vidjeti na slici 6 koja prikazuje usporedbu procjena i stvarne realizacije u jednoj softverskoj kompaniji, tako da se može govoriti o sistematskoj grešci kojoj je uzrok precjenjivanje vlastitih mogućnosti i preveliko oslanjanje na iskustvene metode.

Slika 6. Statistika procjene projekata u tipičnoj softverskoj kompaniji

Nepouzdanost procjenjivanja

Nepouzdanost procjenjivanja postoji zbog postojanja varijabilnosti u projektu. U ranijim fazama projekta postoji više varijabli, pa je zato nepouzdanost procjenjivanja veća, što je ilustrirano na slici 7. Nepouzdanost je moguće smanjiti uklanjanjem varijabli, što se i događa prirodnim tijekom projekta, pa je tako u zadnjim fazama projekta jednostavno predvidjeti konačan ishod. Zato je najbolji način raditi više procjena, barem jednu procjenu u svakoj fazi projekta, a ne samo jednu procjenu u ranoj fazi projekta.

Slika 7. Konus nesigurnosti procjene prema fazama projekta

Osim nesigurnosti koja je posljedica varijabilnosti, postoje i neki drugi faktori koji utječu na pouzdanost procjenjivanja u odnosu na stvarnu realizaciju projekta (slika 8). Neki od bitnijih faktora su kompleksnost projekta koji se procjenjuje, sposobnost poslovnih analitičara, sposobnost razvojnih inženjera, vremenska ograničenja, česte promjene ljudi koji rade na projektu, distribuirani razvoj, itd.

Slika 8. Faktori koji utječu na pouzdanost procjene

Metode procjenjivanja

Suprotno uobičajenom mišljenju da se dobra procjena temelji na iskustvu, kvaliteta procjene u stvari ovisi o egzaktnosti onoga što se procjenjuje. Zbog toga je prioritet odabira metode procjenjivanja, u ovisnosti o mogućnostima u organizaciji i na konkretnom projektu, slijedeći:

  1. Mjerenje i usporedba - Ako postoje uvjeti za to, najtočniji način procjenjivanja je pronaći mjerljive faktore koji utječu na procjenu i zatim ih usporediti s postojećim podacima. Npr. procjenama na prijašnjim projektima istog tipa i veličine ili statistikom industrije na sličnim projektima ako je dostupna (npr. pomoću Construx Estimate i sličnih alata). Zbog toga je poželjno uspostaviti i održavati bazu podataka procjena i realizacija s prošlih projekata unutar vlastite organizacije.
  2. Dekompozicija i izračun - Ukoliko ne postoje uvjeti za direktno mjerenje i uspoređivanje, najbolje je napraviti dekompoziciju projekta na sastavne komponente, a zatim koristiti aproksimativne kalkulativne metode za procjenu. Jedna od takvih metoda je i PERT (Program Evaluation and Review Technique) analiza.
  3.  Iskustvo - Ukoliko nemamo mogućnosti mjerenja niti kalkulativne procjene, tada je dobro procjenu prepustiti iskusnom voditelju projekta koji može napraviti relativno pouzdanu subjektivnu procjenu na osnovi vlastitog iskustva.

PERT analiza - izračun očekivanog slučaja

PERT analiza je kalkulativna metoda procjenjivanja koja se temelji na dekompoziciji projekta na sastavne dijelove, (višestrukom) iskustvenom procjenjivanju optimističnog, najvjerojatnijeg i pesimističnog ishoda svakog sastavnog dijela, te izračunom očekivanog ishoda uz željenu pouzdanost procjene.

Dekompozicija

Dekompozicija projekta može se napraviti npr. prema strukturi posla na projektu (Work Breakdown Structure), modulima u softveru ili nekoj drugoj raspodjeli. Tablica 1 prikazuje dekompoziciju prema strukturi posla na projektu:

Category

Create/
Do

Plan

Manage

Review

Rework

Report Defects

General management

Planning

Corporate activities (meetings, vacation, holidays, and so on)

Hardware setup/Software setup/Maintenance

Staff preparation

Technical Processes/Practices

Requirements work

Coordinate with other projects

Change management

User-interface prototyping

Architecture work

Detailed designing

Coding

Component acquisition

Automated build

Integration

Manual system tests

Automated system tests

Software release (interim, alpha, beta, and final releases)

Documents (user docs, technical docs)

Tablica 1. Dekompozicija prema strukturi posla na projektu

Izračun očekivanog slučaja

U jednostavnijem primjeru prikazanom u tablici 2 dekompozicija je napravljena prema funkcionalnostima konačnog proizvoda. U tom primjeru dana je samo jedna, vrlo rana procjena za svaku funkcionalnost. U odnosu na stvarnu realizaciju, može se vidjeti da za svaku funkcionalnost postoji određena greška u procjeni. Problem kod ovakvih single-point procjena je što se zbog potencijalne greške u procjeni za svaku funkcionalnost ukupna nepouzdanost procjene značajno uvećava. Npr. ako se uzme da je za svaku funkcionalnost procjena dana s 50% pouzdanosti, ukupna pouzdanost procjene dobiva se množenjem pouzdanosti procjena pojedinih funkcionalnosti, tako da je konačna pouzdanost 0,5 na 10-tu, odnosno tek oko 0,098%.

Feature

Estimated Staff Weeks to Complete

Actual Effort

Feature 1

1,6

3

Feature 2

1,8

2,5

Feature 3

2

1,5

Feature 4

0,8

2,5

Feature 5

3,8

4,5

Feature 6

3,8

4,5

Feature 7

2,2

3

Feature 8

0,8

1,5

Feature 9

1,6

2,5

Feature 10

1,6

3,5

TOTAL

20

29

Tablica 2. Single-point procjena u usporedbi s realizacijom

Kako bi se pouzdanost procjene povećala, kod PERT analize radi se trostruka ekspertna procjena: optimistična, najvjerojatnija i pesimistična. Poželjno je također da procjenu radi više osoba, uključujući i osobe koje će sudjelovati u implementaciji.

Kada se računa očekivani slučaj, najjednostavnije je uzeti sredinu od navedene 3 procjene. Međutim, u praksi se pokazalo da će to biti previše pesimistična procjena, tako da se očekivani slučaj točnije može izračunati prema PERT formuli koja omogućava kalibriranje utjecaja optimistične i pesimistične procjene na očekivani slučaj. Uobičajena formula koja se koristi u PERT analizi je:

ExpectedCase = [BestCase + (4 x MostLikelyCase) + WorstCase] / 6

Korištenjem navedene formule očekivani slučaj će iznositi kako je prikazano u tablici 3.

Feature

Best Case (25% Likely)

Most Likely Case

Worst Case (75% Likely)

Expected Case (50% Likely)

Feature 1

1,6

2

3

2,1

Feature 2

1,8

2,5

4

2,63

Feature 3

2

3

4,2

3,03

Feature 4

0,8

1,2

1,6

1,2

Feature 5

3,8

4,5

5,2

4,5

Feature 6

3,8

5

6

4,97

Feature 7

2,2

2,4

3,4

2,53

Feature 8

0,8

1,2

2,2

1,3

Feature 9

1,6

2,5

3

2,43

Feature 10

1,6

4

6

3,93

TOTAL

20

28,3

38,6

28,62

Tablica 3. Trostruka procjena i izračun očekivanog slučaja

Ukoliko očekivani slučaj s navedenom formulom u praksi proizvodi previše optimistične rezultate, PERT formula za izračun očekivanog slučaja može kalibrirati, pa se tako npr. može povećati težina na strani pesimističnog slučaja:

ExpectedCase = [BestCase + (3 x MostLikelyCase) + (2 x WorstCase)] / 6

Usporedba procjene s realizacijom

Kako bi se napravio pozitivan pomak u kvaliteti procjenjivanja, nužno je raditi usporedbe očekivanog slučaja sa stvarnom realizacijom. Mjera za točnost procjenjivanja je MRE (Magnitude of Relative Error) koja se računa pomoću slijedeće formule:

MRE = AbsoluteValue x [(ActualResult - EstimatedResult) / ActualResult]

Izračunate vrijednosti prikazane su u tablici 4.

Feature

Best Case (25% Likely)

Most Likely Case

Worst Case (75% Likely)

Expected Case (50% Likely)

Actual Effort

Magnitude of Relative Error

Feature 1

1,6

2

3

2,1

3

30%

Feature 2

1,8

2,5

4

2,63

2,5

5%

Feature 3

2

3

4,2

3,03

1,5

102%

Feature 4

0,8

1,2

1,6

1,2

2,5

52%

Feature 5

3,8

4,5

5,2

4,5

4,5

0%

Feature 6

3,8

5

6

4,97

4,5

10%

Feature 7

2,2

2,4

3,4

2,53

3

16%

Feature 8

0,8

1,2

2,2

1,3

1,5

13%

Feature 9

1,6

2,5

3

2,43

2,5

3%

Feature 10

1,6

4

6

3,93

3,5

12%

TOTAL

20

28,3

38,6

28,62

29

Average

24%

Tablica 4. Izračun MRE

Dugoročni cilj je smanjiti MRE pri procjenjivanju projekata, odnosno povećati točnost procjenjivanja.

Pouzdanost procjene

Uobičajena aproksimacija u statistici je pretpostaviti da je 1/6 razlike između minimalne i maksimalne vrijednosti jednaka jednoj standardnoj devijaciji. To se bazira na pretpostavci da je vjerojatnost da minimalna vrijednost obuhvaća sve moguće ishode vrlo mala, dok je vjerojatnost da maksimalna vrijednost obuhvaća sve moguće ishode vrlo visoka.

Izračun procjene uz željenu pouzdanost za male projekte

Za projekte s malim brojem dijelova u dekompoziciji, 10 ili manje, može se koristiti jednostavna kalkulacija standardne devijacije na slijedeći način:

StandardDeviation = (SumOfWorstCaseEstimates - SumOfBestCaseEstimates) / 6

Procjena se u tom slučaju može kalibrirati da se dobije željena pouzdanost, kako je prikazano u tablici 5.

Percentage Confident

Calculation

2%

Expected case - (2 x StandardDeviation)

10%

Expected case - (1.28 x StandardDeviation)

16%

Expected case - (1 x StandardDeviation)

20%

Expected case - (0.84 x StandardDeviation)

25%

Expected case - (0.67 x StandardDeviation)

30%

Expected case - (0.52 x StandardDeviation)

40%

Expected case - (0.25 x StandardDeviation)

50%

Expected case

60%

Expected case + (0.25 x StandardDeviation)

70%

Expected case + (0.52 x StandardDeviation)

75%

Expected case + (0.67 x StandardDeviation)

80%

Expected case + (0.84 x StandardDeviation)

84%

Expected case + (1 x StandardDeviation)

90%

Expected case + (1.28 x StandardDeviation)

98%

Expected case + (2 x StandardDeviation)

Tablica 5. Kalkulacija uz pouzdanost procjene

Koristeći ovaj pristup, procjena sa 75%-tnom statističkom pouzdanosti za navedeni primjer bila bi:

ExpectedCase (29 weeks) + 0.67 x StandardDeviation = 29 + (0.67 x 3.1) = 31

Da bi se pouzdanost procjene povećala s 50% (nominalni očekivani slučaj) na 75% potrebno je dakle uvećati procjenu s 28,62 tjedna na 31 tjedan. Ako je potrebna još veća pouzdanost, odabrala bi se prikladna kalkulacija iz navedene tablice koja bi u konačnici dala još veću procjenu.

Izračun procjene uz željenu pouzdanost za veće projekte

Za veće projekte potrebno je koristiti kompleksnu formulu za izračun standardne devijacije za koju je potrebno znati statističku točnost procjenjivanja procjenitelja/organizacije u odnosu na stvarne ishode u realizaciji. Najbolje je koristiti statističke povijesne podatke, ukoliko postoje. Ako ne postoje, radi se subjektivna, približna ocjena točnosti procjenjivanja. U ovisnosti o odabranoj točnosti procjenjivanja, u formuli za izračun standardne devijacije koriste se faktori iz tablice 6.

If this percentage of your actual outcomes fall within your estimation range…

…use this number as the divisor in the standard deviation calculation for individual estimates

10%

0,25

20%

0,51

30%

0,77

40%

1

50%

1,4

60%

1,7

70%

2,1

80%

2,6

90%

3,3

99.7%

6

Tablica 6. Faktor koji ovisi o točnosti procjenjivanja, a koristi se kod izračuna standardne devijacije

Kada smo odabrali točnost procjenjivanja, postupak za izračun standardne devijacije i varijance je slijedeći:

  1.  Izračunati standardnu devijaciju za svaku stavku u dekompoziciji prema slijedećoj formuli:

    IndividualStandardDeviation = (IndividualWorstCaseEstimate - IndividualBestCaseEstimate) / DivisorFromTable6

  2. Izračunati korijen svake standardne devijacije iz prethodne stavke, što se naziva varijanca.
  3.  Sumirati varijance.
  4.  Izračunati konačnu standardnu devijaciju kao korijen sume varijanci.

Izračun iz primjera bi tada izgledao kao u tablici 7.

Feature

Best Case

Worst Case

Standard Deviation

Variance (Standard Deviation Squared)

Feature 1

1,6

3

0,538

0,290

Feature 2

1,8

4

0,846

0,716

Feature 3

2

4,2

0,846

0,716

Feature 4

0,8

1,6

0,308

0,095

Feature 5

3,8

5,2

0,538

0,290

Feature 6

3,8

6

0,846

0,716

Feature 7

2,2

3,4

0,462

0,213

Feature 8

0,8

2,2

0,538

0,290

Feature 9

1,6

3

0,538

0,290

Feature 10

1,6

6

1,692

2,864

TOTAL

20

38,6

-

6,48

Standard Deviation

-

-

-

2,55

Tablica 7. Izračun standardne devijacije i varijance za svaku stavku u dekompoziciji

Kada se navedena vrijednost standardne devijacije iz primjera primijeni u kalkulacijama iz tablice 5 za definirane vrijednosti pouzdanosti, dobiju se slijedeće procjene trajanja projekta:

Percentage Confident

Effort Estimate

2%

23,5

10%

25,4

16%

26,1

20%

26,5

25%

26,9

30%

27,3

40%

28

50%

28,6

60%

29,3

70%

30

75%

30,3

80%

30,8

84%

31,2

90%

31,8

98%

33,7

Tablica 8. Procjene iz primjera u ovisnosti o definiranoj pouzdanosti

Ukoliko npr. želimo procjenu s 80%-tnom pouzdanošću, procjena će iznositi 30,8 tjedana. Ukoliko želimo 98%-tnu pouzdanost, ona će iznositi 33,7 tjedana. Vidljivo je da se s povećanjem željene pouzdanosti nužno povećava i vrijednost procjene, što je i očekivano.

Rizici uz procjenu

Kako bi procjena bila u potpunosti valjana, potrebno je uvijek navesti i rizike koji ne ulaze u procjenu, odnosno rizike koji nisu pokriveni procjenom, a ako se ostvare, mogu utjecati na ishod. Uz svaki rizik potrebno je navesti barem: približnu vjerojatnost ostvarenja rizika, utjecaj na ukupno trajanje projekta i mjere za izbjegavanje rizika.

Ilustracije i primjeri: Software Estimation: Demystifying the Black Art, Steve McConnell

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular automatsko generiranje dokumnetacije Azure Backbone benchmark BI BI projekti blog Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection development dinamička forma dinamički parametri dinamički query distribuirani razvoj dokumentacija Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend funkionalna dokumentacija game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup poslovna analiza pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg swagger tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web workshops Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta