Ekonomika programskog proizvoda

Šta učimo ovog semestra (1–5)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas je poglavlje 10. Isti primjer kroz knjigu: DeliveryApp 2.0.

Šta učimo ovog semestra (6–10)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas: poglavlje 10 (označeno). Isti primjer kroz knjigu: DeliveryApp 2.0.

Priča za početak

Priča za početak

Literatura

1. I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 23, planiranje i procjena).
2. B. W. Boehm: Software Engineering Economics, Prentice Hall, 1981.
3. S. McConnell: Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.

Zašto ovo poglavlje

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.

Riječi ovog poglavlja (1/3)

• 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.

Riječi ovog poglavlja (2/3)

• 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.

Riječi ovog poglavlja (3/3)

• 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

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:

1. Razumijevanje potrebe – istraživanje tržišta, razgovor s korisnicima (poglavlja 1 i 3).
2. Razvoj – dizajn, kod, testovi (poglavlja 3–5).
3. Isporuka i rad – oblak, nadzor, dostupnost (poglavlja 5–6).
4. Prodaja i uvođenje – ugovori s gradovima i restoranima, obuka.
5. 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.

10.1 Lanac vrijednosti softvera

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 – 10.1 Lanac vrijednosti softvera

• 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:

10.2 Troškovi i koristi

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.

10.2 Troškovi i koristi

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.

Ukratko – 10.2 Troškovi i koristi

• 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:

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).

10.3 Razvoj, kupnja ili saradnja

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 – 10.3 Razvoj, kupnja ili saradnja

• 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):

10.4 Ukupna cijena vlasništva

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.

Ukratko – 10.4 Ukupna cijena vlasništva

• 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

1. Šta kupac DeliveryApp zapravo plaća: kod ili vrijednost? Vrijednost (tačnu i brzu narudžbu); kod je trošak.
2. Kada je razumno kupiti gotovo rješenje? Kad je funkcija ista kod svih i ne razlikuje nas od konkurencije.
3. Šta sve ulazi u TCO? Početni trošak, održavanje, infrastruktura, licence, podrška i drugi troškovi kroz cijeli život softvera.

Odgovori: tipka R ili klik na zamućeno polje.

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):

10.5 Metrike složenosti

Funkcijske tačke se mogu prebrojati iz zahtjeva, prije koda, i zato su korisne za procjenu.

Ukratko – 10.5 Metrike složenosti

• 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:

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.

10.6 Procjena troškova

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.

10.6 Procjena troškova

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 – 10.6 Procjena troškova

• 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:

gdje je I ulaganje, P~t~ priliv u godini t, a r diskontna stopa.

10.7 Neto sadašnja vrijednost

10.7 Neto sadašnja vrijednost

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 – 10.7 Neto sadašnja vrijednost

• 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:

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.

10.8 Period povrata i odluka

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:

1. ulaganje 40.000 €, procjena napora 16,9–18 čovjek-mjeseci (COCOMO i plan tima se slažu);
2. NPV uz 10 % je 9.950 €, a period povrata 2,67 godina;
3. TCO razvoja (73.600 €) blizu je TCO kupovine (77.000 €), ali razvoj čuva proizvodnu liniju;
4. najveći rizik je spor ulazak novih gradova: uz pesimistične prilive ili stopu od 25 % NPV postaje negativna;
5. preporuka: krenuti, uz kontrolnu tačku nakon prve godine (ako je priliv manji od 9.000 €, preispitati kupovinu platforme).

10.8 Period povrata i odluka

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 – 10.8 Period povrata i odluka

• 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

1. Koliko danas vrijedi 11.000 € za godinu dana uz stopu 10 %? 11.000 / 1,1 = 10.000 €.
2. Šta znači NPV < 0? Da se ulaganje uz izabranu stopu ne isplati; alternativa donosi više.
3. Koja je glavna mana perioda povrata? Ne gleda vrijednost novca u vremenu ni prilive poslije povrata.

Odgovori: tipka R ili klik na zamućeno polje.

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.py

Korak 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žba za studenta 1 – TCO.

Vježba za studenta 1 – TCO. – rješenje

Vježba za studenta 2 – funkcijske tačke i COCOMO.

Vježba za studenta 2 – funkcijske tačke i COCOMO. – rješenje

Vježba za studenta 3 – NPV.

Vježba za studenta 3 – NPV. – rješenje

Vježba za studenta 4 – odluka.

Vježba za studenta 4 – odluka. – rješenje

Sažetak u pet rečenica

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Pitanja za ponavljanje

1. Šta je bio NPfIT, koliko je koštao i koja je ekonomska pouka?
2. Opišite lanac vrijednosti softverskog proizvoda. Šta kupac zaista plaća?
3. Nabrojte vrste troškova i koristi softverskog proizvoda. Koji je trošak obično najveći?
4. Kada je bolje razviti sami, kada kupiti, a kada razvijati u saradnji?
5. Šta je TCO? Izračunajte TCO razvoja i kupovine za DeliveryApp 2.0.
6. Šta su LOC i ciklomatska složenost, i koja su im ograničenja?
7. Šta su funkcijske tačke? Navedite pet vrsta elemenata i izračunajte FP za DeliveryApp 2.0.
8. Napišite formule osnovnog COCOMO-a i primijenite ih na DeliveryApp 2.0. Kako se rezultat poredi s planom tima?
9. Šta je konus nesigurnosti i šta iz njega slijedi za procjene?
10. Zašto se budući novac diskontuje? Napišite formulu za NPV i izračunajte je za DeliveryApp 2.0.
11. Šta pokazuje NPV uz 25 %? Zašto se računa više scenarija?
12. Šta je period povrata, koliko iznosi za DeliveryApp 2.0 i koje su mu mane?