Program ų kainos vertinimas

1. Programų kainos vertinimas

2. Įžanga • Programų kainos vertinimas Įžanga ( Tikslai, temos, fundamentalūs vertinimo klausimai, kaštų sudedamosios dalys, kaštai ir kaina, faktoriai įtakojantys kainą)

3. Tikslai • Pateikti programų kaštų ir kainos nustatymo pagrindus • Aprašyti tris metrikas programavimo našumo įvertinimui. • Paaiškinti, kodėl skirtingi metodai turi būti naudojami programų vertinimui. • Aprašyti principus COCOMO 2 algoritminiam kaštų įvertinimo modeliui

4. Temos • Programų kūrimo našumas • Vertinimo metodai • Algoritminis kaštų modeliavimas • Projekto planavimas

5. Fundamentalūs vertinimo klausimai • Kiek reikia pastangų atlikti veiklą? • Kiek kalendorinio laiko užims veiklos vykdymas? • Kokie veiklos bendri kaštai? • Projekto vertinimas ir laiko planavimas yra besikeičiančios valdymo veiklos.

6. Programų kaštų sudedamosios dalys • Aparatūros ir programų kaštai. • Komandiruočių ir mokymo kaštai. • Pastangų kaštai (dominuojantys faktoriai daugumoje projektų) • Projekto inžinierių atlyginimai; • Socialiniai ir draudimo kaštai. • Pastangų kaštai turi įvertinti pridėtines išlaidas • Pastato, šildymo, apšvietimo kaštai. • Ryšių ir kompiuterių tinklų kaštai. • Bendri kaštai (biblioteka, darbuotojų restoranas ir pan.)

7. Kaštai ir kaina • Kūrėjai turi įvertinti gaminamos programų sistemos kaštus. • Santykis tarp užsakymo kainos ir kūrimo kaštų nėra paprastas. • Kainą įtakoja platesnės organizacinės, ekonominės, politinės ir verslo aplinkybės.

8. Faktoriai įtakojantys kainą

9. Temos • Programų kūrimo našumas (Našumo matavimas, kodo eilutės, našumo palyginimas, funkciniai, objektiniai taškai, faktoriai įtakojantys našumą, kokybė ir našumas, technologijų kaita) • Vertinimo metodai • Algoritminis kaštų modeliavimas • Projekto planavimas

10. Programų kūrimo našumas • Matuojamas tempas , kuriuo individualūs programuotojai teikia programas ir reikalingą dokumentaciją. • Nesiremia kokybe nors kokybės užtikrinimas yra našumo užtikrinimo faktorius. • Iš esmės mes norime matuoti naudingą funkcionalumą pagamintą per laiko vienetą.

11. Našumo matavimas • Apimtim paremtas matavimas vertina programų kūrimo proceso rezultatus. Tai gali būti pateikto išeities kodo, objektinio kodo eilučių kiekis ir pan. • Funkcionalumu paremtas matavimas vertina pateiktų programų funkcionalumą. Šio tipo matavimo geriausiai žinomi funkciniai taškai.

12. Kodo eilutės • Kas tai kodo eilutė? • Šis matavimas buvo pasiūlytas, kai programos buvo spausdinamos kortelėse, viena eilutė kortelėje; • Kiek tai atitinka operatorius, kai vienas operatorius užima kelias eilutes arba eilutėje užrašomi keli operatoriai. • Kurias programas reikia laikyti sukurtomis? • Paprastai yra tiesinė priklausomybė tarp sistemos dydžio ir dokumentacijos apimties.

13. Našumo palyginimas • Kuo žemesnio lygio kalba tuo našiau dirba programuotojas? • Kuo labiau nekompaktiškai rašo programas programuotojas tuo jo aukštesnis našumas?

14. Sistemos kūrimo laikai

15. Funkciniai taškai • Remiasi programos charakteristikomis • Įėjimų ir išėjimų kiekis; • Vartotojo sąveikų kiekis; • Išorinių sąsajų kiekis; • Sistemoje naudojamų failų kiekis. • Funkciniai taškai skaičiuojami dauginant kiekvienos charakteristikos kiekį iš svorio ir viską sumuojant.

16. Funkciniai taškai • Funkcinių taškų skaičiavimas modifikuojamas priklausomai nuo projekto sudėtingumo. • Pagal funkcinius taškus gali būti paskaičiuotas programos eilučių kiekis. • Eilučių kiekis = Nuo naudojamos kalbos priklausantis koeficientas * funkcinių taškų kiekio; • Nuo naudojamos kalbos priklausantis koeficientasgali kisti nuo 200-300 asembleriui iki 2-40 ketvirtos kartos kalboms. • Funkcinių taškų skaičiavimas labai subjektyvus ir priklauso nuo vertintojo. Automatinis funkcinių taškų skaičiavimas neįmanomas.

17. Objektiniai taškai • Objektiniai taškai yra alternatyvus funkciniams taškams funkcionalumo matavimas. • Objektiniai taškai ne tas pats kas objektų klasės. • Objektinių taškų kiekis vertina: • Rodomų vaizdų ekrane kiekis; • Sistemos teikiamų ataskaitų kiekis; • Programos modulių kiekis;

18. Objektinių taškų vertinimas • Objektinius taškus lengviau negu funkcinius taškus įvertinti pagal specifikaciją, kadangi siejasi su programų moduliais, ataskaitomis, vaizdais ekrane. • Jie gali būti naudojami kūrimo proceso pradžioje objektyviam įvertinimui. • Šiam etape labai sudėtinga įvertinti sistemos kodo eilučių kiekį.

19. Našumo vertinimai • Realaus laiko įterptinėms sistemoms , 40-160 eilučių per mėnesį. • Programų sistemoms, 150-400 eilučių per mėnesį. • Komerciniams taikymams , 200-900 eilučių per mėnesį. • Objektiniais taškais našumas matuojamas tarp 4 ir 50 objektinių taškų per mėnesį, priklausomai nuo kūrėjo gebėjimų ir naudojamų įrankių.

20. Faktoriai įtakojantys našumą

21. Kokybė ir našumas • Visos metrikos besiremiančios apimtimi per laiko vienetą turi trūkumų, kadangi nevertina kokybės. • Našumas gali būti padidintas kokybės sąskaita. • Neaišku, kaip siejasi našumo/kokybės metrikos. • Jeigu reikalavimai pastoviai keičiasi tai eilučių kiekio skaičiavimas nėra prasmingas, kadangi programos nėra statinės.

22. Technologijų kaita • Technologijų kaitasąlygoja, kad ankstesnis patyrimas gali netikti naujoms sistemoms. • Paskirstytų sistemų naudojimas; • Interneto paslaugų naudojimas; • Naudojimas ofšorinių programų; • Pakartotinis panaudojimas kūrime; • Kūrimas naudojant script (scenarijų) kalbas; • CASE priemonių bei generatorių naudojimas.

23. Temos • Programų kūrimo našumas • Vertinimo metodai (smulkinantis, stambinantis vertinimas, kaina laimėjimui) • Algoritminis kaštų modeliavimas • Projekto planavimas

24. Vertinimo metodai • Nėra paprasto būdo tiksliai įvertinti programų sistemos reikalingas kūrimo pastangas. • Pradiniai vertinimai remiasi neadekvačia reikalavimų apibrėžimo informacija; • Programos gali naudoti naujas technologijas; • Projekte dirbantys žmonės nepakankamai pažįstami. • Projekto kainos vertinimas gali būti pats apsprendžiantis. • Vertinimas apsprendžia biudžetą ir produktas yra priderinamas prie to biudžeto.

25. Vertinimo metodai • Algoritminis kaštų skaičiavimas. • Ekspertų nuomonė. • Vertinimas pagal analogą. • Parkinsono dėsnis. • Kaina laimėjimui.

26. Vertinimo metodai

27. Smulkinantis ir stambinantis vertinimas • Visi šie metodai gali būti naudojami smulkinimo ar stambinimo principu. • Smulkinimo principas • Pirmiausia įvertinamas visos sistemos funkcionalumas ir kaip tas pasiskirsto per posistemes. • Stambinimo principas • Pirmiausia įvertinami kiekvieno komponento kaštai ir jie sudedami kol pasiekiamas galutinis vertinimas.

28. Smulkinantis vertinimas • Naudojamas be žinių apie sistemos architektūrą ir jos komponentus. • Vertina integravimą, konfiguracijos valdymą, ir dokumentavimą. • Gali nepakankamai įvertinti žemesnio techninio lygio sudėtingų problemų sprendimą.

29. Stambinantis vertinimas • Naudojamas kai žinoma sistemos architektūra ir identifikuoti komponentai. • Tai gali būti tikslus metodas, jei sistema detaliai suprojektuota. • Gali nepakankamai įvertinti sisteminio lygio veiklas kaip integravimą ir dokumentaciją.

30. Vertinimo metodai • Kiekvienas metodas turi savo silpnybes ir stiprybes. • Vertinimas turi remtis keliais metodais. • Jeigu jie neduoda panašių rezultatų, tai reiškia, kad vertinimui informacija yra nepakankama. • Tokiu atveju reikia papildomų veiksmų, kad gauti daugiau informacijos tikslesniam vertinimui. • Kaina laimėjimui taip pat kartais naudojamas metodas.

31. Kaina laimėjimui • Šis būdas gali atrodyti neetiškas. • Tačiau kai trūksta detalios informacijos, tik tai gali būti tinkama strategija. • Dėl projekto kainos sutariama pagal trumpą santrauką ir kūrimas apribojamas pagal tą kainą. • Dėl detalios specifikacijos gali būti deramasi arba naudojamas evoliucinis sistemos kūrimo būdas.

32. Temos • Programų kūrimo našumas • Vertinimo metodai • Algoritminis kaštų modeliavimas (Vertinimo tikslumas, neapibrėžtumas, COCOMO modelis, daugikliai, eksponentės reikšmė) • Projekto planavimas

33. Algoritminis kainos nustatymas • Kaina yra matematinė funkcija, kurios reikšmė priklauso produkto, projekto, ir proceso atributų, kurių reikšmės nustatomos projekto vadybininko: • Pastangos = A ´DydisB´M • A yra nuo organizacijos priklausanti konstanta, B atspindi pastangų neproporcingumą dideliems projektams ir M yra daugiklis atspindintis produkto, proceso ir žmonių atributus. • Kainos vertinimui bendras produkto atributas yra kodo dydis. • Dauguma modelių yra panašūs, bet jie naudoja skirtingas A, B ir M reikšmes.

34. Vertinimo tikslumas • Tikslus programų sistemos dydis žinomas tik ją užbaigus. • Keletas faktorių įtakoja galutinį dydį • Naudojimas užbaigtų sistemų bei komponentų; • Programavimo kalba; • Sistemos išskirstymo lygis. • Kuo toliau pažengęs kūrimo procesas tuo dydžio vertinimas tampa tikslesnis.

35. Vertinimo neapibrėžtumas

36. COCOMO modelis • Tai empirinis modelis paremtas apibendrinta informacija apie praktiškai įvykdytus projektus. • Modelis nepritaikytas specifinėms programoms. • Ilgai tobulintas nuo pradinės versijos (COCOMO-81) per tarpines iki COCOMO 2. • COCOMO 2 įvertina skirtingus programų kūrimo būdus, pakartotinį naudojimą ir pan.

37. COCOMO 81

38. COCOMO 2 • COCOMO 81 sudarytas remiantis prielaida, kad naudotas kaskadinis proceso modelis ir kad programos bus kuriamos nuo pat pradžios. • COCOMO 2 integruoja skirtingus programų kūrimo būdus, kurie atsirado programų inžinerijoje.

39. COCOMO 2 modeliai • COCOMO 2 įkomponuoja keletą dalinių modelių, kurie detaliau vertina programas. • Daliniai modeliai COCOMO 2 yra: • Taikymų sudėties modelis. Naudojamas, kai programos sudaromos iš jau egzistuojančių dalių. • Ankstyvo projekto modelis.Naudojamas, kai turimi reikalavimai, bet projektavimas dar neprasidėjo. • Pakartotinio naudojimo modelis. Naudojamas pastangų skaičiavimui integruojamų pakartotinio naudojimo komponentų. • Architektūrinis modelis.Naudojamas, kai suprojektuota architektūra ir yra daugiau informacijos apie sistemą.

40. Prototype systems Application Based on Used for Number of developed using composition model application points scripting, DB prog ramming etc. Initial effor t Based on Used for Number of function estimation based on Early design model points system requirements and design options Effor t to integ rate Number of lines of Based on Used for reusable components code reused or Reuse model or automatically generated generated code Development effor t Based on Used for Number of lines of P ost-architecture based on system source code model design specification COCOMO 2 modelių naudojimas

41. Objektinių taškų našumas

42. Įtakos kaštams efektai

43. Temos • Programų kūrimo našumas • Vertinimo metodai • Algoritminis kaštų modeliavimas • Projekto planavimas(Varianto pasirinkimas, projekto trukmė, personalas)

44. Projekto planavimas • Algoritminis kaštų modelis leidžia vykdyti planavimą ir palyginti alternatyvias strategijas. • Kaštų komponentai • Aparatūra; • Kūrimo platforma; • Kūrimo pastangos.

45. Valdymo pasirinkimai

46. Valdymo pasirinkimo kaštai

47. Varianto pasirinkimas • Variantas D naudojantis labiau patyrusius darbuotojus gali būti geriausia alternatyva. • Tačiau siejasi su didele rizika, kadangi gali būti sunku surasti patyrusius darbuotojus. • Variantas C ( atminties atnaujinimas) mažiau sutaupo kaštų bet turi labai mažą riziką. • Bendrai variantai išryškina programų kūrime personalo patyrimo svarbą.

48. Projekto trukmė • Projekto vadybininkai taip pat turi vertinti projekto trukmę ir personalo apkrovimą. • Kalendorinis laikas gali būti vertinamasCOCOMO 2 pagal formule • TDEV = 3 ´ (PM)(0.33+0.2*(B-1.01)) • PM – paskaičiuotos pastangos ir B – eksponentinis faktorius aptartas anksčiau. Tai prognozuoja nominalią projekto trukmę. • Reikalingas laikas nepriklauso nuo žmonių dirbančių prie projekto kiekio.

49. Personalas • Reikiamas personalo kiekis negali būti paskaičiuotas dalinant kūrimo laiko iš reikiamos trukmės. • Prie projekto dirbančių žmonių kiekis keičiasi priklausomai nuo projekto fazės. • Kuo daugiau žmonių dirba prie projekto tuo paprastai daugiau reikia bendrų pastangų. • Greitas žmonių didinimas paprastai siejamas su terminų vėlavimu.

50. Esminiai aspektai • Nėra paprasto ryšio tarp sistemos kainos ir jos kūrimo kaštų. • Faktoriai įtakojantys našumą apima individualius gabumus, srities patyrimą, projekto tipą, dydį, naudojamas priemones ir darbo aplinką. • Programos kaina numatoma kad laimėti kontraktą ir funkcionalumas priderinamas prie kainos.