Lekcija par darbietilpības prognozēšanu Programmētāja kvalifikācijas darba kontekstā.

1. Līva Šteinberga
2012. gada 29. oktobrī
Lekcija LU Datorikas fakultātes kursa
“Kvalifikācijas darbs I” ietvaros
Šis darbs izstrādāts ar Eiropas Sociālā fonda atbalstu projektā
«Atbalsts doktora studijām Latvijas Universitātē».

2. Kvalifikācijas darbam jāsatur paskaidrojošs
teksts, kurā atspoguļota konkrētā
programmatūras projekta organizācija,
kvalitātes nodrošināšana, konfigurāciju
pārvaldība un dots darbietilpības novērtējums
saskaņā ar izplatītām metodēm.

3. Kvalifikācijas darba ietvaros izstrādātā
programmatūras produkta apjomam jāatbilst
vismaz 3 personmēnešu darbietilpībai.

4. } Kas ir darbietilpība?
} Kāpēc tā jāprognozē?
} Kādas prognozēšanas metodes eksistē?
} Piemēri

6. } Darbietilpības novērtēšana ir process, kurā
prognozē programmatūras produkta izstrādei
nepieciešamo darba apjomu.
} Novērtējumi ir vajadzīgi visā izstrādes laikā
◦ Pirms projekta uzsākšanas, lai izvērtētu vai iecere ir
realizējama, piedalītos piedāvājumu konkursos un plānotu
budžetu
◦ Periodiski pārvērtējumi vajadzīgi, lai nepieciešamības
gadījumā projekta realizācijas laikā pārdalītu resursus

7. Piegādāt:
} Vajadzīgo
funkcionalitāti
} Norunātajā laikā
} Par norunāto cenu
} Prasītajā kvalitātē
Posmi:
• Nospraust mērķus
• Censties sasniegt
mērķus
Ko darīt, ja mērķi nav sasniedzami?

8. } Programmatūra nav taustāma
} Programmatūru izstrādā cilvēki
} Programmatūras izstrāde ir radošs process
nevis tikai mehāniska darbība
} Katrs projekts ir unikāls
} Tehnoloģijas strauji mainās
} Maz informācijas par līdzīgu projektu
pieredzi

9. } Parkinsona likums: “Lai cik maz darba būtu, tas
aizņems visu tam atvēlēto laiku.”
Work expands to fill the time available [Parkinson]
} Brūka likums: “Ja aizkavēta darba izpildē piesaista
vairāk (papildus) cilvēku, tad darbs aizkavēsies vēl
ilgāk.”
Putting more people on a late job makes it later. [Brook]
} “Price to win”: Pietiekami zema cena, lai uzvarētu
piedāvājumu konkursā
Price to win : figure sufficiently low to win contract

10. Darbietilpības novērtējumi bieži ir neprecīzi vai
nemaz netiek veikti.
Statistikas dati:
} Vidēji projektiem paredzētais budžets tika
pārtērēts par 90%, bet paredzētais laiks par
120% [Standish Group pētījums par 8380
projektiem 1994. gadā]

11. } International Software Benchmarking Standards
Group repozitorijos glabāto vairāk kā 400 projektu
datu analīzes rezultāti 2005. gadā:
◦ Darbietilpība precīzi aprēķināta ~25% no visiem
projektiem. Vidēji reālā darbietilpība bijusi 2 reizes lielāka
par sākotnēji prognozēto.
◦ Apmēram 60% projektu darbietilpība novērtēta vismaz
par 10% mazāka nekā reālā darbietilpība.
◦ Novērotas nopietnas kļūdas, piemēram, reālā
darbietilpība bijusi 20 reizes lielāka par prognozēto.

12. Paredzot nākotni ir daudz nezināmā
◦ Prasības – ir neprecīzas un mainīgas
◦ Projektējums – var tikt mainīts laika gaitā
◦ Izstrāde – atkarība no programmēšanas valodas un
izstrādes vides
◦ Testēšana – nepieciešamais apjoms dažādām sistēmām
var būtiski atšķirties (piem., dzīvībai kritiskas sistēmas,
elementāras spēles)
◦ Ieviešana – dažādi lietotāja akcepta kritēriji
◦ Personāls – pieredze un kompetence
◦ Tehnoloģijas – viena vai vairākas platformas u.c.

13. Lai uzlabotu novērtējumu precizitāti,
vajadzīga sistēmātiska pieeja darbietilpības
prognozēšanas procesam!

14. } Bottom-up (Dekompozīcija)
◦ Darbu sadala nelielās aktivitātēs (uzdevumos)
◦ Veic darbietilpības novērtējumu katrai aktivitātei
◦ Sasummē iegūtos novērtējumus
◦ Lieto, kad nav pieejami dati par agrāk izstrādātiem
projektiem
} Top-down
◦ Novērtē visu produkta izstrādei nepieciešamo darbu
◦ Zemāka līmeņa uzdevumu veikšanai nepieciešamo darbu
aprēķina kā daļu no kopējās darbietilpības

16. 1. Jāaprēķina produktivitāte jeb darba ražīgums
(darbiniekam vai komandai)

17. 2. Ja zināms programmatūras apjoms/ izmērs
un darbinieku produktivitāte, var izrēķināt cik
darba cilvēk-stundu / dienu / mēnešu vajadzēs,
lai darbu paveiktu jeb kāda ir projekta
darbietilpība.

18. Iedomāto produktivitāti aprēķina pēc
vienādojuma
izmantojot datus par līdzīgiem agrāk
izstrādātiem projektiem savā uzņēmumā vai
citos uzņēmumos (benchmark productivity data)

19. Biežāk lietotās mērvienības programmatūras
apjoma / izmēra noteikšanai:
} pirmkoda rindiņu skaits (LOC jeb SLOC)
source lines of code
} funkcijpunkti
function points

20. Raksturojums
} Tradicionāla metode programmatūras fiziskā
izmēra / apjoma prognozēšanai
} Apraksta programmatūras apjomu no
programmētāja skatu punkta
} Koda kvalitāte netiek ņemta vērā
} Tiek lietots daudzās darbietilpības novērtēšanas
metodēs

21. } Priekšrocības
◦ Vienkārši un automātiski mērāms lielums
◦ Tieša saistība ar gala produktu
◦ Tieša saistība ar programmēšanai patērēto laiku
} Trūkumi
◦ Vāji definēts mērs (Piemēram, vai jāskaita arī komentāru
rindas?)
◦ Atkarīgs no programmēšanas valodas
◦ Atkarīgs no izstrādātāja prasmēm
◦ Nav zināms plānošanas fāzē

22. Nav ieteicams lietot darbietilpības
noteikšanai
“Measuring programming progress by
lines of code is like measuring aircraft
building progress by weight” [Bill Gates]

23. Raksturojums
} Apraksta programmatūras nodrošinātās
funkcionalitātes apjomu
} Aprēķināms pēc programmatūras prasību
specifikācijā iekļautajām prasībām
} Apraksta programmatūras apjomu no lietotāja
skatu punkta
} Neatkarīgi no programmēšanas valodas

24. } Skaita plānotās sistēmas atribūtus, piem.,
lietojot IFPUG metodi jāskaita:
◦ Ievadi
◦ Izvadi
◦ Vaicājumi
◦ Izmantotie “iekšējie” jeb “loģikas” faili
◦ Ārējo saskarņu faili

25. Nepieciešamo darba apjomu var ietekmēt
dažādi izmaksu faktori:
} cilvēku skaits komandā
} programmēšanas valoda
} organizācijas tips
} uzņēmējdarbības sfēra
} lietotnes tips
} izstrādes platforma u.c.

28. } Algoritmiski modeļi
◦ Aprēķinos izmanto formulas
◦ Izmanto citu līdzīgu un pabeigtu projektu datus
◦ COSMIC, IFPUG, MARK II, NESMA, FISMA, COCOMO,
COCOMO II
} Ekspertu vērtējums
◦ DELPHI, PERT, Plānošanas pokers, Vienas personas
vērtējums
} Analoģiju bāzēti vērtējumi
◦ Vērtējumus veic balstoties uz ļoti līdzīgu projektu datiem

29. Algoritmiski modeļi Ekspertu vērtējumi Analoģiju bāzēti
vērtējumi
Pieeja Būvē statistisku modeli Atkarība no
ekspertu viedokļa
Mēra līdzības un
pielāgo
Vajadzība pēc
datiem
Ir Nav Ir
Priekšrocības Objektīvi, atkārtojami,
analizējamas formulas
Relatīvi lēti
Precīzi, ja
ekspertiem ir
pieredze ar
līdzīgiem
projektiem
Bāzēta uz reālu
projektu pieredzi
Trūkumi Nepiemērota
speciālgadījumiem
Kalibrēta uz pagātnes
datiem nevis nākotnes
datiem
Rezultāti stipri
akgarīgi no
vērtētājiem
Nepieciešama
detalizēta
informācija par
daudziem
projektiem

31. } Atbilst starptautiski atzītam standartam
ISO/IEC 19761: 2003
} 1999. gadā to publicēja Common Software
Measurement International Consortium
(COSMIC), pēdējā versija 3.0.1 publicēta 2009.
gadā

32. Derīga, lai prognozētu funkcionālos izmērus:
} Darījumlietotnēm (bussiness applications)
(piem., banku sistēmas, internetveikali)
} Reāla-laika programmatūrai (real-time
software) (piem., automašīnas motora
vadības sistēma, telekomunikāciju sistēmas)
} Hibrīdām lietotnēm (piemēram, reāla-laika
lidmašīnas biļešu rezervācijas sistēmai)

33. Nederīga:
} Programmatūrai, kas ietver sarežģītas
loģiskās izteiksmes,sarežģītu matemātiskus
aprēķinu veikšanu, attēlu un skaņas apstrādi
utml. (piem., ekspertu sistēmas, simulāciju
programmatūru, laika prognožu sistēmas,
datorspēles)

34. [Cigdem Gencel, 2010]

35. } 1 CFP (COSMIC funkcijpunkts) ir definēts kā
viena datu plūsma
} Katra datu plūsmas instance (Ievads, Izvads,
Lasīšana, Rakstīšana), kad dati tiek pievienoti,
mainīti vai izdzēsti ir 1 CFP izmērā

36. } Lietotājs - jebkas, kas darbojas ar ar mērāmo
programmatūru
} Funkcionālais lietotājs - lietotāja tips, kas
funkcionālajās lietotāja prasībās, var sūtīt un var
saņemt datus no programmatūras
◦ Darījumlietotnēs – cilvēki un citas lietotnes, ar kurām tās
sadarbojas
◦ Reāla laika lietotnēs – ierīces vai cita programmatūra

37. } Funkcionālās lietotāju prasības sastāv no
funkcionāliem procesiem
} Funkcionālais process tiek izsaukts, kad
programmatūras lietotājs atpazīst notikumu
(trigeri) un sūta ziņu, lai sāktu procesu
} Process ir pabeigts, kad programmatūra ir
paveikusi visu kas prasīts

38. Trigeri un tiem atbilstošie funkcionālie procesi
} Darījumlietotnēs:
◦ Ir saņemts pasūtījums – Ievadīt pasūtījumu sistēmā
◦ Darbinieks ir apprēcējies – Atjaunināt viņa personas
datus
◦ Ir mēneša beigas – Aprēķināt algas
} Reāla laika lietotnēs
◦ Pilota komanda – Pievilkt lidmašīnas ratus un
pacelties gaisā
◦ Ziņa par sastādītu telefona numuru – Izveidot
savienojumu

39. } 4 tipu datu plūsmu tipi:
◦ Ievads (Entry) – kontroles vai biznesa informācija, kas nāk no
lietotāja un šķērso lietotnes robežu (lietotāja ievaddati,
sensoru informācija)
◦ Izvads (Exit) – apstrādāti dati, kas tiek virzīti ārā no lietotnes
(grafiki, atskaites) lietotājam, kas tos pieprasījis
◦ Lasīšana (Read) – pārvieto datus no atmiņas procesam, kas
tos pieprasījis
◦ Rakstīšana (Write) – pārvieto datus no procesa uz atmiņu

40. [Cigdem Gencel, 2010]

41. Izmērs CFP (funkcionālais processi) =
Σ izmērs(Ievadsi) + Σ izmērs(Izvadsi) + Σ size
(Lasīšanai) + Σ size(Rakstīšanai)

42. } Pasūtījumu apstrādes lietotne glabā datus par
klientiem – klienta ID, vārds, uzvārds, adrese,
telefona numurs, kredīta limits, klienta tipa kods
} Ar klientu informāciju darbojas pasūtījumu
apstrādes operatori
} Process “Jauna klienta izveide sistēmā” ietver
◦ 1 Ievads (saistīts ar klienta objektu)
◦ 1 Rakstīšana (saistīts ar klienta objektu)
◦ 1 Izvads (apstiprinājums vai kļūdas paziņojums)
} Procesa izmērs: 3 CFP (COSMIC Function Point)

43. Functional
Process
User Exch.
rate
Financia
l trans.
User
prof.
Sys.
config.
Entry Exit Read Write CFP
Login
validation
R 1 1 1 0 3
User
profile
loading
R 1 1 1 0 3
Exchange
rates
loading
R/W 1 1 1 1 4
Buying or
Selling
currencies
R/W R R 1 1 3 1 6
Detailed
exchange
rate
information
loading
R 1 1 1 0 3
……….. ……
TOTAL 37

44. } The International Software Benchmarking
Standards Group uztur divus repozitorijus ar
vēsturiskiem projektu datiem
} Pašlaik pieejama informācija par ~5600
projektiem
} Projektu dati pieejami par maksu

45. CFP Planning (h) Analysis (h) Building (h) Testing (h) Deploying (h)
44 9 7 88 50 52
CFP Planning (h) Analysis (h) Building (h) Testing (h) Deploying(h)
37 7 6 74 42 44
Benchmarking jeb industrijas dati par projektu ar
līdzīgu CFP skaitu:
Aprēķina darbietilpību savam projektam:
Tālāk, ņemot vērā projekta unikālitāti un “izmaksu
faktorus”, precizē darbietilpību. Piemēram, par 20%
palielina izstrādes (building) darbu, jo darbinieki ir
iesācēji darbā ar konkrēto programmēšanas valodu.

46. } The COSMIC Functional Size Measurement
Method Version 3.0.1 Measurement Manual
(The COSMIC Implementation Guide for ISO/
IEC 19761: 2003), May 2009
VAI
} The COSMIC Functional Size Measurement
Method Version 3.0 Method Overview,
September 2007

48. } Spēja (agile) pieeja darbietilpības plānošanai
} Darbietilpības novērtējuma mērvienība –
sarežģītības punkts
} Izmanto kārtis uz kurām rakstīts punktu
skaits
} Biežāk lietotās skalas:
◦ Fibonači skaitļi - 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
◦ 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

49. } Komandas biedri sapulcējas un balso par
katras funkcionālās prasības izteiktas
lietotāju stāsta (user story) formā relatīvo
sarežģītības pakāpi, izmantojot kārtis
} Katrs balso individuāli (izvēlas kārti), bet
visi balso vienlaicīgi (atklāj kārti). Ja
vērtējumi atšķiras, tad diskutē un vienojas
vai pārbalso

50. Ātrums
(velocity)
=
vienā
iterācijā
realizēto
punktu
skaits
Darbietilpība
lietotāju
stāstam
=
vidējā
sarežgītības
punkta
darbietilpība
*
punktu
skaits

51. Paldies par uzmanību!

53. [Cigdem Gencel, 2010]