Program ų kainos vertinimas

©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 1

Programų kainos vertinimas


Įžanga Programų kainos vertinimas Įžanga ( Tikslai,

temos, fundamentalūs vertinimo klausimai, kaštų sudedamosios dalys, kaštai ir kaina, faktoriai įtakojantys kainą)


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


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


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.


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


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.


Faktoriai įtakojantys kainąRinkos galimybės A development organisation may quote a low price because it

wishes to move into a new segment of the software market. Accepting a low profit on one project may give the opportunity of more profit later. The experience gained may allow new products to be developed.

Kainos nustatymo neapibrėžtumas

If an organisation is unsure of its cost estimate, it may increase its price by some contingency over and above its normal profit.

Kontrakto sąlygos A customer may be willing to allow the developer to retain ownership of the source code and reuse it in other projects. The price charged may then be less than if the software source code is handed over to the customer.

Reikalavimų kintamumas

If the requirements are likely to change, an organisation may lower its price to win a contract. After the contract is awarded, high prices can be charged for changes to the requirements.

Finansinė padėtis Developers in financial difficulty may lower their price to gain a contract. It is better to make a smaller than normal profit or break even than to go out of business.


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


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

Programų kūrimo našumas


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.

Našumo matavimas


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.

Kodo eilutės


Kuo žemesnio lygio kalba tuo našiau dirba programuotojas?

Kuo labiau nekompaktiškai rašo programas programuotojas tuo jo aukštesnis našumas?

Našumo palyginimas


Sistemos kūrimo laikai

Analysis Design Coding Testing Documentation

Assembly codeHigh-level language

3 weeks3 weeks

5 weeks5 weeks

8 weeks4 weeks

10weeks

6 weeks

2 weeks2 weeks

Size Effort Productivity

Assembly codeHigh-level language

5000 lines1500 lines

28 weeks20 weeks

714 lines/month300 lines/month


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.


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 koeficientas gali 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.


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;


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


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

Našumo vertinimai


Faktoriai įtakojantys našumą

Patyrimas taikymo srityje

Knowledge of the application domain is essential for effective software development. Engineers who already understand a domain are likely to be the most productive.

Proceso kokybė The development process used can have a significant effect on productivity. This is covered in Chapter 28.

Projekto dydis The larger a project, the more time required for team communications. Less time is available for development so individual productivity is reduced.

Naudojama technologija

Good support technology such as CASE tools, configuration management systems, etc. can improve productivity.

Darbo aplinka As I discussed in Chapter 25, a quiet working environment with private work areas contributes to improved productivity.


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.

Kokybė ir našumas


Technologijų kaita Technologijų kaita są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.


Temos Programų kūrimo našumas Vertinimo metodai (smulkinantis, stambinantis

vertinimas, kaina laimėjimui) Algoritminis kaštų modeliavimas Projekto planavimas


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.


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


Vertinimo metodaiAlgoritminis kaštų skaičiavimas

A model based on historical cost information that relates some software metric (usually its size) to the project cost is used. An estimate is made of that metric and the model predicts the effort required.

Ekspertų nuomonė

Several experts on the proposed software development techniques and the application domain are consulted. They each estimate the project cost. These estimates are compared and discussed. The estimation process iterates until an agreed estimate is reached.

Vertinimas pagal analogą

This technique is applicable when other projects in the same application domain have been completed. The cost of a new project is estimated by analogy with these completed projects. Myers (Myers 1989) gives a very clear description of this approach.

Parkinsono dėsnis

Parkinson’s Law states that work expands to fill the time available. The cost is determined by available resources rather than by objective assessment. If the software has to be delivered in 12 months and 5 people are available, the effort required is estimated to be 60 person-months.

Kaina laimėjimui

The software cost is estimated to be whatever the customer has available to spend on the project. The estimated effort depends on the customer’s budget and not on the software functionality.


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.


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


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


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.


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.


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


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.


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.


Vertinimo neapibrėžtumas

x

2x

4x

0.5x

0.25x

Feasibility Requirements Design Code Delivery


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.


COCOMO 81

Projekto sudėtingumas

Formula Description

paprastas PM = 2.4 (KDSI)1.05 M Well-understood applications developed by small teams.

Vidutinise PM = 3.0 (KDSI)1.12 M More complex projects where team members may have limited experience of related systems.

Įterptinis PM = 3.6 (KDSI)1.20 M Complex projects where the software is part of a strongly coupled complex of hardware, software, regulations and operational procedures.


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.


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


COCOMO 2 modelių naudojimas

Number ofapplication points

Number of functionpoints

Based on Used for

Used for

Used for

Used for

Based on

Based on

Based on

Number of lines ofcode reused or

generated

Number of lines ofsource code

Applicationcomposition model

Early design model

Reuse model

Post-architecturemodel

Prototype systemsdeveloped using

scripting, DBprogramming etc.

Initial effortestimation based on

system requirementsand design options

Effort to integratereusable components

or automaticallygenerated code

Development effortbased on system

design specification


Objektinių taškų našumas

Kūrėjo patyrimas ir galimybės

Very low Low Nominal High Very high

CASE branda ir galimybės

Very low Low Nominal High Very high

PROD (NOP/month) 4 7 13 25 50


Įtakos kaštams efektai

Exponent value 1.17System size (including factors for reuseand requirements volatility)

128, 000 DSI

Initial COCOMO estimate withoutcost drivers

730 person-months

Reliability Very high, multiplier = 1.39Complexity Very high, multiplier = 1.3Memory constraint High, multiplier = 1.21Tool use Low, multiplier = 1.12Schedule Accelerated, multiplier = 1.29Adjusted COCOMO estimate 2306 person-months

Reliability Very low, multiplier = 0.75Complexity Very low, multiplier = 0.75Memory constraint None, multiplier = 1Tool use Very high, multiplier = 0.72Schedule Normal, multiplier = 1Adjusted COCOMO estimate 295 person-months


Temos Programų kūrimo našumas Vertinimo metodai Algoritminis kaštų modeliavimas Projekto planavimas (Varianto pasirinkimas,

projekto trukmė, personalas)


Algoritminis kaštų modelis leidžia vykdyti planavimą ir palyginti alternatyvias strategijas.

Kaštų komponentai• Aparatūra;• Kūrimo platforma;• Kūrimo pastangos.

Projekto planavimas


Valdymo pasirinkimaiA. Use existing hardware,development system and

development team

D. Moreexperienced staff

F. Staff withhardware experience

E. New developmentsystem

Hardware cost increaseExperience decrease

B. Processor andmemory upgrade

Hardware cost increaseExperience decrease

C. Memoryupgrade only

Hardware costincrease


Valdymo pasirinkimo kaštai

Option RELY STOR TIME TOOLS LTEX Total effort Software cost Hardwarecost

Total cost

A 1.39 1.06 1.11 0.86 1 63 949393 100000 1049393

B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025

C 1.39 1 1.11 0.86 1 60 895653 105000 1000653

D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490

E 1.39 1 1 0.72 1.22 56 844425 220000 1044159

F 1.39 1 1 1.12 0.84 57 851180 120000 1002706


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


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.


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.


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.


Esminiai aspektai Vertinant kaštus turi būti naudojami įvairūs metodai. COCOMO modelis prognozuodamas reikiamas pastangas

įvertina projekto, produkto, personalo ir aparatūros atributus. Algoritminis kaštų modelis leidžia analizuoti ir palyginti

skirtingus kaštų variantus. Projekto trukmė nėra proporcinga žmonių dirbančių prie

projekto kiekiui.


Esminiai aspektai Ryšys kaina- kaštai, faktoriai įtakojantys našumą,

kaina kontraktui laimėti, kaštų vertinimas, COCOMO modelis, algoritminis kaštų modelis, projekto trukmė ir dirbančių žmonių kiekis)


Klausimas 14.1 Kaip apibūdinamas programavimo našumas?


Klausimas 14.2 Kokie naudojami programų kainos vertinimo

metodai?


Klausimas 14.3 Kokie naudojami algoritminiai kaštų modeliai?

Documents

Program ų kainos vertinimas