KAUNO TECHNOLOGIJOS UNIVERSITETAS INFORMATIKOS FAKULTETAS Programų kaštų vertinimas dokt. V. Uzdanavičiūtė Dėstytojas: prof. habil. dr. R. Šeinauskas Kaunas, 2010

TIKSLAS Paaiškinti PĮ kaštų sampratą ir ją įtakojančius faktorius; Aprašyti tris metrikas programavimo našumo įvertinimui; Pristatyti programų kūrimo našumo rodiklius; Pateikti programų kaštų ir kainos nustatymo pagrindus; Pristatyti PĮ kaštų vertinimo metodus ir strategijas; Paaiškinti, kodėl skirtingi metodai turi būti naudojami programų vertinimui; Įvertinti PĮ kokybės kainą; Įvertinti PĮ palaikymo kainą;

Santykis tarp užsakymo kainos ir kūrimo kaštų nėra paprastas. PĮ KAŠTŲ SAMPRATA Programinės įrangos (PĮ) kaina – aktualu galutiniam vartotojui; PĮ kaštai – aktualu kuriančiai organizacijai; Kaštų įvertinimo rezultatai svarbūs visiems PĮ proceso dalyviams; Santykis tarp užsakymo kainos ir kūrimo kaštų nėra paprastas.

KAŠTAI IR KAINA Kūrėjai turi įvertinti gaminamos programų sistemos kaštus; Kainą įtakoja platesnės organizacinės, ekonominės, politinės ir verslo aplinkybės.

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.

FAKTORIAI ĮTAKOJANTYS PĮ PROJEKTO KAINĄ PĮ projekto kaina – tai projekto išlaidos plius pelnas, tačiau, apskaičiuojant projekto kainą, reikia įvertinti gerokai daugiau veiksnių. Kai kurie veiksniai: Veiksnys Aprašymas Rinkos išplėtimas Projektuojanti organizacija gali pasiūlyti žemą kainą tam, kad užimtų naują nišą PS rinkoje, ar tam, kad įgijusi patirties, vėliau sėkmingai gamintų panašaus profilio produktus. Neaiškumai įvertinant kainą Dėl netikrumo nustatant kainą padidinamas pelno procentas. Sutarties sąlygos Kai kuriamoje PS naudojami komponentai yra tinkami pakartotiniam naudojimui, kaina gali būti sumažinama. Reikalavimų nepastovumas Projektuojanti organizacija gali pasiūlyti žemesnę kainą, kad sudaryti sutartį. Ją sudarius kainą galima padidinti. Finansiniai sunkumai Galima sumažinti kainą, norint sudaryti sutartį (geriau jau mažesnis pelnas negu sutarčių nebuvimas ar dar blogiau – bankrotas).

PĮ SĖKMINGUMO APŽVALGA 1994-2004 istoriniai PĮ sėkmingo pabaigimo rezultatai

PROJEKTŲ ĮVERTINIMO SĖKMINGUMAS Projektų baigties sąryšis su projekto dydžiu Dydis (funkciniais taškais) (apytikslis kodo kiekis LOC) Anksti Laiku Vėlai Žlugo 10 FP (1,000 LOC) 11% 81% 6% 2% 100 FP (10,000 LOC) 75% 12% 7% 1,000 FP (100,000 LOC) 1% 61% 18% 20% 10,000 FP (1,000,000 LOC) <1% 28% 24% 48% 100,000 FP (10,000,000 LOC) 0% 14% 21% 65%

KAŠTŲ ĮVERTINIMO PROBLEMOS Pervertintas resursų poreikis: “Studento” sindromas; Parkinsono dėsnis. Nepakankamai įvertintas resursų poreikis: Plano efektyvumo sumažėjimas; Laiko pritrūksta analizei ir projektavimui; “Vėluojančio” projekto fenomenas.

METODŲ PAGRINDINIAI PARAMETRAI Sistemos dydis. Problemos vertinant dydį (PĮ metrikos); Resursų produktyvumas. Problemos įvertinant reikalingas pastangas darbui atlikti.

PARAMETRŲ 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.

PĮ METRIKOS PROBLEMA (1) Savybių skaičius Reikalavimų kiekis Panaudojimo atvejai Funkciniai taškai Objektiniai taškai Web puslapių skaičius GUI komponentų skaičius DB lentelių kiekis Sąsajų skaičius Klasių kiekis Funkcijų kiekis Kodo eilučių kiekis (LOC)

PĮ METRIKOS PROBLEMA (2) Produktas LOC Darbo metai Išleidimo metai Apytikslė kaina 2006 doleriais (atsižvelgiant į infliaciją) $/LOC LOC/Darbo metus IBM Chief Programmer Team Project 83,000 9 1968 1,400,000 $17 9200 Lincoln Continental 35 1989 2,900,000 $35 2400 IBM Checkout Scanner 90,000 58 4,900,000 $55 1600 Microsoft Word for Windows 1.0 249,000 55 8,500,000 $34 4500 NASA SEL Project 24 2002 3,700,000 $15 10000 Lotus 123 v. 3 400,000 263 36,000,000 $90 1500 Microsoft Excel 3.0 649,000 50 1990 7,700,000 $12 13000 Citibank Teller Machine 780,000 150 22,000,000 $28 5200 Windows NT 3.1 (first version) 2,880,000 2,000* 1994 200,000,000 $70 1400 Space Shuttle 25,600,000 22,096 2000,000,000 $77 1200

KAINOS NUSTATYMO PROCESO VERTINIMO NEAPIBRĖŽTUMAS PS sukūrimo kainos nustatymas yra nenutrūkstamas procesas. PS kainos kitimas (pagal Barry W. Boehm):

KŪRIMO PASTANGŲ VERTINIMAS 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.

PROGRAMOS 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. Norima matuoti naudingą funkcionalumą pagamintą per laiko vienetą.

PROGRAMOS KŪRIMO NAŠUMO ĮVERTINIMAS 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. * Kodo eilutės matavimas buvo pasiūlytas, kai programos buvo spausdinamos kortelėse, viena eilutė kortelėje;

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 Tai alternatyvus funkciniams taškams funkcionalumo matavimas. Objektiniai taškai ne tas pats kas objektų klasės. Objektinių taškų kiekis vertina: Rodomų vaizdų ekrane kiekį; Sistemos teikiamų ataskaitų kiekį; Programos modulių kiekį; 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.

NAŠUMO ĮVERTINIMAI KODO EILUTĖMIS 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ų.

FAKTORIAI ĮTAKOJANTYS NAŠUMĄ Patyrimas taikymo srityje Proceso kokybė Projekto dydis Naudojama technologija Darbo aplinka

PROGRAMOS KAINOS ĮVERTINIMO METODAI Programos kainai įvertinti paprastai taikomi septyni skirtingi metodai: Algoritminis modelis; Ekspertų įvertinimas; Įvertinimas lyginant (pagal analogą); Parkinsono principas; Laimėjimo kainos principas; „Iš viršaus žemyn“ metodas; „Iš apačios aukštyn“ metodas.

PROGRAMOS KAINOS ĮVERTINIMO METODAI-2 Algoritminis modelis – modelis grindžiamas turimais programų sistemos kainos skaičiavimų rezultatais. Kaina, arba sąnaudos, yra vertinamos sprendžiant regresinę lygtį atsižvelgiant į kuriamos programų sistemos metriką. Paprastai programos dydis išreiškiamas programinių eilučių, operatorių, objektų ar kitokių kiekybinių charakteristikų suma. Ekspertų įvertinimas (Delphy metodas) – vienas ar keli PS kainos nustatymo ekspertai nepriklausomai vienas nuo kito vertina produkto sąmatą. Jie remiasi savo patirtimi ir biznio „uosle“. Delphy metodas sukurtas 1948 m. (pasiūlė Rand corporation).

DELPHY METODAS Metodo esminiai bruožai: Koordinatorius kiekvienam ekspertui pateikia sistemos specifikaciją ir vertinimo formą. Ekspertai anonimiškai užpildo vertinimo formas. Jie gali užduoti klausimus koordinatoriui, tačiau negali diskutuoti tarpusavyje. Koordinatorius parengia ir išdalina ekspertams jų vertinimų apibendrinimą ir prideda jų pastabas dėl pastebėtų neįprastų dalykų projekte. Ekspertai, remdamiesi ankstesnio vertinimo rezultatais, anonimiškai parengia naują įvertinimą. Ekspertai, kurių apskaičiavimai labai skiriasi nuo vertinimų vidurkio, gali būti paprašyti (anonimiškai) pagrįsti savo išvadas. Iteracijų skaičius neribojamas. Viso proceso metu yra draudžiamos grupinės diskusijos.

PS KAINOS ĮVERTINIMO METODAI-2 Įvertinimas lyginant (pagal analogą) – metodas taikomas, kai turimi kelių analogiškų projektų rezultatai ir žinoma jų galutinė kaina. Naujo projekto kaina nustatoma įvertinus santykinę planuojamo projekto apimtį. Daugelyje organizacijų PS kainos įvertinimas remiasi ankstesne patirtimi. Parkinsono principas - čia projekto kainą lemia turimi laiko ir finansų ištekliai. Pavyzdžiui, jei projektui vykdyti galime skirti tris žmones ir duoti tam 12 mėnesių laiko, tai projekto kainą sudarys per metus šiems trims specialistams išmokėti atlyginimai.

PS KAINOS ĮVERTINIMO METODAI-3 Laimėjimo kainos principas – PS kainą lemia suma, pakankama laimėti PS įgyvendinimo konkursą. PS kaina yra nustatoma pagal tai, kiek užsakovas gali užmokėti už projektą (angl. Pricing to win). Darbo sąnaudos priklauso ne nuo PS funkcijų, bet nuo užsakovo biudžeto. Dėl projekto kainos yra susitariama remiantis pasiūlymo metmenimis. Vėliau, derantis su užsakovu, yra sudaroma išsami projekto specifikacija. Ši specifikacija yra ribojama sutartos kainos, ir pirkėjas bei pardavėjas privalo suderinti priimtiną sistemos funkcionalumą. Taigi projekte fiksuotasis veiksnys yra ne reikalavimų specifikacija, o kaina. Šis būdas gali pasirodyti neetiškas.

PS KAINOS ĮVERTINIMO STRATEGIJOS „Iš viršaus žemyn“ – PS kaina nustatoma nagrinėjant bendrą programų sistemos funkcionalumą. Įskaičiuojamos ir sisteminio lygio veiklos: Integravimas; Konfigūracijos valdymas; Dokumentavimas; Atskirų programų sistemos komponentų kaina apskaičiuojama iš bendros kainos. „Iš apačios aukštyn“ – įvertinama kiekvieno programų sistemos komponento kaina. Bendrą projekto kainą sudaro sudedamųjų dalių visuma. Taikant šią strategiją galima neteisingai įvertinti sisteminio lygio veiklų, tokių kaip integracija, kainą.

PS KAINOS ĮVERTINIMO METODŲ TAIKYMAS Svarbu derinti visas galimas PS kainos nustatymo metodikas. Reikia mokėti jas palyginti ir pasirinkti geriausią sąnaudų skaičiavimo algoritmą. Siūloma taikyti tokius pateiktų metodų derinius: taikyti metodą „iš viršaus į apačią“ remiantis ekspertų sprendimais ir jei įmanoma, kainą vertinti lyginant su kitomis analogiškomis programų sistemomis; taikyti metodą „iš apačios į viršų“ ir algoritminį modelį pavieniams komponentams įvertinti.

ALGORITMINIAI KAINOS NUSTATYMO MODELIAI Algoritminis kainos nustatymo metodas grindžiamas regresinės analizės principais, įvertintant PĮ metrikas. Paprastai nustatomos tam tikros buvusių projektų charakteristikos: trukmė, kaina, projekto komandos dydis, konkretūs kiekybiniai programų sistemos rodikliai (programos eilučių, operatorių ar kitų programinių objektų skaičius). Nustatyta, kad nedidelių PS sukūrimo projektų sąnaudos tiesiškai priklauso nuo jos dydžio: sąnaudos = a * dydis + b

ALGORITMINIAI KAINOS NUSTATYMO MODELIAI - 2 Dideliems projektams, paprastai tokiems, kuriuos rengia daugiau kaip trys žmonės, sąnaudų ir programų sistemos dydžio priklausomybė yra eksponentinė (kaina priklausomai nuo projekto dydžio didėja netiesiškai, nes didėjant projektui reikia papildomų sąnaudų dėl didėjančių ryšių kiekio, sudėtingesnio konfigūracijos valdymo, sunkesnės integracijos ir pan.): sąnaudos = a * dydisb ; čia a ir b – regresiniai koeficientai ( a – konstanta, priklausanti nuo projektuojamos PS tipo ir projektuojančios organizacijos ypatumų, b – konstanta (dažniausiai tarp l–1,5), atspindinti sąnaudų eksponentinę priklausomybę nuo sistemos dydžio); dydis reiškia vieną iš kiekybinių charakteristikų. Sąnaudos paprastai skaičiuojamos žmogaus mėnesiais (ŽM).

PUTNAM’O METODAS (MATEMATINIS MODELIS SLIM). Vienas iš anksčiau taikytų algoritminių metodų didelių projektų sąnaudoms apskaičiuoti buvo Putnamo metodas (Putnam H. Lawrence). Jis remiasi Norden / Reyleigh funkcija ir vadinamąja technologine konstanta C, kuri priklauso nuo naudojamų programavimo priemonių, projekto unikalumo, didumo, komandos patirties, kokybės standartų ir kt. S = čia T – projekto realizavimui skiriamas laikas (metais), C – 600 ÷ 57000

NORDEN / REYLEIGH FUNKCIJA Čia n(t) – personalo poreikio laikinė priklausomybė, S – sąnaudos ŽM; a – pagreičio faktorius T – visas projekto laikas

SLIM MODELIO TRŪKUMAI Tinka tik pakankamai dideliems projektams (KE > 5000, ŽM > 18, T>6 mėn.) Naudojant šį modelį reikia iš anksto žinoti PS dydį – eilučių skaičių. Modelis labai jautrus technologinei konstantai C. Modelis labai jautrus projekto realizavimo laikui T. Modelis labai jautrus PS dydžiui. Naudojant šį modelį dažnai gaunama, kad vykdant mažesnius projektus bendra sąnaudų suma gaunasi mažesnė, nei vykdant vieną didelį projektą. Todėl reikia atsargiai jį taikyti, kai didelis projektas yra padalinamas į mažesnius struktūrinius vienetus.

COCOMO METODAS Kitas algoritminis PS kainos įvertinimo metodas – COCOMO (Constructive Cost Model) modelis, sukurtas institute CSE (Center for Software Engineering) (http://sunset.usc.edu /research/COCOMOII/index.html). Pagal COCOMO’81 nagrinėjamos dvi pagrindinės regresinės lygtys: viena – sąnaudoms, išreikštoms ŽM, kita – projekto realizavimo laikui (RL) nustatyti: ŽM = a * dydisb; RL = c * ŽMd . čia: a, b, c, d – regresiniai koeficientai, programų sistemos dydis gali būti matuojamas tūkstančiais programos operatorių, RL – mėnesiais.

COCOMO METODO TAIKYMO LYGIAI Bazinis. Tai elementarus, statinis modelis, siejantis sąnaudas tik su programų sistemos dydžiu. Yra trys visuotinai pripažinti produkto sudėtingumo lygiai: 1) taikomosios programos (TP); 2) servisinės programos (SP); 3) sisteminio lygio programos (SLP). Brooks teigia, kad sudėtingumo santykis tarp šių kategorijų yra –1/3/9. Tarpinis. Šiuo atveju sąnaudos priklauso ne tik nuo programų sistemos dydžio, bet ir nuo 15-os kainos veiksnių, išreiškiančių subjektyvią nuomonę apie produktą, kompiuterinę techniką, personalą ir patį projektą. Šiame modelyje (1) lygtis keičiama tokia priklausomybe: ŽM = a * dydisb * C; čia C = – 15-os kainos veiksnių sandauga.

15 KAINOS VEIKSNIŲ Labai mažas Mažas Nominalus Didelis Labai didelis Sudėtingumo laipsnis Kaino faktorius Labai mažas Mažas Nominalus Didelis Labai didelis Produkto: Suderinamumas 0,75 0,88 1,00 1,15 1,40 Duomenų bazės dydis 0,94 1,08 1,16 PĮ sudėtingumo laipsnis 1,30 Kompiuterių: Greitis 1,11 Atmintis 1,06 1,21 Suderinamumas su kitomis OS 0,87 Atlikėjų: Projektuotojų kvalifikacija 1,50 1,22 0,83 0,67 PĮ kūrimo patirtis 1,23 1,10 0,80 Programuotojų kvalifikacija 1,37 0,74 Bendras darbo stažas 1,26 0,91 Kompiuterinė kvalifikacija 1,12 Programavimo kalbos patirtis 1,24 0,90 0,82 Projekto: Modernios PĮ kūrimo priemonės 1,20 Ribotas atlikimo terminas 1,04 Tinklinė PĮ 0,92 0,85

COCOMO METODO TAIKYMO LYGIAI-2 Detalusis. Sąnaudų priklausomybė tokia, kaip ir tarpinio projekto atveju, tik kainos veiksnių skaičiavimai atliekami kiekvienai projekto realizacijos fazei, t. y. reikalavimų specifikavimui, projektavimui, kodavimui, testavimui ir bandomajam naudojimui. Taikant COCOMO, kiekviename lygyje dar išskiriamos trys PS kūrimo sudėtingumo pakopos: Įprastinis produktas – sąlygiškai nedidelis, analogiškas buvusiems produktams. Normalus produktas. Dalis jo įprastinė, kitai daliai reikia originalių sprendimų. Inovacinis produktas. Tai naujas produktas, kuriam būtinas didelis patikimumas, originalios idėjos, nauji sprendimai.

COCOMO METODO KOEFICIENTAI Sudėtingumo pakopos a b c d bazinis tarpinis Įprastas 2,4 3,2 1,05 2,5 0,38 Normalus 3,0 1,12 0,35 Inovacinis 3,6 2,8 1,20 0,32

COCOMO II MODELIS Pasikeitus kompiuterinės technikos ir programų sistemų kūrimo sąlygoms, nuo 1995 m. COCOMO’81 modelis pakeistas modeliu COCOMO II. Tai yra trys skirtingi PS kainos įvertinimo modeliai: Struktūrinis modelis. Tinkamas projektams, realizuotiems naujausia automatizuoto programavimo įranga. Ankstyvosios konstrukcijos modelis. Taikomas, norint gauti projekto sąmatos įvertinimą ankstyvojoje PS kūrimo fazėje. Vėlyvosios konstrukcijos modelis. Tai pats sudėtingiausias ir tiksliausias COCOMO II modelis. Jis taikomas, kai jau sudarytas detalus PS kūrimo projektas.

STRUKTŪRINIS MODELIS Objekto tipas Jo taikymas grindžiamas objektų balų (OB) skaičiavimu. Objektai – tai langai ir ataskaitos, jie nebūtinai susiję su objektais, naudojamais objektinio programavimo metu. Trijų lygių skale vertinamas langų ir ataskaitų sudėtingumo laipsnis: paprastas, normalus, sudėtingas. OB priskyrimas pagal sudėtingumo laipsnį: Objekto tipas Sudėtingumo laipsnis paprastas normalus sudėtingas Langai 1 2 3 Ataskaitos 5 8 3GL komponentai   10

STRUKTŪRINIS MODELIS-2 Žinodami OB sumą ir pasirinkę naudojamų išteklių (kompiuterinių ir programinių priemonių, specialistų kvalifikacijos) lygį, galima įvertinti projekto sąnaudas (žmogaus mėnesiais) pagal formulę: ŽM= Išteklių lygis Labai žemas Žemas Nominalus Aukštas RL 4 7 13 25

ANKSTYVOSIOS KONSTRUKCIJOS MODELIS Tai daug tikslesnis kainos nustatymo metodas nei taikant struktūrinį modelį. Jis panašus į COCOMO metodo tarpinį taikymo lygį. Naudojamas sumažintas kainą lemiančių 7 veiksnių rinkinys: Eil. Nr. Kainos veiksniai (KV) Indeksai 1 Projektuotojų pajėgumas 3,53 2 Produkto sudėtingumas 2,38 3 Pasikartojimų lygis 1,31 4 Programuotojų patirtis 1,51 5 Kompiuterinės platformos sudėtingumas 1,40 6 Kompiuterinė kvalifikacija 1,43 7 Terminų glaustumas 1,63

ANKSTYVOSIOS KONSTRUKCIJOS MODELIS-2 Taikant COCOMO II modelį, projekto sąnaudos priklauso ir nuo projekto lygio veiksnių (LV), kuriems turi įtakos programų sistemos dydis. Koeficientas b priklauso nuo PS dydžio ir nuo lygio veiksnių svorių: b = Lygio veiksniai (LV) Programos dydis tūkstančiais programinių eilučių 10 100 1000 Projekto naujoviškumas 1,15 1,33 1,53 Projekto lankstumas 1,12 1,26 1,42 Reikalaujamas patikimumas 1,18 1,39 1,63 Komandos susitelkimas 1,13 1,29 1,46 Organizacinės struktūros brandumas 1,20 1,43 1,71

ANKSTYVOSIOS KONSTRUKCIJOS MODELIS-3 Taikant ankstyvos konstrukcijos modelį PS dydis dažniausiai skaičiuojamas funkciniais balais (metodas IFPUG FPA). Funkcinių balų skaičiavimas remiasi identifikavimu ir suskaičiavimu tokių programinių objektų: išorinės įvesties (paprastai duomenų failų); išorinės išvesties (ataskaitų, pranešimų, langų); užklausų ir atsakymų (programinių užklausų, kurioms reikia atsakymo); išorinių failų ar sąsajų (bendrai su kitomis programomis naudojamų failų); vidinių failų (nematomų programos vartotojui).

ANKSTYVOSIOS KONSTRUKCIJOS MODELIS-4 Kiekvienam objektui yra nustatomas sudėtingumo laipsnis (paprastas, normalus, sudėtingas objektas) ir atitinkami svoriai nuo 3 (paprasta išorinė įvestis) iki 15 (sudėtingas vidinis failas). Objekto sudėtingumą galima nustatyti pagal objektų sudėtingumo lentelę: Failų sąsajų skaičius Duomenų elementų skaičius 1–5 6–19 20– 0–1 Paprastas Normalus 2–3 Sudėtingas 4–

ANKSTYVOSIOS KONSTRUKCIJOS MODELIS-5 A. Albrechtas siūlo suteikti objektams tokius svorius: Objekto tipas Paprastas Normalus Sudėtingas Išorinės įvestys 3 4 6 Išorinės išvestys 5 7 Užklausos ir atsakymai Išoriniai failai ar sąsajos 10 Vidiniai failai 15

ANKSTYVOSIOS KONSTRUKCIJOS MODELIS-6 Funkciniams balams suskaičiuoti pagal šias lenteles reikėtų rasti visų programinių objektų svertinę sumą. Funkciniai balai padeda įvertinti programų sistemos dydį programinėmis eilutėmis. Tam pakanka žinoti TE ir funkcinių balų ryšį, kuris nesunkiai randamas remiantis turimais duomenimis. Funkcinių balų pranašumas tas, kad juos galima skaičiuoti pradinėje projekto stadijoje – turint tik programų sistemos reikalavimus. Vėlyvosios konstrukcijos modelio regresinė sąnaudų lygtis pagal COCOMO II : ŽM = Regresinė lygtis projekto realizavimo laikui (RL) apskaičiuoti: RL =

VĖLYVOSIOS KONSTRUKCIJOS MODELIS PS kainai nustatyti programavimo metu ar baigiamojoje kūrimo stadijoje verčiau naudoti vėlyvosios konstrukcijos modelį. Šio metodo regresinės lygtys analogiškos ankstyvosios konstrukcijos modeliui, tačiau vietoje septynių kainos veiksnių dažniausiai naudojama net 17. Jų gausa ir detalizavimo lygis leidžia daug tiksliau įvertinti visus kuriamo produkto niuansus. Šioje stadijoje jau galima gerokai tiksliau įvertinti programų sistemos dydį naudojant TE. Funkcijų balams transformuoti į TE jau nebūtini duomenys apie anksčiau vykdytus projektus, tam galima pasinaudoti jau pastebėta priklausomybe realizuojamame PS produkte.

KITI PS KAINOS APSKAIČIAVIMO METODAI Charles Symon sukūrė kitą funkcinių taškų metodą Mark II, analogišką A. Albrecht metodui, bet logiškai labiau pagristą ir naudojantį šiuolaikiškesnes technologijas. Skirtingai nuo IFPUG FPA, čia yra vartojama viena transakcijos sąvoka, turinti įėjimą, apdorojimą ir išėjimą. Funkcinių taškų metodas Feature points (jo autorius Capers Jones). 3D Points, sukurtas Boeing kompanijoje.

FUNKCINIŲ TAŠKŲ METODO ISTORIJA Paimta iš Cristof Ebert, Reiner Dumke SOFTWARE MEASUREMENT, Springer, 2007, 568 p.

PROGRAMŲ SISTEMOS PALAIKYMO SĄNAUDOS Sąvoka palaikymas (evoliution) buvo ir yra taikoma PS (IS) modifikavimo procesui, tuomet kai PS yra pateikta vartotojui ir naudojama. Yra nustatyta, kad: ~20 % palaikymo sudaro palaikymas, susijęs su klaidų taisymu, ~20 % – palaikymas, susijęs su PS pritaikymu naujoje aplinkoje (keičiasi įstatymai ir pan.), ~60 % – palaikymas, susijęs su PS kokybės gerinimu. Palaikymą PS inžinieriai dažnai laiko mažiau įgūdžių reikalaujančiu procesu ir daugelyje organizacijų jį atlieka mažiau patyręs personalas (ir tai kelia palaikymo kainą).

VEIKSNIAI, TURINTYS ĮTAKOS PALAIKYMO SĄNAUDOMS Bendra tendencija yra tokia, kad, kuriant ir diegiant PS, IS palaikymo sąnaudos yra planuojamos visiškai mažos, nors jos yra 2–4 kartus didesnės nei projektavimo (PS, IS sukūrimo) sąnaudos (kartais dar ir daugiau). PS palaikymo sąnaudoms turi įtakos: Personalo stabilumas. Palaikymo sąnaudos yra sumažinamos, jei sistemos projektuotojai yra atsakingi ir už sistemos palaikymą. PS gyvavimo laikas. Kuo senesnė PS, tuo daugiau ji buvo keista, tuo labiau degradavusi jos struktūra. PS senstant, palaikymo sąnaudos didėja. PS priklausomybė nuo išorinės aplinkos. Pvz., mūsų informacines buhalterines sistemas reikia nuolat palaikyti, nes įstatymai keičiasi pakankamai dažnai.

VEIKSNIAI, TURINTYS ĮTAKOS PALAIKYMO SĄNAUDOMS-2 Techninės įrangos moralinis senėjimas. PS keičiama dėl to, kad panaudojama nauja techninė įranga, pakeičianti morališkai pasenusią. Modulių nepriklausomybė. Būtina turėti galimybę modifikuoti vieną sistemos komponentą nedarant poveikio kitiems. Programavimo kalba. Aukšto lygio kalba parašytą PS yra lengviau suprasti, vadinasi, ir modifikuoti. Programavimo stilius. Komentarų naudojimas ir pan. PS testavimas. Kuo geriau PS ištestuota, tuo mažiau reikia sąnaudų palaikymui, susijusiam su klaidų taisymu. Sistemos dokumentacijos kokybė. Konfigūracijos vadybos kokybė. Visi sistemos dokumentai turi būti nuoseklūs, neprieštarauti vienas kitam.

PALAIKYMO SĄNAUDŲ APSKAIČIAVIMAS COCOMO modelyje palaikymo sąnaudoms įvertinti yra vartojama sąvoka kasmetinis pakeitimų judėjimas (KPJ) (angl. annual change traffic). KPJ yra PS produkto pradinio kodo dalis, keičiama (modifikuojama arba papildoma) per metus: KPS = KPJ ∙ PSPL, čia KPS – kasmetinės palaikymo sąnaudos, o PSPL – PS projektavimo laikas (abu dydžiai yra išreiškiami programuotojo mėnesiais).

PALAIKYMO SĄNAUDŲ APSKAIČIAVIMAS-2 Sistemai palaikyti vadybininkas nusprendė sutaupyti lėšas pasirinkdamas mažiau patyrusį ir kartu menkiau apmokamą personalą, tačiau variantų analizė parodė, kad kaip tik patyrusių PS inžinierių darbas leidžia sutaupyti lėšas, nepaisant to, kad jie yra geriau apmokami: Personalas Pradinis įvertinimas,ŽM Mėnesio alga, Lt Patirties veiksnys Palaikymo išlaidos, Lt Nepatyręs 35,4 1500 1,21 64 251 Mišrus 1700 1,03 61 985,4 Patyręs 2000 0,86 60 888

KOKYBĖS KAŠTAI dažniausiai suprantami kaip atitikties ir neatitikties kaštų suma. (A.Schiffauerova, V.Thomson) Kokybės kaina – tai galutinio produkto kainos dalis, kuri būtų sutaupyta, jei visi darbuotojai dirbtų nepriekaištingai. Kokybės kaina – svarbi kategorija, kuri faktiškai rodo: perdarymų darbų kainą; kiek papildomai išauga produkto palaikymo kaina. Išskiriami du kokybės kainos tipai: Atitikties arba suderinta (conformance); Neatitikties arba kitaip - nesuderinta (nonconformance).

PHILIP CROSBY KOKYBĖS KAŠTŲ MODELIS “KOKYBĖ VIS DAR NIEKO NEKAINUOJA. KAINUOJA NE KOKYBĖ, O JOS STOKA.”

SUDERINTOJI KOKYBĖS KAINA Suderintoji - atitikties kokybės kaina – tai suma, skirta tam, kad būtų gauta reikiama PS produkto kokybė. Ji skirstoma į : Prevencinę kainą (prevention cost). Prevencinės išlaidos yra susijusios su defektų prevencija (iki jų pasireiškimo). Kontrolės – įvertinimo (appraisal cost) kainą. Šią kainą sudaro PS kokybės nustatymo, įvertinimo, tikrinimo ir testavimo išlaidos.

NESUDERINTOJI KOKYBĖS KAINA Nesuderintoji – neatitikties kokybės kaina – tai išlaidos, kurių reikia sistemos trūkumams padengti, ištaisyti sutrikimams ir atsirandančioms klaidoms, ar apskritai išėjusiai iš rikiuotės sistemai tvarkyti. Ją sudaro : Vidinės išlaidos. Jos susijusios su problemomis, kurios išryškėja prieš pateikiant produktą vartotojui. Tai yra PS perdirbimo, pakartotinio tikrinimo ir testavimo kaina. Tai materialūs, laiko kaštai. Išorinės išlaidos. Tai išlaidos, skirtos klaidoms pašalinti PS produkto eksploatavimo metu (palaikymo išlaidos, prastovų nuostoliai ar nekorektiško funkcionavimo nuostoliai). Tai Laiko, materialūs, nematerialūs kaštai.

STATISTINIAI PS KOKYBĖS TYRIMAI Statistiniai PS projektavimo proceso įtakos kuriamo produkto kokybei tyrimai rodo, kad: PS projektavimo ir įdiegimo proceso tobulinimas labai sumažina santykinę (perskaičiavus programų sistemos kiekio vienetui pagal pasirinktą metriką) nesuderintą kokybės kainą, išlaikant suderintą kokybės kainą tame pačiame lygyje. Investicijos, skirtos programų sistemos projektavimo procesui tobulinti, su sąlyga, kad kokybės gerinimo procedūros yra taikomos tikslingai ir ankstyviausiose projekto stadijose, duoda didelį ekonominį efektą.

KOKYBĖS KAINOS PRIKLAUSOMYBĖ

KOKYBĖS KAŠTŲ OPTIMIZAVIMAS

KOKYBĖS KAŠTŲ APSKAITOS STANDARTAI Australija – AS 2561-1982 “Nuorodos kokybės kaštams nustatyti”; Prancūzija – metodika. “Kokybės vadyba – nuorodos įvertinti prastos kokybės kaštams” (australų standarto pagrindu), 1987 m.; D. Britanija, BSI – Nuorodos kokybės ekonomikai, 1992 m.; ISO/TR 10014:1998(E) “Guidelines for managing the economics for quality”.

PASIKLIAUNAMUMO KAINA Parengtumas, patikimumas, sauga ir apsauga

PASIKLIAUNAMUMO EKONOMIJA Dėl didelės pasikliaunamumo kainos, kartais labiau apsimoka pasirinkti mažiau patikimas sistemas ir padengti klaidų kaštus. Kaip bebūtų, tai priklauso nuo socialinių ir politinių faktorių. Dėl blogos sistemų, kuriomis negalima pilnai pasitikėti, reputacijos jos ateityje gali prarasti paklausą. Priklausomai nuo sistemos tipo (paprastai verslo sistemoms) užtenka ir vidutinio pasikliaunamumo.

10 PAGRINDINIŲ PS PROJEKTŲ EKONOMIKOS VALDYMO PRINCIPŲ Klaidų paieška jau įdiegus PS kainuoja 100 kartų daugiau nei klaidų nustatymas ankstyvosiose projektavimo stadijose. PS sukūrimo terminus galima sutrumpinti iki 25 %, bet ne daugiau. Ši taisyklė ir toliau lieka galioti projekto stadijai, kai dirbama prie intelektualaus sistemos turinio. Programų sistemos palaikymas kainuoja 2 kartus daugiau nei jos sukūrimas. Dabartinė tendencija - kainos pamažu susilygina. PS sukūrimo ir palaikymo kaina pirmiausia priklauso nuo pradinio kodo eilučių skaičiaus. Ateityje PS kainos apibrėžimo modeliai vis mažiau bus priklausomi nuo pradinio kodo eilučių skaičiaus, labiau priklausys nuo naudojamų komponentų skaičiaus ir nuo jų integravimo galimybių.

10 PAGRINDINIŲ PS PROJEKTŲ EKONOMIKOS VALDYMO PRINCIPŲ-2 Personalo darbo produktyvumas skiriasi dėl komandos narių kvalifikacijos skirtumų. Šie skirtumai laipsniškai mažėja, ypač didelėse komandose. PS ir techninės įrangos santykis nuolat didėja. 1955 m. jis sudarė 15:85, o 1985 m. jau 85:15. Aparatūra ir toliau pinga. Kuriant PS tik 15 % darbo skiriama programavimui (programos kodo rašymui). Dabar investuojama į proceso brandos nustatymo technologijas, vizualaus modeliavimo (UML), testavimo automatizavimo, komponentų (ActiveX, Java ir CORBA) kūrimo ir kitų PS kūrimo aspektų technologijas. 15 % skaičius išlieka, nors 1980 m. žmogaus mėnesį sudarė 1 000 kodo eilučių. Dabar šis skaičius padidėjo dešimtis kartų, nors realiai per mėnesį reikia parašyti tik keletą šimtų programos kodo eilučių.

10 PAGRINDINIŲ PS PROJEKTŲ EKONOMIKOS VALDYMO PRINCIPŲ-3 Programų sistemos ir produktai paprastai kainuoja 3 kartus daugiau (perskaičiuojant vienai kodo eilutei) negu atskiros programos. Dabar tas santykis jau mažėja, kai programų sistemos kuriamos daugiau nei vienam užsakovui ir naudojama vienoda architektūra, aplinka ir unifikuotas kūrimo procesas. Nepertraukiama kontrolė padeda surasti 60 % klaidų. Ši taisyklė dabar mažiau svarbi. 20 % darbuotojų atlieka 80 % darbų. Šis santykis galioja visiems laikams.

IŠVADOS Kaštų įvertinimas yra svarbi bet kokio inžinerijos projekto dalis. Dėl PĮ inžinerijos specifikos, rinkoje susiklostė situacija, kad net 70% projektų arba vėluoja arba iš vis žlunga, todėl tikslesnis kaštų įvertinimas padėtų dalį šių projektų pabaigti laiku ar apskritai. Priklausomai nuo projekto ir jį vykdančios komandos rekomenduojamos skirtingos kaštų įvertinimo metodų kombinacijos. Kaštų įvertinimo metodai dažnai reikalauja konkrečių žinių apie projektą ir jį atliksiančios komandos brandos lygį. Algoritminiai kaštų įvertinimo modeliai naudoja empirinius duomenis, kurie gauti atliekant praeities projektų metrikų analizę. 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ą. Dažniausiai programos kaina numatoma, kad laimėti kontraktą ir funkcionalumas priderinamas prie kainos. Projekto trukmė nėra proporcinga žmonių dirbančių prie projekto kiekiui.

AČIŪ UŽ DĖMESĮ