Poglavlje 10: Ekonomika programskog proizvoda
Priča za početak. Godine 2002. britanska vlada pokrenula je Nacionalni program za informacione tehnologije u zdravstvu (NPfIT), najveći civilni softverski projekat svog vremena. Cilj je bio velik i plemenit: jedan elektronski karton za svakog pacijenta u Engleskoj, dostupan u svakoj bolnici i ambulanti. Ugovori su potpisani brzo, s velikim dobavljačima, za cijelu zemlju odjednom. Ali bolnice su radile na različite načine, ljekari nisu bili pitani šta im treba, rokovi su probijani, a dobavljači su odustajali. Parlamentarni odbor je 2011. preporučio da se program ugasi, i iste godine vlada ga je raspustila; dijelovi koji su već radili nastavili su kao zasebni projekti. Nacionalna revizorska kancelarija je kasnije procijenila da će ukupan trošak, do kraja korištenja svih dijelova, iznositi oko 10 milijardi funti. Koristi izmjerene do 2012. procijenjene su na 3,7 milijardi, otprilike trećinu potrošenog. Niko nije sumnjao da je cilj bio dobar. Pitanje koje je falilo na početku bilo je ekonomsko: koliko će zaista koštati, šta ćemo zaista dobiti, i kada?
U poglavlju 2 napravili smo budžet tima DeliveryApp (40.000 €), a u poglavljima 3–9 vidjeli smo da svaka odluka ima cijenu: nefunkcionalni zahtjevi, arhitektura, komponente, servisi. Ovo poglavlje sve to stavlja na vagu. Prvi dio govori o tome gdje softver stvara vrijednost, šta košta, kada je bolje kupiti nego razvijati, i šta je ukupna cijena vlasništva. Drugi dio govori kako se mjeri veličina i složenost softvera, kako se procjenjuje trošak, i kako se odlučuje o ulaganju pomoću neto sadašnje vrijednosti i perioda povrata. Matematike ima malo, i sve je na brojevima DeliveryApp.
Literatura. Osnovna literatura predmeta:
- I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 23, planiranje i procjena).
- B. W. Boehm: Software Engineering Economics, Prentice Hall, 1981.
- S. McConnell: Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
Riječi ovog poglavlja.
- Lanac vrijednosti – niz aktivnosti kroz koje firma stvara vrijednost za kupca.
- Analiza troškova i koristi – poređenje svega što projekat košta sa svim što donosi.
- Razvoj ili kupnja (make or buy) – odluka da li softver praviti sami ili kupiti gotov.
- Razvoj u saradnji – razvoj s drugima: otvoreni kod, zajednički projekti, partneri.
- TCO (total cost of ownership) – ukupna cijena vlasništva: sve što softver košta kroz cijeli život.
- LOC (lines of code) – broj linija koda.
- Ciklomatska složenost – broj nezavisnih putanja kroz funkciju (McCabe, 1976).
- Funkcijske tačke – mjera veličine softvera prema onome što radi za korisnika (Albrecht, 1979).
- COCOMO – model za procjenu napora i trajanja razvoja (Boehm, 1981).
- Čovjek-mjesec – posao jedne osobe tokom jednog mjeseca.
- NPV (net present value) – neto sadašnja vrijednost: današnja vrijednost svih budućih priliva minus ulaganje.
- Diskontna stopa – procenat kojim se umanjuje vrijednost budućeg novca.
- Period povrata – vrijeme za koje se ulaganje vrati.
Ciljevi poglavlja. Nakon poglavlja možete: objasniti gdje u lancu vrijednosti softver stvara vrijednost; nabrojati vrste troškova i koristi softverskog proizvoda; obrazložiti odluku razvoj, kupnja ili saradnja; izračunati TCO za dvije opcije; izmjeriti LOC i ciklomatsku složenost i objasniti njihova ograničenja; prebrojati funkcijske tačke za jednostavan sistem; procijeniti napor i trajanje osnovnim COCOMO modelom; objasniti konus nesigurnosti; izračunati NPV i period povrata i na osnovu njih preporučiti odluku.
Plan poglavlja – Predavanje 10: dva časa teorije i jedan čas dopunske prakse
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 10.1–10.4 Lanac vrijednosti, troškovi i koristi, razvoj ili kupnja, TCO | Razvijati ili kupiti platformu? 73.600 € naspram 77.000 € |
| Teorija 2 | 10.5–10.8 Metrike, procjena, NPV, period povrata | Da li se DeliveryApp 2.0 isplati? NPV = 9.950 € |
| Dopunska praksa | NPV i povrat u Pythonu ili Excelu | Šta ako je stopa 25 %? |
Dio 1 – Vrijednost i trošak
10.1 Lanac vrijednosti softvera
Michael Porter je 1985. opisao lanac vrijednosti: firma stvara vrijednost kroz niz aktivnosti, i svaka dodaje nešto što kupac plaća. Za softverski proizvod lanac izgleda ovako:
- Razumijevanje potrebe – istraživanje tržišta, razgovor s korisnicima (poglavlja 1 i 3).
- Razvoj – dizajn, kod, testovi (poglavlja 3–5).
- Isporuka i rad – oblak, nadzor, dostupnost (poglavlja 5–6).
- Prodaja i uvođenje – ugovori s gradovima i restoranima, obuka.
- Podrška i održavanje – pomoć korisnicima, ispravke, nove verzije.
Uz to idu aktivnosti podrške: ljudi (zapošljavanje, učenje), alati i infrastruktura, upravljanje.
Važan uvid: kupac DeliveryApp ne plaća kod, nego vrijednost: narudžbu koja stigne tačno, tačan obračun, manje izgubljenih poziva u restoranu. Kod je trošak; vrijednost je ono što proizvod donosi. Zato tim pita „koja funkcija donosi najviše vrijednosti za najmanje troška?”, a to je isto pitanje koje vlasnica proizvoda postavlja kad slaže backlog (poglavlje 2).
Ukratko.
- Lanac vrijednosti softvera: razumijevanje potrebe, razvoj, isporuka i rad, prodaja i uvođenje, podrška i održavanje.
- Kupac plaća vrijednost, a ne kod; kod je trošak.
- Prioriteti backloga su ekonomska odluka: najviše vrijednosti za najmanje troška.
10.2 Troškovi i koristi
Troškovi softverskog proizvoda dijele se na:
| Vrsta | Primjeri u DeliveryApp 2.0 |
|---|---|
| razvoj | plate tima (36.000 €), dizajn, licence alata |
| infrastruktura | oblak, baza, red poruka, SMS (po poruci) |
| isporuka i uvođenje | obuka restorana, marketing u novom gradu |
| održavanje | ispravke, nadogradnje komponenti, sigurnosne zakrpe |
| podrška | odgovori na pozive restorana i kupaca |
| skriveni troškovi | tehnički dug (poglavlje 4), zastoji, incidenti |
Koristi mogu biti:
- direktne, mjerljive u novcu – pretplate restorana, provizije, manje izgubljenih narudžbi;
- indirektne – manje grešaka u obračunu, manje posla telefonom, bolji podaci za odluke;
- nemjerljive ili teško mjerljive – zadovoljstvo kupaca, ugled udruženja, mogućnost širenja u nove gradove.
Održavanje je najveći trošak. Prema većini istraživanja, više od polovine ukupnog troška softvera koji se koristi godinama odlazi na održavanje i razvoj poslije prve isporuke. Zato poglavlja o čistom kodu, testovima i arhitekturi nisu „lijepo pisanje”, nego ekonomija: ona smanjuju najveću stavku troška.
Česta zabluda. „Najjeftinije je ono što se najbrže napravi.” Brzo napravljen proizvod s mnogo tehničkog duga je jeftin samo do prve isporuke. Svaka sljedeća izmjena je skuplja (slika 4.3), a izmjena ima mnogo više od prve isporuke.
Ukratko.
- Troškovi: razvoj, infrastruktura, uvođenje, održavanje, podrška i skriveni troškovi.
- Koristi: direktne, indirektne i teško mjerljive.
- Održavanje je obično najveći trošak, pa kvalitet koda smanjuje ukupni trošak.
10.3 Razvoj, kupnja ili saradnja
Prije nego što se išta razvija, pita se: mora li to biti naše? Postoje tri puta:
| Put | Kada ima smisla | Rizik |
|---|---|---|
| razviti sami | funkcija je srce proizvoda i razlikuje nas od konkurencije | trošak, vrijeme, održavanje zauvijek |
| kupiti gotovo (proizvod, usluga, komponenta) | funkcija je ista kod svih (plaćanje, SMS, računovodstvo) | zavisnost od dobavljača, cijena licence, manje kontrole |
| razviti u saradnji | više firmi ima isti problem; otvoreni kod | dogovaranje, licence, sporije odluke |
Pravilo palca: razvijaj ono što te razlikuje, kupuj ono što je isto kod svih. DeliveryApp ne razvija vlastiti sistem plaćanja karticama (to je isto kod svih, i strogo regulisano), ali razvija obračun dostave po gradovima i praćenje uživo (to ga razlikuje).
Razvoj u saradnji danas najčešće znači otvoreni kod: Python, .NET, FastAPI, PostgreSQL, Linux, Kubernetes razvijaju hiljade ljudi iz stotina firmi zajedno. Firme koriste otvoreni kod jer je besplatan za upotrebu, ali i doprinose mu, jer je jeftinije zajedno održavati zajedničku osnovu nego svako svoju. Uslovi su provjera licence i rizici iz poglavlja 8 (left-pad, ranjivosti).
Odluka za DeliveryApp 2.0. Na tržištu postoji gotova platforma za dostavu koja se može prilagoditi („white label”): uvođenje 5.000 €, licenca 1.500 € mjesečno. Lana mora odlučiti: razvijati DeliveryApp 2.0 dalje ili preći na gotovu platformu? Odgovor daje ukupna cijena vlasništva.
Ukratko.
- Tri puta: razviti sami, kupiti gotovo, razviti u saradnji.
- Pravilo palca: razvijaj ono što te razlikuje, kupuj ono što je isto kod svih.
- Otvoreni kod je najčešći oblik razvoja u saradnji.
10.4 Ukupna cijena vlasništva
Ukupna cijena vlasništva (TCO) je sve što softver košta kroz cijeli život, a ne samo cijena kupovine ili razvoja. Analogija je automobil: jeftin auto koji troši mnogo goriva i često je u servisu može za pet godina koštati više od skupljeg, a štedljivog.
TCO za DeliveryApp 2.0, za četiri godine (primjeri/python/ekonomika.py):
| Stavka | Razviti sami | Kupiti platformu |
|---|---|---|
| početno | ulaganje u 2.0: 40.000 € | uvođenje: 5.000 € |
| godišnje | održavanje 20 % troška razvoja: 7.200 €; hosting: 1.200 € | licenca 12 × 1.500 € = 18.000 € |
| 4 godine | 40.000 + 4 × (7.200 + 1.200) = 73.600 € | 5.000 + 48 × 1.500 = 77.000 € |
Razlika od 3.400 € nije velika, i zato odluka ne može biti samo o brojevima. U korist razvoja: DeliveryApp ostaje svoj, s pravilima po gradu koja gotova platforma možda ne podržava, i s mogućnošću proizvodne linije (DeliveryApp Apoteka, poglavlje 9). U korist kupovine: manji rizik, brže uvođenje, tim se može baviti drugim stvarima. Lana bira razvoj, ali zapisuje odluku u ADR (poglavlje 7), s uslovom: ako za dvije godine broj gradova ne pređe pet, odluka se preispituje.
Na času. Kad bi licenca platforme bila 1.200 € mjesečno, koliko bi bio TCO kupovine za 4 godine? Da li bi se odluka promijenila? (Odgovor: 5.000 + 48 × 1.200 = 62.600 €, što je 11.000 € manje od razvoja; odluka bi tražila jače razloge za razvoj.)
Ukratko.
- TCO je sve što softver košta kroz cijeli život, kao automobil s gorivom i servisom.
- Za DeliveryApp 2.0 TCO razvoja je 73.600 €, a kupovine 77.000 € za četiri godine.
- Kad su brojevi blizu, odluku nose strateški razlozi, a zapisuje se s uslovom za preispitivanje.
Provjeri se.
- Šta kupac DeliveryApp zapravo plaća: kod ili vrijednost? – Vrijednost (tačnu i brzu narudžbu); kod je trošak.
- Kada je razumno kupiti gotovo rješenje? – Kad je funkcija ista kod svih i ne razlikuje nas od konkurencije.
- Šta sve ulazi u TCO? – Početni trošak, održavanje, infrastruktura, licence, podrška i drugi troškovi kroz cijeli život softvera.
Dio 2 – Mjerenje, procjena i odluka
10.5 Metrike složenosti
Da bi se procijenilo koliko će nešto koštati, treba znati koliko je veliko i koliko je složeno. Tri mjere se najčešće koriste.
Linije koda (LOC). Najjednostavnija mjera: koliko linija ima program. Stara funkcija obracun iz poglavlja 4 ima 46 linija, a refaktorisani obračun 23 linije. Ograničenja: različiti jezici trebaju različit broj linija za isti posao; bolji programer često napiše manje linija; i LOC se zna tek kad je kod napisan, a procjena treba prije.
Ciklomatska složenost (Thomas McCabe, 1976) broji nezavisne putanje kroz funkciju: svaki if, petlja ili logičko „ili” dodaje jednu. Za praksu je važno pravilo: što je broj veći, to je funkcija teža za razumijevanje i treba više testova. Iznad 10 se smatra rizičnim. Izmjereno alatom radon: stara funkcija obracun ima 16, a nove funkcije najviše 5. U slučaju Toyote (poglavlje 4) vještak je naveo desetine funkcija sa složenosti daleko iznad toga.
Funkcijske tačke (Allan Albrecht, IBM, 1979) mjere veličinu prema onome što softver radi za korisnika, nezavisno od jezika. Prebrojavaju se pet vrsta elemenata i množe težinom (ovdje prosječne težine po metodi IFPUG):
| Element | Šta je | U DeliveryApp 2.0 | Broj | Težina | Tačke |
|---|---|---|---|---|---|
| ulazi (EI) | korisnik unosi podatke | narudžba, otkazivanje, prijava, novi restoran, novo jelo, tarifa | 6 | 4 | 24 |
| izlazi (EO) | izvještaj ili izračunat rezultat | račun, izvještaj prometa, obračun dostave, potvrda | 4 | 5 | 20 |
| upiti (EQ) | jednostavno čitanje | jelovnik, stanje narudžbe, moje narudžbe, lista restorana, lista gradova | 5 | 4 | 20 |
| interni fajlovi (ILF) | grupe podataka koje sistem čuva | narudžbe, kupci, restorani i jela, tarife, dostavljači | 5 | 10 | 50 |
| vanjski interfejsi (EIF) | podaci drugih sistema | servis mapa, sistem plaćanja | 2 | 7 | 14 |
| ukupno | 128 |
Funkcijske tačke se mogu prebrojati iz zahtjeva, prije koda, i zato su korisne za procjenu.
Ukratko.
- LOC je jednostavan, ali zavisi od jezika i poznat je tek nakon koda.
- Ciklomatska složenost broji putanje kroz funkciju; iznad 10 je rizično (obracun: 16 → 5).
- Funkcijske tačke mjere ono što softver radi za korisnika i mogu se prebrojati iz zahtjeva; DeliveryApp 2.0 ima 128.
10.6 Procjena troškova
Barry Boehm je 1981. objavio model COCOMO (Constructive Cost Model), napravljen na podacima iz šezdesetak stvarnih projekata. Najjednostavnija verzija, osnovni COCOMO za „organski” projekat (mali tim, poznat problem), ima dvije formule:
\[ E = 2{,}4 \cdot \text{KLOC}^{1{,}05} \qquad T = 2{,}5 \cdot E^{0{,}38} \]
gdje je E napor u čovjek-mjesecima, T trajanje u mjesecima, a KLOC hiljade linija koda.
Za DeliveryApp 2.0: iz 128 funkcijskih tačaka, uz pretpostavku od oko 50 linija Pythona ili C# po tački, dobija se 128 × 50 = 6.400 linija, dakle 6,4 KLOC. Tada je
- napor E = 2,4 × 6,4^1,05 ≈ 16,9 čovjek-mjeseci,
- trajanje T = 2,5 × 16,9^0,38 ≈ 7,3 mjeseca,
- prosječan broj ljudi E / T ≈ 2,3.
Uporedimo s planom iz poglavlja 2: šest ljudi tri mjeseca, to je 18 čovjek-mjeseci. Napor se poklapa (16,9 i 18), ali COCOMO predlaže manji tim duže (2–3 osobe oko 7 mjeseci). Šest ljudi za tri mjeseca je moguće samo ako se posao zaista može podijeliti bez mnogo komunikacije, a Brooksov zakon (poglavlje 2) upozorava da to nije uvijek tako. Tim zato prati brzinu u prvim sprintovima i spreman je da plan izdanja produži.
COCOMO II (2000) je novija verzija s više faktora (iskustvo tima, alati, zahtjevi za pouzdanošću…). Ali nijedan model nije tačan sam po sebi; on daje polaznu tačku za razgovor.
Konus nesigurnosti. Što je projekat ranije, to je procjena nesigurnija. Boehm, a kasnije McConnell, opisali su konus nesigurnosti: na samom početku stvarni trošak može biti i četiri puta manji ili veći od procjene; kad su zahtjevi jasni, raspon se suzi na otprilike ±50 %; tek pred kraj procjena postaje tačna. Zato se procjena daje kao raspon („između 14 i 22 čovjek-mjeseca”), a ne kao jedan broj, i ponavlja se kako projekat odmiče.
U praksi se kombinuje više metoda: COCOMO ili funkcijske tačke odozgo, procjena tima (planning poker, poglavlje 2) odozdo, i analogija s prethodnim projektima („DeliveryApp 1.0 je trajao…”). Ako se metode slažu, procjena je vjerovatno razumna; ako se mnogo razlikuju, treba razgovarati zašto.
Ukratko.
- Osnovni COCOMO: E = 2,4 × KLOC^1,05, T = 2,5 × E^0,38.
- Za DeliveryApp 2.0 (6,4 KLOC): oko 16,9 čovjek-mjeseci i 7,3 mjeseca, prosječno 2,3 osobe.
- Konus nesigurnosti: rana procjena može biti pogrešna i četiri puta, pa se daje kao raspon.
- Najbolje je kombinovati model, procjenu tima i analogiju.
10.7 Neto sadašnja vrijednost
Udruženje ulaže 40.000 € u DeliveryApp 2.0 danas, a očekuje neto priliv (prihod od pretplata i provizija, umanjen za troškove rada) u naredne četiri godine: 12.000, 16.000, 18.000 i 18.000 €. Zbir priliva je 64.000 €, više od ulaganja. Da li to znači da se isplati?
Ne nužno, jer euro danas vrijedi više od eura za tri godine. Novac danas može se uložiti u banku i donositi kamatu; uz to, budući priliv je nesiguran. Zato se budući novac diskontuje: umanjuje se za diskontnu stopu (npr. 10 % godišnje). Priliv od 12.000 € za godinu dana danas vrijedi 12.000 / 1,1 ≈ 10.909 €.
Neto sadašnja vrijednost (NPV) je zbir svih diskontovanih priliva minus ulaganje:
\[ NPV = -I + \sum_{t=1}^{n} \frac{P_t}{(1+r)^t} \]
gdje je I ulaganje, Pt priliv u godini t, a r diskontna stopa.
| Godina | Priliv | Djelilac (1,1^t) | Današnja vrijednost |
|---|---|---|---|
| 0 | −40.000 € | 1 | −40.000 € |
| 1 | 12.000 € | 1,100 | 10.909 € |
| 2 | 16.000 € | 1,210 | 13.223 € |
| 3 | 18.000 € | 1,331 | 13.524 € |
| 4 | 18.000 € | 1,464 | 12.294 € |
| NPV | 9.950 € |
Pravilo odluke: NPV > 0 znači da se ulaganje isplati uz izabranu stopu, jer donosi više nego alternativa (npr. banka). NPV od 9.950 € znači da je DeliveryApp 2.0, uz stopu od 10 %, bolji od alternative za skoro deset hiljada eura u današnjem novcu.
Osjetljivost. Stopa izražava i rizik: što je ulaganje rizičnije, to je stopa veća. Uz stopu od 25 %, NPV istih priliva je −3.571 €, pa se ulaganje više ne isplati. Zato se NPV uvijek računa za nekoliko stopa i nekoliko scenarija priliva (optimistični, očekivani, pesimistični).
Ukratko.
- Euro danas vrijedi više od eura sutra, pa se budući prilivi diskontuju.
- NPV = zbir diskontovanih priliva minus ulaganje; NPV > 0 znači da se ulaganje isplati.
- Za DeliveryApp 2.0 uz 10 %: NPV = 9.950 €; uz 25 %: −3.571 €.
- NPV se računa za više stopa i scenarija.
10.8 Period povrata i odluka
Period povrata odgovara na pitanje koje svaki investitor prvo postavi: za koliko se vraća uloženo? Saberu se prilivi godinu po godinu dok zbir ne dostigne ulaganje:
| Godina | Priliv | Kumulativno |
|---|---|---|
| 1 | 12.000 € | 12.000 € |
| 2 | 16.000 € | 28.000 € |
| 3 | 18.000 € | 46.000 € ← prešli 40.000 € |
Nakon dvije godine vraćeno je 28.000 €; nedostaje još 12.000 €, a treća godina donosi 18.000 €. Dio treće godine je 12.000 / 18.000 ≈ 0,67, pa je period povrata 2,67 godina, oko dvije godine i osam mjeseci.
Period povrata je jednostavan i razumljiv, ali ima dvije mane: ne gleda vrijednost novca u vremenu (to radi NPV), i ne gleda šta se dešava poslije povrata. Projekat koji se vrati za dvije godine i onda ništa ne donosi izgleda bolje od projekta koji se vrati za tri, a onda donosi deset godina. Zato se koriste obje mjere zajedno.
Odluka o DeliveryApp 2.0. Lana iznosi udruženju:
- ulaganje 40.000 €, procjena napora 16,9–18 čovjek-mjeseci (COCOMO i plan tima se slažu);
- NPV uz 10 % je 9.950 €, a period povrata 2,67 godina;
- TCO razvoja (73.600 €) blizu je TCO kupovine (77.000 €), ali razvoj čuva proizvodnu liniju;
- najveći rizik je spor ulazak novih gradova: uz pesimistične prilive ili stopu od 25 % NPV postaje negativna;
- preporuka: krenuti, uz kontrolnu tačku nakon prve godine (ako je priliv manji od 9.000 €, preispitati kupovinu platforme).
Udruženje prihvata. Priča o NHS-u iz početka poglavlja nije nastala zato što niko nije računao, nego zato što su se računi pravili jednom, za sve odjednom, i nisu se preispitivali dok se projekat mijenjao. DeliveryApp radi suprotno: mali koraci, brojevi u svakom koraku, i jasan trenutak kad se odluka ponovo gleda.
Ukratko.
- Period povrata je vrijeme za koje kumulativni prilivi dostignu ulaganje; za DeliveryApp 2.0 to je 2,67 godina.
- Period povrata ne gleda vrijednost novca u vremenu ni prilive poslije povrata, pa se koristi uz NPV.
- Dobra odluka kombinuje procjenu napora, TCO, NPV, povrat, rizike i kontrolnu tačku za preispitivanje.
Provjeri se.
- Koliko danas vrijedi 11.000 € za godinu dana uz stopu 10 %? – 11.000 / 1,1 = 10.000 €.
- Šta znači NPV < 0? – Da se ulaganje uz izabranu stopu ne isplati; alternativa donosi više.
- Koja je glavna mana perioda povrata? – Ne gleda vrijednost novca u vremenu ni prilive poslije povrata.
Dopunska praksa – NPV i povrat u Pythonu ili Excelu
Cilj je izračunati NPV, period povrata i TCO za DeliveryApp 2.0 i ispitati osjetljivost odluke. Trajanje: jedan čas.
Korak 1 – Python
Pokrenite primjeri/python/ekonomika.py. Program ispisuje broj kanala komunikacije, brzinu tima, funkcijske tačke i COCOMO, NPV za 10 % i 25 %, period povrata i TCO. Provjerite da se brojevi slažu s ovim poglavljem.
python primjeri/python/ekonomika.pyKorak 2 – Excel ili LibreOffice Calc
Napravite tabelu s kolonama Godina, Priliv, Diskontovano, Kumulativno. U ćeliju za diskontovani priliv upišite formulu =B3/(1+$F$1)^A3, gdje je u F1 stopa (10 %). NPV izračunajte kao zbir diskontovanih priliva minus ulaganje, a provjerite i ugrađenom funkcijom =NPV(F1; B3:B6) + B2 (u Excelu na engleskom zarez umjesto tačke-zareza; B2 je −40.000).
Korak 3 – Osjetljivost
Napravite tri scenarija priliva:
- optimistični: 15.000, 20.000, 24.000, 24.000 €;
- očekivani: 12.000, 16.000, 18.000, 18.000 €;
- pesimistični: 8.000, 11.000, 13.000, 13.000 €.
Za svaki izračunajte NPV uz 10 % i 25 % i period povrata. Koji scenarij i koja stopa mijenjaju odluku?
Korak 4 – Preporuka
U docs/ekonomika.md napišite preporuku udruženju u pet tačaka, po uzoru na odjeljak 10.8, s vašim brojevima.
Rezultat: tabela s tri scenarija i dvije stope, i preporuka u pet tačaka.
Vježbe
Vježba za studenta 1 – TCO.
Opcija A: razvoj 30.000 €, održavanje 6.000 € godišnje. Opcija B: licenca 900 € mjesečno, bez početnog troška. Koja je jeftinija za 3 godine, a koja za 5?
Rješenje. 3 godine: A = 30.000 + 3 × 6.000 = 48.000 €; B = 36 × 900 = 32.400 €; B je jeftinija. 5 godina: A = 30.000 + 5 × 6.000 = 60.000 €; B = 60 × 900 = 54.000 €; B je i dalje jeftinija. Opcija A se isplati tek ako donosi koristi koje B nema.
Vježba za studenta 2 – funkcijske tačke i COCOMO.
Mala aplikacija ima 3 ulaza, 2 izlaza, 3 upita, 2 interna fajla i 1 vanjski interfejs. Uz prosječne težine i 50 linija po tački, koliko je funkcijskih tačaka i KLOC, i koliki su napor i trajanje po osnovnom COCOMO-u? (Stepene izračunajte kalkulatorom ili u Pythonu.)
Rješenje. FP = 3 × 4 + 2 × 5 + 3 × 4 + 2 × 10 + 1 × 7 = 12 + 10 + 12 + 20 + 7 = 61. KLOC = 61 × 50 / 1000 = 3,05. Napor E = 2,4 × 3,05^1,05 ≈ 7,7 čovjek-mjeseci; trajanje T = 2,5 × 7,7^0,38 ≈ 5,4 mjeseca; prosječno oko 1,4 osobe. (Provjera u Pythonu: 2.4 * 3.05 ** 1.05.)
Vježba za studenta 3 – NPV.
Ulaganje 20.000 €, prilivi 8.000 € u svakoj od tri godine, stopa 10 %. Izračunajte NPV i period povrata.
Rješenje. Diskontovano: 8.000 / 1,1 ≈ 7.273; 8.000 / 1,21 ≈ 6.612; 8.000 / 1,331 ≈ 6.011; zbir ≈ 19.895 €. NPV ≈ 19.895 − 20.000 = −105 €, dakle (tijesno) ne isplati se uz 10 %. Period povrata: nakon dvije godine 16.000 €, nedostaje 4.000 od 8.000, pa 2,5 godina. Primjer pokazuje da kratak povrat ne znači i pozitivnu NPV.
Vježba za studenta 4 – odluka.
Opština nudi DeliveryApp 10.000 € podsticaja ako u Gradu C uvede termo-torbe (poglavlje 9), čiji razvoj i uređaji koštaju 18.000 €. Očekuje se dodatni neto priliv od 4.000 € godišnje u naredne 3 godine. Izračunajte NPV uz 10 % i dajte preporuku.
Rješenje. Neto ulaganje = 18.000 − 10.000 = 8.000 €. Diskontovani prilivi: 3.636 + 3.306 + 3.005 ≈ 9.947 €. NPV ≈ 9.947 − 8.000 = 1.947 € > 0, pa se uz podsticaj isplati. Bez podsticaja (ulaganje 18.000 €) NPV bi bio ≈ −8.053 €. Preporuka: prihvatiti, uz provjeru da je priliv od 4.000 € realan (npr. pilot s 20 torbi).
Sažetak u pet rečenica
- Britanski program NPfIT ugašen je 2011. nakon troška procijenjenog na oko 10 milijardi funti i izmjerenih koristi od oko 3,7 milijardi, jer ekonomska pitanja nisu postavljana i preispitivana na vrijeme.
- Softver stvara vrijednost kroz lanac od razumijevanja potrebe do podrške, kupac plaća vrijednost a ne kod, a najveći trošak je obično održavanje, zbog čega je kvalitet koda ekonomsko pitanje.
- Razvija se ono što proizvod razlikuje, a kupuje ono što je isto kod svih, i odluka se donosi na osnovu ukupne cijene vlasništva, koja je za DeliveryApp 2.0 73.600 € za razvoj i 77.000 € za kupovinu u četiri godine.
- Veličina i složenost mjere se linijama koda, ciklomatskom složenošću i funkcijskim tačkama (128 za DeliveryApp 2.0), a osnovni COCOMO iz toga daje oko 16,9 čovjek-mjeseci i 7,3 mjeseca, uz konus nesigurnosti koji traži procjenu kao raspon.
- Neto sadašnja vrijednost diskontuje buduće prilive i za DeliveryApp 2.0 uz 10 % iznosi 9.950 €, period povrata je 2,67 godina, a dobra odluka kombinuje obje mjere, rizike i kontrolnu tačku za preispitivanje.