darbietilpiibas prognozeeshana liva steinberga - 29 10 2012

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]