darbietilpiibas prognozeeshana liva steinberga - 29 10 2012
DESCRIPTION
Lekcija par darbietilpības prognozēšanu Programmētāja kvalifikācijas darba kontekstā.TRANSCRIPT
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ē».
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.
Kvalifikācijas darba ietvaros izstrādātā
programmatūras produkta apjomam jāatbilst vismaz 3 personmēnešu darbietilpībai.
} Kas ir darbietilpība?
} Kāpēc tā jāprognozē?
} Kādas prognozēšanas metodes eksistē?
} Piemēri
} 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
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?
} 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
} 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
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ā]
} 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.
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.
Lai uzlabotu novērtējumu precizitāti, vajadzīga sistēmātiska pieeja darbietilpības prognozēšanas procesam!
} 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
1. Jāaprēķina produktivitāte jeb darba ražīgums (darbiniekam vai komandai)
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.
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)
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
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
} 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ē
Nav ieteicams lietot darbietilpības noteikšanai “Measuring programming progress by lines of code is like measuring aircraft building progress by weight” [Bill Gates]
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
} 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
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.
} 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
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
} 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ā
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)
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)
[Cigdem Gencel, 2010]
} 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ā
} 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
} 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
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
} 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
[Cigdem Gencel, 2010]
Izmērs CFP (funkcionālais processi) = Σ izmērs(Ievadsi) + Σ izmērs(Izvadsi) + Σ size(Lasīšanai) + Σ size(Rakstīšanai)
} 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)
Functional Process
User Exch. rate
Financial 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
} 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
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.
} 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
} 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
} 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
Ā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
Paldies par uzmanību!
[Cigdem Gencel, 2010]