Download - Program ų kainos vertinimas
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 1
Programų kainos vertinimas
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 2
Įžanga Programų kainos vertinimas Įžanga ( Tikslai,
temos, fundamentalūs vertinimo klausimai, kaštų sudedamosios dalys, kaštai ir kaina, faktoriai įtakojantys kainą)
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 4
Temos Programų kūrimo našumas Vertinimo metodai Algoritminis kaštų modeliavimas Projekto planavimas
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.)
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 8
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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 10
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 11
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 12
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 13
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 14
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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;
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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į.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 19
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 20
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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 21
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 22
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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 23
Temos Programų kūrimo našumas Vertinimo metodai (smulkinantis, stambinantis
vertinimas, kaina laimėjimui) Algoritminis kaštų modeliavimas Projekto planavimas
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 25
Vertinimo metodai Algoritminis kaštų skaičiavimas. Ekspertų nuomonė. Vertinimas pagal analogą. Parkinsono dėsnis. Kaina laimėjimui.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 26
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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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ą.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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ą.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 35
Vertinimo neapibrėžtumas
x
2x
4x
0.5x
0.25x
Feasibility Requirements Design Code Delivery
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 37
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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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ą.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 40
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 41
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 42
Į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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 43
Temos Programų kūrimo našumas Vertinimo metodai Algoritminis kaštų modeliavimas Projekto planavimas (Varianto pasirinkimas,
projekto trukmė, personalas)
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 44
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 45
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 46
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
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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ą.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 51
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.
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 52
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)
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 53
Klausimas 14.1 Kaip apibūdinamas programavimo našumas?
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 54
Klausimas 14.2 Kokie naudojami programų kainos vertinimo
metodai?
©Ian Sommerville 2010 Software Engineering, 8th edition. Slide 55
Klausimas 14.3 Kokie naudojami algoritminiai kaštų modeliai?