Virginija Limanauskienė Kęstutis Motiejūnas. PrograMinės įrangos diegimo

Transcription

1 Virginija Limanauskienė Kęstutis Motiejūnas PrograMinės įrangos diegimo tyrimas

2 Švietimo ir mokslo ministerija Virginija Limanauskienė Kęstutis Motiejūnas Programinės įrangos diegimo Tyrimas MOKOMOJI KNYGA Projektas Aukštojo mokslo I ir II pakopų informatikos ir informatikos inžinerijos krypčių studijų programų atnaujinimas bei naujų sukūrimas ir įgyvendinimas (AMIPA), kodas VP1 2.2 ŠMM 09 V , finansuojamas iš Europos socialinio fondo ir Lietuvos valstybės biudžeto lėšų.

3 Recenzavo: dr. T. Krilavičius doc. dr. A. Lenkevičius V. Limanauskienė, K. Motiejūnas, 2011 KTU Informatikos fakultetas, 2011 UAB TEV, 2011 ISBN

4 TURINYS 1. Programų sistemų inžinerijos matavimai. Matavimo proceso planavimas Matavimų svarba programų inžinerijos valdymo procese Matai, metrikos, indikatoriai Matavimų įsipareigojimų nustatymas Matavimų proceso planavimas...14 REIKŠMINIAI ŽODŽIAI / KEY WORDS...15 NAUDOTA LITERATŪRA Matavimo proceso vykdymas. Matavimų vertinimas Matavimo procesas Matavimo proceso vykdymas Matavimų analizė...20 REIKŠMINIAI ŽODŽIAI / KEY WORDS...21 REKOMENDUOJAMI SKAITINIAI...21 NAUDOTA LITERATŪRA Programų inžinerijos standartų prigimtis ir vaidmuo Standartizacijos institucijos Standartizavimo procesas Standartai ir jų taikymas Standartai programų inžinerijoje ISO/IEC (SPICE) Programinės įrangos proceso vertinimo standartas ISO 9126 Programų inžinerijos produkto vertinimo kokybės standartas ISO/IEC 15939:2007 Matavimo proceso standartas IEEE Programinės įrangos standartai Santrauka...29 REIKŠMINIAI ŽODŽIAI / KEY WORDS...30 NAUDOTA LITERATŪRA A.1 Priedas: standartų, kuriuos įsigijusi KTU Programų inžinerijos katedra, Sąrašas A.2 Priedas: standartų, prieinamų Lietuvos standartizacijos departamento tinklalapyje, Sąrašas A.3 Priedas: ISO Standards> By ICS> 35: Information technology. Office machines> : Software

5 4. Inžinerinės ekonomikos pagrindai Įžanga Projekto planavimo uždaviniai PĮ apimties apibrėžimas Projekto įgyvendinamumo nustatymas Išteklių įvertinimas PĮ projekto kaštų įvertinimas Įvertinimas pagal analogą Ekspertų įvertinimas (Delfi metodas) Užsakovo kaina Algoritminis kainos modeliavimas Bazinis COCOMO modelis Tarpinis COCOMO modelis...55 NAUDOTA LITERATŪRA Rizikos ir neapibrėžtumo sprendimai Rizika ir neapibrėžtumas projekte Projekto rizikų valdymo procesas Rizikos identifikavimo metodai SSGG analizė Delfi prognozavimo metodas Rizikos analizė Atsako į rizikas planavimas...67 REIKŠMINIAI žodžiai / Key words...69 REKOMENDUOJAMI SKAITINIAI...69 NAUDOTA LITERATŪRA A Priedas: Rizikos valdymo plano šablonas Produkto ir proceso matavimai. Programų sistemų proceso matavimai Programinės įrangos procesų charakteristikos Procesas ir produkto kokybė Procesų klasifikacija Proceso matavimai Proceso analizė ir modeliavimas...79 REIKŠMINIAI ŽODŽIAI / KEY WORDS...80 REKOMENDUOJAMI SKAITINIAI...81 NAUDOTA LITERATŪRA Programų sistemos produkto matavimai: dydžio, struktūros, kokybės Programinės įrangos metrikos Efektyvių PĮ metrikų atributai PĮ metrikos pagal sritis Analizės modelio metrikos

6 Kai kurios produkto metrikos Objektiškai orientuoto produkto metrikos Projekto modelio metrikos Objektiškai orientuoto projektavimo metrikos Į klasę orientuotos metrikos CK metrikų rinkinys Į klasę orientuotos metrikos MOOD metrikų rinkinys Objektiškai orientuotos metrikos pagal Lorenz ir Kidd Vartotojo sąsajos projektavimo metrikos Programinio kodo metrikos Testavimo metrikos Objektiškai orientuoto testavimo metrikos Priežiūros metrikos...90 REIKŠMINIAI ŽODŽIAI / KEY WORDS...90 REKOMENDUOJAMI SKAITINIAI...90 NAUDOTA LITERATŪRA Programinės įrangos kokybės valdymas Kokybės apibrėžimas Programinės įrangos kokybės valdymo procesas Programinės įrangos kokybės užtikrinimas pagal standartus Kokybės planavimas Kokybės kontrolė Programinės įrangos gebėjimų brandos modeliai Žmogiškųjų išteklių gebėjimų brandos modelis Programinės įrangos gebėjimų brandos modelių programinės priemonės PKP BRANDA programų kūrimo proceso modelis Kaip kokybė susijusi su projekto valdymo trikampiu Kuo skiriasi PĮ kokybės valdymas nuo testavimo Santrauka REIKŠMINIAI ŽODŽIAI / KEY WORDS REKOMENDUOJAMI SKAITINIAI NAUDOTA LITERATŪRA Programos ar sistemos vertinimas pagal testą. atlikto testavimo įvertinimas Įvadas Programų sistemos vertinimas pagal testą Testavimo planavimas Testavimo planas Testavimo tikslai Ankstyvasis testavimas Nekonkretaus testavimo trūkumai Psichologinė testavimo įtaka Testavimo ir derinimo ryšys

7 9.3. Atlikto testavimo įvertinimas Bendras testavimo rezultatų vertinimo principas Testavimo pabaiga pasitelkus rezultatų analizę Santrauka REIKŠMINIAI ŽODŽIAI / KEY WORDS REKOMENDUOJAMI SKAITINIAI NAUDOTA LITERATŪRA A priedas: testavimo PLANAS Programinės įrangos diegimas. Konfigūracijos valdymas Konfigūracijos valdymo svarba Konfigūracijos valdymo svarba Konfigūracijos valdymas evoliucinio projektavimo procese Konfigūracijos valdymo planavimas Konfigūracijos vienetų identifikavimas Konfigūracijos duomenų bazė Keitimų valdymas Versijų valdymas ir identifikavimas Leidimų valdymas Kada reikia rengti naują sistemos leidimą Leidimo kūrimas ir dokumentavimas REiKŠMINIAI ŽODŽIAI / KEY WORDS REKOMENDUOJAMI SKAITINIAI NAUDOTA LITERATŪRA A Priedas: patarimai programų sistemos reklaminio skelbimo kūrėjui Programų inžinerijos projekto užbaigimas. Užbaigimo apibūdinimas. Užbaigimo veiklos Įvadas Projekto užbaigimas ir perdavimas naudoti Užbaigimas Projekto tikrinimas (peržiūra) Proceso tobulinimas Kokybės kainos nustatymas Santrauka REIKŠMINIAI ŽODŽIAI / KEY WORDS REKOMENDUOJAMI SKAITINIAI NAUDOTA LITERATŪRA Projekto dokumentacija Dokumentacijos paskirtis Dokumentų klasifikacija Vartotojo dokumentacija

8 Sistemos dokumentacija Dokumentų kokybė ir rašymo stilius Intelektinių teisių apsauga programų sistemų kūrimo procese Licencijos Programinės įrangos licencijos Vartotojo licencija Creative Commons licencijos REIKŠMINIAI ŽODŽIAI / KEY WORDS REKOMENDUOJAMI SKAITINIAI NAUDOTA LITERATŪRA Semestro projektas Projektavimo studijavimo metodika Semestrų projektų tikslai Mokymo projektuojant įgyvendinimas (pedagoginis modelis) Magistrinio projekto kokybės reikalavimai Praktika projektavimo organizacijoje Praktikos programa Modulio atsiskaitymai Santrumpos A Priedas: Studento praktinio mokymo sutarties pavyzdinė forma B Priedas: Programų inžinerijos magistrantūros priimančiosios organizacijos praktikos vadovo vertinimo lentelė C Priedas: Programų sistemos perdavimo ir aprobavimo akto šablonas D Priedas: Programinės įrangos diegimo tyrimas Projekto galutinės dokumentacijos turinys E Priedas: Projekto kokybės vertinimo ataskaitos turinys

9 Mokomoji medžiaga skirta magistrantams, studijuojantiems Programų sistemų inžinerijos programą. Magistrantūros modulio Programinės įrangos įdiegimo tyrimas tikslas pagilinti programų sistemų inžinerijos žinias ir projekto valdymo įgūdžius, suteikti programų sistemos kokybės matavimų praktinių gebėjimų, ugdyti gebėjimus analizuoti projektavimo įmonės valdymą, procesus, taikyti standartus. Modulio suteikiamos žinios ir gebėjimai. Baigę šį kursą, studentai turi: įgyti patirties kuriant tam tikro tipo (realaus laiko, paskirstytą, kritinės saugos, įterptinę) programų sistemą, kurios apimtis ne mažesnė kaip 2 5 tūkst. kodo eilučių, arba į didelę sistemą integruoti trečiųjų šalių komponentus, kurių apimtis didesnė kaip tūkstantis kodo eilučių, įgyti profesionalaus darbo praktinių įgūdžių projektavimo įmonėje, patobulinti gebėjimus programuoti, testuoti, analizuoti ir vertinti programų sistemų kokybę, valdyti projektavimo grupės darbą, susiformuoti gebėjimus priimti projektavimo valdymo sprendimus, praplėsti programų inžinerijos žinias ir gebėjimus tam tikroje taikomojoje srityje, priimti etiškus profesionalius sprendimus ir etiškai profesionaliai elgtis. Modulio anotacija Tiriamasis darbas įmonėje, surenkant medžiagą magistro baigiamajam darbui. Studentai įgyja darbo realioje organizacijoje įgūdžių, taiko mokslinio darbo principus, specializuojasi taikyti plataus spektro programų inžinerijos metodus ir įrankius, realizuoja, testuoja ir įdiegia programinės įrangos projektą, matuoja kokybinius parametrus. Atliekamas įmonėje įdiegtos programų sistemos kokybės kiekybinis tyrimas. Medžiagos anotacija Mokomojoje medžiagoje aprašomas programų inžinerijos projekto matavimo proceso planavimas ir vykdymas, proceso matavimai, programų sistemos dydžio, struktūros, kokybės matavimai, analizuojamas matavimų įvertinimas, nagrinėjami programų inžinerijos standartai, aptariami programų inžinerijos ekonomikos metodai ir sprendimai, rizikos vertinimo metodai, aiškinama matavimo rezultatų kokybė, analitiniai ir lyginamosios analizės metodai, aptariamas programos ar sistemos įvertinimas pagal testą, aprašomas programinės įrangos diegimas įmonėje, apžiūra ir vertinimas, analizuojamas programinės įrangos eksploatacinių savybių patikrinimas ir įvertinimas, aprašomas programų inžinerijos projekto užbaigimas veiklos, produkto pristatymo užsakovui ypatumai. Pateikiamos savarankiško darbo užduotys, reikiamų dokumentų ruošiniai, ataskaitų rengimo nurodymai. 8

10 1. Programų sistemų inžinerijos matavimai. Matavimo proceso planavimas 1.1. Matavimų svarba programų inžinerijos valdymo procese Programinės įrangos (PĮ) projektavimo vadyba gali būti apibrėžta kaip vadybos, planavimo, koordinavimo, matavimo, kontroliavimo, kontrolės ir dokumentavimo taikymas siekiant garantuoti sisteminį, disciplinuotą ir išmatuojamą programinės įrangos kūrimą ir aptarnavimą. Matavimai yra svarbūs ir projektavimo, ir valdymo procese. Deja, bendra programinės įrangos pramonės praktika rodo, kad produktai sukuriami per vėlai, projektai viršija biudžetą, PĮ būna prastos kokybės ir abejotino funkcionalumo. Vadyba be kiekybinių ir kokybinių matų yra betikslė, o matavimai be valdymo praranda prasmę ir kontekstą. Taip pat matavimai ir vadyba negali būti veiksmingi be ekspertų žinių. Siekiant efektyvios vadybos reikia derinti kiekybinius matavimus ir žmonių patirtį. Projekto valdymo procesus galima suskirstyti į šias dideles grupes: inicijavimo procesai idėjos generavimas ir atranka, formalus projekto pradžios pripažinimas; planavimo procesai projekto plano, kuris leistų pasiekti projekto tikslus, parengimas; vykdymo procesai projekto įgyvendinimas, darbuotojų ir kitų išteklių valdymas, vykdant projekto planą; analizės procesai projekto įgyvendinimo eigos stebėjimas, vertinimas; valdymo procesai projekto koregavimo veiklos nustatymas, vykdymas, nepalankios veiklos šalinimas; užbaigimo procesai formalus projekto baigimas, rezultatų įvertinimas. Projekto valdymo procesai gali sekti vienas paskui kitą, dengtis, gali vykti skirtingu intensyvumu, kaip pavaizduota 1.1 pav. (Bareiša ir kt., 2003). Be to, projekto valdymo procesai rezultatais yra susieti vienas su kitu, t. y. vieno proceso rezultatai tampa pradiniais kito proceso duomenimis (pavyzdžiui, prieš baigiamąją fazę reikia projektinės dokumentacijos, kuri gaunama projektavimo etapo pabaigoje). 9

11 Proceso lygis Planavimas Vykdymas Valdymas Inicijavimas Analizė Užbaigimas Pradinė fazė Baigiamoji fazė 1.1 pav. Projekto valdymo procesų išsidėstymas projektavimo laike 1.2 pav. Programų inžinerijos valdymo žinių sritys (Guide to the Software Engineering Body of Knowledge (SWEBOK): 10

12 Programų inžinerijos valdymo žinių sritys skaidomos į šešias temas, kurių detalizuota schema iš Programų inžinerijos žinių vadovo (Chapter 8, Software Engineering Management, Guide to the Software Engineering Body of Knowledge SWEBOK) anglų kalba pateikta 1.2 pav. : 1. Inicijavimas ir srities apibrėžimas analizuoja sprendimą pradėti programų sistemos projektavimą. 2. PĮ projekto planavimas skirtas pasiruošti sėkmingai PĮ projektavimo vadybai. 3. PĮ projekto įgyvendinimas analizuoja bendrai priimtas programų inžinerijos vadybos veiklas. 4. Peržiūros ir įvertinimas skirta PĮ kokybei užtikrinti. 5. Užbaigimas analizuoja veiksmus užbaigus programų inžinerijos projektą. 6. Programų inžinerijos matavimai nagrinėja efektyvų kūrimą ir matavimų įgyvendinimą PĮ projektavimo organizacijose. Programų inžinerijoje vadyba atliekama trijuose lygmenyse: organizacijos ir infrastruktūros vadybos, projekto valdymo bei matavimų planavimo ir kontrolės. 1.3 pav. Modulio Programinės įrangos diegimo tyrimas žinių sritys 11

13 Šio modulio teorinė medžiaga skirta palengvinti magistrinio projekto kokybės užtikrinimą, įdiegimą įmonėje ir projektavimo mokslinį tyrimą, kurio rezultatai bus pateikti baigiamajame magistro darbe. Studijų veiklos, vykdomos 3-iame semestre, atitinka magistrinio projekto vykdymo, valdymo ir užbaigimo procesus (1.1 pav.). Todėl modulio Programinės įrangos diegimo tyrimas žinių sritys apima kelis programų inžinerijos valdymo poaibius, pavaizduotus 1.3 pav Matai, metrikos, indikatoriai Kokybės peržiūros yra brangios ir užima laiko. Siekiant pagreitinti peržiūros procesą, naudinga taikyti automatizuotus projektavimo įrankius ir atlikti automatinį PĮ kokybės vertinimą. PĮ matavimai nustato skaitmenines kai kurių produkto ar proceso atributų reikšmes. Lyginant tas reikšmes tarpusavyje ir su standartu, galima padaryti išvadas apie produkto ar proceso kokybę. Pavyzdys: Norint įvertinti testavimo įrankio efektyvumą, turi būti žinomas anksčiau be testavimo įrankio nustatomų klaidų kiekis, kuris palyginamas su testavimo įrankio aptinkamų klaidų kiekiu per tą patį laiką. Jei bus randama daugiau defektų taikant testavimo įrankį, galima daryti išvadą, kad šis įrankis naudingas validavimo procese. PĮ produkto matavimai gali būti naudojami dviem tikslais (1.4 pav.): 1. Bendram sistemos įvertinimui prognozuoti. 2. Nenormaliems komponentams nustatyti, t. y. tiems, kurių charakteristikos skiriasi nuo apibrėžtų normų (Sommerville, 2007). Matas, matavimas (angl. measurement) kiekybiškai nusako produkto ar proceso atributo apimtį, kiekį, mastą, talpą arba dydį. Metrika (angl. metric) tai matas, susijęs su PĮ sistema, procesu ar dokumentacija; metrikos susieja atskirus matavimus. Indikatorius tai metrika ar jų rinkinys, padedantis suprasti ir numatyti tolesnį PĮ vystymą. Valdymo matai yra susiję su projektavimo procesu, o prognozės matai su produktu. 1.4 pav. parodyta, kad valdymo ir prognozės matai gali turėti įtakos valdymo sprendimams PĮ projektavimo procese. Bus vartojami tokie darbiniai apibrėžimai: Vadyba tai procesas, kuris siejasi su tokiomis veiklomis, kurios atliekamos,siekiant užtikrinti programinės įrangos projektavimo procesų ir organizacijos politikos, tikslų bei standartų atitikimą. 12

14 Matavimai apima verčių ir žymų skyrimą programinės įrangos projektavimo aspektams (produktams, procesams ir ištekliams (Fenton, 91) ir modelius, kurie yra gauti, taikant statistines bei ekspertines žinias ar kitus metodus. 1.4 pav. Prognozės matų ir valdymo matų taikymas (Sommerville, 2007) Vadybos praktikoje matavimų svarba ir jų nauda yra akivaizdžiai suprantami. Efektyvūs matavimai yra vienas iš svarbių organizacijos brandos kertinių akmenų (SWEBOK). Matavimų procese laikomasi tarptautinio standarto ISO/IEC 15939, kuris apibūdina procesą, sudarytą iš veiklų ir užduočių, reikalingų programų inžinerijos matavimo procesui ir matavimų informacijos modeliui įgyvendinti. Žemiau pateiktas matavimų proceso veiklų ir užduočių aprašymas pagal ISO/IEC standartą Matavimų įsipareigojimų nustatymas Esminiai matavimo proceso etapai pateikti 1.5 pav. Nustatykite reikalavimus matavimams Reikėtų vadovautis organizacijos tikslais ir nustatytais projekto matavimų reikalavimais. Pavyzdžiui, organizacijos tikslas galėtų skambėti taip: būti pirmiesiems rinkoje su nauju produktu (Fenton, 1998). Tai savo ruožtu galėtų išsilieti į reikalavimą, kad veiksniai, turintys įtakos šiam tikslui, būtų matuojami taip, kad projektui būtų vadovaujama siekiant šio tikslo. Reikia apibrėžti matavimo apimtį. Tam reikia nustatyti, kokiems organizacijos elementams bus taikomas kiekvienas matavimo reikalavimas: funkcinei sričiai, vienai svetainei, vienam projektui, visai įmonei. Matavimų apimtyje turi būti apibrėžtos visų matavimų užduotys ir susiję tarpininkai. 13

15 Pasirinkti matavimus Analizuoti anomalius komponentus Pasirinkti matuojamus komponentus Nustatyti anomalius matavimus Matuoti komponentų charakteristikas 1.5 pav. Matavimo proceso etapai Įpareigokite darbuotojus Įpareigojimai turėtų būti įforminti formaliai, jiems turėtų būti skirti reikalingi ištekliai. Išteklių priskyrimas yra esminis veiksnys siekiant sėkmingai įvykdyti matavimus. Išteklius sudaro: darbuotojai, atitinkamas finansavimas, mokymai, įrankiai, pagalba Matavimų proceso planavimas Charakterizuokite organizacinį vienetą Organizacinis vienetas sudaro matavimų kontekstą, nusako, kas atliks matavimus ir apribojimus bei prielaidas. Charakterizavimas gali būti išreiškiamas organizaciniais procesais, taikomosiomis sritimis, technologija ir organizaciniais interfeisais. Tipinė organizacinio vieneto charakteristika yra organizacinis proceso modelis (ISO : 5.2.1). Identifikuokite informacijos poreikį Informacijos poreikis yra grįstas tikslais, apribojimais, pavojais ir organizacinio vieneto problemomis, kurie gali būti gauti iš verslo, organizacijos, priežiūros ir/ar produkto tikslų. Jie turi būti identifikuoti ir surikiuoti pagal prioritetus. Tada turėtų būti išrinktas ir su tarpininkais aptartas poaibis, į kurį norima atkreipti dėmesį, ir rezultatai turi būti dokumentuoti [ISO : 5.2.2]. Išrinkite matus Matai išrenkami pagal suranguotus kriterijus, tokius kaip: informacijos poreikis, surinkimo kaina, proceso žlugdymo laipsnis renkant duomenis, analizės lengvumas, tikslių ir nuoseklių duomenų gavimo paprastumas ir pan. [ISO : 5.2.3]. 14

16 Apibrėžkite duomenų surinkimo, analizės ir ataskaitų procedūras Tai apima surinkimo procedūras ir tvarkaraščius, saugojimą, verifikavimą (tikrinimą), analizę, ataskaitų parengimą ir konfigūracijos duomenų valdymą [ISO : 5.2.4]. Apibrėžkite informacijos produktų vertinimo kriterijus Vertinimo kriterijams įtaką daro organizacinio vieneto techniniai ir verslo tikslai. Informacijos produktai yra susiję su gaminamu produktu ir projekto valdymo bei vadybos procesais [ISO : 5.2.5]. Išanalizuokite, patvirtinkite ir pateikite išteklius matavimo užduotims Tarpininkai turėtų išanalizuoti ir pritarti matavimų planui: duomenų surinkimo, saugojimo, analizės ir ataskaitų procedūroms; vertinimo kriterijams; tvarkaraščiams ir atsakomybėms. Šių duomenų analizės kriterijai turėtų būti patvirtinti organizacinio vieneto ar aukštesniame lygmenyje ir naudojami analizuojant. Tokie kriterijai turi atsižvelgti į ankstesnę patirtį, išteklius ir galimą pakenkimą projektui, jei būtų pasiūlyti kitokie nei įprastos praktikos pakeitimai. Pritarimas rodo, kad matavimo procesui įsipareigota [ISO : ]. Įgyvendinant matavimo užduotis, ištekliai turi būti prieinami. Ypatingas dėmesys turėtų būti skiriamas naujoms procedūroms ir matams sėkmingai pritaikyti [ISO : ]. Susiraskite, įsigykite ir pritaikykite palaikymo technologijas [ISO : 5.2.7]. REIKŠMINIAI ŽODŽIAI / KEY WORDS Programų inžinerijos projekto valdymas, programų sistemų inžinerijos matavimai, kokybės užtikrinimas apibrėžiamas [ISO ] remiantis ISO metrologijos tarptautiniu žodynu [ISO93]. Literatūroje įvairiai taikomi terminai metrika (angl. metrics) vietoje matavimai (angl. measures) (SWEBOK). Software engineering management, Software Engineering Measurement, Plan the measurement process, SQA: Software Quality Assurance. Guide to the Software Engineering Body of Knowledge (SWEBOK). Guide to the Project Management Body of Knowledge (PMBOK) (PMI00). Projekto aprašymo ir vertinimo pavyzdžiai straipsniuose, kurie buvo daugiausia kartų cituoti 2011 m. iš ACM Computing IGMETRICS Special Interest Group on Measurement and Evaluation, žiūrėta , 37&CFID= &CFTOKEN= Sąrašas pateiktas kaip gautas, siekiant lengviau rasti. Straipsnius nemokamai gali atsisiųsti ACM nariai. Norinčiuosius skaityti straipsnių tekstus mokymosi tikslais, prašome kreiptis į dėstytoją. 15

17 1. GPSR: greedy perimeter stateless routing for wireless networks 2000 Brad Karp, H. T. Kung Cituota 860 kartų 2. Directed diffusion: a scalable and robust communication paradigm for sensor networks 2000 Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin Cituota 843 kartus 3. The Cricket location-support system 2000 Nissanka B. Priyantha, Anit Chakraborty, Hari Balakrishnan Cituota 476 kartus 4. Next century challenges: scalable coordination in sensor networks 1999 Deborah Estrin, Ramesh Govindan, John Heidemann, Satish Kumar Cituota 443 kartus 5. Mitigating routing misbehavior in mobile ad hoc networks 2000 Sergio Marti, T. J. Giuli, Kevin Lai, Mary Baker Cituota 370 kartų 6. Generating representative Web workloads for network and server performance evaluation 1998 Paul Barford, Mark Crovella Cituota 361 kartą 7. Versatile low power media access for wireless sensor networks 2004 Joseph Polastre, Jason Hill, David Culler Cituota 346 kartus 8. The broadcast storm problem in a mobile ad hoc network 1999 Sze-Yao Ni, Yu-Chee Tseng, Yuh-Shyan Chen, Jang-Ping Sheu Cituota 331 kartą 9. A case for end system multicast (keynote address) 2000 Yang-hua Chu, Sanjay G. Rao, Hui Zhang Cituota 321 kartą 10. Taming the underlying challenges of reliable multihop routing in sensor networks 2003 Alec Woo, Terence Tong, David Culler, Cituota 295 kartus NAUDOTA LITERATŪRA Bareiša, E., Krivickas, J., Motiejūnas, K., Keršienė, V., Ambrazas, A., Programinės įrangos projektų valdymas, Kaunas: Technologija, Fenton, N. E.and Pfleeger, S. L., Software Metrics: A Rigorous & Practical Approach, second ed., International Thomson Computer Press,

18 Fairley, R. E., Managing and Leading Software Projects, Wiley-IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK): Graduate Software Engineering 2009 (GSwE2009) Software management approaches: project management, estimation, and life cycle support / Michael Haug... [et al.], (eds.). Berlin : Springer, [ISBN ]. Henry, J., Software project management: a real-world guide to success, 2004 [ISBN ] Sommerville, I. Software engineering. Harlow: Addison-Wesley, [ISBN ]. 17

19 2. Matavimo proceso vykdymas. Matavimų vertinimas 2.1. Matavimo procesas Nors kai kurios kompanijos jau įdiegė metrikų skaičiavimo programas, sisteminis metrikų naudojimas dar nėra plačiai paplitęs. Naudojant metrikas, firmoje reikia nuolat taikyti tą pačią vienos ar kitos metrikos skaičiavimo ideologiją, priešingu atveju jomis bus sunku remtis priimant sprendinius. Kontrolės metrikos dažniausiai siejasi su PĮ procesais (pvz., vidutinės sąnaudos defektui pataisyti), prognozavimo metrikos su PĮ produktais (pvz., modulio ciklomatinis kompleksiškumas). Dažnai neįmanoma tiesiogiai išmatuoti programinės įrangos kokybės atributų, ypač kai kalbama apie išorinius atributus, tokius kaip palaikomumas, suprantamumas, kompleksiškumas ir t. t. Kad vidinio atributo matavimai galėtų būti naudingi prognozuojant išorines PĮ charakteristikas, turi būti taikomos trys sąlygos (Kitchenham, 1990): 1. Vidinis atributas turi būti išmatuojamas tiksliai; 2. Turi egzistuoti ryšys tarp to, ką mes galime išmatuoti, ir išorinio atributo; 3. Tas ryšys turi būti suprastas, patikrintas ir išreikštas formule ar modeliu. Galimi ryšiai tarp išorinių ir vidinių PĮ atributų pateikti 2.1 pav. PĮ matavimo procesas gali būti kokybės kontrolės proceso dalis (žr. temą Programinės įrangos kokybės valdymas ). Surinkti duomenys turi būti saugomi. Kai yra sukaupta pakankamai didelė matavimų duomenų bazė, galima paskirus projektus palyginti ir patikslinti kai kurias metrikas pagal organizacijos poreikius. Esminiai matavimo proceso etapai pateikti 1.2 pav. Matavimo procesas nusakomas penkiais charakteringais veiksmais: 1. Formulavimas PĮ matų ir metrikų nustatymas, padedantis apibūdinti kuriamą PĮ. 2. Surinkimas mechanizmas naudojamas duomenims surinkti siekiant gauti metrikas. 3. Analizė metrikų nustatymas. 4. Interpretacija metrikų įvertinimas stengiantis nustatyti reprezentavimo kokybę. 5. Grįžtamasis ryšys rekomendacijos PĮ kūrėjų komandai, kilusios iš produkto metrikų interpretacijos. 18

20 Palaikomumas Patikimumas Perkeliamumas Vartojamumas Procedūrų parametrų kiekis Ciklomatinis kompleksiškumas Programos kodo eilučių kiekis Klaidų pranešimų kiekis Vartotojo vadovo dydis 2.1 pav. Ryšiai tarp išorinių ir vidinių programinės įrangos atributų Duomenis turi būti renkami neatidėliojant ir, jei įmanoma, automatiškai. Nerinkite nereikalingų duomenų. Paaiškinkite darbuotojams, kodėl yra renkami duomenys, duomenų rinkimas neturi būti skirtas personalui įvertinimui. Rinkite duomenis tada, kada jie yra sukuriami, o ne pasibaigus projektui Matavimo proceso vykdymas Integruokite matavimus į atitinkamus jų procesus Matavimo procedūros, t. y. duomenų surinkimas, turi būti integruotos į tuos procesus, kuriuos jos matuoja. Tuo tikslu gali tekti modifikuoti procesą siekiant įterpti duomenų surinkimo ar generavimo veiklas. Kad darbuotojai neprieštarautų matavimams, reikia analizuoti procesus, kad būtų minimizuotos papildomos pastangos ir įvertintas poveikis darbuotojams. Reikia atsižvelgti į moralinius ir kitus žmogiškuosius veiksnius. Turi būti informuojami žmonės, kurie teiks duomenis, jie turėtų būti mokomi, jiems teikiama pagalba. Panašiai duomenų analizės ir ataskaitos procedūros privalo būti tipiškai integruotos į organizacijos ar projekto procesus [ISO : 5.3.1]. Surinkite duomenis Reikalingi duomenys turi būti surinkti, verifikuoti ir saugomi pagal tarptautinį standartą [ISO :5.3.2]. 19

21 Išanalizuokite duomenis ir sukurkite informacinius produktus Analizės procese duomenys gali būti sujungti, transformuoti ar iš naujo koduoti pagal duomenų prigimtį. Šios analizės rezultatai yra tipiški indikatoriai, tokie kaip grafai, skaičiai ar kiti požymiai, kurie bus interpretuoti išvadose, skirtose tarpininkams. Rezultatai ir išvados turi būti išanalizuoti pagal organizacijoje apibrėžtą (formalų ar neformalų) procesą. Duomenų tiekėjai ir matavimo vartotojai turi dalyvauti duomenų peržiūrose, kad garantuotų duomenų prasmingumą bei tikslumą ir kad sukeltų protingus veiksmus [ISO : 5.3.3]. Pateikite rezultatus Rezultatai turi būti dokumentuoti ir pateikti vartotojams bei tarpininkams [ISO : 5.3.4] Matavimų analizė Įvertinkite matavimus Informacijos produktai turėtų būti įvertinti atsižvelgiant į apibrėžtus (specifikuotus) vertinimo kriterijus ir nustatytos informacijos produktų stiprybės (angl. strengths) ir silpnybės (angl. weaknesses). Tai gali būti atlikta vidiniais procesais arba išoriniu auditu ir turi būti įtraukta matavimų naudotojų atsakomoji reakcija. Gautas pastabas ir atliktų veiklų aprašymus geriausia išsaugoti atitinkamoje duomenų bazėje [ISO : 5.4.1] Identifikuokite potencialius patobulinimus Patobulinimai gali būti įvairūs: indikatorių formatų pakeitimas, pakeitimai matuojamuose elementuose, kategorijų perkvalifikavimas. Nustačius potencialių patobulinimų kainą ir naudą, turi būti pasirinkti atitinkami tobulinimo veiksmai. Apie siūlomus pakeitimus turi būti informuotas matavimo proceso savininkas ir suinteresuoti asmenys, kad patikrintų ir pritartų. Jei analizės metu nepavyksta identifikuoti, ką reikia tobulinti, apie tai taip pat turi būti pranešta [ISO : 5.4.2]. Viena iš problemų renkant kiekybinius duomenis apie PĮ projektus yra ta, kad reikia suprasti, ką šie duomenys iš tikrųjų reiškia. Galima neteisingai juos interpretuoti ir padaryti neteisingas išvadas. Matavimai turi būti nuodugniai išanalizuoti siekiant suprasti, ką jie realiai reiškia. Pavyzdys Panagrinėkime tokį pavyzdį. Vadybininkas nusprendžia kontroliuoti pakeitimų reikalavimų skaičių remdamasis prielaida, kad yra aiškus ryšys tarp šių reikalavimų skaičiaus ir produkto naudingumo bei tinkamumo, t. y. kuo didesnis šis skaičius, tuo mažiau PĮ atitinka vartotojo poreikius. Įgyvendinti pakeitimus yra brangu, todėl organizacija nusprendžia modifikuoti projektavimo procesą, siekdama padidinti vartotojo pasitenkinimą ir kartu sumažinti pakeitimų kainą. 20

22 Proceso modifikavimo esmė didesnis vartotojo įtraukimas į projektavimo procesą. Išleidžiamos naujo produkto versijos, tačiau vienais atvejais pakeitimų pareikalavimų skaičius sumažėjo, kitais padidėjo. Vadybininkas sutrikęs jis negali įvertinti proceso modifikavimo efekto produkto kokybei. Siekiant suprasti, kaip tai galėjo atsitikti, visų pirma reikia žinoti, kodėl šie pakeitimų reikalavimai buvo daromi. Viena iš priežasčių galėjo būti, kad suprojektuota PĮ nedaro to, ko nori vartotojas. Kita galimybė PĮ yra labai gera, plačiai naudojama, kartais net ne tuo tikslu, kuriam buvo suprojektuota. Kadangi tiek daug žmonių šią PĮ naudoja, dėl to yra tiek pakeitimų reikalavimų. Trečia galimybė organizacija labai atsakingai reaguoja į pakeitimų reikalavimus, vartotojai žino, kad į jų reikalavimus anksčiau ar vėliau bus atsižvelgta, todėl jie jų daug ir prašo. Pakeitimų reikalavimų skaičius galėjo sumažėti dėl to, kad projektavimo proceso pakeitimai buvo efektyvūs ir PĮ tapo naudingesnė ir tinkamesnė, arba dėl to, kad produktas prarado rinką atsiradus konkuruojančiam produktui. Pakeitimų reikalavimų skaičius galėjo padidėti, pvz., dėl padidėjusio vartotojų skaičiaus. Taigi, siekiant analizuoti pakeitimų reikalavimų duomenis, neužtenka tiktai žinoti jų skaičių. Reikia žinoti, kas pateikė pareikalavimą, kaip jie naudoja PĮ ir kodėl pareikalavimas pateiktas. Reikia žinoti, ar nėra išorinių veiksnių, tokių kaip, pvz., rinkos pasikeitimai, kurie galėjo padaryti poveikį. Išanalizavus visą šią informaciją, galima daryti išvadas apie proceso pakeitimų efektyvumą produkto kokybės atžvilgiu. Išnagrinėtas pavyzdys iliustruoja, kad kiekybinių duomenų apie produktą ar procesą interpretavimas yra nevienareikšmis procesas. Tiek produktai, tiek procesai nėra izoliuoti nuo jų aplinkos poveikio, kuris gali iškreipti kiekybinių duomenų palyginimą. REIKŠMINIAI ŽODŽIAI / KEY WORDS Programų inžinerijos projekto valdymas, programų sistemų inžinerijos matavimai, kokybės užtikrinimas. Software engineering management, Software Engineering Measurement, Plan the measurement process, SQA: Software Quality Assurance. REKOMENDUOJAMI SKAITINIAI ISO/IEC 15939:2007 Systems and software engineering Measurement process. 21

23 NAUDOTA LITERATŪRA Guide to the Software Engineering Body of Knowledge (SWEBOK): Graduate Software Engineering 2009 (GSwE2009). Bareiša, E., Krivickas, J., Motiejūnas, K., Keršienė, V., Ambrazas, A., Programinės įrangos projektų valdymas, Kaunas: Technologija,

24 3. Programų inžinerijos standartų prigimtis ir vaidmuo 3.1. Standartizacijos institucijos ISO (International Organization for Standardization, tai Tarptautinė daugiasektorė standartizacijos organizacija, kuri veikia visose srityse, išskyrus elektrotechnikos ir telekomunikacijų. Už elektrotechnikos ir elektronikos srities standartizaciją atsakinga IEC organizacija, o už telekomunikacijų ITU organizacija ( ISO yra 147 valstybių nacionalinių standartų institutų tinklas, vieno nario iš vienos šalies pagrindu, turintis Centrinį Sekretoriatą Ženevoje, Šveicarijoje. Tai nevyriausybinė organizacija. ISO vaidmuo per pirmuosius penkiasdešimt veiklos metų kito m. sukūrus ISO, pagrindinis jos tikslas buvo rekomendacijų teikimas savo nariams, padedant suderinti nacionalinius standartus, ir buvo skelbiamos ISO rekomendacijos. 8-ojo dešimtmečio pradžioje ISO pradėjo skelbti Tarptautinius standartus. Apie 40 % visų Europos standartų yra tiesiogiai iš ISO perimti standartai. ISO rengia savanoriškai taikomus, pripažintus, rinkos reikalavimus atitinkančius techninius standartus, kurie padidina verslo operacijų vertę. CEN (Europos standartizacijos komitetas) yra Europos daugiasektorė standartizacijos organizacija, pagrindinė Europos standartų ir techninių reikalavimų rengėja. Tai vienintelė organizacija Europoje standartams planuoti, rengti ir priimti visose ekonominės veiklos srityse, išskyrus elektrotechniką (CENELEC) ir telekomunikacijas (ETSI). CEN atsakinga už Naująjį požiūrį, pagal kurį standartai apibrėžia specifines technines detales, atsižvelgiant į Europos teisės aktus Standartizavimo procesas Standartizavimas yra savanoriškas procesas, paremtas susitarimu tarp skirtingų ekonomikos dalyvių (pramonės, įmonių, vartotojų, darbuotojų, valstybinės valdžios institucijų). Jį vykdo nepriklausomos standartizavimo institucijos, veikiančios nacionaliniu, Europos ar tarptautiniu lygiu. 23

25 Tarptautinis standartas yra susitarimo tarp ISO narių institucijų rezultatas. Jis gali būti naudojamas kaip toks arba gali būti įgyvendintas inkorporuojant į skirtingų šalių nacionalinius standartus. ISO techninis darbas yra išskaidytas į apie techninių komitetų, pakomitečių ir darbo grupių. Šiuose komitetuose kompetentingi pramonės atstovai, tyrimų institutai, vyriausybinės institucijos, vartotojų organai ir tarptautinės organizacijos iš viso pasaulio veikia kartu kaip lygiaverčiai partneriai ir sprendžia globalios standartizacijos problemas. Kiekvienais metais pasitarimuose dalyvauja maždaug specialistų. Iki šiol ISO darbas sudaro tarptautinių standartų, užimančių daugiau negu puslapių anglų ir prancūzų kalbomis (terminologija taip pat pateikiama ir kitomis kalbomis). ISO standartai rengiami pagal tokius principus: Konsensuso Atsižvelgiama į visų suinteresuotųjų grupių: gamintojų, pardavėjų ir naudotojų, vartotojų grupių, bandymų laboratorijų, vyriausybių, inžinerinių verslų ir tyrimų organizacijų nuomonę. Pramonės masto Globalūs sprendimai, siekiant patenkinti pasaulinę pramonę ir pasaulio vartotojus. Savanoriškumo Tarptautinės standartizacijos varomoji jėga yra rinka, todėl ji pagrįsta visų interesų grupių savanorišku dalyvavimu rinkoje. Daugelis standartų periodiškai reikia peržiūrėti. Standartas pasensta susidėjus keliems veiksniams: technologinei plėtrai, naujiems metodams ir medžiagoms, naujiems kokybės ir saugumo reikalavimams. Atsižvelgiant į šiuos veiksnius, ISO patvirtino bendrą taisyklę, kad visi ISO standartai turi būti peržiūrimi ne rečiau kaip kartą per penkerius metus. Kartais standartą būtina peržiūrėti ir anksčiau Standartai ir jų taikymas Standarto sąvoka Lietuvos standartizacijos departamento tinklalapyje pateiktas toks standarto apibūdinimas: Standartas yra sutarimu parengtas ir pripažintos standartizacijos institucijos priimtas dokumentas, kuriame gali būti pateikiami reikalavimai, rekomendacijos arba kitos nuostatos. Standartai turėtų būti pagrįsti apibendrintais mokslo, technikos bei patirties rezultatais ir teikti kuo didesnę naudą visuomenei. Lietuvos standarte LST EN 45020:2007 pateikiama tokia standarto termino apibrėžtis: Standartas sutarimu parengtas ir pripažintos standartizacijos institucijos priimtas dokumentas, kuriame nustatytos bendram ir daugkartiniam naudojimui tinkančios veiklos taisyklės, bendrieji principai ar charakteristikos arba jos rezultatai, skirtas optimaliai tvarkai tam tikroje srityje pasiekti. 24

26 Standartai gali būti tarptautiniai, pvz., ISO, IEC; regioniniai, pvz., Europos (EN); nacionaliniai, pvz., Lietuvos (LST), Vokietijos (DIN), Rusijos (GOST R). Lietuvos standartas (LST) yra Lietuvos nacionalinės standartizacijos institucijos priimtas, paskelbtas ir visuomenei skirtas standartas. Lietuvos standartas identifikuojamas pagal santrumpą LST ir numerį. Perimtas tarptautinis ar Europos standartas gali būti identifikuojamas iš santrumpos, kurią sudaro LST ir perimamo tarptautinio ar Europos standarto santrumpa ir atitinkamas numeris. Pvz.: VLST EN 45020:2007 Standartizacija ir su ja susijusi veikla. Bendrasis aiškinamasis žodynas (ISO/IEC Guide 2:2004); LST ISO 10002:2007 Kokybės vadyba. Kliento pasitenkinimas. Skundų tvarkybos organizacijose gairės (tapatus ISO 10002:2004). Lietuvos standartas yra savanoriško taikymo dokumentas. Nuo Lietuvos standartizacijos departamento įsteigimo išleista daugiau kaip Lietuvos standartai, iš kurių 98,8 procentų sudaro Europos ir tarptautiniai standartai, perimti kaip Lietuvos standartai. Informacija apie išleistus Lietuvos standartus skelbiama Lietuvos standartizacijos departamento (LST) elektroniniame periodiniame leidinyje LST biuletenis ( ir paslaugos). Informacija pateikiama nurodant LST TK arba LDG, Tarptautinės standartų klasifikacijos (ICS) indeksą, Lietuvos standarto projekto žymenį, antraštę, standarto projekto teksto kalbos kodą (LSD, Lietuvos ir tarptautinius standartus galima užsisakyti faksu, telefonu, el. paštu arba per el. parduotuvę Lietuvos standartizacijos departamente. Standartai yra įvairių tipų: baziniai, terminologijos, bandymų, produktų ir t. t. Standartai yra dokumentuoti, savanoriški susitarimai, kuriais kuriami svarbūs produktų, paslaugų ir procesų kriterijai. Todėl standartai padeda užtikrinti, kad produktai ir paslaugos atitiktų savo tikslus ir būtų palyginami bei suderinami. Standartų svarba ir nauda Standartizacija suteikia bendrą pagrindą atitikties įvertinimo procedūroms, kurios numatomos tam, kad produktai galėtų patekti į rinką geriausiomis sąlygomis. Kiekvienai įmonei naudinga taikyti standartus savo vidiniuose procesuose, kadangi: įmonė pati neišradinėja dviračio, o naudojasi esamais standartuose nustatytais sprendimais, kurie jau buvo gerai apgalvoti; suderina savo procedūras, taigi bendradarbiavimas yra paprastesnis, o įsigijimas pigesnis; efektyviai dirba, pakartotinai naudodama tą patį sprendimą; naudoja pripažintus reikalavimus kaip vertinimo pagrindą. 25

27 Taikanti standartus įmonė išorėje: sugeba pateikti produktus į rinką, nes jie tenkina standartuose ir įstatymuose nustatytus reikalavimus; tenkina vartotojų poreikius; suteikia klientams pasitikėjimą, nes produktas ar gamybos metodas atitinka pripažintus reikalavimus Standartai programų inžinerijoje Programų sistemų kūrėjai privalo suprasti ir gebėti taikyti šiuos standartus ir vertinimo modelius: ISO 9000 kokybės standartus, IEEE programinės įrangos standartus (angl. software standards), Integruotą gebėjimų brandos modelį (angl. SEI Capability Maturity Model Integrated CMMI). ISO-9126 standartą sudaro keturios dalys: kokybės modelis, išorinės metrikos, vidinės metrikos ir naudojimo kokybės metrikos (ISO-9126, 2009). Kokybės modelis yra pirmoji standarto dalis (ISO ) ir naudojamas programai vertinti. Kitos trys dalys svarbesnės PĮ kokybei užtikrinti ir PĮ kūrimo procesui tobulinti (ISO-9126, 2009; Software, 2007). Programų inžinerijoje komponentų standartai palengvina komponentų integraciją. Tie standartai būna įterpti į komponento modelį ir minimaliai apibrėžia, kaip komponento sąsajos turėtų būti specifikuotos ir kaip komponentai komunikuoja. Jei komponentai atitinka standartus, jų veikimas nepriklauso nuo programavimo kalbos. Komponentai, parašyti skirtingomis programavimo kalbomis, gali būti integruoti į bendrą sistemą ISO/IEC (SPICE) Programinės įrangos proceso vertinimo standartas SO/IEC 15504: Information Technology Software Process Assessment yra didelė tarptautinių standartų sistema, skirta procesui įvertinti, apimanti visus dalinius procesus: programinės įrangos įsigijimo (angl. Software acquisition); kūrimo (angl. Development); veikimo (angl. Operation); tiekimo (angl. Supply); priežiūra (angl. Maintenance); pagalbos, palaikymo (angl. Support). ISO/IEC susideda iš devynių dedamųjų dalių, apimančių sąvokas, proceso charakteristikų modelį ir tobulinimo instrukciją, vertinimo modelį ir vadovus, vertintojų kvalifikaciją ir vadovą, tiekėjo proceso brandumo nustatymo vadovą, žodyną: 26

28 1) ISO/IEC Part 1: Concepts and Introductory Guide. 2) ISO/IEC Part 2: A Reference Model for Processes and Process Capability. 3) ISO/IEC Part 3: Performing an Assessment. 4) ISO/IEC Part 4: Guide to Performing Assessments. 5) ISO/IEC Part 5: An Assessment Model and Indicator Guidance. 6) ISO/IEC Part 6: Guide to Competency of Assessors. 7) ISO/IEC Part 7: Guide for Use in Process Improvement. 8) ISO/IEC Part 8: Guide for Use in Determining Supplier Process Capability. 9) ISO/IEC Part 9: Vocabulary. Tokia ISO/IEC dokumentacijos struktūra ir turinys yra labiau susiję su ISO 9000, ISO/IEC ir CMM negu kokybės modeliai (McCall, Boehm) ir ISO ISO 9126 Programų inžinerijos produkto vertinimo kokybės standartas ISO/IEC 9126:2001 sudaro keturios dalys: 1 dalis: Kokybės modelis (Part 1: Quality Model) 2 dalis: Išorinės metrikos (Part 2: External Metrics) 3 dalis: Vidinės metrikos (Part 3: Internal Metrics) 4 dalis: Naudojimo kokybės metrikos (Part 4: Quality in use metrics) 3.1 pav. Programų inžinerijos produkto kokybės modelis (ISO/IEC :2001 Software engineering Product quality Part 1: Quality model) 27

29 Kokybės modelio, pateikto 3.1. pav. charakteristikos yra šios: funkcionalumas (angl. functionality) svarbiausia charakteristika, skirta įvertinti, kaip PĮ atlieka savo svarbiausią paskirtį, t. y. ar realizuotos visos reikalaujamos funkcijos; patikimumas (angl. reliability), skirta jau paleistos sistemos gebėjimui patikimai veikti įvertinti; vnaudojamumas (angl. usability), skirta įvertinti, ar vartotojui lengva (išmokti) naudotis PĮ; efektyvumas (angl. efficiency), skirta PĮ efektyvumui laiko ir kitų išteklių atžvilgiu įvertinti; palaikomumas (angl. maintainability), skirta įvertinti, ar lengva modifikuoti PĮ; pernešamumas (angl. portability), skirta įvertinti, ar lengva perkelti PĮ iš vienos platformos į kitą ISO/IEC 15939:2007 Matavimo proceso standartas ISO/IEC 15939:2007 Systems and software engineering Measurement process Šis tarptautinis standartas apibrėžia matavimo procesą, taikomą sistemų ir programinės įrangos projektavimui bei vadybai. Procesas yra apibūdintas per modelį, kuris apibrėžia matavimo proceso veiklas, reikalingas adekvačiai apibrėžti, kokia matavimo informacija yra reikalinga, kokiu būdu matai ir analizės rezultatai turi būti pritaikyti ir kaip nustatyti, ar analizės rezultatai yra galiojantys. Matavimo procesas yra lankstus, paruoštas taikyti ir pritaikomas skirtingų vartotojų poreikiams. Šis tarptautinis standartas identifikuoja procesą, kuris palaiko apibūdinimą tinkamo komplekto matų, kurie atkreipia dėmesį į specifinį informacijos poreikį. Standartas identifikuoja veiklas ir užduotis, kurios būtinos sėkmingai identifikuoti, apibrėžti, rinkti, taikyti, ir gerinti vidinius visa apimančios projektinės ar organizacinės matavimų struktūros matavimus. Jame taip pat pateikti bendrai priimti matavimo terminų apibrėžimai. Šis tarptautinis standartas detalizuoja standartų ISO/IEC 15288:2008 ir IEEE Std , taip pat ISO/IEC 12207:2008 ir IEEE Std matavimo procesus. Apie programinės įrangos standartų taikymą kokybės valdymo procese taip pat kalbama 8-ame skyriuje, kuriame pateiktos ISO 9126 apibrėžtos PĮ kokybės charakteristikos ir jų vidinės bei išorinės dedamosios (8.2 pav.) IEEE Programinės įrangos standartai IEEE asociacija (IEEE Standards Association, taip pat yra išleidusi daugiau kaip 40 programinės įrangos standartų, kurie skirti ISO standartams taikyti, pavyzdžiui: IEEE Std : IEEE Standard for Application and Management of the Systems Engineering Process IEEE Std : IEEE Standard for Software Quality Assurance Plans 28

30 IEEE Std : IEEE Standard for Software Configuration Management Plans Description IEEE Std : IEEE Standard For Software Test Documentation IEEE Std : IEEE recommended practice for software requirements specifications IEEE Std : IEEE standard for software verification and validation plans IEEE Std : IEEE recommended practice for software design descriptions IEEE Std : IEEE Standard for Software Reviews IEEE Std : IEEE standard for software project management plans IEEE Std : IEEE standard for a software quality metrics methodology IEEE Std : IEEE standard for software user documentation IEEE Std : IEEE standard for developing software life cycle processes IEEE/EIA : Standard Industry Implementation of International Standard ISO/IEC 12207: IEEE IEEE Standard for Adoption of ISO/IEC 26514:2008 Systems and Software Engineering-Requirements for Designers and Developers of User Documentation - IEEE IEEE Standard for Adoption of ISO/IEC 26513:2009 Systems and Software Engineering-Requirements for Testers and Reviewers of Documentation - IEEE IEEE Standard for Information Technology-System and Software Life Cycle Processes-Reuse Processes - IEEE IEEE/ISO/IEC Systems and Software Engineering- Requirements for Acquirers and Suppliers of User Documentation 3.6. Santrauka 1. Programų inžinerijos profesionalas turi gebėti taikyti standartizuotą terminologiją, matavimo metodus ir proceso metodus, naudojamus nacionalinėje ir tarptautinėje profesijos praktikoje. 2. Standartai padeda profesionalams, pedagogams ir organizacijoms bendrauti tarptautiniu mastu, pagerinti efektyvumą ir profesinio darbo našumą. KTU Programų inžinerijos katedra yra įsigijusi kai kuriuos ISO standartus, pagal klasifikaciją ICS : Programinės įrangos kūrimas ir sistemų aprašymas, jų sąrašas pateiktas 3A.1 priede. Sąrašas standartų : Programinės įrangos kūrimas ir sistemų aprašymas (Software), prieinamų iš Lietuvos standartizacijos departamento tinklalapio, pateiktas 3A.2 priede. Sąrašas ISO Standartų, atitinkančių klasifikaciją ICS 35: Information technology. Office machines> : Software, pateiktas 3A.3 priede. 29

31 REIKŠMINIAI ŽODŽIAI / KEY WORDS Programinės įrangos ir sistemų inžinerijos standartai. Programinės įrangos kūrimas ir sistemų aprašymas. Software and Systems Engineering Standards. Information technology, Office macines, : Software. NAUDOTA LITERATŪRA ISO (International Organization for Standardization, ISO 9126 Software Quality Characteristics. (2009) [žiūrėta 2011 m. gegužės 17 d.]. Prieiga per internetą: < ISO/IEC :2001 Software engineering Product quality Part 1: Quality model Lietuvos standartizacijos departamentas prie Lietuvos Respublikos aplinkos ministerijos STANDARTIZACIJA IR MVĮ, CEN ( CENELEC ( ETSI ( IEC ( IEEE Standards Association ( ITU-T ( BSI ( 30

32 3A.1 Priedas: Sąrašas standartų, kuriuos įsigijusi KTU Programų inžinerijos katedra Programinės įrangos kūrimas ir sistemų aprašymas standartai ISO/IEC :2001 Software engineering Product quality Part 1: Quality model (available in English only) ISO/IEC CD TR Software engineering Product quality Part 2: External metrics ISO/IEC TR 9294:1990 Information technology Guidelines for the management of software documentation ISO/IEC TR 14369:1999 Information technology Programming languages, their environments and system software interfaces Guidelines for the preparation of Language-Independent Service Specifications (LISS) (available in English only) ISO/IEC TR 14471:1999 Information technology Software engineering Guidelines for the adoption of CASE tools (available in English only) ISO/IEC :1999 Information technology Software product evaluation Part 1: General overview (available in English only) ISO/IEC :2000 Software engineering Product evaluation Part 2: Planning and management (available in English only) ISO/IEC :2000 Software engineering Product evaluation Part 3: Process for developers (available in English only) ISO/IEC :1999 Software engineering Product evaluation Part 4: Process for acquirers (available in English only) ISO/IEC :2001 Software engineering Product evaluation Part 6: Documentation of evaluation modules (available in English only) ISO/IEC 14756:1999 Information technology Measurement and rating of performance of computer-based software systems (available in English only) ISO/IEC 14764:1999 Information technology Software maintenance (available in English only) 31

33 3A.2 Priedas: standartų, prieinamų Lietuvos standartizacijos departamento tinklalapyje, Sąrašas PROGRAMINĖS ĮRANGOS KŪRIMAS IR SISTEMŲ APRAŠYMAS (SOFTWARE) standartai (žiūrėta , LST CEN/TS :2006 Sveikatos informatika. Fiziologinių matavimų programinės įrangos testavimas. 1 dalis. Bendrosios nuostatos LST EN A1:2001 Advanced Surface Movement Guidance and Control System (A-SMGCS), Part 1: Community Specification for application under the Single European Sky Interoperability Regulation EC 552/2004 for A-SMGCS Level 1 including external interfaces LST EN V1.1.1:2009 LST EN ISO :2004 Daugialypės terpės vartotojų sietuvų programinės įrangos ergonomika. 2 dalis. Daugialypės terpės navigacija ir valdymas (ISO :2003) LST EN ISO :2003 Daugialypės terpės vartotojų sietuvų programinės įrangos ergonomika. 3 dalis. Informacijos technologijų parinkimas ir jų derinimas (ISO :2002) LST ISO/IEC 38500:2009 Organizacijos informacinių technologijų valdymas (tapatus ISO/IEC 38500:2008) LST ISO/IEC 8631:1995 Informacijos technologija. Programų struktūriniai elementai ir jų vaizdavimo taisyklės LST ISO/IEC 90003:2007 Programinės įrangos inžinerija. ISO 9001:2000 taikymo kompiuterio programinei įrangai rekomendacijos (tapatus ISO/IEC 90003:2004) 32

34 3A.3 Priedas: ISO Standards> By ICS> 35: Information technology. Office machines> : Software Sąrašas prieinamas ISO tinklalapyje, žiūrėta ISO/IEC :1990 Information technology Vocabulary Part 20: System development JTC 1 ISO 3535:1977 Forms design sheet and layout chart JTC 1/SC 7 ISO 5806:1984 Information processing Specification of single-hit decision tables JTC 1/SC 7 ISO 5807:1985 Information processing Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts JTC 1/SC 7 ISO/IEC 6592:2000 Information technology Guidelines for the documentation of computer-based application systems JTC 1/SC 7 ISO/IEC 8211:1994 Information technology Specification for a data descriptive file for information interchange JTC 1 ISO/IEC 8631:1989 Information technology Program constructs and conventions for their representation JTC 1/SC 7 ISO 8790:1987 Information processing systems Computer system configuration diagram symbols and conventions JTC 1/SC 7 ISO/IEC :2001 Software engineering Product quality Part 1: Quality model JTC 1/SC 7 ISO/IEC TR :2003 Software engineering Product quality Part 2: External metrics JTC 1/SC 7 ISO/IEC TR :2003 Software engineering Product quality Part 3: Internal metrics JTC 1/SC 7 33

35 ISO/IEC TR :2004 Software engineering Product quality Part 4: Quality in use metrics JTC 1/SC 7 ISO 9127:1988 Information processing systems User documentation and cover information for consumer software packages JTC 1/SC 7 ISO/IEC TR 9294:2005 Information technology Guidelines for the management of software documentation JTC 1/SC 7 ISO/IEC :1998 Information technology Open Distributed Processing Reference model: Overview JTC 1/SC 7 ISO/IEC :2009 Information technology Open distributed processing Reference model: Foundations JTC 1/SC 7 ISO/IEC :2009 Information technology Open distributed processing Reference model: Architecture JTC 1/SC 7 ISO/IEC :1998 Information technology Open Distributed Processing Reference Model: Architectural semantics JTC 1/SC 7 ISO/IEC :1998/Amd 1:2001 Computational formalization JTC 1/SC 7 ISO/IEC 11411:1995 Information technology Representation for human communication of state transition of software JTC 1/SC 7 ISO/IEC TR 12182:1998 Information technology Categorization of software JTC 1/SC 7 ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes JTC 1/SC 7 ISO/IEC :1998 Information technology Open Distributed Processing Trading function: Specification JTC 1/SC 7 ISO/IEC :1998 Information technology Open Distributed Processing Trading Function Part 3: Provision of Trading Function using OSI Directory service JTC 1/SC 7 34

36 ISO/IEC :1998/Cor 1: JTC 1/SC 7 ISO/IEC 13244:1998 Information technology Open Distributed Management Architecture JTC 1 ISO/IEC 13244:1998/Amd 1:1999 Support using Common Object Request Broker Architecture (CORBA) JTC 1 ISO/IEC 13800:1996 Information technology Procedure for the registration of identifiers and attributes for volume and file structure JTC 1 ISO/IEC 14102:2008 Information technology Guideline for the evaluation and selection of CASE tools JTC 1/SC 7 ISO/IEC :2007 Information technology Software measurement Functional size measurement Part 1: Definition of concepts JTC 1/SC 7 ISO/IEC :2002 Information technology Software measurement Functional size measurement Part 2: Conformity evaluation of software size measurement methods to ISO/IEC : JTC 1/SC 7 ISO/IEC TR :2003 Information technology Software measurement Functional size measurement Part 3: Verification of functional size measurement methods JTC 1/SC 7 ISO/IEC TR :2002 Information technology Software measurement Functional size measurement Part 4: Reference model JTC 1/SC 7 ISO/IEC TR :2004 Information technology Software measurement Functional size measurement Part 5: Determination of functional domains for use with functional size measurement JTC 1/SC 7 ISO/IEC :2006 Information technology Software measurement Functional size measurement Part 6: Guide for use of ISO/IEC series and related International Standards JTC 1/SC 7 ISO/IEC TR 14471:2007 Information technology Software engineering Guidelines for the adoption of CASE tools JTC 1/SC 7 35

37 ISO/IEC :1999 Information technology Software product evaluation Part 1: General overview JTC 1/SC 7 ISO/IEC :2000 Software engineering Product evaluation Part 2: Planning and management JTC 1/SC 7 ISO/IEC :2000 Software engineering Product evaluation Part 3: Process for developers JTC 1/SC 7 ISO/IEC :1999 Software engineering Product evaluation Part 4: Process for acquirers JTC 1/SC 7 ISO/IEC :1998 Information technology Software product evaluation Part 5: Process for evaluators JTC 1/SC 7 ISO/IEC :2001 Software engineering Product evaluation Part 6: Documentation of evaluation modules JTC 1/SC 7 ISO/IEC 14750:1999 Information technology Open Distributed Processing Interface Definition Language JTC 1/SC 7 ISO/IEC 14752:2000 Information technology Open Distributed Processing Protocol support for computational interactions JTC 1/SC 7 ISO/IEC 14753:1999 Information technology Open Distributed Processing Interface references and binding JTC 1/SC 7 ISO/IEC 14756:1999 Information technology Measurement and rating of performance of computer-based software systems JTC 1/SC 7 ISO/IEC TR 14759:1999 Software engineering Mock up and prototype A categorization of software mock up and prototype models and their use JTC 1/SC 7 ISO/IEC 14764:2006 Software Engineering Software Life Cycle Processes Maintenance JTC 1/SC 7 36

38 ISO/IEC 14769:2001 Information technology Open Distributed Processing Type Repository Function JTC 1/SC 7 ISO/IEC 14771:1999 Information technology Open Distributed Processing Naming framework JTC 1/SC 7 ISO/IEC 14834:1996 Information technology Distributed Transaction Processing The XA Specification JTC 1 ISO/IEC 14863:1996 Information technology System-Independent Data Format (SIDF) JTC 1 ISO/IEC 15026:1998 Information technology System and software integrity levels JTC 1/SC 7 ISO/IEC TR :2010 Systems and software engineering Systems and software assurance Part 1: Concepts and vocabulary JTC 1/SC 7 ISO/IEC :2011 Systems and software engineering Systems and software assurance Part 2: Assurance case JTC 1/SC 7 ISO/IEC TR 15271:1998 Information technology Guide for ISO/IEC (Software Life Cycle Processes) JTC 1/SC 7 ISO/IEC 15288:2008 Systems and software engineering System life cycle processes JTC 1/SC 7 ISO/IEC 15289:2006 Systems and software engineering Content of systems and software life cycle process information products (Documentation) JTC 1/SC 7 ISO/IEC 15414:2006 Information technology Open distributed processing Reference model Enterprise language JTC 1/SC 7 ISO/IEC 15437:2001 Information technology Enhancements to LOTOS (E-LOTOS) JTC 1/SC 7 ISO/IEC :2002 Information technology CDIF framework Part 1: Overview JTC 1/SC 7 37

39 ISO/IEC :2002 Information technology CDIF framework Part 2: Modelling and extensibility JTC 1/SC 7 ISO/IEC :2002 Information technology CDIF transfer format Part 1: General rules for syntaxes and encodings JTC 1/SC 7 ISO/IEC :2002 Information technology CDIF transfer format Part 2: Syntax SYNTAX JTC 1/SC 7 ISO/IEC :2002 Information technology CDIF transfer format Part 3: Encoding ENCODING JTC 1/SC 7 ISO/IEC :2002 Information technology CDIF semantic metamodel Part 1: Foundation JTC 1/SC 7 ISO/IEC :2002 Information technology CDIF semantic metamodel Part 2: Common JTC 1/ SC 7 ISO/IEC :2006 Information technology CDIF semantic metamodel Part 3: Data definitions JTC 1/SC 7 ISO/IEC :2005 Information technology CDIF semantic metamodel Part 4: Data models JTC 1/SC 7 ISO/IEC :2006 Information technology CDIF semantic metamodel Part 6: State/event models JTC 1/SC 7 ISO/IEC :2004 Information technology - Process assessment Part 1: Concepts and vocabulary JTC 1/SC 7 ISO/IEC :2003 Information technology Process assessment Part 2: Performing an assessment JTC 1/SC 7 ISO/IEC :2003/Cor 1: JTC 1/SC 7 38

40 ISO/IEC :2004 Information technology Process assessment Part 3: Guidance on performing an assessment JTC 1/SC 7 ISO/IEC :2004 Information technology Process assessment Part 4: Guidance on use for process improvement and process capability determination JTC 1/SC 7 ISO/IEC :2006 Information technology Process Assessment Part 5: An exemplar Process Assessment Model JTC 1/SC 7 ISO/IEC TR :2008 Information technology Process assessment Part 6: An exemplar system life cycle process assessment model JTC 1/SC 7 ISO/IEC TR :2008 Information technology Process assessment Part 7: Assessment of organizational maturity JTC 1/SC 7 ISO/IEC TS :2011 Information technology Process assessment Part 9: Target process profiles JTC 1/SC 7 ISO/IEC :2004 Systems and software engineering High-level Petri nets Part 1: Concepts, definitions and graphical notation JTC 1/SC 7 ISO/IEC :2004/Amd 1:2010 Symmetric Nets JTC 1/SC 7 ISO/IEC :2011 Systems and software engineering High-level Petri nets Part 2: Transfer format JTC 1/SC 7 ISO/IEC 15939:2007 Systems and software engineering Measurement process JTC 1/SC 7 ISO/IEC 15940:2006 Information Technology Software Engineering Environment Services JTC 1/SC 7 ISO/IEC 16085:2006 Systems and software engineering Life cycle processes Risk management JTC 1/SC 7 39

41 ISO/IEC/IEEE 16326:2009 Systems and software engineering Life cycle processes Project management JTC 1/SC 7 ISO/IEC TR 18018:2010 Information technology Systems and software engineering Guide for configuration management tool capabilities JTC 1/SC 7 ISO/IEC 18019:2004 Software and system engineering Guidelines for the design and preparation of user documentation for application software JTC 1/SC 7 ISO/IEC :2003 Information technology Open Distributed Processing Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP) JTC 1/SC 7 ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified Modeling Language (UML) Version JTC 1/SC 7 ISO/IEC TR 19759:2005 Software Engineering Guide to the Software Engineering Body of Knowledge (SWE- BOK) JTC 1/SC 7 ISO/IEC TR 19760:2003 Systems engineering A guide for the application of ISO/IEC (System life cycle processes) JTC 1/SC 7 ISO/IEC 19761:2011 Software engineering COSMIC: a functional size measurement method JTC 1/SC 7 ISO/IEC :2006 Information technology Software asset management Part 1: Processes JTC 1/SC 7 ISO/IEC :2009 Information technology Software asset management Part 2: Software identification tag JTC 1/SC 7 ISO/IEC 19793:2008 Information technology Open Distributed Processing Use of UML for ODP system specifications JTC 1/SC 7 ISO/IEC 19793:2008/Cor 1: JTC 1/SC 7 40

42 ISO/IEC 20926:2009 Software and systems engineering Software measurement IFPUG functional size measurement method JTC 1/SC 7 ISO/IEC 20968:2002 Software engineering Mk II Function Point Analysis Counting Practices Manual JTC 1/SC 7 ISO/IEC 23026:2006 Software Engineering Recommended Practice for the Internet Web Site Engineering, Web Site Management, and Web Site Life Cycle JTC 1/SC 7 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 1: Generic specification JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 2: Specification for IA32 architecture JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 3: Specification for IA64 architecture JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 4: Specification for AMD64 architecture JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 5: Specification for PPC32 architecture JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 6: Specification for PPC64 architecture JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 7: Specification for S390 architecture JTC 1/SC 22 ISO/IEC :2006 Linux Standard Base (LSB) core specification 3.1 Part 8: Specification for S390X architecture JTC 1/SC 22 ISO/IEC 24570:

43 Software engineering NESMA functional size measurement method version 2.1 Definitions and counting guidelines for the application of Function Point Analysis JTC 1/SC 7 ISO/IEC 24744:2007 Software Engineering Metamodel for Development Methodologies JTC 1/SC 7 ISO/IEC 24744:2007/Amd 1:2010 Notation JTC 1/SC 7 ISO/IEC TR :2010 Systems and software engineering Life cycle management Part 1: Guide for life cycle management JTC 1/SC 7 ISO/IEC/IEEE 24765:2010 Systems and software engineering Vocabulary JTC 1/SC 7 ISO/IEC TR 24766:2009 Information technology Systems and software engineering Guide for requirements engineering tool capabilities JTC 1/SC 7 ISO/IEC 24773:2008 Software engineering Certification of software engineering professionals Comparison framework JTC 1/SC 7 ISO/IEC TR 24774:2010 Systems and software engineering Life cycle management Guidelines for process description JTC 1/SC 7 ISO/IEC 25000:2005 Software Engineering Software product Quality Requirements and Evaluation (SQuaRE) Guide to SQuaRE JTC 1/SC 7 ISO/IEC 25001:2007 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Planning and management JTC 1/SC 7 ISO/IEC 25010:2011 Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) System and software quality models JTC 1/SC 7 ISO/IEC 25012:2008 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Data quality model JTC 1/SC 7 ISO/IEC 25020:2007 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Measurement reference model and guide JTC 1/SC 7 42

44 ISO/IEC TR 25021:2007 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Quality measure elements JTC 1/SC 7 ISO/IEC 25030:2007 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Quality requirements JTC 1/SC 7 ISO/IEC 25040:2011 Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Evaluation process JTC 1/SC 7 ISO/IEC 25045:2010 Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Evaluation module for recoverability JTC 1/SC 7 ISO/IEC 25051:2006 Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing JTC 1/SC 7 ISO/IEC 25051:2006/Cor 1: JTC 1/SC 7 ISO/IEC TR 25060:2010 Systems and software engineering Systems and software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for usability: General framework for usability-related information JTC 1/SC 7 ISO/IEC 25062:2006 Software engineering Software product Quality Requirements and Evaluation (SQua- RE) Common Industry Format (CIF) for usability test reports JTC 1/SC 7 ISO/IEC/IEEE 26512:2011 Systems and software engineering Requirements for acquirers and suppliers of user documentation JTC 1/SC 7 ISO/IEC 26513:2009 Systems and software engineering - Requirements for testers and reviewers of user documentation JTC 1/SC 7 ISO/IEC 26514:2008 Systems and software engineering Requirements for designers and developers of user documentation JTC 1/SC 7 ISO/IEC 26702:2007 Systems engineering Application and management of the systems engineering process JTC 1/SC 7 43

45 ISO/IEC :2011 Software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 2: Framework and taxonomy JTC 1/SC 7 ISO/IEC :2011 Software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 4-1: Profile specifications: Generic profile group JTC 1/SC 7 ISO/IEC TR :2011 Software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 5-1-2: Management and engineering guide: Generic profile group: Basic profile JTC 1/ SC 7 ISO/IEC 29881:2010 Information technology Systems and software engineering FiSMA 1.1 functional size measurement method JTC 1/SC 7 ISO/IEC 38500:2008 Corporate governance of information technology JTC 1 ISO/IEC 42010:2007 Systems and software engineering Recommended practice for architectural description of software-intensive systems JTC 1/SC 7 ISO/IEC 90003:2004 Software engineering Guidelines for the application of ISO 9001:2000 to computer software JTC 1/SC 7 ISO/IEC TR 90005:2008 Systems engineering Guidelines for the application of ISO 9001 to system life cycle processes 44

46 4. Inžinerinės ekonomikos pagrindai 4.1. Įžanga Sunku parengti standartinį programų sistemų grupės vadovo pareigybės aprašymą, kadangi jo darbas labai priklauso nuo organizacijos ir nuo kuriamos programų sistemos. Dauguma programų inžinerijos vadovų yra atsakingi už tokias veiklas: Projekto paraiškos (pasiūlymo) rengimas Projekto planavimas ir tvarkaraščio sudarymas Projekto (programinės įrangos) kainos skaičiavimas Projekto stebėsena ir įvertinimas Personalo atranka ir įvertinimas Ataskaitų rengimas ir pristatymas PĮ projekto planavimas apima penkis pagrindinius veiksmus: 1) kainos įvertinimą, 2) tvarkaraščio sudarymą, 3) rizikos analizę, 4) kokybės valdymo planavimą 5) pakeitimų valdymo planavimą. Šiame skyriuje detaliai nagrinėjamas kainos įvertinimas bandymai apibrėžti, kiek pinigų, pastangų, išteklių ir laiko reikia norint sukurti produktą programų sistemą. Išteklių, kaštų ir PĮ inžinerijos pastangų tvarkaraščiui įvertinti reikia patirties, priėjimo prie geros archyvinės informacijos (metrikų) ir drąsos patikėti kiekybinėmis prognozėmis, kai turima tik kokybinė informacija. Vertinimui būdinga rizika, kuri sukelia netikrumo jausmą. Kai išsamios praėjusių projektų PĮ metrikos yra prieinamos, vertinimas gali būti atliktas didesniu patikimumu, tvarkaraščiai gali būti sukurti išvengiant praeities sunkumų ir rizika gali būti mažesnė. Kiekybinių išteklių, kaštų ir tvarkaraščio vertinimo rizika matuojama netikrumo laipsniu. Jei projekto apimtis yra prastai suprantama arba projekto reikalavimai linkę keistis, netikrumas ir vertinimo rizika tampa pavojingai didelė. Klientas turi suprasti, kad PĮ reikalavimų kitimas gali reikšti kaštų ir tvarkaraščio nestabilumą. 45

47 Be šių pagrindinių inžinerijos veiklų, programų sistemų kūrimo specialistai dalyvauja ir organizacijų vadyboje. Organizacinės vadybos aspektai yra svarbūs programų sistemų inžinerijoje, kadangi organizacijos politika ir standartai tai struktūra, kurioje vykdomas programinės įrangos projektavimas. Žmonių ištekliai nustato specifinius organizacijos procesus ar procedūras visam programinės įrangos kūrimo procesui. Tokia politika yra būtina efektyviai ilgalaikei programinės įrangos projektavimo vadybai ir yra pagrindas jai tobulinti. Kitas svarbus valdymo aspektas yra personalo valdymas: įdarbinimo, mokymo ir personalo motyvavimo kelti kvalifikaciją politika bei procedūros. Personalo valdymas svarbus ne tik projekto lygmenyje, bet ir ilgalaikei visos organizacijos sėkmei. Komunikavimo valdymas yra svarbus aspektas atliekant vartotojų poreikių analizę, projekto matavimus. Organizacijos portfelio valdymas yra gebėjimas turėti visa apimančią viziją ne tik apie kuriamą PĮ, bet ir apie jau sukurtą bei naudojamą organizacijoje. PĮ pakartotinis naudojimas yra svarbiausias veiksnys, gerinantis produktyvumą ir konkurencingumą. Efektyvus pakartotinis PĮ komponentų naudojimas neatsiejamas nuo strateginio mąstymo Projekto planavimo uždaviniai Objektyvus PĮ projekto planavimas leidžia vadovams įvertinti išteklius, kaštus ir tvarkaraštį. Vertinant turėtų būti numatyti geriausio ir blogiausio atvejo scenarijai. Planas turi būti pritaikomas ir atnaujinamas vykstant projekto įgyvendinimo procesui. Projekto planavimo uždaviniai yra šie: 1. Apibrėžti projekto apimtį. 2. Nustatyti įgyvendinamumą. 3. Išanalizuoti riziką. 4. Apibrėžti reikiamus išteklius. 5. Apskaičiuoti kaštus ir pastangas. 6. Sukurti projekto tvarkaraštį PĮ apimties apibrėžimas PĮ apimtis aprašo funkcijas ir savybes, kurios turi būti pateiktos galutiniam vartotojui, duomenis, kurie yra įvestyje ir išvestyje, vartotojo pasitenkinimą ir charakteristikas, apribojimus, sąsajas bei patikimumą, privalomą sistemai. Apimtis apibrėžiama naudojantis dviem technikomis: 1. Pasakojamuoju PĮ apimties aprašymu, sukurtu pabendravus su visais suinteresuotais asmenimis. 2. Panaudojimo atvejų rinkiniu. 46

48 Apimties dokumente (arba panaudojimo atvejuose) aprašomos funkcijos yra įvertintos ir patobulintos, norint jas detalizuoti. Kadangi tiek kaštų, tiek tvarkaraščio vertinimai orientuoti į funkcijas, tam tikras detalizavimo laipsnis yra naudingas. Charakteristikos apima vykdymo ir atsakymo laikų reikalavimus. Apribojimai nusako PĮ ribas, nustatomas išorinės techninės įrangos, prieinamos atminties ar kitos egzistuojančios sistemos Projekto įgyvendinamumo nustatymas Ne viskas, kas įsivaizduojama, yra įgyvendinama. PĮ įgyvendinimas turi keturis tvirtus aspektus: technologiją ar projektas technologiškai įgyvendinamas? finansus ar daug finansų pareikalavęs projektas atsipirks klientui ir bus priimtinas rinkos kainomis? laiką ar projektas bus pagamintas tuo metu, kai galės konkuruoti rinkoje? išteklius ar firma turi išteklių, reikalingų tikslui pasiekti? Kai apimtis apibrėžta, PĮ komanda ir kiti suinteresuoti asmenys turi nustatyti, ar projektas gali būti įgyvendintas, įvertinus šiuos keturis aspektus. Tai yra lemiama, nors dažnai praleidžiama, įvertinimo proceso dalis Išteklių įvertinimas Antrasis planavimo uždavinys yra išteklių, reikalingų PĮ kurti, įvertinimas. Įgūdžiai Skaičius PĮ įrankiai Techninė įranga Vieta Žmonės Aplinka Tinklo ištekliai Projektas Užbaigti Visos patirties Pakartotinio naudojimo programinės įrangos komponentai Dalinės patirties Nauji 4.1 pav. Programų sistemų inžinerijos išteklių kategorijos 47

49 4.1 pav. vaizduoja tris pagrindines PĮ inžinerijos išteklių kategorijas: žmones, pakartotinio naudojimo komponentus ir kūrimo aplinką (techninės ir programinės įrangos priemones). Kiekvienas išteklius apibūdintas keturiomis charakteristikomis: aprašu, prieinamumu, laiku, kada išteklius bus reikalingas, ir trukme, kiek jis bus naudojamas. Žmonių ištekliai Pirmiausia planuotojas apskaičiuoja PĮ apimtį ir numato, kokių įgūdžių reikės kuriant PĮ. Taip pat nustatomos organizacinės pozicijos (pvz., vadovas, vyresnysis PĮ inžinierius) ir specializacija (pvz., telekomunikacijos, duomenų bazės, kliento/serverio sistema). Mažuose projektuose (kuriuose dalyvaus keli žmonės arba kuris truks trumpai laiko atžvilgiu) vienas žmogus gali atlikti visus PĮ uždavinius, jei reikia, konsultuodamasis su specialistais. Didelių projektų komanda geografiškai gali būti išsidėsčiusi skirtingose vietose. Tokiu atveju kiekvieną tokią vietą reikia apibrėžti. Žmonių, dalyvausiančių PĮ projekte, skaičius gali būti apibrėžtas tik įvertinus kūrimo pastangas. Pakartotinio naudojimo PĮ ištekliai Komponentais grįsta PĮ inžinerija remiasi programinės įrangos komponentų kūrimu ir jų pakartotiniu naudojimu. Komponentai turi būti kataloguojami lengvomis nuorodomis, standartizuojami paprastoms taikomosioms programoms ir patvirtinami, kad juos būtų lengva integruoti. Keturios PĮ išteklių kategorijos, kurios turėtų būti aptartos planavimo etape: Pagaminti komponentai. Užbaigta programinė įranga gali būti perkama iš trečiosios šalies arba gali būti sukurta pačioje firmos, vykdant ankstesnius projektus. Komercinių užbaigtų programų komponentai perkami iš trečiosios šalies, jie yra paruošti naudoti esamame projekte ir visiškai atestuoti. Visiškos patirties komponentai. Jau egzistuojančių specifikacijų, dizaino, kodo ar testavimo duomenų kūrimas ankstesniems projektams vyko panašiai kaip ir kuriant dabartinį PĮ projektą. Todėl dabartinio PĮ kūrimo projekto komandos nariai gali remtis ankstesnės taikomosios programos, kurią sudaro tie komponentai, kūrimo patirtimi. Tokiu atveju tokių visiškos patirties komponentų keitiniai bus mažai rizikingi. Dalinės patirties komponentai. Jau egzistuojančių specifikacijų, dizaino, kodo ar testavimo duomenų kūrimas ankstesniems projektams yra susijęs su dabartinio projekto PĮ kūrimu ir pareikalaus didelių pakeitimų. Dabartinės PĮ komandos nariai turi tik dalinę patirtį taikomosios programos, kurią sudaro tie komponentai, srityje. Todėl pakeitimai, reikalingi dalinės patirties komponentams, gali turėti bauginantį rizikos laipsnį. Nauji komponentai. PĮ komponentai turi būti sukurti specialiai pagal esamo projekto poreikius. Aplinkos ištekliai Aplinka, dažnai vadinama PĮ inžinerine aplinka, apima techninę ir programinę įrangą. 48

50 Techninė įranga lemia platformą, kuri palaiko įvairius PĮ įrankius, reikalingus produktams sukurti. Daugelis klientų nori turėti priėjimą prie PĮ inžinerinės aplinkos, taigi projekto planuotojas turi nurodyti, kokia techninė ir programinė įranga bus naudojama kūrimo procese, ir patvirtinti, kokie ištekliai bus prieinami. Kita techninė įranga tikslo aplinka tai galutinio naudotojo kompiuteris(-ai), kuriame bus vykdoma sukurtoji PĮ. Kai kompiuterinė sistema yra kuriama, PĮ komandai gali prireikti prieiti prie aparatūrinės įrangos elementų, kuriamų kitų inžinerinių grupių. Pvz., PĮ patobulintam puslapių išdėstymo projektui gali reikėti aukštos kokybės spausdintuvo. Kiekvienas aparatūrinės įrangos elementas turi būti specifikuotas PĮ projekto kaštų įvertinimas Norint atlikti patikimą PĮ projekto kaštų ir pastangų įvertinimą, rekomenduojama: 1. Užlaikyti įvertinimus iki vėlesnio projekto etapo (savaime aišku, kad baigus projektą, įvertinimų tikslumas būtų 100 %). Deja, tai neįgyvendinama, nes kaštai turi būti įvertinti prieš pradedant projektą. Tačiau kuo ilgiau lauksime, tuo daugiau sužinosime, ir tai leis išvengti rimtų įvertinimo klaidų. 2. Remtis panašių užbaigtų projektų įvertinimu. geraitis punktas tiks, jei esamas projektas yra labai panašus į ankstesnįjį ir to projekto pastangos bei kiti lemiami veiksniai (pvz., PĮ komanda, klientas, verslo sąlygos, PĮ inžinerinė aplinka) yra beveik tie patys. 3. Vertinant projekto kaštus ir pastangas taikyti paprastą skaidymo (angl. decomposition) metodiką. 4. Naudoti keletą patikrintų modelių PĮ kaštams ir pastangoms įvertinti. Projekto kainą sudaro: techninės įrangos kaina ir kelionių bei pasiruošimo išlaidos, taip pat užmokestis personalui. Dominuoja personalo darbo užmokesčio išlaidos. Jas sunkiausia apskaičiuoti ir kontroliuoti. Šiame skyriuje daugiausia ir bus kalbama apie darbo užmokesčio apskaičiavimą. Be to, reikia įvertinti ir papildomas išlaidas, kurias sudaro: biuro komunaliniai mokesčiai (nuoma, šildymas, elektra, vanduo ir t. t.); pagalbinio personalo (buhalteriai, sekretorės, valytojai, technikai) algos. Vakaruose laikoma, kad papildomos išlaidos yra maždaug lygios personalo išlaidoms. Bendru atveju projekto kaina tai projekto išlaidos plius pelnas, tačiau apskaičiuojant projekto kainą reikia įvertinti gerokai daugiau veiksnių. Kai kurie veiksniai, į kuriuos reikėtų atsižvelgti įvertinant projekto kainą, pateikti 4.1 lentelėje. 49

51 4.1 lentelė. Projekto kainai įtakos turintys veiksniai Veiksnys Rinkos išplėtimas Neaiškumai įvertinant kainą Kontrakto sąlygos Reikalavimų nepastovumas Finansiniai sunkumai Aprašymas Projektuojanti organizacija gali pasiūlyti žemą kainą, kad užimtų naują nišą PĮ rinkoje, kas gali atnešti didesnį pelną ateityje, arba kad įgijusi patirties po to sėkmingai gamintų panašaus profilio produktus. Dėl netikrumo įvertinant kainą, padidinamas pelno procentas. Užsakovas gali leisti projektuotojui naudoti išeities kodą. Tuo atveju, kai šis kodas tinkamas for reuse, kaina gali būti sumažinama. Matant, kad reikalavimai gali keistis, projektuojančioji organizacija gali pasiūlyti žemesnę kainą siekdama gauti kontraktą. Gavus kontraktą, galima padidinti keičiamų reikalavimų kainą. Galima sumažinti kainą siekiant gauti kontraktą. Geriau jau mažesnis nei normaliai pelnas negu kontraktų nebuvimas ar dar blogiau bankrotas. Įvairūs kainos apskaičiavimo metodai remiasi arba strategija iš viršaus žemyn, arba strategija iš apačios aukštyn. Strategijos iš viršaus žemyn atveju kaina pradedama skaičiuoti sisteminiu lygiu įvertinant bendrą produkto funkcionalumą. Taip pat atsižvelgiama į tokią sisteminio lygio veiklą kaip integravimas, konfigūracijos valdymas ir dokumentavimas. Ir priešingai, taikant strategiją iš apačios aukštyn kaina pradedama skaičiuoti komponentiniu lygiu. Sistema yra dekomponuojama į komponentus ir apskaičiuojamos sąnaudos, kurių reikia projektuojant kiekvieną komponentą. Paskui tos kainos sudedamos ir gaunama bendra sistemos kaina. Vienos strategijos privalumai yra kitos trūkumai, ir atvirkščiai. Pagal strategiją iš viršaus žemyn, galima neteisingai įvertinti kai kurių specifinių komponentų, pvz., realizuojančių sąsają su nestandartine aparatūra, kainą. O pagal strategiją iš apačios aukštyn, galima neteisingai įvertinti sisteminio lygio veiklos, pvz., integracijos, kainą. Be to, strategija iš apačios aukštyn yra brangesnė, nes jai reikia turėti pradinę sistemos architektūrą siekiant identifikuoti įvertinamus komponentus. 4.2 lentelėje pateikti kainos apskaičiavimo metodai ir trumpas jų aprašymas. 4.2 lentelė. Projekto kainos skaičiavimo metodų santrauka Metodas Įvertinimas pagal analogą Ekspertų įvertinimas Pagal biudžetą (Pricing to win) Algoritminis kainos modeliavimas Parkinsono dėsnis Aprašymas Metodas taikomas tada, kai organizacijoje jau buvo vykdyti keli projektai iš tos pačios taikomosios srities. Naujo projekto kaina apskaičiuojama pagal analogą. Kiekvienas ekspertas apskaičiuoja projekto kainą. Apskaičiuotos kainos yra palyginamos ir aptariamos. Įvertinimo procesas iteruoja, kol pasiekiamas bendras sutarimas dėl projekto kainos. Kaina nustatoma pagal tai, kiek užsakovas gali mokėti už produktą. Taigi kaina priklauso nuo užsakovo biudžeto, o ne nuo projektuojamos sistemos funkcionalumo. Modeliai sudaromi pagal ankstesnių projektų informaciją, remiantis PĮ metrikomis (dažniausiai dydžiu). Įvertinus šias metrikas, modelis leidžia apskaičiuoti projekto sąnaudas. Parkinsono dėsnis teigia, kad darbas išsiplečia, kad užimtų prieinamą laiką. Kaina yra apibrėžiama pagal prieinamus šaltinius, bet ne pagal objektyvų įvertinimą. Jei PĮ turi būti sukurta per 12 mėnesių ir yra prieinami 5 darbuotojai, tai darbo sąnaudos yra vertinamos 60 žmogaus mėnesių (Sommerville, 2007). 50

52 Įvertinimas pagal analogą Daugelyje organizacijų PĮ kainos įvertinimas remiasi ankstesne patirtimi, o tai reiškia, kad vykdant projektus reikia rinkti įvairius duomenis, kad vėliau galima būtų jais remtis. Pavyzdys. Reikia suprojektuoti procesų kontrolės sistemą, panašią į tą, kuri buvo sukurta praėjusiais metais per 10 mėnesių ir kainavo 1 mln. dol. Nauja sistema turi kontroliuoti ~25 % daugiau procesų, taigi ~25 % turėtų padidėti naujos sistemos kaina ir projektavimo laikas. Ankstesnė sistema buvo pirma tokio tipo sistema, suprojektuota organizacijoje; daugelį žmonių bus galima pakviesti iš ankstesnio projekto tai leis sumažinti kainą ~20 %. Be to, bus galima panaudoti kai kuriuos ankstesnės sistemos modulius tai turėtų sutrumpinti laiką ir sumažinti kainą ~25 %. Taigi gauname, kad lyginant su buvusiu projektu galima ~ 20 % sumažinti laiko ir išlaidų sąnaudas, t. y. naujo projekto kaina turėtų būti dol., o projektavimo laikas 8 mėn. Žinoma, kad užsakovas gali mokėti 1 mln. dol., jei sistema bus padaryta per 1 metus, taigi pritaikę nedidelį saugumo koeficientą, užsakovui siūlome tokias sąlygas: kaina dol., vykdymo laikas 9 mėnesiai. Šio metodo teigiamas aspektas patirtis, bet tai gali būti ir silpnoji vieta. Ekspertas(-ai) gali nepastebėti kai kurių veiksnių, dėl kurių naujas projektas reikšmingai skiriasi nuo ankstesniojo, arba ekspertai gali neturėti šios taikomosios srities projektų patirties. To galima išvengti, jei ekspertų grupė parengs konsensusu paremtus apskaičiavimus. Silpnoji vieta grupėje gali būti dominuojanti asmenybė Ekspertų įvertinimas (Delfi metodas) Plačiausiai taikomas PĮ kainos apskaičiavimo metodas yra ekspertų įvertinimas, kuris daugiausia remiasi vieno ar kelių žmonių patirtimi ir verslo intuicija. Delfi metodas sukurtas 1948 m. (angl. Rand corporation). Jo esminiai punktai: 1. Koordinatorius kiekvienam ekspertui pateikia sistemos apibrėžimo dokumentą. 2. Ekspertai atlieka anonimišką įvertinimą. Jie gali klausinėti koordinatorių, tačiau negali diskutuoti tarpusavyje. 3. Koordinatorius parengia ir išdalija ekspertams jų atsakymų santrauką ir ją papildo ekspertų pastebėtais neįprastais projekto momentais. 4. Ekspertai, naudodamiesi praėjusio įvertinimo rezultatais, vėl anonimiškai parengia naują įvertinimą. Ekspertai, kurių apskaičiavimai labai skiriasi nuo vidurkio, gali būti paprašyti (anonimiškai) pagrįsti savo išvadas. 5. Iteracijų skaičius neribojamas. Viso proceso metu yra draudžiamos grupinės diskusijos. Galimos įvairios šio metodo variacijos, pvz., po kiekvienos iteracijos aptariamos ir diskutuojamos grupėje iškilusios problemos. 51

53 Daug organizacijų taiko kelis PĮ kainos apskaičiavimo metodus ir vykdo iteracijas tol, kol išsprendžiami esminiai skirtumai. Apskaičiuodami projekto kainą, vadybininkai turi įvertinti, kad yra didelių skirtumų tarp praeities ir ateities projektų. Per pastaruosius metus labai daug kas pasikeitė, o daugelis vadybininkų yra menkai susipažinę su naujovėmis ir tuo, kaip jos veikia projekto kainą. Žemiau pateikti kai kurie pasikeitimai, kurie gali daryti įtaką kainos įvertinimui, paremtam patirtimi: objektiškai orientuotas projektavimas vietoje funkcinio projektavimo; kliento serverio sistemos vietoje didelių (angl. mainframe) kompiuterių; projektavimas for reuse ir with reuse ; CASE priemonių naudojimas. Šie kainos apskaičiavimo metodai taikytini tada, kai turimas sistemos reikalavimų dokumentas. Tačiau daugeliu atvejų kainą reikia apskaičiuoti tik apytiksliai žinant reikalavimus sistemai (tik žinant reikalavimų metmenis). Reikalavimų analizė ir specifikavimas yra brangus procesas, todėl įmonės vadovybė gali nenorėti tam leisti pinigų dar negavusi kontrakto. Tokiomis aplinkybėmis dažnai taikomas pricing to win metodas Užsakovo kaina PĮ kaina nustatoma pagal tai, kiek užsakovas gali užmokėti už projektą (angl. pricing to win). Taigi darbo sąnaudos priklauso ne nuo PĮ funkcijų, bet nuo užsakovo biudžeto. Nors toks vertinimas gali atrodyti neetiškas, bet tikrovėje jis gana dažnai pasitaiko. Dėl projekto kainos yra susitariama remiantis pasiūlymo metmenimis. Vėliau, derantis su užsakovu, sudaroma detali projekto specifikacija. Ši specifikacija yra ribojama sutartos kainos, ir pirkėjas bei pardavėjas privalo suderinti priimtiną sistemos funkcionalumą. Taigi daugelyje projektų fiksuotas veiksnys yra ne reikalavimų specifikacija, o kaina. Reikalavimai gali būti keičiami tam, kad projektas neviršytų nustatytos kainos Algoritminis kainos modeliavimas Labiausiai moksliškas, nors nebūtinai tiksliausias, PĮ kainos nustatymo metodas yra algoritminis kainos modeliavimas. Tokių modelių yra keletas. Mohanty suskaičiavo hipotetinės PĮ kainą, remdamasis įvairiais modeliais. Kraštutiniai įvertinimai buvo dol. ir dol. Daugelis algoritminių modelių turi eksponentinį komponentą, atspindintį faktą, kad kaina priklausomai nuo projekto dydžio didėja netiesiškai. Tai susieta su tuo, kad didėjant projektui reikia papildomų sąnaudų dėl didėjančio komunikavimo, sudėtingesnio konfigūracijos valdymo, sunkesnės integracijos ir t. t. Bendriausia forma kaina (sąnaudos) yra išreiškiama tokia formule: Sąnaudos = A*Dydis B *M 52

54 A konstanta, priklausanti nuo projektuojamos PĮ tipo ir projektuojančios organizacijos ypatumų; Dydis išreikštas kodo eilutėmis arba funkciniais ar objektiniais taškais; B konstanta, dažniausiai tarp 1 1,5, rodanti eksponentinę sąnaudų priklausomybę nuo sistemos dydžio, M daugiklis, gautas analizuojant įvairius proceso ir projekto atributus. Pagrindiniai algoritminių modelių minusai: 1. Ankstyvoje stadijoje labai sunku įvertinti projekto dydį. 2. Konstantų A, B ir M dydžiai yra subjektyvūs, priklausomi nuo vertintojo patirties ir pasiruošimo Bazinis COCOMO modelis Pagrindiniai veiksniai, apibrėžiantys PĮ kainą: 1. Programuotojų sugebėjimai. 2. Produkto sudėtingumas. 3. Produkto dydis. 4. Turimas laikas. 5. Reikalaujamas patikimumas. 6. Technologijos lygis. COCOMO (Constructive Cost Model) modelis sukurtas 1981 m., dar žymimas kaip COCOMO81, nauja COCOMO versija, sudaryta 1995 m. ir vadinama COCO- MO2. Bazinis COCOMO81 modelis (dar yra tarpinis ir detalusis modeliai) remiasi tik PĮ projekto dydžiu ir projektuojamos PĮ tipu (sudėtingumu). Jis apima visus PĮ gyvavimo ciklo etapus, išskyrus planavimą ir analizę, t. y. analizės ir planavimo darbo sąnaudos turi būti apskaičiuotos atskirai. Produkto sudėtingumas Bendrai pripažinti produkto sudėtingumo lygiai yra trys: 1. Taikomosios programos (TP); 2. Serviso programos (SP); 3. Sisteminio lygio programos (SLP). Brooks teigia, kad sudėtingumo santykis tarp aukščiau minėtų kategorijų yra ~1/3/9. Darbo sąnaudų apskaičiavimas Boehm pateikia formules, pagal kurias apskaičiuojamos bendros darbo sąnaudos, išreikštos programuotojų mėnesiais (PM): PM=2,4*(KKE**1,05); TP PM=3,0*(KKE**1,12); SP PM=3,6*(KKE**1,20); SLP Jei turime dydžio programą, tai gauname tokį reikalingų PM santykį: 1/1,7/2,8. 53

55 Šie įvertinimai yra ne geresni, nei Jūsų sugebėjimas apskaičiuoti (įvertinti) KE skaičių projektuojamoje sistemoje. Dažnai pasitaikanti klaida apskaičiuojant KE skaičių yra per menkas reikalingų aptarnaujančių programų (įvedimas/išvedimas, sąsaja, klaidų kontrolė) įvertinimas. Jos dažnai sudaro >50 %, o kartais net 90 % KE skaičiaus. Lengviau įvertinti kodo, reikalingo skaičiavimams vykdyti, dydį. Projekto vykdymo laiko apskaičiavimas Bazinis COCOMO modelis taip pat siūlo formules, pagal kurias apskaičiuojamas projekto vykdymo laikas (PVL): PVL=2,5*(PM**0,38); TP PVL=2,5*(PM**0,35); SP PVL=2,5*(PM**0,32); SLP Pavyzdžiui, planuojamas projektuojamos sistemos (dydis) yra KE, tada PM=2,4*(32**1,05)=91 progr. mėn; PVL=2,5*(91**0,38)=14 mėn. Reikia atkreipti dėmesį, kad projekto vykdymo laikas yra funkcija, priklausanti nuo sąnaudų, o ne nuo asmenų, dirbančių su projektu, skaičiaus. Tai tik patvirtina nuomonę, kad panaudojus daugiau žmonių vėluojančiame projekte, jo grafikas nebūtinai bus atstatytas. Putnam teigia, kad projektavimo grafikas negali būti suspaustas žemiau kaip 86 % lygio lyginant su optimaliu grafiku, o toks grafiko suspaudimas reikalauja 1,82 karto padidinti žmonių, dirbančių su projektu, skaičių. Boehm nuomone, grafiką galima suspausti iki 75 %. Dažniausiai projekto vykdymo laiko sumažinimas sukelia projekto kainos padidėjimą. Reikiamo personalo lygio apskaičiavimas Personalo, reikalingo projektui vykdyti, skaičius nėra pastovus, t. y. PĮ inžinierių skaičius įvairiuose etapuose yra skirtingas, todėl negalima formulės ŽSK=PM/PVL taikyti tiesiogiai. Dažniausiai planavimą ir analizę atlieka maža grupė žmonių, architektūrinį projektavimą didesnė (bet vis dar maža), detalų projektavimą dar didesnė, o didžiausias personalo kiekis reikalingas realizavimo ir sisteminio testavimo etapuose. Ankstyva palaikymo fazė taip pat gali reikalauti gausaus žmonių kiekio, bet jų skaičius per trumpą laiką turi sumažėti Tarpinis COCOMO modelis Bazinis COCOMO modelis yra išeities taškas įvertinant projekto kainą, tačiau, kaip minėta, greta projekto dydžio ir tipo (sudėtingumo) yra daug veiksnių, veikiančių projekto sąnaudas. Pagrindinius iš jų įvertina tarpinis COCOMO modelis. 54

56 Įvairūs atributai yra taikomi skaičiams, gautiems panaudojus bazinį COCOMO modelį. Šie koeficientai leidžia (bando) įvertinti veiksnius, tokius kaip reikalaujamas produkto patikimumas, duomenų bazės dydis, vykdymo laiko ir atminties apribojimas, personalo sugebėjimai ir t. t. Boehm aprašo net 15 tokių veiksnių. Juos suskirsto į keturias klases: 1. Produkto atributai; 2. Kompiuterio atributai; 3. Personalo atributai; 4. Projekto atributai. Atributų skalė yra nuo labai žemos koeficiento reikšmės iki labai aukštos. Produkto atributai 1. Patikimumas. PĮ patikimumą galima apibrėžti kaip tikimybę, kad programa atliks reikiamą funkciją per nustatytą laiko periodą esant nustatytoms sąlygoms. 4.3 lentelėje pateikti projektavimo sąnaudų koeficientai pagal patikimumo lygį. 4.3 lentelė. Projektavimo sąnaudų koeficientai pagal patikimumo lygį Kategorija Gedimo poveikis Sąnaudų koeficientas Labai žemas Maži nepatogumai 0,75 Žemas Nuostoliai lengvai atstatomi 0,88 Nominalus Vidutiniškai sunku atstatyti nuostolius 1,00 Aukštas Dideli finansiniai nuostoliai 1,15 Labai aukštas Pavojus žmogaus gyvybei 1,40 Taigi sąnaudų santykis, realizuojant programą labai žemu ir labai aukštu patikimumu, yra 1,87 (1,4/0,75). 2. Duomenų bazės dydis. Koeficientas <1, jei DB dydis baitais yra mažiau nei 10 kartų didesnis už PŠ produkto dydį, išreikštą kodo eilutėmis. Koeficientas lygus 1, jei DB kartų didesnė nei PĮ produktas, ir koeficientas >1, jei DB daugiau nei 100 kartų didesnė nei PĮ produktas. Kraštutinė reikšmė, kai DB >1000 kartų didesnė. 3. Sudėtingumas Kompiuterio atributai Vykdymo laiko apribojimai. Nominali reikšmė reiškia, kad išnaudojama mažiau kaip 50 % turimo vykdymo laiko, ypač aukšta išnaudojama >=95 % turimo vykdymo laiko. Atminties apribojimai. Nominali reikšmė reiškia, kad išnaudojama mažiau kaip 50 % turimos atminties, ypač aukšta išnaudojama >=95 % turimos atminties. Virtualios mašinos pastovumas. Virtuali mašina tai techninės ir programinės įrangos kombinacija, su kurios pagalba kuriamas PĮ produktas. Žema koeficiento reikšmė reiškia, kad VM keičiasi retai (~kartą per metus), nominali kartą per pusmetį, o aukšta dažniau. Personalo atributai: analitiko sugebėjimai; patirtis taikomojoje srityje; virtualios mašinos patirtis; programuotojo sugebėjimai; programavimo kalbos patirtis. Visi aukščiau nurodyti atributai daugiausia remiasi darbo stažu. Nominali koeficiento reikšmė mažiausiai 1-erių metų patirtis, labai aukšta reikšmė (koeficientas <1) >3-ejų metų patirtis, labai žema reikšmė mažai arba jokios patirties. 55

57 Projekto atributai: PĮ priemonių naudojimas; projekto darbų grafikas. Projekto grafiko atributas yra itin svarbus. Tiek suspaustas, tiek išplėstas darbų grafikas reiškia koeficiento reikšmes >1. Nominali reikšmė (=1) atitinka darbų trukmę, apskaičiuotą pagal COCOMO modelį. Sąnaudų koeficientai pagal COCOMO modelį pateikti 4.4 lentelėje. 4.4 lentelė. Projektavimo sąnaudų koeficientai pagal COCOMO modelį Atributai Koeficientų reikšmės Produkto atributai Patikimumas 0,75 1,40 Duomenų bazės dydis 0,94 1,16 Sudėtingumas 0,70 1,65 Kompiuterio atributai Vykdymo laiko apribojimai 1,00 1,66 Atminties apribojimai 1,00 1,56 Virtualios mašinos pastovumas 0,87 1,30 Personalo atributai Analitiko sugebėjimai 1,46 0,71 Patirtis taikomojoje srityje 1,29 0,82 Virtualios mašinos patirtis 1,21 0,90 Programuotojo sugebėjimai 1,42 0,70 Programavimo kalbos patirtis 1,14 0,95 Projekto atributai Modernų projektavimo metodų taikymas 1,24 0,82 PĮ priemonių naudojimas 1,24 0,83 Projekto darbų grafikas 1,23 1,00 Tiek bazinio, tiek tarpinio modelio problema yra ta, kad jie kuriamą PĮ produktą traktuoja kaip pavienį objektą ir taiko koeficientus jam kaip visumai. Iš tikrųjų ypač didelės sistemos nėra homogeniškos. Visas arba detalus COCOMO modelis į tai atsižvelgia ir apskaičiuoja bendrą sistemos kainą kaip posistemių kainų, apskaičiuotų atskirai, sumą. Kita problema, kad yra laikoma, jog atskiri koeficientai yra tarpusavyje nepriklausomi, nors realybėje taip nėra, nors ir nelabai aišku, kaip paskirų veiksnių variacijos veikia kitus veiksnius. Išvada Nepaisant visų COCOMO modelio trūkumų ir netikslumų, jis ypač gerai tinka variantų analizei, t. y. kai vadybininkas turi galimybę išanalizuoti įvairius variantus ir pasirinkti, jo nuomone, optimalų. Nors absoliutūs skaičiai ir nėra itin tikslūs, bet tarpinis ar detalus COCOMO modelis įgalina santykinai palyginti variantus. 4.5 lentelėje kaip pavyzdys pateiktas kelių koeficientų poveikis sąnaudų įvertinimui. 56

58 4.5 lentelė. Pavyzdys: projektavimo sąnaudų variantų įvertinimas Sistemos tipas Sistemos dydis Bazinis COCOMO įvertinimas Reikalaujamas patikimumas Sudėtingumas Atminties apribojimai PĮ priemonių naudojimas Darbų grafikas Tarpinis COCOMO įvertinimas Reikalaujamas patikimumas Sudėtingumas Atminties apribojimai PĮ priemonių naudojimas Darbų grafikas Tarpinis COCOMO įvertinimas SLP KE 1216 PM Labai aukštas, koef. = 1,4 Aukštas, koef. = 1,3 Aukštas, koef. = 1,2 Žemas, koef. = 1,1 Suspaustas, koef. = 1, PM Labai žemas, koef. = 0,75 Labai žemas, koef. = 0,7 Jokių, koef. = 1,0 Aukštas, koef. = 0,9 Normalus, koef. = 1,0 575 PM NAUDOTA LITERATŪRA Maylor, H., Project Management, PrenticeHall, Pressman, R., S Software Engineering: A practioner s Approach, 6th edition, McGrow Hill Higher Education, Brooks, Jr., Frederick P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975 (Reprinted with corrections, January 1982).Sommerville, I., Software Engineering, Addison-Wesley,

59 5. Rizikos ir neapibrėžtumo sprendimai 5.1. Rizika ir neapibrėžtumas projekte Charette išskiria tokias rizikos kaip koncepcijos ypatybes: 1. rizika liečia ateitį (mūsų nedomina tai, kas vyko praeityje ar kas vyksta dabar, nes to nebegalime pakeisti. Tačiau keisdami savo elgesį dabartyje, galime tikėtis geresnių rezultatų ateityje); 2. planuojami pokyčiai: nuomonės, veiksmų ir t. t.; 3. rizika neišvengiamai susijusi su pasirinkimo galimybe ir kartu su neapibrėžtumu, kurį ta galimybė lemia (Charette, 1996). Rizika tai tikimybė, kad tam tikromis aplinkybėms nepalankus (neigiamai veikiantis projektą) įvykis gali realiai atsitikti. Kaip projekto gyvavimo laike kinta rizikos ir neapibrėžtumų įtaka, pavaizduota 5.1 pav. (ASQH). 5.1 pav. Rizikos ir neapibrėžtumų bei tarpininkų įtakos laipsnis projekto laike (ASQH) Esminės rizikos komponentės yra: Grėsmė (angl. Threat) aplinkybė, turinti potencialą sukelti nuostolius. 58

60 Pasekmė (angl. Consequence) žala arba nuostoliai, kurie įvyks, kai grėsmė realizuosis. Analizuojant programinės įrangos projekto riziką, labai svarbu tinkamai įvertinti šias kiekvienos rizikos charakteristikas, t. y. kiek tikėtina kiekviena rizika ir, jei ji įvyktų, kokias pasekmes tai turėtų nagrinėjamam projektui. Sukurta keletas rizikos valdymo tarptautinių standartų (ISO 31000) ir žodynas (ISO/IEC Guide 73:2009) Projekto rizikų valdymo procesas Rizikos valdymas tai galimos rizikos nustatymas ir planų, kurie minimizuotų rizikos poveikį projektui, sudarymas. Pagal projektų valdymo instituto (PMI) teoriją, rizikos valdymo procesą sudaro tokios veiklos: Rizikų valdymo planavimas. Rizikų identifikavimas. Kokybinė rizikų analizė (angl. Qualitative Risk Analysis). Kiekybinė rizikų analizė (angl. Quantitative Risk Analysis). Atsako į rizikas planas. Rizikų stebėjimas ir kontrolė. Rizikos valdymo schema parodyta 5.2 paveiksle. Rizikos identifikavimas Rizikos analizė Rizikos planavimas Rizikos stebėjimas Galimos rizikos sąrašas Rizikos prioritetų sąrašas Rizikos išvengimo ir galimų atsitiktinumų sąrašas Rizikos įvertinimas 5.2 pav. Rizikos valdymo schema Pirmasis žingsnis bandant suvaldyti riziką sudaryti rizikų sąrašą. Naudinga rizikas klasifikuoti. Presman rekomenduoja rizikas skirstyti į bendrąsias (angl. generic) ir specifines (angl. product-specific). Bendrosios rizikos tai dalykai, potencialiai keliantys grėsmę bet kokiam programinės įrangos projektui. Pavyzdžiui, kuriamo produkto dydis, biudžeto, laiko ribos, komandos narių patirtis ir t. t. Atpažinti bendrąsias rizikas nėra sudėtinga internete 59

61 galima rasti daug įvairiausių tokių rizikų sąrašų (angl. risk item check-lists), kurį belieka peržiūrėti ir atmesti tai, kas konkrečiam projektui neaktualu. Tačiau jei Jūsų rizikų plane yra tik bendrosios rizikos, yra blogai. Tuo tarpu specifinės rizikos apima potencialias problemas, kylančias konkrečiam projektui. Jas įvardyti gali tik projekto komandos nariai, bandydami atsakyti į klausimą, kokios šiam produktui būdingos charakteristikos gali kelti grėsmę mūsų projektui? (Presman, 2007). Bareiša ir kt. rekomenduoja riziką skirstyti į tris kategorijas: projekto rizika turi įtakos grafikui arba ištekliams; produkto (techninė) rizika turi įtakos kuriamos PĮ kokybei; verslo rizika turi įtakos PĮ platinimui. Projekto rizikos kelia grėsmę numatytam projekto biudžetui ir skirtam laikui. Pavyzdys galėtų būti nepakankamas komandos dydis ar per didelis reikalavimų kitimas. 5.1 lentelėje pateikti galimos projekto rizikos aprašymai. Techninės rizikos apima technologinius klausimus (pavyzdžiui, sąsajų nesuderinamumas, sistemos palaikymo sudėtingumas ir t. t.) ir gali turėti visai nedidelę ar net katastrofišką įtaką projektui, priklausomai nuo to, kiek svarbią kuriamo produkto dalį šios problemos liečia. Verslo rizikos apima tokius klausimus kaip Ar sukurtas produktas bus paklausus?, Ar pasikeitus įmonės ilgalaikei strategijai projektas nebus paliktas likimo valiai? ir panašiai. Akivaizdu, kad verslo rizikos kelia grėsmę visam projektui ir turėtų sulaukti tinkamo dėmesio. 5.1 lentelė. Galimos projekto rizikos aprašymai (Bareiša ir kt.) Rizika Rizikos kategorija Aprašymas Personalo kaita Projekto Patyręs personalas paliks projektą iki projekto pabaigos Vadybininkų kaita Projekto Pasikeis projekto organizacinė struktūra Nėra techninės įrangos Projekto Reikalinga projektui aparatūra nepristatyta pagal grafiką Reikalavimų pasikeitimas Projekto ir produkto Didesnis reikalavimų pakeitimų kiekis nei tikėtasi Specifikacijų vėlinimas Projekto ir produkto Esminių reikalavimų specifikacijos vėluoja Blogai įvertintas sistemos Projekto ir produkto Sistema yra didesnė nei tikėtasi dydis Menkas CASE įrankių našumas Projekto ir produkto CASE įrankiai yra prastesni nei tikėtasi Technologijos pasikeitimas Verslo Pagrindinės technologijos, kurių pagrindu veikia sistema, pakeistos naujomis Produkto konkurencija Verslo Konkuruojantis produktas pasirodo rinkoje, kai sistema dar nebaigta 60

62 5.3. Rizikos identifikavimo metodai Identifikavimo tikslas nustatyti projekto riziką, remiantis įvairiais metodais: smegenų šturmo (angl. brainstorming) metodu; SSGG (stiprybės, silpnybės, galimybės, grėsmės), angliškai SWOT (angl. strengths, weaknesses, opportunities, threats), analizė; prielaidų (angl. assumtions) analizė; standartinių populiarių rizikų sąrašo peržiūra; dokumentacijos analizė; Delfi metodas Interviu Diagramų analizė SSGG analizė SSGG matricos pildymo pavyzdys pateikiamas 5.2 lentelėje. 5.2 lentelė. SSGG analizės pavyzdys STIPRYBĖS Aukšta produkto kokybė Stiprus prekės ženklas Gera organizacijos reputacija Kvalifikuoti darbuotojai Naujausios technologijos GALIMYBĖS (teigiama rizika) ES struktūrinių fondų parama, diegiant naujausias technologijas Vartotojų perkamosios galios didėjimas Rinkos dalies didinimas, įeinant į globalią rinką SILPNYBĖS Projekto produktas skirtas labai nedidelei vartotojų tikslinei grupei Neatliekami tyrimai, siekiant išnagrinėti nepatenkintus vartotojų poreikius ir jų elgseną Projektas labai unikalus GRĖSMĖS Naujų konkurentų atėjimas į rinką Tiekėjai techninę įrangą vėluoja pateikti Verslo partneriai gali subankrutuoti Šioje matricoje yra iš anksto surinkta ir apdorota informacija. Pildant matricą svarbu suprasti ir užfiksuoti, kad silpnosios ir stipriosios pusės tai informacija apie analizuojamą projektą, o galimybės ir grėsmės apie išorinę analizuojamo projekto aplinką. Tolesnė SSGG matricos analizė numato atsakymą į keturis klausimus: Ar stiprybės leis panaudoti palankias galimybes? Ar stiprybės padės išvengti grėsmių? Ar silpnybės netrukdys panaudoti palankias galimybes? Ar silpnybės netrukdys išvengti grėsmių? Atsakymai į šiuos klausimus yra matricos langeliuose 5.3 lentelėje: 61

63 5.3 lentelė. SSGG matricos analizės rezultatai Stiprybės Silpnybės Galimybės Ar stiprybės leis panaudoti palankias galimybes? Ar silpnybės netrukdys panaudoti palankias galimybes? Grėsmės Ar stiprybės padės išvengti grėsmių? Ar silpnybės netrukdys išvengti grėsmių? Galimi veiksmai esant teigiamam atsakymui pateikti 5.4 lentelėje. 5.4 lentelė. Koreliacinė SSGG analizės matrica. Atsakymai į riziką Galimybės Stiprybės Sustiprinti Pasipriešinti Silpnybes Ištirti Išeiti Grėsmės Koreliacinę matricą, pavaizduotą 5.4 lentelėje, galima pildyti iš karto, praleidžiant vaizduojamą 5.3 lentelėje. Čia siūlomi veiksmai tuo atveju, jei atsakymai į visus klausimus apie stiprybes ir silpnybes, galimybes ir pavojus buvo teigiami, ir yra tik apibendrintas variantas, neatspindintis visų galimų charakteristikų ir atitinkamų veiksmų konkrečiomis realiomis situacijomis. Realioje situacijoje, kai jau turime atsakymus į visus klausimus, sudaromas problemų sąrašas, vėliau išrūšiuojant jas pagal prioritetą arba pagal svarbą. Prioriteto ir svarbumo vertinimo kriterijus gali būti jų poveikio siekiant projekto tikslų laipsnis, atsižvelgiant į tikslų hierarchiją Delfi prognozavimo metodas Delfi metodas remiasi nepriklausomų ekspertų nuomonėmis. Tai sisteminis interaktyvus sociologinis metodas, taikomas įvairiose srityse prognozavimui ir struktūriniams tyrimams (Wright, 1999; 2001). Pagrindiniai Delfi metodo elementai: 1. Disponuojamos informacijos struktūra. Tyrimo metu renkami ekspertų atsakymai pagal klausimyną. Tikslingai atrinkti ekspertai atsako į klausimyno klausimus. Apklausa atliekama keliais etapais. Kiekvieno etapo duomenys analizuojami. Tyrėjas atsakymus apibendrina, pakoreguoja klausimyną ir pakartotinai persiunčia ekspertų grupei. Pakartotinai apklausiami tie patys ekspertai, tačiau jiems pateikiamas jau pakoreguotas klausimynas. 2. Nuolatinis grįžtamasis ryšys. Esant poreikiui, papildomai gali būti renkami ekspertų komentarai apie sprendimus. Tyrimo dalyviams sudaromos galimybės komentuoti savo pasirinkimą, kitų tyrimo dalyvių sprendimus ir galutinį rezultatą. Kiekvienu momentu jie gali peržiūrėti savo ankstesnius sprendimus. 3. Dalyvių anonimiškumas. Dalyviams paprastai garantuojamas anonimiškumas. Jie nėra identifikuojami net ir tyrimo pabaigoje. Metodo valdymo priemonės yra: Sisteminių nukrypimų pašalinimas. 62

64 Papildomi klausimai. Respondentams leidžiama sudaryti papildomus klausimus arba pateikti savo atsakymų variantus, kurie gali būti įtraukti į kito etapo klausimyną. Nusveriančios nuomonės. Didesni nei kitų svoriai gali būti suteikti kompetentingiausių ekspertų svarstomu klausimu nuomonėms. Metodas tinka ekspertizei nuotoliniu būdu (internetu arba elektroniniu paštu). Kadangi duomenys jau pateikti elektroniniu pavidalu, juos įmanoma paprastai ir sparčiai apdoroti. Teigiama, kad taikant Delfi metodą gaunamas tiksliausias rezultatas, kadangi metodas yra sukurtas aukšto lygio specialistams. Rezultatų objektyvumą garantuoja kompetentingų ekspertų nuomonės ir tų nuomonių kaita laike (Wright, 1999; 2001). Galimi rizikos tipai: Technologinė rizika. Pvz., naudojama duomenų bazė apdoroja mažiau transakcijų per sekundę nei tikėtasi, PĮ komponentai, kurie yra reused, yra su klaidomis. Žmonių rizika. Pvz., neįmanoma įdarbinti reikiamų sugebėjimų žmonių, pagrindiniai darbuotojai serga kritiniu laiku, negalimas reikalingas personalo mokymas. Organizacinė rizika. Pvz., pasikeičia už projektą atsakingas vadybininkas. Organizacinės finansinės problemos priverčia mažinti projekto biudžetą. Įrankių (angl. tools) rizika. Pvz., CASE įrankiais sugeneruotas kodas yra neefektyvus, neįmanoma integruoti CASE įrankių; Reikalavimų rizika. Pvz., reikalavimų pakeitimas sukelia didelius architektūrinius pasikeitimus, užsakovai nesupranta (neįvertina) reikalavimų pasikeitimo poveikio. Vertinimo rizika. Pvz., per trumpas projekto realizavimo laikas, blogai įvertintas PĮ dydis, suplanuotas per mažas galimų defektų kiekis Rizikos analizė Rizikos komponentės pateiktos 5.3 pav. 5.3 pav. Projekto rizikos komponentės (Alberts, 2009) Toliau reikia įvertinti kiekvienos rizikos tikimybę. Ši charakteristika labai svarbi tolesniam rizikos valdymo etapui, todėl ją vertinti turėtų visi komandos nariai. Vienas iš būdų tai padaryti pildomą rizikos lentelę siųsti ratu, kiekvienam dalyvaujančiajam 63

65 parašant savo nuomonę apie rizikos tikimybę. Tai tęsiama tol, kol nuomonės pradeda suartėti ir pasiekiamas konsensusas. Rizikos tikimybė gali būti įvertinta kaip: minimali (<10 %), maža (10 25 %), vidutinė (25 50 %), didelė (50 75 %) arba maksimali (>75 %). Software Engineering Institute rekomenduojami rizikos tikimybės kriterijai pateikti 5.5 lentelėje. 5.5 lentelė. Projekto rizikos tikimybės kriterijai (Alberts, 2009) Pasirodymo tikimybė Maksimali (>75 %) Didelė (50 75 %) Vidutinė (25 50 %) Maža (10 25 %) Minimali (<10 %) Nežinoma Neįvertinama Aprašymas Projekto rizikos konstatavimas yra visai neabejotinai teisingas. Beveik jokių netikrumų nėra. Projekto rizikos konstatavimas yra panašiausias į tiesą. Tam tikrų neaiškumų yra. Tikėtina, kad tvirtinimas bus teisingas ar neteisingas. Tikėtina, kad tvirtinimas bus neteisingas. Yra nedidelė galimybė, kad tvirtinimas teisingas. Labiausiai tikėtina, kad tvirtinimas yra neteisingas. Beveik neegzistuoja jokių neaiškumų. Siekiant įvertinti tikimybę, reikia daugiau informacijos. Šiuo momentu šis rizikos tvirtinimas yra neaktualus ir nevertinamas. Kartais sunku įvertinti bendrą riziką; tokiu atveju galima pabandyti apibrėžti galimas neigiamas rizikos pasekmes atskiriems projekto aspektams (komponentams), pavyzdžiui veiksmingumui, palaikymo sudėtingumui, kainai ir laikui. Tuomet bendra įtaka gaunama suskaičiavus įtakos atskiriems rizikos komponentams vidurkį. Rizikos įtaka gali būti katastrofiška (5), didelė (4), vidutinė (3), maža (2), minimali (1), nežinoma ir nevertinama (0). Software Engineering Institute rekomenduojami rizikos įtakos kriterijai pateikti 5.6 lentelėje. 5.6 lentelė. Projekto rizikos įtakos kriterijai (Alberts, 2009) Įtaka Katastrofiška (angl. severe) Didelė Vidutinė Maža Minimali Nežinoma Nevertinama Aprašymas Jei projekto rizikos konstatavimas būtų teisingas, poveikis projekto tikslams būtų ypač stiprus. Projektas beveik tikrai patirs nesėkmę. Jei projekto rizikos konstatavimas būtų teisingas, poveikis projekto tikslams būtų stiprus. Projektas gali patirti nesėkmę. Tačiau maža galimybė yra. Jei projekto rizikos konstatavimas būtų teisingas, poveikis projekto tikslams būtų vidutinis. Labiausiai tikėtina, kad projektas pasiseks. Jei projekto rizikos konstatavimas būtų teisingas, poveikis projekto tikslams būtų mažas. Tikėtina, kad projektas pasiseks. Jei projekto rizikos konstatavimas būtų teisingas, poveikis projekto tikslams būtų nereikšmingas. Projektas tikrai bus sėkmingas. Siekiant įvertinti įtaką, reikia daugiau informacijos. Šiuo momentu šis rizikos tvirtinimas yra neaktualus ir nevertinamas. Rizikos analizės proceso rezultatai turi būti surašyti į lentelę pagal rizikos įtakos rimtumą. Aišku, rizikos įtaka ir tikimybė gali keistis rizikos valdymo proceso kiekvienos iteracijos metu. 64

66 Kai rizikos buvo išanalizuotos ir surikiuotos, reikia nuspręsti, kurios iš jų yra svarbiausios ir kurias iš jų reikia vertinti projekto vykdymo metu. Šitas sprendimas priklauso nuo rizikos įtakos ir jos pasirodymo tikimybės kombinacijos. Apskritai visada reikia nagrinėti visas rizikas su katastrofine įtaka ir visas rizikas su didele įtaka, kurių pasirodymo tikimybė vidutinė ir didesnė nei vidutinė. Stebimų rizikų kiekis neturi būti per didelis, kad rizikai valdyti reikalingos informacijos kiekis būtų aprėpiamas. Pavyzdžiui, 5.7 lentelėje reikėtų atsižvelgti į pirmąsias 8 rizikos eilutes. 5.7 lentelė. Galimos rizikos tikimybės ir poveikio pavyzdys Nr. Rizika Tikimybė Įtaka 1 Organizacinės-finansinės problemos priverčia mažinti projekto biudžetą (Organizacinė rizika) Žema Katastrofiška 2 Neįmanoma įdarbinti personalo su reikiamais įgūdžiais (Žmonių rizika) Aukšta Katastrofiška 3 Pagrindiniai darbuotojai serga kritiniu laiku (Žmonių rizika) Vidutinė Katastrofiška 4 Organizacija yra reorganizuojama, dėl to pasikeičia už projektą atsakingas vadybininkas (Organizacinė rizika) Aukšta Vidutinė 5 Per trumpas projekto realizavimo laikas (Įvertinimo rizika) Aukšta Didelė 6 PĮ komponentai, kurie yra reused, yra su klaidomis (Technologinė rizika) Vidutinė Didelė 7 Reikalavimų pakeitimai sukelia didelius architektūrinius pasikeitimus (Reikalavimų rizika) Vidutinė Didelė 8 Naudojama duomenų bazė apdoroja mažiau transakcijų per sekundę nei tikėtasi (Technologinė rizika) Vidutinė Didelė 9 Neįmanoma integruoti CASE įrankių (Įrankių rizika) Aukšta Maža 10 Blogai įvertintas PĮ dydis (Įvertinimo rizika) Aukšta Maža 11 Užsakovai nesupranta (neįvertina) reikalavimų pasikeitimo poveikio (Reikalavimų rizika) Vidutinė Maža 12 Negalimas reikalingas personalo mokymas (Žmonių rizika) Vidutinė Maža 13 Suplanuotas per mažas galimų defektų kiekis (Įvertinimo rizika) Vidutinė Maža 14 CASE įrankiais sugeneruotas kodas yra neefektyvus (Įrankių rizika) Vidutinė Nereikšminga Norint sistemingai tyrinėti rizikos valdymą, reikia nustatyti, kokie veiksniai daro didžiausią įtaką galutiniam produktui ar rezultatui, t. y. nustatyti varovus (angl. driver). Varovai agreguoja sąlygų ir potencialių įvykių poveikį. Rizikos varovai gali būti: technologija, įranga, informacijos valdymas, komunikavimas, organizacinės sąlygos, neatitikimas teisės aktų, politikai, įvykiai, reikalavimai, projektas ir architektūra, sistemos galimybės, sistemos integracija, programos veikimo palaikymas, kliūčių apėjimas, pasirengimas veikti, sertifikavimas bei akreditavimas ir t. t. Alberts pateikia standartinį rizikos varovų sąrašą. 5.5 pav. Pateiktas pavyzdys, kaip rizikos įtakos dydis neigiamai veikia keturias pagrindines projekto dedamąsias: kainą (angl. cost), laiką (angl. time), apimtį (angl. scope) ir kokybę (angl. quality). 65

67 5.4 pav. Projekto rizikos komponenčių sistema (Alberts, 2009) 5.5 pav. Rizikos takos dydžio poveikis pagrindiniams projekto tikslams (PMP.A_Guide_to_the_Project_Management_Body_of_Knowledge_PMBOK Rizikos valdymo plano šablonas, parengtas pagal šabloną, yra pateiktas 5A priede. Rizikos analizės pavyzdžiai 66

68 5.8 lentelė. Rizikos analizės pavyzdys Rizika Pasirodymo tikimybė Įtaka Sutrumpintas pristatymo laikas 50 % 2 Prarastas finansavimas 40 % 3 Užsakovas pakeis reikalavimus 80 % 2 Personalas be patirties 30 % 2 Didelės personalo klaidos 60 % 2 Didesnis vartotojų skaičius negu planuota 30 % 1 Įtakos žymėjimas: 3 katastrofiška 2 kritinė 1 nedidelė 0 nereikšminga 5.9 lentelė. Rizikos rangavimo pavyzdys Įtaka Laikas Pasirodymo tikimybė Didelė (3) Vidutinė (2) Maža (1) Didesnis negu 3 mėnesių nukrypimas nuo tvarkaraščio (3) Įgyvendinimas vėluotų nuo 1 3 mėnesius (2) Įgyvendinimas vėluotų nuo 1 savaitės iki 1 mėnesio (1) Labai tikėtina daugiau negu 70 % Tikriausiai: % tikimybė Neįtikėtina: mažesnė negu 30 % tikimybė Rangas (įtaka x pasirodymo tikimybė = rangas) 3x0,7=2, Atsako į rizikas planavimas Atsako į rizikas planavimo proceso metu nagrinėjama kiekviena identifikuota esminė (stebima) rizika ir nustatomos jų valdymo strategijos. Atsako strategijos į negatyvias rizikas yra tokios: 1. Išvengti (angl. Avoid). Mažinama rizikos pasirodymo tikimybė. Pvz., komponentai su klaidomis pakeisti juos reikiamo patikimumo komponentais. 2. Perleisti poveikį (angl. Transfer). 3. Sumažinti poveikį (angl. Mitigate). Mažinama rizikos įtaka. Pvz., darbuotojų ligos perorganizuoti darbo grupę taip, kad užduotys labiau dengtųsi ir bendradarbiai geriau žinotų, ką kiekvienas daro. 4. Priimti kaip faktą (angl. Accept). Kai atsitinka blogiausia, Jūs esate tam pasirengę ir turite strategiją, kaip tada elgtis. Pvz., organizacinės-finansinės problemos parengti dokumentą, skirtą vyresniems vadybininkams, nurodant, kokią svarbią reikšmę verslo požiūriu visai organizacijai turi jūsų vykdomas projektas. Atsako strategijos į pozityvias rizikas yra tokios: 1. Pradėti įvykį (angl. Exploit). 2. Pasidalinti naudą (angl. Share). 3. Padidinti poveikį (angl. Enhance). 4. Priimti kaip faktą (angl. Accept). 67

69 Rizikos stebėjimas (angl. monitoring) tai reguliarus kiekvienos rizikos įvertinimas tuo požiūriu, ar konkreti rizika tampa mažiau ar daugiau galima ir ar rizikos įtaka pasikeitė. Aišku, dažniausiai tai neįmanoma pastebėti tiesiogiai, todėl tenka remtis šalutiniais veiksniais, kaip pateikta žemiau. Rizikos stebėjimo procesas turi būti nepertraukiamas ir visos esminės rizikos turi aptariamos kiekvienoje vadybos peržiūroje. Rezultatai surašomi į 5.3 lentelę. Dažniausiai veiksmų planas sudaromas kiekvienai rizikai atskirai ir susideda iš trijų dalių: vengimo, stebėjimo ir padarinių mažinimo. Praktiškai neįmanoma visiškai panaikinti jokios realios rizikos, tačiau beveik visada galima imtis vienokių ar kitokių žingsnių jos tikimybei sumažinti. Pavyzdžiui, jei kalbame apie riziką projekto komandoje dažnai keisis žmonės, jos tikimybę mažinti galėtume organizuodami susitikimus su darbuotojais ir bandydami išsiaiškinti, kas juos galėtų paskatinti (ar jau paskatino) palikti įmonę ir kiek įmanoma į nuogąstavimus atsižvelgti; taip pat reikėtų apsvarstyti galimybę paskirti papildomus darbuotojus dirbti kartu su svarbiausiais projektui žmonėmis lentelė. Rizikos indikatoriai Rizikos tipas Technologinė Žmonių Organizacinė Įrankių Reikalavimų Įvertinimo Galimi indikatoriai Vėluojantis aparatūros ar palaikančiosios PĮ tiekimas, daug ataskaitų apie technologines problemas. Žema personalo moralė, blogi santykiai tarp grupės narių. Organizacinės paskalos, mažai vadovaujančiojo personalo iniciatyvos. Grupės narių nenoras naudoti įrankius, nusiskundimai dėl CASE įrankių, galingesnių kompiuterių reikalavimai. Daug prašymų pakeisti reikalavimus, užsakovų nusiskundimai. Nesiseka dirbti pagal tvarkaraštį, nesiseka taisyti defektų. Kad galėtume valdyti riziką, privalome ją stebėti: numatyti, kaip keisis jos tikimybė ar/ir įtaka projektui. Tęsiant tą patį pavyzdį, turėtume atkreipti dėmesį į bendrą projekto komandos narių nuotaiką, jų tarpusavio santykius, panašaus tipo darbo vietų pasiūlą kitose įmonėse, ir panašiai. Jei vis dėlto rizikos išvengti nepavyksta, turime būti pasiruošę kuo labiau sumažinti jos padarinius. Dar kartą grįžkime prie to paties pavyzdžio: projektą paliko keli darbuotojai. Čia mums pravers tie papildomi žmonės, dirbę kartu su išeinančiaisiais. Taip pat tokiu atveju būtų naudinga visų projektą paliekančių darbuotojų paprašyti nutraukiant visus darbus savo darbus perduoti raštu ir apmokyti naujus komandos narius. JAV Carnegie Melon universitete Programų inžinerijos institute atliekami projekto rizikos moksliniai tyrimai kuria naują požiūrį į rizikos valdymą. Jie siūlo paskirstytų sistemų sėkmingam projekto valdymui taikyti struktūrizuotą metodą (Pastaba: studentams naudinga atsisiųsti pranešimo skaidres: Tutorial: Rethinking Risk Management 5A priede pateiktas Rizikos valdymo plano šablonas, parengtas pagal šabloną 68

70 REIKŠMINIAI žodžiai / Key words Rizikos valdymas, priežastis, pasekmė, įtaka, tikimybė, grėsme, padariniai. Risk management, cause, effect, impact, probability, threat, consequence. REKOMENDUOJAMI SKAITINIAI ISO/IEC Guide 73:2009 (2009). Risk management Vocabulary. International Organization for Standardization. ISO/DIS (2009). Risk management Principles and guidelines on implementation. International Organization for Standardization. Committee Draft of ISO Risk management (PDF). International Organization for Standardization. CMU/SEI-93-TR-6 Taxonomy-based risk identification in software industry. A Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI Project Management Institute. The World s Leading Professional Association for Project Management, Library of PMI Global Standards, Standards-Library-of-PMI-Global-Standards.aspx Risk & Opportunity Management Overview, Carnegie Mellon University Software Engineering Inst., Alberts, Ch., Dorofee, A. J., Rethinking Risk Management Tutorial, Software Engineering Institute, Carnegie Mellon University, Prieiga per internetą: cmu.edu/library/abstracts/presentations/rethinking-risk-management-tutorial.cfm NAUDOTA LITERATŪRA Charette, R. N., Taking responsibility for our risks, Communications of the ACM, Vol. 39, Issue 3, Crosby, P. B., Quality is Free, McGaw-Hill,

71 Harvey, M., Project management, Prentice Hall, Henry, J., Software Project management, Pearson Addison Wesley, Pressman, R. S., Software Engineering: A Practitioner s Approach, 6th Edition, McGraw-Hill, Project life cycle VS Project management process, Project-life-cycle-VS-Project-management-process PMP.A_Guide_to_the_Project_Management_Body_of_Knowledge_PMBOK. microlps.freewebsites.com/pmp/a_guide_to_the_project_management_body_of_ Knowledge_PMBOKGuide/LiB0063.html#figure.Lib39 Wright, R., The Delphi technique as a forecasting tool: issues and anglysis, International Journal of Forecasting, Vol. 15, Issue 4, October Wright, R., Expert Opinions in Forecasting. Role of the Delphi Technique, Principles of Forecasting: A Handbook of Researchers and Practitioners, Armstrong (Ed.). Boston: Kluwer Academic Publishers,

72 5A Priedas: Rizikos valdymo plano šablonas Įvadas [Pateikite rizikos valdymo planą. Kokie veikėjai dalyvaus, kokios procedūros bus vykdomos, kaip bus matuojama rizikos įtaka?] Procesas [Aprašykite procesą, kaip planuojate suvaldyti riziką. Ar tuo tikslu panaudosite kitus susitikimus, siekdami nedidinti susirinkimų skaičiaus? Kokios bus poveikio procedūros? Vaidmenys ir atsakomybė [Aprašykite, kas bus įtrauktas į rizikos valdymo procesą. Kokios pareigybės reikalingos? Ar reikia organizuoti susirinkimus ir kaip dažnai?] Rizikos valdymo strategija [Kokie bus problemų sprendimo metodai?] Taisyklės / procedūros [Aprašykite, kokių taisyklių turi laikytis komandos nariai, kai nustato, valdo ir vertina riziką? Ar visas rizikas turi valdyti projekto vadovas? Koks mechanizmas turi būti taikomas, siekiant įregistruoti riziką?] Rizikos įtakos analizės metodai [Aprašykite kiekvienos rizikos įtakos įvertinimo procesą. Kas dalyvaus įtakos vertinimo procese? Žemiau pateiktas pavyzdys, kaip gali būti vertinama įtaka ir tikimybė.] Rangas Įtaka Laikas Pasirodymo tikimybė (įtaka x pasirodymo tikimybė = rangas Didelė 3 Vidutinė 2 Maža 1 Didesnis negu 3 mėnesių nukrypimas nuo tvarkaraščio (3) Įgyvendinimas vėluotų nuo 1 3 mėnesius (2) Įgyvendinimas vėluotų nuo 1 savaitės iki 1 mėnesio (1) Labi tikėtina daugiau negu 70 % Tikriausiai: % tikimybė Neįtikėtina: mažesnė negu 30 % tikimybė [pvz., 3x0,7=2,1] 71

73 Patvirtinimas ir atsakingų vykdytojų paskyrimas Vardas, Pavardė Pareigos Data Šaltinis: 72

74 6. Produkto ir proceso matavimai. Programų sistemų proceso matavimai 6.1. Programinės įrangos procesų charakteristikos Labai glaudus ryšys yra tarp kokybiškai plėtojamo proceso ir kuriamų produktų kokybės. Būtent dėl šios priežasties programinės įrangos kūrėjai tobulina programinės įrangos procesą, kad pagerintų kuriamos programinės įrangos kokybę. Proceso plėtojimas, gerinimas reiškia esamų procesų supratimą ir šių procesų keitimą, siekiant padidinti produktų kokybę ir/ar sumažinti plėtojimo kaštus bei laiką. Procesas tobulinamas, siekiant padidinti gaminių kokybę ir kartu sumažinti klaidas, defektus galutinėje programinėje įrangoje. Kai tik tai pasiekiama, pagrindiniai tikslai galėtų būti kaina ar laiko mažinimas. Programinės įrangos procesai yra kompleksiniai ir apima daug veiksnių. Kaip ir produktai, procesai turi tam tikrų bruožų ar charakteristikų: Suprantamumas (angl. Understability) iki kokio laipsnio procesas aiškiai apibrėžtas ir kaip lengva suprasti proceso apibrėžimą? Vaizdumas (angl. Visibility) ar proceso veiklos pasibaigia aiškiu rezultatu taip, kad proceso progresas matomas išoriškai? Remtinumas (angl. Supportability) iki kokio laipsnio proceso veiklos gali būti palaikomos CASE įrankiais? Priimtinumas (angl. Acceptability) ar apibrėžtas procesas priimtinas ir ar jis tinkamas naudoti inžinieriams? Patikimumas (angl. Reliability) ar procesas suprojektuotas tokiu būdu, kad proceso klaidos yra išvengiamos arba aptiktos anksčiau, nei jos virstų programinės įrangos klaidomis? Patvarumas (angl. Robustness) ar procesas tęsiamas nepaisant netikėtų problemų? Palaikomumas (angl. Maintainability) ar procesas gali būti vystomas, kad atspindėtų besikeičiančius organizacinius reikalavimus ir nustatytus proceso tobulinimus? Sparta (angl. Rapidity) kaip greitai iš nustatytos specifikacijos gali būti užbaigtas sistemos pateikimo procesas? 73

75 Neįmanoma taip patobulinti procesą, kad būtų optimizuoti visi jo bruožai tuo pat metu. Proceso tobulinimas nereiškia paprasčiausio tam tikrų metodų ar įrankių pasisavinim iš tokio paties modelio procesų, kurie buvo naudojami kažkur kitur. Vis dėlto organizacijos, kurios kuria tam tikrą programinę įrangą, be abejo, turi daug ką bendra, visada yra vidiniai organizaciniai veiksniai, technologijos ir standartai, kurie turi įtakos procesui. Proceso gerinimas yra cikliškas. Jį sudaro trys stadijos: 1) Proceso matavimas. Projektų ar produktų požymiai yra matuojami. Tikslas gerinti matus pagal tam tikros organizacijos siekius procesą gerinti. 2) Proceso analizė. Dabartinis procesas yra atestuojamas, nustatomos proceso silpnybės ir silpnosios vietos. Proceso modeliai, kurie apibūdina procesą, dažniausiai yra plėtojami šiame lygmenyje. 3) Proceso keitimas. Procese diegiami pakeitimai, kurie buvo nustatyti analizės metu. Kiekvienas proceso etapas gali tęstis keletą mėnesių; proceso gerinimas yra nenutrūkstamas, daug laiko reikalaujantis darbas, nes kai tik pristatomas naujas procesas, verslo sąlygos keičiasi, ir šie procesai keičiasi taip pat. Kaip parodyta 6.1 pav., matavimas susideda iš tam tikrų etapų ir požymių (angl. attribute). 6.1 pav. Matavimo vieta projektavimo procese 74

76 6.2. Procesas ir produkto kokybė Proceso gerinimas yra paremtas supratimu, kad proceso kokybė yra svarbi produkto kokybei. Proceso gerinimo idėja priklauso Amerikos inžinieriui W. E Demingui. Demingas po Antrojo pasaulinio karo pritaikė statistinius procesų kontrolės metodus Japonijos pramonėje. Šie metodai daugelį metų buvo nuolat tobulinami, todėl šiuo metu Japonijoje pagaminti produktai yra pačios aukščiausios kokybės. Demingas (ir kiti) pristatė statistinės kokybės kontrolės idėją. Ji paremta produkto defektų, kurie vėliau būna susiejami su procesais, skaičiavimu. Tikslas yra sumažinti defektų kiekį tobulinant procesus tol, kol jie kartojasi. Tai yra nuspėjami procesų rezultatai ir defektų kiekis sumažinamas. Tuomet procesas imamas kaip standartinis ir pradedamas kitas tobulinimo ciklas. Humphrey knygoje apie procesų valdymą Managing the Software Process įrodė, kad tokia pati metodika gali būti naudojama ir programinei įrangai kurti (Humphrey, 1989). Gamyboje proceso sąryšis su produktu yra akivaizdus. Norint išvengti defektų, gerinamas procesas, ir kaip to rezultatas gaminami geresni produktai. Šis ryšys yra ne toks aiškus, kai produktas neapčiuopiamas ir yra priklausomas nuo intelektualių procesų, kurie negali būti automatizuojami. Programinės įrangos kokybė yra priklausoma ne nuo gamybos, o nuo projektavimo proceso, kur yra svarbios individualios žmogaus savybės. Kai kuriose produktų klasėse naudojami procesai yra pats svarbiausias veiksnys, lemiantis produkto kokybę. Vis dėlto, ypač taikant naujoves, žmonės, įtraukti į procesą, gali būti daug svarbesni nei procesas. Programinės įrangos ar bet kokių kitų intelektualių produktų kokybę lemia keturi pagrindiniai veiksniai, kurie pavaizduoti 6.2 pav. Proceso kokybė Technologijų projektavimas Produkto kokybė Kaina, laikas ir tvarkaraštis Žmonių kokybė 6.2 pav. Pagrindiniai PĮ produkto kokybės veiksniai (Sommerville, 2007) Kiekvieno iš šių veiksnių įtaka priklauso nuo projekto dydžio ir tipo. Labai didelių sistemų, kurios susideda iš posistemių, yra vystomos ir plėtojamos skirtingų komandų, dirbančių skirtingose vietose, pagrindinis kokybės veiksnys yra programinės įrangos procesas. Pagrindinės didelių projektų problemos yra integravimas (sujungi- 75

77 mas į visumą), vadovavimas projektui ir bendravimas. Dažniausiai vienoje komandoje dirba skirtingų gabumų ir patirties darbuotojai, o vystymo, plėtojimo procesas užtrunka daugelį metų, plėtojimo komanda nuolat kinta. Per projekto gyvavimo laiką ji gali pasikeisti visiškai. Be to, ypač kvalifikuoti ar talentingi komandos nariai paprastai niekada nedominuoja visą projekto gyvavimo laiką. Mažiems projektams, kai komandą sudaro tik keli nariai, projektavimo komandos kokybė yra daug svarbesnė nei naudojami procesai. Jei komanda turi daug sugebėjimų ir yra patyrusi, jų produktų kokybė dažniausiai labai gera. Jei komanda yra nepatyrusi ir nekvalifikuota, geras procesas galbūt sumažins žalą, tačiau negalės garantuoti, kad sukurta PĮ bus aukštos kokybės. Kai komandos mažos, gera plėtojimo technologija yra ypač svarbi. Maža komanda negali skirti daug laiko nuobodžioms administravimo procedūroms. Komandos nariai didžiąją laiko dalį praleidžia modeliuodami ir programuodami sistemą, taigi geri įrankiai gali ženkliai padidinti produktyvumą. Didesniems projektams svarbiausias technologijų projektavimo lygis yra esminis informacijos valdymo procese. Paradoksalu, tačiau sudėtingi CASE įrankiai yra ne tokie svarbūs dideliuose projektuose. Tokių projektų komandos nariai praleidžia mažiau laiko plėtodami darbus, bet daugiau laiko bendraudami ir suprasdami kitas sistemos dalis. Tai yra pagrindinis veiksnys, kuris ir turi didžiausią įtaką aukštam efektyvumui. Technologijų projektavimas tam neturi jokios įtakos Procesų klasifikacija Programinės įrangos procesai yra visose organizacijose, pradedant vieno asmens kompanijomis ir baigiant didelėmis tarptautinėmis kompanijomis. Šie procesai yra skirtingų tipų priklausomai nuo proceso formalumo laipsnio, plėtojamų produktų tipo, organizacijos dydžio ir pan. Yra keturios programinės įrangos procesų klasės (6.3 pav.). Tobulinami procesai nėra parodyti 6.3 paveiksle, kadangi bet kokio tipo procesai gali būti tobulinamieji. 1. Neformalus procesas. Kai nėra griežtai apibrėžto proceso modelio, projektavimo komanda pasirenka naudos procesą. Neformalūs procesai gali naudoti formalias procedūras, tokias kaip konfigūracijos valdymas, tačiau procedūros ir santykiai tarp procedūrų yra apibrėžti, kaip reikalauja projektavimo komanda. 2. Valdomas procesas. Projektavimo procesų valdymui taikomas apibrėžtas proceso modelis. Šis modelis apibūdina procedūras, jų grafiką ir santykius tarp procedūrų. 3. Metodinis procesas. Kai taikomi apibrėžti projektavimo metodai, jiems palaikyti naudojami CASE įrankiai. 4. Tobulinimo procesai. Jie skirti tobulinimo tikslams, turi specifinį biudžetą tobulinimams ir procedūras, įdiegiančias šiuos patobulinimus. 76

78 Neformalus procesas Valdomas procesas Prototipai Trumpo gyvavimo sistemos 4GL verslo sistemos Didelės sistemos Ilgaamžiai produktai Metodinis procesas Gerai suprantamos taikomosios sferos, perdaromos sistemos 6.3 pav. Proceso pritaikomumas (Sommerville, 2007) 6.3 pav. pavaizduoti įvairaus tipo produktai ir įvairaus tipo procesai, kurie taikomi tiems produktams sukurti. Šios klasifikacijos, be abejo, persidengiami, ir procesai gali pakliūti į keletą klasių. Tačiau ši klasifikacija yra naudinga daugiamačiams procesams gerinti. Ji padeda organizacijoms pasirinkti atitinkamą procesą tam tikro unikalaus produkto projektavimo reikmėms. 6.4 pav. rodo skirtingo tipo produktus ir proceso tipą, kuris gali būti naudojamas jiems projektuoti. Neoficialus procesas Valdomas procesas Metodinis procesas Tobulinimo procesas Bendri Konfigūracijos Projekto Analizės ir dizaino Specializuoti įrankiai valdymo valdymo darbastaliai įrankiai 6.4 pav. Įrankiai, kurie palaiko procesus Procesų klasifikacija naudinga renkantis tinkamą kuriamam produktui procesą. Pavyzdžiui, programa, kuri palaiko perėjimą nuo vieno tipo kompiuterinės sistemos prie kito, gyvuoja trumpai. Jai projektuoti nereikia standartų ir valdymo procedūrų, kurios būdingos programinei įrangai, naudojamai daugelį metų. 77

79 6.4. Proceso matavimai Procesų matavimai yra kiekybiniai programinės įrangos procesų duomenys. Procesų matavimai gali būti naudojami atestuojant proceso efektyvumo padidėjimą. Pavyzdžiui, efektyvūs testavimo proceso pokyčiai turėtų sumažinti pastangas, testavimo laiką ar abu iš karto. Vis dėlto vien tik proceso matavimais negalima nustatyti, ar produkto kokybė pagerėjo. Produkto kokybės duomenys taip pat turėtų būti renkami ir susieti su proceso veiklomis. Sommerville išskiria tris proceso metrikų klases: 1. Laiką, kurio reikia tam tikram procesui įvykdyti. Jis gali būti visą laiką siejamas su procesu, kalendoriniu laiku ar kūrėjų dirbtu tam tikrame procese laiku ir pan. 2. Išteklius, reikalingus tam tikram procesui. Išteklius gali sudaryti personalo darbo dienų skaičius, kelionės išlaidos, kompiuterių ištekliai. 3. Tam tikro įvykio (angl. event) atvejų (angl. occurrences) skaičių. Pvz., įvykiai, kurie galėtų būti stebimi, yra: kodo inspektavimo metu aptiktas defektų kiekis; reikalavimų keitimo metu tai galėtų būti: reikalavimų pokyčių kiekis ir vidutinis pakeistų kodo eilučių kiekis. Pirmieji du matavimo tipai gali būti naudojami siekiant išsiaiškinti ar pakeitimai procese padidino paties proceso efektyvumą. Atsitinkančių įvykių matavimas labiau yra sietinas su programinės įrangos kokybe (Sommerville, 2007). Didžiausias sunkumas matuojant procesus yra žinojimas, ką matuoti. Basili ir Rombach pasiūlė, kaip jie pavadino, GQM (angl. Goal-Question-Metric) paradigmą (Basili, 1988). Ji yra naudojama padedant nuspręsti, kokie matavimai turėtų būti imami ir kaip jie turėtų būti naudojami. Remiantis šia paradigma, galima nustatyti: 1. Tikslus (angl. goals). Ką organizacija stengiasi pasiekti. Pavyzdys galėtų būti pagerėjęs programuotojo produktyvumas, trumpesnis produkto projektavimo laikas ir padidėjęs produkto patikimumas. 2. Klausimus (angl. questions). Patobulinami tikslai, nustatant specifines sritis, susijusias su tikslais. Paprastai tikslas turi tam tikrą kiekį susijusių klausimų, į kuriuos reikia atsakyti. Pvz., kaip galima sutrumpinti produkto reikalavimų užbaigimą. 3. Metrikas (angl. metrics). Tai matavimai, kuriuos reikia rinkti siekiant atsakyti į klausimus ir patvirtinti, ar proceso tobulinimai padėjo pasiekti norimus tikslus. Šio požiūrio taikymas tobulinant procesus naudingas tuo, kad atskiria organizacinius rūpesčius (tikslus) nuo tam tikro proceso dalykų (klausimų). Jis sutelkia dėmesį į duomenų rinkimą ir siūlo įvairius analizės būdus surinktiems duomenims analizuoti, atsižvelgiant į klausimą, kurį reikia atsakyti. 78

80 6.5. Proceso analizė ir modeliavimas Procesų analizei ir modeliavimui priklauso studijuoti egzistuojančius procesus ir plėtoti šių procesų bei jų charakteristikų abstraktų modelį. Šie modeliai padeda suprasti procesus. Procesų analizė skirta egzistuojantiems procesams studijuoti, kad būtų suprastas ryšys tarp proceso dalių. Pirminiai procesų analizės etapai yra kokybiniai: analizuotojas paprasčiausiai bando atrasti pagrindinius modelio bruožus. Formalus proceso modelis gali padėti kaip pradinis taškas analizuojant procesą. Vis dėlto į formaliems proceso modeliams retai priklauso pakankamai detalių, jie neatspindi tikrų programinės įrangos projektavimo darbų. Procesų analizės metodai apima: 1. Klausimus ir interviu. Inžinieriai, kurie dirba su tam tikru projektu, yra klausinėjami, kas vyksta. 2. Etnografinius tyrimus. Etnografiniai tyrimai gali būti naudojami programinės įrangos projektavimo prigimčiai, kaip žmogaus veiklai, suprasti. Detalūs proceso modeliai yra labai sudėtingi. Aptarsime pavyzdžius. Pvz., proceso fragmentai pavaizduoti 6.5 ir 6.6 pav. Jie vaizduoja vieno modulio testavimo procesą didelėje sistemoje, kuri naudoja griežtai kontroliuojamą konfigūracijos valdymo procesą. Programinė įranga yra testuojama, ir testavimo duomenys yra skirti konfigūracijai kontroliuoti. 6.5 pav. pavaizduotas vaidmuo, atsakingas už testavimo procesą, rodo testavimo procesą, proceso išėjimus ir įėjimus, prieš ir po sąlygas. 6.6 pav. pavaizduotas į atskiras veiklas išskaidytas procesas testuoti modulį. Šis fragmentas rodo tik gan paprastas modulio testavimo veiklas. Keturi veiklų srautai atsakingi už testavimo duomenų paruošimą, testavimo rinkinių rašymą modeliui, testų paleidimą ir testų rezultatų gavimą. Prieš būsena Vaidmuo Po būsena Modulis kompiliuojasi be sintaksės klaidų Testavimo inžinierius Visi nustatyti testai modulyje veikė Įėjimas Modulio specifikacija Procesas Testavimo modulis Išėjimai Pažymėti testavimo įrašai Modulio testo duomenys 6.5 pav. Modulio testavimo procesas 79

81 Perskaityti modulio speficikacij Pagal specifikaciją Paruošti testavimo duomenis Pateikti testavimo duomenis patikrai Patikrinti testavimo duomenis MODULIO TESTAVIMO PRIEMONIŲ PARUOŠIMAS Patikrinti modulį iš konfigūracijos valdymo sistemos Perskaityti ir suprasti modulio sąsają Patikrinti testavimo priemones moduliui SukompiliuotI testavimo priemones TESTAVIMO VYKDYMAS Sujungti modulį su testavimo priemonėmis Modulyje paleisti tinkamus testus Įrašyti testavimo rezultatus grįžtamajam testavimui TESTAVIMO REZULTATAI Parašyti modulio ataskaitą pridedant rastas problema Atiduoti ataskaitą patvirtinint Patvirtinti testavimo rezultatus 6.6 pav. Modulio testavimo veiklos REIKŠMINIAI ŽODŽIAI / KEY WORDS Programų sistemų projekto matavimai ir metrikos, tobulinimas. Software engineering process measurement, improvement. CMMI: Capability Maturity Model Integration EF: Experience Factory FP: Function Point HRM: Human Resources Management QIP: Quality Improvement Paradigm SCAMPI CMM: Based Appraisal for Process Improvement using the CMMI SCE: Software Capability Evaluation SEPG: Software Engineering Process Group 80

82 REKOMENDUOJAMI SKAITINIAI Assessment Tools, HM&S IT-Consulting GmbH, Austria [žiūrėta ]. Prieiga per internetą: NAUDOTA LITERATŪRA Basili, V., Rombach, H. D., The TAME project: twards improvement-oriented software environments, IEE Trans on Software Engineering, 14(6), (Chs. 27, 28). Deming, W. E., Out of the crisis : quality, productivity and competitive position, Cambridge Univ. Press, Humphrey, W.,S. Managing the Software Process, Addison-Wesley Professional,1989. Sommerville, I., Software Engineering, Eight edition, Pearson Education Limited, McGarry, J., Card, D., Jones, Ch., Layman, B.,Clark, E., Dean, J., Hall, F., Practical Software Measurement: Objective Information for Decision Makers: elektroninė knyga. Prieiga per internetą: Fenton, N. E., Software metrics, p

83 7. Programų sistemos produkto matavimai: dydžio, struktūros, kokybės 7.1. Programinės įrangos metrikos Reikalavimai programinei įrangai yra pagrindas kokybei matuoti. Reikalavimų neatitikimas mažina kokybę. Specifikuoti standartai apibrėžia PĮ kūrimo kriterijus, kurie nurodo PĮ projektavimo metodą. Jeigu kriterijų nesilaikoma, kokybės nuostoliai beveik garantuoti. Jei PĮ tenkina išorinius reikalavimus, bet netenkina vidinių, ji nėra aukštos kokybės. McCall o pasiūlė veiksniu, kurie daro įtaką PĮ kokybei, skirstyti į dvi grupes: tiesiogiai išmatuojami veiksniai (pvz., defektai, neaptikti testavimo metu). netiesiogiai išmatuojami veiksniai (pvz., patogumas naudoti arba palaikomumas). Palaikomumas Lankstumas Patikrinamumas Portatyvumas Panaudojamumas Veikimas Produkto priežiūra Produkto perėjimas Produkto veikimas Teisingumas Patikimumas Vartosena Integralumas Efektyvumas 7.1 pav. PĮ kokybei įtakos turinčių veiksnių kategorijos pagal McCall ą ISO 9126 standartas buvo sukurtas PĮ kokybės vertinimo pagrindiniams atributams identifikuoti: 1. Funkcionalumas 2. Patikimumas 3. Naudojamumas 82

84 4. Efektyvumas 5. Palaikomumas 6. Portatyvumas Kaip ir kiti kokybės veiksniai, pastarieji negali būti tiksliai išmatuoti, tačiau tai atributai, pagal kuriuos galima nustatyti PĮ kokybę. PĮ metrikos bus naudingos tik tuo atveju, jei jos yra tinkamai charakterizuotos: Metrikos turi turėti matematinę prasmę (pvz., metrikos reikšmė nuo 0 iki 1). Metrika atvaizduoja PĮ charakteristikas. Kai imamasi netinkamų veiksmų, PĮ charakteristikos pablogėja, kai imamasi kokybę gerinančių veiksmų, PĮ charakteristikos pagerėja. Metrika turi būti patikrinta įvairiuose kontekstuose prieš ją naudojant Efektyvių PĮ metrikų atributai Metrikos ir matai turėtų pasižymėti šiomis savybėmis: Paprastos ir apskaičiuojamos. Turėtų būti reliatyviai lengva apskaičiuoti metrikas, ir metrikų apskaičiavimas neturėtų užimti daug laiko ir pastangų. Lengvai ir intuityviai suprantamos. Metrikos turėtų teikti inžinieriams intuityvų suvokimą apie produkto atributus. Nuoseklios ir objektyvios. Metrikos turi teikti nedviprasmiškus rezultatus. Nuoseklios naudojant vienetus. Matematiniai metrikų skaičiavimai neturėtų naudoti keistų vienetų kombinacijų. Nepriklausomos nuo programavimo kalbos. Metrikos turi remtis analizės arba dizaino modeliu ar programos struktūra. Efektyvus mechanizmas aukšto lygio feedback ui. Metrika turi padėti išgauti aukštesnio lygio produktą. Metrikų sritys: Analizės modelio metrikos Projektavimo modelio metrikos. Kodo modelio metrikos Testavimo metrikos Analizės modelio metrikos PĮ metrikos pagal sritis Analizės modelio metrikos Šios metrikos naudojamos analizės modeliui testuoti, norint nustatyti būsimos sistemos dydį. Dydis dažniausiai, bet ne visada, nusako sistemos sudėtingumą, kodo rašymo ir testavimo pastangas. 83

85 Funkcijomis paremtos metrikos: Sistemos dydžio metrikos. Kokybės specifikacijos metrikos. Funkcijomis paremtų metrikų paskirtis yra: Apytikriai apskaičiuoti kaštus ir pastangas, reikalingas projektuoti, programuoti ir sistemai testuoti. Numatyti klaidų, atsirasiančių testavimo metu, skaičių. Komponentų kiekiui ir/arba kodo eilučių kiekiui kuriamoje sistemoje prognozuoti. Apie programinės įrangos standartų taikymą kokybės valdymo procese taip pat kalbama 8-ame skyriuje, kuriame pateiktos ISO 9126 apibrėžiamos PĮ kokybės vertinimo charakteristikos ir jų vidinės bei išorinės dedamosios (8.2 pav.) Kai kurios produkto metrikos Metrika: Fan-in / Fan-out Fan-in yra skaičius funkcijų, kurios kreipiasi į kitą funkciją, sakykime funkciją X. Aukšta Fan-in reikšmė reiškia, kad X yra glaudžiai susijusi su likusia sistemos dalimi, ir pakeitimai joje gali stipriai paveikti kitas sistemos dalis. Fan-out yra skaičius funkcijų, į kurias kreipiasi funkcija X. Aukšta Fan-out reikšmė gali reikšti, kad X yra gana sudėtinga ir susijusi su didele kontrolės logikos, reikalingos kviečiamiems komponentams koordinuoti, apimtimi. Metrika: kodo ilgis Tai programos dydžio matas. Apibendrintai, kuo didesnis yra programos komponentas, tuo jis sudėtingesnis ir tuo didesnė klaidų tikimybė jame. Metrika: Ciklomatinis kompleksiškumas Tai kontrolės logikos sudėtingumo matas. Jį galima susieti su programos suprantamumu. Metrika: Identifikatorių ilgis Tai vidutinis identifikatorių ilgis programoje. Kuo jie ilgesni, tuo tikriausiai prasmingesni, ir tada tuo suprantamesnė programa. Metrika: Sąlygos tikrinimo gylis Tai skaičius vienas į kitą įdėtų IF operatorių. Kuo šis skaičius didesnis, tuo mažiau suprantama programa ir tuo didesnė klaidų tikimybė. Metrika: Fog o indeksas Tai vidutinis žodžių ir sakinių ilgis dokumente. Kuo Fog o indeksas aukštesnis, tuo sunkiau suprasti dokumentą. 84

86 Objektiškai orientuoto produkto metrikos Metrika: Paveldėjimo medžio gylis Tai paveldėjimo medžio lygių skaičius, kur subklasės paveldi metodus ir atributus iš superklasių. Kuo gilesnis paveldėjimo medis, tuo sudėtingesnė architektūra, tuo sunkiau suprasti žemiausio lygio objektus. Metrika: Metodas Fan-in / Fan-out Labai panašu į funkcinę metriką, tik reikėtų skirti kreipinius vienos klasės ribose ir išorinių metodų kreipinius. Metrika: Įvertintų (angl. Weighted) metodų kiekis klasėje Tai metodų, įvertintų pagal sudėtingumą, kiekis klasėje. Paprastas metodas gali turėti rekšmę 1, o sudėtingas daug aukštesnę. Kuo didesnė skaitmeninė metrikos reikšmė, tuo sudėtingesnė objektų klasė. Sudėtingus objektus sunkiau suprasti, jie gali būti logiškai nerišlūs (angl. cohesive), taigi juos sunkiau pakartotinai panaudoti (angl. reuse) kaip superklases paveldėjimo medyje. Metrika: Besidengiančių operacijų skaičius Tai superklasės operacijų, kurios dengiasi subklasėje, skaičius. Aukšta šios metrikos reikšmė rodo, kad panaudota superklasė gali būti netinkamas tėvas subklasei Projekto modelio metrikos Projekto modelio metrikų rūšys: Architektūrinio projektavimo metrikos Objektiškai orientuoto projektavimo metrikos Į klasę orientuotos metrikos CK metrikų rinkinys Į klasę orientuotos metrikos MOOD metrikų rinkinys Objektiškai orientuotos metrikos, pagal Lorenz ir Kidd Į operacijas orientuotos metrikos Vartotojo sąsajos projektavimo metrikos 7.5. Objektiškai orientuoto projektavimo metrikos Whitmire [WHI97] siūlo tokias OO sistemų programinės įrangos metrikas: Dydis Sudėtingumas Sujungimas Užbaigtumas Elementarumas Panašumas Kintamumas 85

87 DYDIS Dydis nusakomas tokiais keturiais atžvilgiais: 1. populiacija tai statinis OO elementų, tokių kaip klasės ir operacijos, skaičius; 2. talpa jos matai yra sukaupiami dinamiškai nustatytu laiko momentu; 3. ilgis sujungtų projekto elementų grandinės matas; 4. funkcionalumas parodo netiesioginį reikšmės, kurią pateikia OO programa vartotojui, požymį. SUDĖTINGUMAS Yra daug skirtingų požiūrių į programinės įrangos sudėtingumą. Pasak Whitmire, sudėtingumas rodo, kaip objektiškai orientuoto projekto klasės yra susijusios viena su kita. Ši sąsaja išreiškiama struktūrinėmis charakteristikomis. SUJUNGIMAS Tai yra fizinis ryšys tarp OO projekto elementų. (Pvz., bendradarbiavimas tarp klasių arba pranešimai, perduodami tarp objektų.) UŽBAIGTUMAS Užbaigtumo matas apima skirtingus požiūrius, taigi jis netiesiogiai reiškia laipsnį, kuriuo abstrakcija ar projekto komponentai gali būti panaudoti iš naujo. PRIMITYVUMAS Charakteristika, panaši į paprastumą, primityvumas (pritaikomas tiek operacijoms, tiek klasėms) yra laipsnis, rodantis, kad operacija yra atominė, t. y. operacija negali būti konstruojama be kitų operacijų, esančių klasėje. Klasė, kuri turi aukštą primityvumo laipsnį, apima tiktai primityvias operacijas. PANAŠUMAS Dviejų ar daugiau klasių struktūros, funkcijos, elgesio ar tikslo panašumo matas. KINTAMUMAS Kintamumas nusako, kokia yra tikimybė, kad pasikeitimas projekte įvyks Į klasę orientuotos metrikos CK metrikų rinkinys CK metrikų rinkinį sudaro šešios klase paremtos OO sistemų metrikos: Svorinis klasės metodas (WMC) Paveldėjimo medžio gylis (DIT) Vaikų skaičius (NOC) Sujungimas tarp objekto klasių (CBO) Klasės atsakymas (RFC) Sąryšių tarp metodų stoka (LCOM) Svorinis metodas klasei (WMC) Tarkime, yra apibrėžta n sudėtingumo c1,c2...cn metodų klasei C. Specifinė sudėtingumo metrika, kuri yra parenkama (pvz., ciklomatinis sudėtingumas), turi būti normalizuota taip, kad minimalus metodo sudėtingumas turėtų reikšmę

88 WMC= ci, kur i=1..n Metodų ir jų sudėtingumų skaičius yra reikalingas klasei realizuoti ir testuoti. Augant nustatytos klasės metodų skaičiui programa tampa vis specifiškesnė, taip yra ribojamas pakartotinis naudojimas. Dėl visų šių priežasčių WMC turėtų būti kuo mažesnis. Paveldėjimo medžio gylis (DIT) Tai yra maksimalus ilgis nuo medžio mazgo iki šaknies. Jei DIT reikšmė didėja, tai reiškia, kad žemesnio lygio klasė paveldės daugiau metodų. Gili klasės hierarchija (DIT yra didelis) lemia didesnį projekto sudėtingumą. Teigiama tai, kad didelės DIT reikšmės reiškia, jod daugelis metodų gali būti panaudoti pakartotinai. Vaikų skaičius (NOC) Subklasės (poklasės), kurios yra tiesiogiai pavaldžios klasei, klasių hierarchijoje yra vadinamos tos klasės vaikais. Jei vaikų skaičius didėja, tai galimybė panaudoti pakartotinai didėja taip pat. Jei NOC didėja, tai testavimo (reikalingo kiekvienam vaikui atlikti jų operaciniame kontekste) kiekis taip pat didėja. Sujungimas tarp objekto klasių (CBO) CBO yra sujungimų skaičius, įrašytas į klasės sarašą jos CRC indekso lentelėje. Jei CBO didėja, tai reiškia, kad klasės tinkamumas būti panaudotai dar kartą mažėja. Didelės CBO reikšmės komplikuoja modifikacijas ir testavimą. CBO reikšmės kiekvienai klasei turi būti laikomos kuo mažesnės. Klasės atsakymas (RFC) Klasės atsakymų rinkinys tai metodų rinkinys, kuris gali būti vykdomas atsakant į pranešimą, gautą tos klasės objekto. Jei RFC didėja, tai pastangos, reikalingos testavimui, taip pat didėja, nes didėja patikrinimų skaičius. Jei RFC didėja, tai bendras projekto klasės sudėtingumas taip pat didėja. Sąryšių tarp metodų stoka (LCOM) LCOM yra metodų, kurie turi vieną ar daugiau vienodų atributų, Skaičius. Jei nė vienas iš metodų neturi tokių pat atributų, tai LCOM=0. Jei LCOM reikšmė yra didelė, tai metodai gali būti sujungiami vienas su kitu per atributus. Tai padidina klasės projekto sudėtingumą. 87

89 Į klasę orientuotos metrikos MOOD metrikų rinkinys Metodo paveldėjimo veiksnys (MIF) Sujungimo veiksnys (CF) Metodo paveldėjimo veiksnys (MIF) Laipsnis, kuriuo OO sistemos klasės architektūra panaudoja tiek metodų (operacijų), tiek atributų paveldimumą, yra apibrėžiamas taip: MIF= Mi(Ci)/ Ma(Ci), kur i=1..tc MIF reikšmė rodo paveldėjimo lygį OO programinėje įrangoje. Sujungimo veiksnys (CF) MOOD metrikų rinkinys sujungimą apibrėžia taip: CF= i j is_client(ci,cj)/(tc2 Tc), kur i=1..tc j=1..tc Didėjant CF reikšmei, OO programinės įrangos sudėtingumas taip pat didėja. Dėl to gali nukentėti programinės įrangos suprantamumas, palaikomumas ir galimybė pakartotinai naudoti Objektiškai orientuotos metrikos pagal Lorenz ir Kidd Lorenz ir Kidd klase paremtas metrikas skirsto į keturias plačias kategorijas: dydis paveldimumas vidinės aplinkybės išorinės aplinkybės Klasės dydis (CS) Bendrą klasės dydį apibūdina: Bendras operacijų, esančių klasėje, skaičius. Klasės atributų skaičius. Didelės CS reikšmės gali sumažinti pakartotinį klasės panaudojimą ir komplikuoti įdiegimą bei testavimą. Subklasės pridėtų operacijų skaičius (NOA) Subklasės specializuojamos pridedant operacijas ir atributus. Kai klasių hierarchijos lygis išauga (DIT tampa didelis), žemesnių hierarchijos lygių NOA reikšmė sumažėja. Į operacijas orientuotos metrikos Vidutinis operacijos dydis (OSvid) tai vidutinis pranešimų, kuriuos išsiuntė operacija, skaičius. Operacijos sudėtingumas (OC) apskaičiuojamas naudojant bet kurią iš sudėtingumo metrikų. Vidutinis operacijos parametrų skaičius (NPvid) kuo didesnis operacijos parametrų skaičius, tuo sudėtingesnis bendradarbiavimas tarp objektų. 88

90 7.7. Vartotojo sąsajos projektavimo metrikos Išdėstymo tinkamumas absoliuti ir reliatyvi kiekvieno ekrane išdėstyto elemento (grafinės ikonos, tekstas, meniu, langai) pozicija, to elemento naudojimo dažnumas ir perėjimo nuo vieno elemento prie kito kaštai rodo vartotojo sąsajos tinkamumą. Ekrano sąryšis apibūdina ryšį tarp dviejų ekranų turinių Programinio kodo metrikos Bendram programos ilgiui, minimaliam algoritmo dydžiui, programos lygiui, kalbos lygiui ir tokioms savybėms kaip vystymo pastangos, vystymo laikas, projekto klaidų skaičius, nustatyti yra naudojami tokie paprasti matai: n1 skirtingų operatorių, esančių programoje, skaičius; n2 skirtingų operandų, esančių programoje, skaičius; N1 bendras operatorių skaičius; N2 bendras operandų skaičius. Ilgis N gali būti apskaičiuotas taip: N=n1log2n1+log2n2 Programos dydis gali būti apibrėžtas taip: V=Nlog2(n1+n2) 7.9. Testavimo metrikos Pasak Halsted, taikant programos dydžio (V) ir programos lygio (PL) apibrėžimus, testavimo pastangos e gali būti apskaičiuojamos taip: PL=1/[n1/2)*(N2/n2)] e=v/pl Bendras modulio k testavimo pastangų procentas gali būti apskaičiuojamas pagal tokią išraišką: testavimo pastangų procentas (k)=e(k)/ e(i) Objektiškai orientuoto testavimo metrikos Sąryšių tarp metodų stoka (LCOM) kuo didesnė LCOM reikšmė, tuo daugiau būsenų turi būti testuojama, siekiant įsitikinti, kad metodai nesukelia šalutinio poveikio. 89

91 Viešumo ir saugumo procentas (PAP) ši metrika rodo viešų ir apsaugotų klasės atributų procentą. Viešas priėjimas prie duomenų (PAD) ši metrika rodo klasių (ar metodų), galinčių prieiti prie kitų klasių atributų, skaičių. Tėvinių klasių skaičius (NOR) ši metrika rodo skirtingų klasės hierarchijų, aprašytų projektavimo modelyje, skaičių. Fan-in (FIN) OO kontekste Fan-in paveldėjimo hierarchijai yra daugialypio paveldimumo požymis. Vaikų skaičius (NOC) ir paveldėjimo medžo gylis (DIT) superklasės metodai, turi būti dar kartą testuojami su kiekviena poklase Priežiūros metrikos Programinės įrangos brandumo indeksas (SMI) rodo programinės įrangos produkto stabilumą (patvarumą). Programinės įrangos brandumo indeksas yra apskaičiuojamas taip: SMI=[MT-(Fa+Fc+Fd)]/MT, MT modulių skaičius dabartinėje versijoje; Fc modulių, pakeistų dabartinėje versijoje, skaičius; Fa modulių, pridėtų dabartinėje versijoje, skaičius; Fd ankstesnės versijos modulių, ištrintų dabartinėje versijoje, skaičius. REIKŠMINIAI ŽODŽIAI / KEY WORDS Programinės įrangos gaminių linija, savybių modelis, kokybės požymiai, prižiūrimumas, struktūrinis sudėtingumas. Software product line, Feature model, Quality attributes, Maintainability, Structural. REKOMENDUOJAMI SKAITINIAI Projekto aprašymo ir įvertinimo pavyzdžiai straipsniuose, kurie buvo daugiausia kartų atsisiųsti 2011 m. iš ACM Computing IGMETRICS Special Interest Group on Measurement and Evaluation [žiūrėta ], D= &CFTOKEN= Sąrašas pateiktas kaip gautas, kad būtų lengviau rasti. Norinčiuosius skaityti straipsnių tekstus mokymosi tikslais prašome kreiptis į dėstytoją. 1. SensLoc: sensing everyday places and paths using less energy Donnie H. Kim, Younghun Kim, Deborah Estrin, Mani B. Srivastava 2. Cooperative transit tracking using smart-phones Arvind Thiagarajan, James Biagioni, Tomas Gerlich, Jakob Eriksson 90

92 3. Sensing meets mobile social networks: the design, implementation and evaluation of the CenceMe application Emiliano Miluzzo, Nicholas D. Lane, Kristóf Fodor, Ronald Peterson, Hong Lu, Mirco Musolesi, Shane B. Eisenman, Xiao Zheng, Andrew T. Campbell 4. The Jigsaw continuous sensing engine for mobile phone applications Hong Lu, Jun Yang, Zhigang Liu, Nicholas D. Lane, Tanzeem Choudhury, Andrew T. Campbell 5. Code in the air: simplifying sensing on smartphones Tim Kaler, John Patrick Lynch, Timothy Peng, Lenin Ravindranath, Arvind Thiagarajan, Hari Balakrishnan, Sam Madden 6. Design and evaluation of a versatile and efficient receiver-initiated link layer for low-power wireless Prabal Dutta, Stephen Dawson-Haggerty, Yin Chen, Chieh-Jan Mike Liang, Andreas Terzis 7. CloudCmp: comparing public cloud providers Ang Li, Xiaowei Yang, Srikanth Kandula, Ming Zhang 8. AutoWitness: locating and tracking stolen property while tolerating GPS and radio outages Santanu Guha, Kurt Plarre, Daniel Lissner, Somnath Mitra, Bhagavathy Krishna, Prabal Dutta, Santosh Kumar 9. Evolution and sustainability of a wildlife monitoring sensor network Vladimir Dyo, Stephen A. Ellwood, David W. Macdonald, Andrew Markham, Cecilia Mascolo, Bence Pásztor, Salvatore Scellato,Niki Trigoni, Ricklef Wohlers, Kharsim Yousef 10. Directed diffusion: a scalable and robust communication paradigm for sensor networks Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin NAUDOTA LITERATŪRA Bagheri, E., Dragan Gasevic, D., Assessing the maintainability of software product line feature models using structural metrics, Software quality journal, Vol. 19, N. 3, p , DOI: /s ISO 9126 Software Quality Characteristics. (2009) [žiūrėta ]. Prieiga per internetą: < ISO/IEC :2001 Software engineering Product quality Part 1: Quality modelį. 91

93 8. Programinės įrangos kokybės valdymas 8.1. Kokybės apibrėžimas Literatūroje galima rasti daugybę požiūrių į kokybę ir įvairių kokybės modelių (McCall et al., 1977; Boehm et al., 1978; Bowen, 1985; ISO , ISO 9241:11, ISO 13407). Jie yra tyrinėjami specialiose kokybės valdymui skirtose disciplinose. Šiame skyriuje trumpai apžvelgsime praktiniam taikymui reikalingus terminus ir patogiausius modelius. Šiuolaikinės kokybės valdymo pradininku laikomas amerikietis W. Edvardsas Demingas. Jis pritaikė statistinius metodus masinės gamybos kokybės kontrolei XX a. 3-iajame dešimtmetyje. Iš jų jis suprato, kad kokybės kontrolė yra pagrista nukrypimų kontrole (Deming, 1988). Demingo amžininkas J. M. Džuranas pateikė šį pagrindinį kokybės apibrėžimą: kokybė tai tinkamumas naudoti. Tada klientas yra kokybės valdymo reikšmingumo centre (Juran, 1988). Džuranas laikėsi nuomonės, kad labiausiai už kokybės valdymą atsakingi aukštesnės grandies organizacijos vadovai, kurie turi užtikrinti kokybės planavimą, kokybės kontrolę ir kokybės tobulinimą. Iki XX a. 9-ojo dešimtmečio Demingo ir Džurano idėjos Vakarų šalyse buvo ignoruojamos, tačiau Japonijoje tomis idėjomis buvo remiamasi. Sistemiškai įdiegę kokybės valdymą, japonai sugebėjo taip pagerinti savo produktų kokybę, kad daugeliu atvejų jie pralenkė Amerikos ar Europos produktus. Ši japonų veikla lėmė didelį pasaulio susidomėjimą kokybės valdymu. Dabar daugelis organizacijų metodiškai įgyvendina kokybės valdymą savo veikloje. Kokybės valdymo guru Philipas Bayardas Crosby apibrėžė kokybės įgyvendinimo principą: daryk teisingai iš pirmo karto (angl. doing it right the first time DIRFT). Jis pasiūlė keturis pagrindinius principus: kokybė yra reikalavimų atitikimas (reikalavimai reiškia produkto specifikacijas ir kliento reikalavimus), kokybės sistema yra prevencija, kokybės standartas yra nulis defektų, neatitikimo kaina yra kokybės matas. Valstybių vyriausybės taip pat kelia kokybės reikalavimus produktams, nustato produktų saugumo, sveikatos ir aplinkos apsaugos reikalavimus. Prekės, tenkinančios 92

94 šiuos esminius reikalavimus, pažymimos CE ženklu. Kai kuriais atvejais CE žymėti leidžiama tik tada, kai įmonė, gaminanti produktą, naudoja kokybės sistemą, įdiegtą EN-ISO 9001 pagrindu. Pirmieji tarptautiniai kokybės standartai ISO 9000 buvo paskelbti 1987 m. Egzistuoja du požiūriai į programinės įrangos kokybę: 1. Vartotojo poreikių tenkinimas tinkamumas naudoti. 2. Specifikacijų atitikimas: prekių ir paslaugų kokybę apibrėžia išmatuojamos charakteristikos (atributai), kurios atitinka fiksuotą, iš anksto apibrėžtą specifikaciją. Programų inžinerijoje yra glaudžiai susiję: vartotojo pasitenkinimas = produkto kokybė + reikalavimų tenkinimas + pateikimas laiku + atitinkama kaina. Trumpai programinės įrangos kokybę galima apibūdinti kaip charakteristikų (atributų) kolekciją. Atributai detaliai bus aptarti kituose skyriuose Programinės įrangos kokybės valdymo procesas Kokybiška PĮ turi atitikti jai keliamus funkcionalumo bei efektyvumo reikalavimus ir reikalavimus, kurių tikimasi iš bet kurios geros PĮ. PĮ turi būti kuriama pagal apibrėžtus PĮ kūrimo standartus. Tačiau aukštai produkto kokybei pasiekti neužtenka biurokratiškai laikytis standartų, reikalingas kokybės valdymas (angl. Quality management). 8.1 pav. Kokybės valdymas ir programinės įrangos kūrimas (Sommerville, 2007) Kokybės valdymas yra procesas, apibrėžiantis, kaip gali būti pasiekta PĮ kokybė ir kaip projektavimo organizacija sužino, kad PĮ turi reikiamą kokybės lygmenį. Kokybės valdymo veiklos yra šios: 93

95 Kokybės užtikrinimas nustatyti organizacines procedūras ir standartus, kurie lemia aukštą PĮ kokybę. Kokybės planavimas pasirinkti tinkamas procedūras ir standartus konkrečiame projekte ir pakeisti juos pagal reikalavimus. Kokybės kontrolė garantuoti, kad kuriant programinę įrangą būtų laikomasi procedūrų ir standartų. Nepriklausomybei užtikrinti kokybės valdymas turėtų būti atskirtas nuo projekto valdymo pav. pavaizduota, kaip kokybės valdymo proceso metu tikrinami projekto rezultatus (angl. deliverables), siekiant užtikrinti, kad jie atitiks organizacijos standartus ir tikslus Programinės įrangos kokybės užtikrinimas pagal standartus Kokybės valdymas tiesiogiai susijęs su standartais, kurie yra dvejopi: produkto standartai ir proceso standartai. Standartų lygmenys: tarptautiniai, valstybiniai, organizacijos ir projekto. Kokybės valdymo tarnybos savo organizacijų standartus grindžia nacionaliniais ir tarptautiniais standartais. Standartai yra pagrindas efektyviam kokybės valdymui. Įmonės ar projekto standartai surašomi į standartų vadovą. Produkto standartų pavyzdžiai: Reikalavimų aprašymo dokumento struktūra Metodo antraštės formatas Java programavimo stilius Projekto plano formatas Pakeitimų poreikio forma Proceso standartų pavyzdžiai: Versijų leidimo procesas Projekto plano patvirtinimo procesas Pakeitimų valdymo procesas Testo įrašymo procesas Organizacijos turi pasirinkti ir taikyti įrankius bei metodus, palaikančius šiuos standartus. Kad projektuotojai noriai taikytų standartus, projekte rekomenduojama: 1. Įtraukti specialistus į standartų kūrimą. 2. Reguliariai peržiūrėti standartus ir jų naudojimą keičiantis technologijoms. 3. Naudoti programinės įrangos įrankius, kurie palaiko standartus. Įvairi programinė įranga kuriama taikant skirtingus procesus. Procesų standartai turėtų tikti projektuotojų komandai, todėl jei taip nėra, aptarus su kokybės valdymo tarnyba, proceso standartai gali būti pakeisti Tarptautiniai standartai detaliai apibūdinti 3-ioje temoje Programų inžinerijos standartų prigimtis ir vaidmuo. Programinės įrangos produkto įvertinimo standartas ISO 9126 (Software Product Evaluation: Quality Characteristics and Guidelines for their Use-standard) yra 94

96 pagrįstas ir struktūrizuotas kaip McCall ir Boehm modeliai (3.1 pav.), turi funkcionalumo parametrą, taip pat identifikuoja vidines ir išorines programinės įrangos produkto charakteristikas. 8.2 pav. ISO 9126 apibrėžiamos PĮ kokybės charakteristikos ir jų vidinės bei išorinės dedamosios (Berander et al., 2005) ISO 9126 PĮ kokybės charakteristikos ir jų vidinės bei išorinės dedamosios apibrėžiamos taip: Funkcionalumas (angl. Functionality): aibė atributų, susijusių su egzistuojančių funkcijų aibe ir jų specifikuotomis savybėmis (angl. properties). Funkcijos yra tos, kurios tenkina nurodytuosius ar numatytuosius poreikius. Funkcionalumo dedamosios charakteristikos: - Tinkamumas (angl. Suitability): PĮ atributas, susijęs su buvimu ir tinkamumu funkcijų, reikalingų specifikuotoms užduotims. - Tikslumas (angl. Accuracy): PĮ atributas, kuris apibūdina pateikimą teisingų ar sutartų rezultatų ar efektų. - Saugumas (angl. Security): PĮ atributas, susijęs su programinės įrangos gebėjimu užkirsti kelią nesankcionuotai, atsitiktinei ar tyčinei programų ir duomenų prieigai. - Sąveikavimas (angl. Interoperability): PĮ atributas, susijęs su programinės įrangos gebėjimu sąveikauti su specifikuotomis sistemomis. - Laikymasis (angl. Compliance): PĮ atributas, kuris apibūdina, kaip programinė įranga laikosi su taikymu susijusių standartų, konvencijų, taisyklių, įstatymų ir panašių nurodymų. 95

97 Patikimumas (angl. Reliability): aibė PĮ atributų, susijusių su programinės įrangos pajėgumu nurodytomis sąlygomis išlaikyti savo veikimo lygį nustatytą laiko periodą. - Branda (angl. Maturity): PĮ atributas, susijęs su programinės įrangos gedimų dažnumu. - Atsparumas defektams (angl. Fault tolerance): PĮ atributas, susijęs su programinės įrangos gebėjimu išlaikyti specifikuotą veikimo lygmenį įvykus gedimui arba pažeidus specifikuotą sąsają. - Atgautinumas, išgydomumas (angl. Recoverability): PĮ atributas, susijęs su programinės įrangos gebėjimu per tam tikrą laiką ir reikalingomis pastangomis atkurti savo veikimo lygmenį ar tiesiogiai paveiktus duomenis gedimo atveju. - Laikymasis (angl. Compliance): PĮ atributas, kuris apibūdina, kaip programinė įranga laikosi su taikymu susijusių standartų, konvencijų, taisyklių, įstatymų ir panašių nurodymų. Naudojamumas (angl. Usability): aibė atributų, susijusių su vartotojo pastangomis vartoti ir pagrįsti individualiu vartojimo įvertinimu, pareikštu arba numanomu aibės vartotojų. - Suprantamumas (angl. Understandability): PĮ atributas, susijęs su vartotojų pastangomis suprasti loginę koncepciją ir jo pritaikomumą. - Išmokstamumas (angl. Learnability): PĮ atributas, susijęs su vartotojų pastangomis išmokti dirbti taikomąja PĮ, pvz., valdyti veikimą, įvesti, išvesti). - Operuojamumas (angl. Operability): PĮ atributas, susijęs su vartotojų pastangomis paleisti programą ir valdyti programos darbą. - Patrauklumas (angl. Attractiveness): tai nereikalauja komentarų. - Laikymasis (angl. Compliance): PĮ atributas, kuris apibūdina, kaip programinė įranga laikosi su taikymu susijusių standartų, konvencijų, taisyklių, įstatymų ir panašių nurodymų. Efektyvumas (angl. Efficiency): aibė atributų, susijusių su programinės įrangos veikimo nustatytomis sąlygomis lygmens santykiu su naudojamų išteklių dydžiu. - Funkcionavimo laikas (angl. Time behaviour): PĮ atributas, susijęs su reagavimo ir apdorojimo laiku našiai vykdant jo funkciją. - Elgesys su ištekliais (angl. Resource behaviour): PĮ atributas, susijęs su naudojamų išteklių kiekiu ir jų naudojimo trukme vykdant PĮ fukcijas. - Laikymasis (angl. Compliance): kaip aukščiau. Palaikomumas (angl. Maintainability): aibė atributų, susijusių su pastangomis atlikti specifikuotas modifikacijas. - Analizuojamumas (angl. Analyzability): PĮ atributas, susijęs su pastangomis, reikalingomis diagnozuoti trūkumus ar trikių priežastis, taip pat identifikuoti dalis, kurias reikia modifikuoti. 96

98 - Keičiamumas (angl. Changeability): PĮ atributai, susiję su pastangomis modifikuoti PĮ, pašalinti trikį ar pakeisti aplinką. - Stabilumas (angl. Stability): PĮ atributai, susiję su modifikacijų netikėtų efektų rizika. - Testuojamumas (angl. Testability): PĮ atributai, susiję su pastangomis validuoti modifikuotą programinę įrangą. - Laikymasis (angl. Compliance): kaip aukščiau. Pernešamumas (angl. Portability): aibė atributų, susijusių su programinės įrangos gebėjimu būti perkeltai iš vienos aplinkos į kitą. - Prisitaikymas (angl. Adaptability): PĮ atributai, susiję su galimybe adaptuotis prie įvairių aplinkų neatliekant kitų veiksmų ar priemonių, išskyrus tas, kurios numatytos analizuojamoje PĮ. - Instaliuojamumas (angl. Installability): PĮ atributai, susiję su pastangomis, reikalingomis instaliuoti programinę įrangą numatytoje aplinkoje. - Atitiktis (angl. Conformance): PĮ atributai, kurie padaro programinę įrangą atitinkančią standartus ar susitarimus, susijusius su pernešamumu. - Pakeičiamumas (angl. Replaceability): PĮ atributai, susiję su galimybėmis ir pastangomis naudoti šią programinę įrangą specifikuotoje vietoje kitos įrangos ir tos įrangos aplinkoje. Programų inžinerijoje pasitaiko, kad stengiantis pagerinti vieną kokybės atributą, pablogėja kitas. Pavyzdžiui, gerinant efektyvumą, pablogėja pernešamumas Kokybės planavimas Kokybės planas nustato norimą produkto kokybę ir tai, kaip ji vertinama; taip pat apibūdina reikšmingiausius kokybės požymius. Kokybės planas turėtų nustatyti kokybės vertinimo procesus. Taip pat turėtų nustatyti, kuris organizacijos standartas turėtų būti naudojamas, ir jei reikia nustatyti naujus standartus. Kokybės planai turėtų būti trumpi, glausti dokumentai, jei jie per ilgi, niekas jų neskaitys. Rekomenduojama tokia kokybės plano struktūra: 1. Produkto apibūdinimas: aprašymas, jo būsima rinka, laukiama produkto kokybė. 2. Produkto planai: kritinės leidimo datos, kas atsakingas už produktą iki jo pateikimo vartotojams ir aptarnavimo. 3. Proceso apibūdinimas: produkto sukūrimo ir aptarnavimo bei valdymo procesų aprašymas. 4. Kokybės tikslai: produkto kokybės tikslai ir planai, kritinių kokybės atributų išanalizavimas. 5. Rizika ir rizikos valdymas: svarbiausios rizikos, kurios gali paveikti produkto kokybę, ir veiksmai, skirti toms rinkoms. 97

99 8.5. Kokybės kontrolė Kokybės kontrolė apima programinės įrangos kūrimo procesų patikrinimą, kad užtikrintų procedūrų ir standartų laikymąsi. Kokybės kontrolės būdai yra du: Kokybės patikrinimas (peržiūra). Grupė asmenų tikrina PĮ, dokumentaciją ir kuriant naudotus procesus. Tikrinama, kaip laikomasi projekto standartų ir ar PĮ bei dokumentacija tenkina tuos standartus. Nukrypimai nuo standartų užfiksuojami, ir projekto vadovas įspėjamas. Peržiūra turi būti ne ilgesnė kaip 2 val., padeda projekto grupės narys. Automatinis programinės įrangos vertinimas ir matavimas. PĮ ir sukurti dokumentai apdorojami tam tikros programos lyginant su standartais. Gali būti matuojami kai kurie atributai, lyginant juos su siektinais lygmenimis. Kokybės patikrinimas yra plačiai taikomas. Patikrinimo išvados yra formaliai protokoluojamos ir perduodamos asmeniui, kuris atsakingas už aptiktų problemų koregavimą. Patikrinimai neapsiroboja specifikacijomis, projektavimu ar kodu. Taip pat peržiūrimi testavimo planai, konfigūracijos, valdymo procedūros, proceso standartai ir vartotojų vadovai. Reikia pažymėti, kad yra dar keli patikrinimo (peržiūros) tipai: 1. Projektavimo ir kodo inspekcijos. Jų tikslas aptikti klaidas ir patikrinti, ar laikomasi reikalavimų specifikacijų. Kodo inspekcija organizuojama pagal klaidų sąrašą. 2. Progreso patikrinimas (vadybininko peržiūra). Šis peržiūros tipas iš esmės apima sąnaudas, planus ir darbų grafikus. Valdymo peržiūros yra svarbūs projekto kontroliniai taškai, kuriuose yra priimami sprendiniai apie tolesnius projektavimo žingsnius Programinės įrangos gebėjimų brandos modeliai Karčiauskas ir kiti straipsnyje Programinės įrangos kūrimo procesų gerinimo modelių įrankiai,rašo, kad siekiant užtikrinti produkto ar paslaugų kokybę, valdant programų kūrimą naudojami programų kūrimo proceso brandos modeliai, specifikuojantys procesus ir jų atributus, užtikrinančius kokybišką programų kūrimą. Programinės įrangos gebėjimų brandos modeliai sparčiai auganti programų inžinerijos sritis, pradėjusi plėtotis 8-ojo dešimtmečio antrojoje pusėje JAV, kai buvo sukurtas trumpas procesų brandos karkaso aprašymas ir brandumo klausimynas. Pagal jį buvo galima nustatyti, kurias organizacijos programinių produktų kūrimo proceso vietas reikėtų gerinti. Kiek vėliau, remiantis sukauptais programinių produktų kūrimo procesų įvertinimo duomenimis, buvo sukurtas programinių produktų kūrimo proceso gebėjimų brandos modelis SW-CMM (angl. Capability Maturity Model for Software). Jis turėjo nemažą pasisekimą, didėjo poreikis taikyti šį modelį kitose srityse (pvz., sistemų inžinerijoje), todėl jis skilo, t. y. buvo išplėtotos kelios šio modelio versijos (SE, SSE, SA, IPD, 98

100 P-CMM (angl. People Capability Maturity Model)). Kiek vėliau atsirado nauja integruota CMM versija CMMI. Lygiagrečiai su CMM šeimos modeliais buvo kuriamas europietiškasis atsakas šiems modeliams: ISO/IEC 15504, pradedant 1993 metais. Esminis skirtumas nuo SW-CMM buvo ne organizacijų, bet raktinių procesų vertinimas (tolydinis vaizdavimas). Reikia paminėti, kad kuriant CMMI modelį buvo pasinaudota ir ISO/IEC standarto patirtimi. CMMI modelis turi tiek pakopinį, tiek tolydųjį vaizdavimą, todėl yra suderinamas su ISO/IEC modeliu. Stebint programinės įrangos kokybės standartų, modelių ir metodikų evoliuciją, galima išskirti tokias stadijas: sukūrimas, skilimas arba pavienių versijų plėtojimas, integracija ir konsolidacija (Karčiauskas ir kt., 2005). Skilimui paprastai turi įtakos sėkmingas modelio taikymas tam tikroje srityje. Tuomet mėginama jį adaptuoti kitose srityse. Ilgainiui atsiranda poreikis turėti apibendrintą vientisą modelį, todėl kuriamas integruotas modelis, kartu atsižvelgiant į tuometinius konkurentų sprendimus. Minėtas amerikietiškas CMM ir europietiškas ISO/ IEC (SPICE) plėtojami nuolat įtraukiant vienas kito patirtį (Capability, 2002; ISO,1998) Žmogiškųjų išteklių gebėjimų brandos modelis CMM modeliui palaikyti Amerikos programų inžinerijos institutas (Software Engineering Institute) pasiūlė Žmonių gebėjimų brandos modelį (P-CMM People Capability Maturity Model), kuris gali būti naudojamas kaip sistema, skirta patobulinti žmogiškųjų išteklių valdymo būdą organizacijoje. P-CMM yra penkių lygmenų modelis: 1. Pradinis (angl. Initial) Ad hoc neformali žmonių valdymo praktika. 2. Kartojamas (angl. Repeatable) darbuotojų gebėjimų vystymo politikos sukūrimas. Į žmonių veiklas diegiamas disciplinuotumas. 3. Apibrėžtas (angl. Defined) gerosios žmogiškųjų išteklių valdymo patirties standartizavimas. Identifikuojamos pradinės kompetencijos ir joms priderinamos žmogiškųjų išteklių veiklos. 4. Valdomas (angl. Managed) kiekybiniais parametrais valdomas organizacijos augimas, žmogiškųjų išteklių gebėjimų augimas ir kompetencija grįstos komandos sukūrimas. 5. Optimizuojantis (angl. Optimizing) asmeninės ir organizacijos kompetencijos tobulinimo metodų nuolatinis gerinimas (Sommerville, 2007) Programinės įrangos gebėjimų brandos modelių programinės priemonės Visą programinę įrangą, skirtą gebėjimų brandos modeliams diegti ir palaikyti, galima skirstyti pagal palaikomąjį modelį, t. y. CMMI arba ISO/IEC modelius. Kitas skirstymo aspektas tai atvirojo kodo ir komercinė programinė įranga. Nagrinė- 99

101 jant atvirojo kodo programinę įrangą galima atkreipti dėmesį į tai, kad daugiau žinomų įrankių sukurta CMM šeimos modeliams. Be abejonės, yra sukurtų nekomercinių įrankių ir ISO/IEC modeliams. Bet tai daugiausia tiriamoji programinė įranga. Atvirojo kodo programinė įranga labiau orientuota arba į paties modelio atvaizdavimą, arba į bazinius skaičiavimus (t. y. skaičiavimus, kurie yra būtini vertinimams), o vertinimo duomenų vizualizavimo posistemis yra išplėtotas silpniau nei komercinėse programose, labai mažai dėmesio skiriama proceso diegimui ir gerinimui palaikyti. Gebėjimų brandos modelių įrankių kūrėjus domina modelių tobulinimo karkasai. Deja, komercinės programinės įrangos kūrėjai neatskleidžia savo kuriamų įrankių ir medžiagos tobulinimo metodikų. Tuo tarpu atvirojo kodo programinė įranga yra daryta atskirų žmonių ir dažniausiai ji neturi brandžios kūrimo metodikos. CMM Europos versija buvo ESPRIT projektas Bootstrap, inicijuotas Austrijos Grrass technikos universiteto Programų inžinerijos instituto. Jie sukūrė programų sistemą SPICE / ISO Proceso įvertinimas, vėliau daugelį kitų programinės įrangos vertinimo paketų: SPICE- Lite ir SPICE121 ir t. t. (HM&S IT-Consulting GmbH). Lietuvoje Vilniaus universitetui ir KTU inicijavus projektą Brandaus programų kūrimo proceso įdiegimo metodikos ir instrumentinių priemonių sukūrimas (PKP BRANDA), 2003 m. buvo atlikta mokslinė egzistuojančių brandos gebėjimo modelių analizė, sukurtas modelis SPICE pagrindu PKP BRANDA programų kūrimo proceso modelis Brandaus programų kūrimo proceso modelio paskirtis suteikti pagrindą proceso apibrėžimui ir vertinimui, užtikrinant, kad proceso apibrėžimas bei vertinimo rezultatai remiasi programų kūrimo proceso inžinerijos geriausia patirtimi, yra sulyginami su kitų vertinimų rezultatais ir dera su pasaulyje pripažintais standartais. PKP BRANDA programų kūrimo procesų modelis (8.3 pav.) yra tolydinės architektūros. Tolydinės architektūros modelis leidžia įvertinti kiekvieno vardinio proceso gebėjimą, organizacijos įvertinimas yra vardinių procesų gebėjimų lygių profilis, parodantis organizacijos silpnąsias ir stipriąsias puses. Brandaus programų kūrimo proceso charakteristikos išskiriamos į procesų ir brandos dimensijas. Procesų dimensija apibrėžiama nusakant programų kūrimo procesų kategorijas, pačius vardinius procesus, procesų tikslus, rezultatus, naudojamus ir kuriamus darbo produktus ir bazines praktikas. Brandos dimensija apibrėžiama proceso atributais, kuriais turi pasižymėti vardiniai procesai ir kurie modeliuoja išmatuojamas kokybines proceso charakteristikas, įgyvendinamas bendrosiomis praktikomis, bendriniais ištekliais ir bendriniais darbo produktais. 100

102 8.3 pav. PKP BRANDA programų kūrimo proceso modelis PKP Branda brandaus programų kūrimo proceso modelio procesų dimensiją sudaro 9 procesų kategorijos ir 48 vardiniai procesai, brandos dimensiją sudaro 5 brandos lygiai ir 9 proceso atributai m. sukurta programų sistema, apimanti tiek tobulinimo aplinką, tiek vertinimų posistemį. Daug dėmesio buvo skirta paskirstytajai tobulinimo aplinkai kurti, nes buvo numatoma, kad projekte dalyvaujančių universitetų bendruomenės galės palaikyti modelio tobulinimą ir pasibaigus projektui (PKP BRANDA). Programų sistemą galima atsisiųsti iš PKP Branda svetainės Naujienų tinklalapio ( lt/pkp/pkbm/) Kaip kokybė susijusi su projekto valdymo trikampiu Kiekvieno projekto vadovai kasdien taiko vieną svarbiausių projekto valdymo principų: kainos (angl. Cost), apimties (angl. Scope) ir laiko (angl. Time) trikampį (8.4 pav.). Trikampio kraštinės vaizduoja kiekvieno projekto tris pagrindinius apribojimus: kainą, apimtį ir laiką. Šio trikampio viduje yra vaizduojama kokybė (angl. Quality), arba projekto sėkmė. 101

103 8.4 pav. Projekto valdymo principas: trikampis kaina apimtis laikas (Christy, 2011) Valdymo principo esmė ta, kad kiekviena iš trikampio kraštinių yra susieta su kitomis dviem. Žemiau pateikti paveikslai iliustruoja, kaip vieno kintamojo pakeitimas veikia trikampį. 1 pavyzdys: jei projekto laikas numatytas trumpas, sumažės projekto apimtis ir/ arba išaugs kaina, planas turi būti labai detalus (8.5 pav.). 8.5 pav. Projekto valdymo principas: trikampis kaina apimtis laikas. Sutrumpinta projekto trukmė (Christy, 2011) 102

104 2 pavyzdys: jei projekto laikas ilgas, biudžetas (kaina) gali būti mažas (8.6 pav.). Šis pavyzdys tinka rangovams, kurie neturi išteklų ir galimybių. 8.6 pav. Projekto valdymo principas: trikampis kaina apimtis laikas. Pailginta projekto trukmė (Christy, 2011) 8.8. Kuo skiriasi PĮ kokybės valdymas nuo testavimo Bareiša ir kiti akcentuoja, kad PĮ kokybės valdymas yra artimai susijęs su PĮ testavimu. Dargi kai kuriose organizacijose šios dvi veiklos nėra atskiriamos. Tačiau iš tikrųjų tai skirtingi dalykai. Kokybės užtikrinimas yra valdymo funkcija, o testavimas PĮ projektavimo proceso dalis (Bareiša ir kt., 2003). Organizacijos ribose kokybės užtikrinimu turi rūpintis atskira darbo grupė, atsiskaitanti aukštesniojo lygio vadovams, t. y. apeinant projekto valdymo lygmenį. Kokybės užtikrinimo grupė turi būti nesusieta su jokia konkrečia projektavimo grupe ir atsakinga už projektų kokybę visos organizacijos ribose. Kitas esminis skirtumas yra tas, kad testavimo užduotis yra klaidų aptikimas, o kokybės užtikrinimas yra platesnė sąvoka. Kokybės užtikrinimas didesnį dėmesį skiria PĮ patikimumui, mobilumui, palaikomumui, naudingumui ir t. t. Svarbi kokybės užtikrinimo grupės užduotis yra palaikyti viso PĮ gyvavimo ciklo kokybę. Kokybė turi būti programinės įrangos proceso varomoji jėga. Kokybė nėra atributas, kurį galima pridėti prie produkto kažkuriame etape, visose projektavimo fazėse aukšta kokybė turi būti pagrindinis tikslas. Kokybės užtikrinimo funkcija yra paremti aukštos kokybės siekimą, o ne teisėjauti ir kritikuoti projektavimo grupę. 103

105 8.9. Santrauka Modernios kokybės valdymo teorijos papildo projektų valdymo teorijas: 1. Kliento pasitenkinimas. Supratimas, matavimas, nustatymas ir lūkesčių valdymas, kad kliento reikalavimai būtų patenkinti. Apima produkto ar paslaugos ir susitarimų atitikimą bei užtikrina, kad produktas bus realiai naudojamas. 2. Prevencija geriau negu patikrinimas. Prevencinių veiksmų įdiegimas į procesą kainuoja mažiau nei broko, pastebėto patikrinimo metu ar galutinio vartotojo, taisymas. 3. Kokybės kaina. Apima visas pastangas, susijusias su kokybės užtikrinimu per visą projektą (pvz., kokybės valdymo plano kūrimas, pastovus tobulinimas, prevencijos ir patikrinimo kaštai, broko taisymas). REIKŠMINIAI ŽODŽIAI / KEY WORDS Gebėjimo brandos modelis, komercinė programinė įranga, programinės įrangos linija, programinės įrangos kokybės užtikrinimas, patikrinimas ir patvirtinimas. CMMI: Capability Maturity Model Integrated, COTS: Commercial Off-the-Shelf Software, PDCA: Plan, Do, Check, Act, SQA: Software Quality Assurance, SQM: Software Quality Management, TQM: Total Quality Management, V&V: Verification and Validation. REKOMENDUOJAMI SKAITINIAI Berander, P., et al. Software Quality Attributes and Trade-offs. Blekinge Institute of Technology: elektroninė knyga, 2005 [žiūrėta ]. Prieiga per internetą: bth.se/tek/besq.nsf/pages/017bd879b7c9165dc aae2!opendocument Karčiauskas, E., Blažauskas, T., Mačikėnas, E., Programinės įrangos kūrimo procesų gerinimo modelių įrankiai, ISSN Informacijos mokslai, 2005, 34 [žiūrėta ]. Prieiga per internetą: mokslai/2005_34/ pdf Minimum Expectations for a Certified Software Quality Engineer [žiūrėta ]. Prieiga per internetą: Brandaus programų kūrimo proceso įdiegimo metodikos ir instrumentinių priemonių sukūrimas (PKP BRANDA), Lietuvos valstybinis mokslo ir studijų fondas, Prieiga per internetą: Assessment Tools, HM&S IT-Consulting GmbH, Austria [žiūrėta ]. Prieiga per internetą: assess_tools.htm 104

106 NAUDOTA LITERATŪRA Crosby, P. B., Quality is free: the art of making quality certain, New York: McGraw- Hill, Deming, W. E., Out of the crisis: quality, productivity and competitive position, Cambridge Univ. Press, Juran, J. M., Juran s Quality Control Handbook, McGraw-Hill, McCall, J. A., Richards, P. K., and Walters, G. F., Factors in Software Quality, Nat l Tech. Information Service, Vol. 1, 2 and 3, Christy, N., The Project Management Triangle, R21 BLOG, Prieiga per internetą: 105

107 9. Programos ar sistemos vertinimas pagal testą. Atlikto testavimo įvertinimas 9.1. Įvadas Testavimas yra vienas iš esminių programų sistemos kūrimo etapų. Testavimas ir derinimas yra neatsiejami testavimo metu randami funkcionavimo trikdžiai, kurie yra toliau derinami, paskui vėl testuojama ir taip toliau. Testavimą galima trumpai apibrėžti kaip išsamų ir organizuotą bandymą vykdyti visus programų sistemos aspektus ieškant funkcionavimo trikdžių. Siekiant efektyviau atlikti testavimą, reikia atitinkamo pasirengimo, todėl šiame skyriuje bus aptartas testavimo planas, pabrėžta ankstyvo ir nuoseklaus testavimo svarba. Apibrėžti testavimo tikslai, paminėtos galimos problemos, kylančios atliekant testavimą, bei testavimo įtaka ne tik projektui, bet ir komandiniam darbui. Taip pat bus apžvelgta testavimo rezultatų analizė ir aptarta projekto vykdymo pabaiga, atsižvelgiant į testavimą ir esamą situaciją Programų sistemos vertinimas pagal testą Testavimo planavimas Prieš atliekant testavimą turi būti kruopščiai pasirengta ir suplanuota, iškelti aiškūs ir konkretūs tikslai. Testavimo procesas turi būti atliekamas programų sistemos kūrimo metu nuo jos pradinės stadijos, siekiant padidinti jo efektyvumą ir teikiamą naudą. Testas turi būti aiškiai apibrėžtas ir konkretus, kaip ir jo rezultatai, kuriuos vėliau reikia analizuoti, kad galima būtų nuspręsti apie programų sistemos kokybiškumą ir funkcionavimo stabilumą, ir padarius išvadas priimti atitinkamus sprendimus dėl tolesnio projekto plėtojimo. Norint panaudoti testavimą efektyviai, reikia remtis iškeltais testavimo tikslais. Be šių tikslų testavimo procesas gali turėti mažai įtakos ir teikti mažai naudos. Būtina žinoti, kas, kodėl ir kada bus testuojama. Į testavimą turi būti įtraukta visa projekto komanda, suformuotas jai svarbus ir aiškus kokybės standartas. Atliekant šiuos veiksmus didinamas testavimo efektyvumas. 106

108 Planavimas turi būti vystomas kuo anksčiau projekto metu. Negalima, kad pasiruošimas testuoti būtų vykdomas prieš pat testavimo laiką. Aiškinantis programų sistemos subtilybes ir funkcijas reikia parengti sisteminį ir priimtinumo testavimus. Sisteminis testavimas skirtas įvertinti, ar programų sistema parengta antrajam testavimui arba ar ji parengta išleisti. Priimtinumo testavimas skirtas įvertinti programų sistemos diegimo ir naudojimo priimtinumą vartotojui. Atliekant šiuos veiksmus gali iškilti naujų funkcijų trūkumas ar poreikis tobulinti ir koreguoti esamas. Projektavimo metu gali būti atliekamas integracijos testavimas. Integracijos testavimas padeda aptikti trūkumus programų sistemos struktūroje ir įgalina juos pataisyti stadijoje, kai tai galima atlikti santykinai greitai. Verta paminėti, kad testavimo planavimas padeda išvengti problemų dėl programų sistemos kūrimo grafiko. Daugelis projektų kompensuoja laiko trūkumą programai kurti trumpindami laiką, skirtą testavimui. Jei testavimas būna suplanuotas ir įtrauktas į numatytą grafiką, sumažėja tikimybė, kad testavimui bus skirta mažiau dėmesio nei būtina. Žinoma, visuomet gali įsiterpti žmogiškasis faktorius kas nors gali nuspręsti, kad šioje vietoje programų sistema yra pakankamai gera ir nebūtina atlikti daugiau testų arba kad testų rezultatai yra pakankamai geri Testavimo planas Bendru atveju testavimo planas neturi būti itin didelis, nes detalės keisis projekto vystymo metu. Plane turi būti informacija apie testavimo tipą kas bus testuojama, testavimo grafiką kada bus testuojama, kokias funkcijas konkrečiu metu atliks projekto komandos nariai, kaip bus surenkami ir analizuojami testavimo rezultatai. Kuriant didelės apimties programų sistemą, yra natūralu, kad ji bus padalinta į tam tikras dalis. Testavimo planai įgalina projekto komandą numatyti, kada bus pradedamos testuoti atskiros dalys, kad būtų išvengta nekoordinuoto testavimo: kai kurias dalis testuoti per anksti, kai kurias per vėlai, dar kitas praleisti neplanuotas ir nekoordinuotas. Neplaningas testavimas sukeltų kokybės sumažėjimą arba net funkcionalumo trūkumą. J. Henry siūlo tokią testavimo plano struktūrą: 1. Įvadas. Apibūdinami svarbiausi numatomo testavimo tipai ir jų tikslai. Šios dalies apimtis turėtų būti 3 5 paragrafai. 2. Aukšto lygio etapai. Apibrėžiami testavimo etapai, numatomos sąlygos, reiškiančios konkretaus testavimo etapo pabaigą. Natūralu, kad apibūdinant testavimo etapus svarbu suskaičiuoti, kiek jų bus, ir numatyti jų pabaigas. 3. Testavimo organizatoriai. Numatomos konkrečios užduotys programų sistemos projekto komandos nariams, atsakingiems už testavimą, ir sritys, kurių testavimas bus atliekamas. 4. Testavimo procesas. Apibūdinamas testavimo vykdymas. Šiame skirsnyje reikia numatyti, kokie duomenys bus naudojami testavimui ir kokios procedūros bus testuojamos. Taip pat, svarbu numatyti organizuotą rastų defektų stebėjimą ir galimas papildomas testavimo operacijas. 107

109 5. Testavimo metodai. Apibrėžiami testavimo metodai ir testavimui naudojama technika, kurie bus naudojami projekte. 6. Rezultatai. Apibrėžiama, kaip ir kada bus klasifikuojami testavimo ir matavimo rezultatai, kokiuose etapuose bus renkami ir apdorojami rezultatai. Turi būti įtraukti matavimo analizės principai ir taikymas. 7. Testavimo pavojai. Išnagrinėjami testavimo pavojai. Kiekvienam pavojui skiriamas paragrafas, pavojai rūšiuojami pagal tikimybę jiems įvykti ir keliamos grėsmės dydį vykdomam projektui. 8. Programiniai įrankiai. Numatomas reikalingos programinės įrangos sąrašas ir kokiuose testavimo etapuose ji bus panaudota. 9. Testavimo parama. Šiame skyriuje turi būti įtraukta informacija apie būtinas sąlygas, kurių reikia siekiant korektiškai atlikti testavimą. Taip pat apibūdinti testavimo struktūros, įgyvendinimo ir diegimo aspektai, būtini, kad testavimas veiktų. Taip pat svarbu numatyti programinę ar techninę įrangą, kuri turi būti gauta ir įdiegta ar atnaujinta ir kuri bus reikalinga testuojant programų sistemą. 10. Personalo parama. Šiame, paskutiniame, skyriuje turi būti nurodoma informacija apie konkrečius asmenis ar jų grupes, kurie padės už testavimą atsakingiems asmenims jo metu. Taip pat reikia numatyti, už kuriuos etapus jie bus atsakingi (Henry, 2004). IEEE testavimo plano šablonas kartu su pavyzdžiu yra prieinamas saityne adresu: Pastaba: Programų sistemų inžinerijos magistrinio projekto Testavimo plano šablonas pateiktas 9A priede Testavimo tikslai Testavimą reikia suprasti teisingai, jo tikslas ne įrodyti, kad defektų nėra, bet juos surasti. Testuojant konkrečias programų sistemos dalis, tikslas gali būti patikrinti kiekvieną dalį ir testavimo metu suaktyvinti kiekvieną esamą kodo dalį, siekiant rasti galimus defektus. Sisteminio testavimo tikslas gali būti patikrinti kiekvieną galimą ir aprašytą programų sistemos vartotojo elgesio scenarijų, kiekvieną funkciją, kurią galima akivaizdžiai pasiekti arba kurios, tikėtina, bus naudojamos dažnai. Iškelti konkretūs tikslai leidžia sukonkretinti testavimą ir numatyti konkrečios srities testavimo kiekį ir ilgį. Taip sureguliuojamas laikas ir žmogiškieji ištekliai, kurių reikia testavimui atlikti, ir galima aiškiai išskirti testavimo rezultatus bei progresą. Bendru atveju testavimas programų sistemos kūrimo komandai garantuoja galimybes realiai pamatyti jų kūrinio veikimą. Išanalizavus rezultatus galima susidaryti nuomonę apie produkto kokybę. Kad ir kiek komanda būtų įdėjusi pastangų projektuodama ir rašydama programų sistemą, pirmą kartą veikianti programų sistema pamatoma testavimo metu. 108

110 Ankstyvasis testavimas Projekto vykdymo metu testavimui reikia naudoti pačią pirmą sėkmingą programų sistemos versiją. Net jei tuo metu veikia tik darbo pabaigos mygtukas, optimistiškai žvelgiant, galima analizuoti vartotojo sąsają, lyginti ją su numatyta ar su užsakovo poreikiais. Ankstyvojo testavimo metu reikia būti atsargiems. Būtent dėl ankstyvosios stadijos kai kurie defektai gali tiesiog nebūti defektai. Surinktus rezultatus reikia kruopščiai juos išanalizuoti. Galima nuspręsti, jog kai kurias programų sistemos sritis testuoti yra per anksti. Esmė yra ta, kad reikia nuspėti, kada konkreti sritis ir konkrečios funkcijos gali būti testuojamos, kad defektus ir kylančias problemas būtų galima rasti kuo anksčiau, nes kuo ankstesnėje stadijoje jie bus rasti, tuo lengvesnis bus taisymo procesas. Testuojant anksti ir dažnai galima rasti defektus, kurie, tikėtina, būtų rasti vėlesnėse stadijose. Dažnai ankstyvasis testavimas gali atvesti prie programų sistemai keliamų reikalavimų pokyčių. Taip nutinka todėl, kad pirmųjų testavimų metu produktą pirmą kartą pamato gyvai tiek pačių kūrėjų komanda, tiek ir užsakovas. Tai gali turėti įtakos struktūriniams pakitimams atsirasti, paskui vyktų ir kodo pakeitimai. Tokie pakitimai yra daug lengviau organizuojami ir vykdomi ankstesnėse programų sistemos vystymo stadijose. J. Henry knygoje testavimui skirtų išteklių išlaidų priklausomybė nuo programų sistemos vystymo stadijos grafiškai vaizduojama eksponente (9.1 pav.). 9.1 pav. Testavimui skirtų išteklių išlaidų dydis programų sistemos vystymo stadijose (Henry, 2004) 109

111 Nekonkretaus testavimo trūkumai Nesukonkretintą testavimą galima būtų palyginti su abstrakčiu ir nesukonkretintu projektavimu. Projektavimo atveju programų sistemoje gali atsirasti programinio kodo sričių, kur funkcijos veikia, tačiau integracijos laipsnis į bendrą programų sistemos struktūrą yra labai žemas. Testavimo atveju analogiška problema testavimo procesą gali atvesti prie klaidingo testavimo pasisekimo, klaidingos testavimo nesėkmės ar netgi klaidingų tikslų siekimo vykdomame projekte. Klaidingas testavimo pasisekimas reiškia, kad bet kokia situacija iš galimų projekte patenkins testo keliamus reikalavimus, taip testą paversdama beprasmiu. Klaidinga testavimo nesėkmė reiškia, kad programų sistema buvo testuojama klaidingai, tikimasi klaidingų rezultatų. Dėl to dažnai testo rezultatai atmetami, ir programų sistema tiesiog nebūna testuojama, tikintis gauti teisingus rezultatus. Pasitaiko atvejų, kad testavimas būna toks neapibrėžtas ir nekonkretus, jog prarandama programų sistemos vystymo kryptis ir tikslas. Šiuo atveju programuotojas ir testuotojas gali tikėtis skirtingų dalykų ir vykdyti savo darbą skirtingomis kryptimis. Efektyvus ir tiksliai apibrėžtas testavimas turėtų susidėti iš numatytų pradinių duomenų, su kuriais atlikus tam tikras operacijas yra gaunami rezultatai, kurie vėliau turi būti lyginami su rezultatais, gautais testuojamam objektui veikiant korektiškai. Jei testavimas yra nekonkretus ir paruoštas ne pagal konkretaus testuojamo atvejo tikslus, su bet kokiais duomenimis galima gauti bet kokius rezultatus, kurie tiks, kad patenkintų testo keliamus reikalavimus Psichologinė testavimo įtaka Dėl anksčiau minėtų priežasčių testavimas, ypač, jei atliekamas ankstyvojoje stadijoje, gali daryti stiprią įtaką projekto komandos nusiteikimui. Rezultatų analizavimo metu būtina koncentruotis į tai, ką reikia pataisyti, ir ieškoti sprendimų, leidžiančių atlikti pataisas greitai. Šiame etape nereikia koncentruotis į paiešką tų, kurie atsakingi už klaidas. Reikia sutvirtinti projekto tikslus. Komanda turi būti susitelkusi ties klaidų taisymu ir keliamų sąlygų tobulinimu, kas pasiekiama modifikuojant programų kodą ir struktūrą. Nagrinėjant gautus rezultatus gali iškilti poreikis pakeisti tam tikras komandos narių pareigas ar pakoreguoti projektavimo proceso eigą. Būtina įsidėmėti, kad su projekto komandos nariais reikia elgtis atsargiai, ir jų pareigų pokyčius gali būti tikslinga nukelti į netolimą ateitį. Tokie pokyčiai esant prastiems testavimo rezultatams gali sukelti darbingumo sumažėjimą ir palaužti moralę Testavimo ir derinimo ryšys Testavimas ir derinimas yra neatsiejami. Dažnai projektuose nepastebima, kad šie etapai vyksta pakaitomis. Testuojant programų sistemą randamą įvairių defektų, kuriuos reikia taisyti ir derinti, vėl testuoti ir t. t. Paprastai šis tikslas nutraukiamas, kai 110

112 aptinkamų klaidų skaičius, atsižvelgiant į atliktų testų kiekį, ženklai nukrinta. Reikia turėti omenyje, kad tiek testavimas ir gautų rezultatų analizavimas, tiek ir derinimas užima labai daug laiko, todėl vykdant šiuos procesus svarbu nepersistengti Atlikto testavimo įvertinimas Testavimo etapas programų sistemos vystymo metu būtų bevertis nesurinkus rezultatų ir jų neišanalizavus. Būtent iš rezultatų galima spręsti apie esamą situaciją, programų sistemos kokybę ir numatyti projekto pabaigą Bendras testavimo rezultatų vertinimo principas Projektui akivaizdžiai artėjant į pabaigą ateis momentas, kai reikės nuspręsti, ar programų sistema yra parengta diegti ir naudoti. Literatūroje siūloma daugybė statistinių modelių, tačiau svarbi yra ir projekto komandos nuomonė bei testavimo rezultatų analizė. Šie du aspektai gali nulemti tolesnę projekto raidą. Bendru atveju testavimo apimtis turėtų nekisti, o randamų defektų kiekis ženkliai mažėti. Toks santykis akivaizdžiai reiškia, kad programų sistema tobulėja (9.2 pav.) Testuojami scenarijai Randami defektai pav. Tobulėjančios programų sistemos testavimo procese aptinkamų defektų kiekis mažėja Akivaizdu, kad kitoje diagramoje (9.3 pav.) vaizduojamos programų sistemos būsena yra prasta, ir produktas neparuoštas naudoti, nes nėra pakankamai stabilus. Analizuojant šiuos du bruožus galima greitai susidaryti bendrą vaizdą apie projekto eigą. Tai taip pat reikėtų panaudoti spėjant projekto vystymosi kryptį ir padėtį netolimoje ateityje. 111

113 Testuojami scenarijai Randami defektai pav. Nesėkmingai vystomos programų sistemos testavimo procese defektų kiekis nemažėja Projekto pabaigoje ypač svarbi projekto komandos nuomonė apie produkto kokybę. Čia slypi pavojų projekto komandos nariai gali būti nepakankamai objektyvūs, tačiau šie žmonės yra artimiausia kuriamos sistemos grandis. Todėl su jais reikia aptarti tokius klausimus: Ką komandos nariai mano apie produktą? Ar pagerėjo produkto kokybė? Kaip ir kuriose srityse pagerėjo produkto kokybė? Ar produktas yra paruoštas pateikti užsakovui ir vartotojams? Kas ir kodėl turi būti atlikta? Renkant šią informaciją svarbu ją susieti su gautais testavimo rezultatais. Tokia analizė, kuri apima testavimo rezultatus ir komandos nuomonę, gali padėti suprasti, ar jau priartėta prie pabaigos. Testuoti galima ilgai, tačiau ekonomiškai tai yra netikslinga ir nuostolinga. Testavimo metu bus prieitas taškas, kai randamų defektų kiekis nepateisins jiems rasti išleidžiamų išteklių kiekio ir kainos. Taip pat galima sulaukti tokio momento, kai pasiekiamas technologinis limitas, kai komanda nesugeba patikrinti programų sistemos reikiamais naujais būdais ar gana išsamiai pritaikyti senuosius būdus. Negalima pamiršti, kad projekto komandos narių moralė ir entuziazmas taip pat krenta. Jie nori greičiau užbaigti projektą, išleisti jį vartotojams arba pristatyti užsakovui Testavimo pabaiga pasitelkus rezultatų analizę J. Henry siūlo gana paprastą taisyklę. Kai testavimo scenarijų kiekis išlaikomas pastovus, o randamų klaidų skaičius stipriai nukrinta, produkto tobulinimas juda link numatytos stadijos. Prieš kiekvieną testavimo etapą užsakovas su projekto komanda turėtų nuspręsti, kaip vertinti kuriamo produkto kokybę. Tai svarbu siekiant išvengti 112

114 klaidingų išvadų. Pavyzdžiui, mažėjantį aptinkamų defektų kiekį gali lemti mažėjantis testavimo scenarijų skaičius (9.4 pav.) Testuojami scenarijai Randami defektai 9.4 pav. Mažėjantį aptinkamų defektų kiekį lemia mažėjantis testavimo scenarijų skaičius Svarbu įsidėmėti, kad testavimas nebaigiamas dėl to, jog pasibaigė jam skirtas laikas. Užsakovai papildomo laiko poreikį tiesiogiai sieja su papildomomis išlaidomis, todėl už projektą atsakingas asmuo turi sugebėti pagrįsti testavimo ir derinimo svarbą bei jo tąsą. Defektai anksčiau ar vėliau bus rasti, svarbu, kad tai būtų padaryta kuo anksčiau. Negalima kokybės keisti į greitai, bet nekokybiškai parengtą produktą Santrauka Testavimas neatsiejama programų sistemos kūrimo dalis. Prieš atliekant testavimą, jis turi būti kruopščiai suplanuotas. Tikslinga sukurti testavimo planą, kuriame turėtų būti paminėti testavimo tikslai, techniniai, žmogiškieji ir programiniai ištekliai, reikalingi testuojant, informacija apie galimą pagalbą ir kitokia reikalinga informacija. Svarbu numatyti testavimo tikslus ir pradėti testuoti kuo anksčiau, norint pasiekti maksimalią naudą. Testavimo procesas turi būti kruopščiai apgalvotas ir parengtas. Nekonkretūs duomenys ar rezultatai testavimą gali paversti prasmės neturinčiu procesu. Tikslinga atsižvelgti į testo poveikį programų sistemos kūrimo komandos psichologinei būklei. Tai gali tiesiogiai paveikti tolesnę projekto vystymo eigą. Po kiekvieno testavimo prasideda kitas etapas rezultatų analizė. Rezultatai turi būti analizuojami bendrai su komandos nariais ir su tais, kurie atsakingi už testavimą. Iš šių rezultatų galima susidaryti nuomonę, kuriame kūrimo etape projektas yra. Apžvelgus rezultatus ir aptarus su komanda, galima spręsti, ar produktas ganėtinai kokybiškas, kad būtų pristatytas vartotojams ar užsakovui. 113

115 REIKŠMINIAI ŽODŽIAI / KEY WORDS Programų sistemos testavimo planavimas; Programų sistemos testavimo ypatybės; Programų sistemos testo rezultatų analizė. Software test planning; Software testing specifics; Software test results analysis. REKOMENDUOJAMI SKAITINIAI Assessment Tools, HM&S IT-Consulting GmbH, Austria [žiūrėta ]. Prieiga per internetą: NAUDOTA LITERATŪRA IEEE TEST PLAN TEMPLATE ieee829mtp.pdf Henry, J., Software Project Management: A Real-World Guide to Success, Boston: Pearson Education / Addison Wesley, 2004, p Goodrich, M. T., Tamassia, R., Data Structures and Algorithms in Java, 4th edition, 2005, p , elektroninė versija. 114

116 9A priedas: TESTAVIMO PLANAS Turinio šablonas 1. Įvadas 1.1. Testavimo tikslai ir objektai 1.2. Testavimo apimtis 1.3. Pagrindiniai apribojimai 1.4. Terminų žodynas 1.5. Nuorodos 1.6. Dokumento struktūra 2. Testavimo planas 2.1. Testuojama programinė įranga Sąsajos 2.2. Testavimo strategija Vienetų testavimas Integravimo testavimas Priėmimo testavimas Aukšto lygio testavimas 2.3. Testavimo ištekliai 2.4. Testavimo rezultatai 2.5. Testavimo įrankiai ir aplinka 2.6. Testavimo tvarkaraštis 3. Testavimo procedūra 3.1. Testuojama programinė įranga 3.2. Testavimo procedūros Vienetų testavimas Integravimo testavimas Priėmimo testavimas Aukšto lygio testavimas 3.3. Testavimo išteklių paskirstymas 3.4. Testavimo rezultatų kaupimas 115

117 10. Programinės įrangos diegimas. Konfigūracijos valdymas Konfigūracijos valdymo svarba Konfigūracijos valdymo svarba Šiame skyriuje aptarsime plėtojamos sudėtingos programinės įrangos kodo ir dokumentacijos valdymo procesą, t. y. konfigūracijos valdymą. Sommerville apibūdina konfigūracijos valdymą (angl. Configuration management CM) kaip standartų ir procedūrų naudojimą valdant kuriamą programų sistemą. Sistemos reikalavimai jos kūrimo ir naudojimo procese nuolat kinta, todėl sistemos kūrėjams į naują sistemos versiją tenka įtraukti naujus reikalavimus. Besikeičiančią sistemą reikia valdyti, nes tarp daugybės pakeitimų, įtrauktų į naująją sistemos versiją, galima pasimesti. Versijose būna įtraukta pakeitimų siūlymų dėl klaidų taisymo, aparatūros ir operacinių sistemų pritaikymo. Gali būti kuriamos ir naudojamos net kelios versijos vienu metu. Jei organizacijoje nėra efektyvaus konfigūracijos valdymo, pasitaiko pristatyti neteisingą sistemos versiją klientui ir pamesti vietą, kur programinės įrangos išeities kodas yra saugomas. ISO 9000 apibrėžia konfigūracijos valdymą laikantis standartų. Konfigūracijos valdymo planą aprašo IEE standartas. Konfigūracijos valdymo standartai pirmiausia remiasi vidiniais organizacijos standartais, kurie turi apibrėžti, kaip programiniai vienetai identifikuojami, kaip kontroliuojami pakeitimai ir kaip valdomos naujos versijos. Vidiniai standartai gali remtis ir išoriniais standartais. Egzistuojantys standartai daugiausia remiasi krioklio proceso modeliu, o evoliuciniam programų kūrimo procesui reikia ir jau kuriamų naujų standartų. Konfigūracijos valdymo procedūros nustato, kaip registruoti ir tvarkyti siūlomus sistemos pakeitimus, susijusius su dedamosiomis sistemos dalimis, bei metodus, naudojamus sistemos versijoms nustatyti. Konfigūracijos valdymo įrankiai naudojami sistemos komponentų versijoms saugoti, sistemoms iš komponentų sukurti ir išleidžiamoms klientui versijoms sekti. Į konfigūracijos valdymą kartais žiūrima kaip į programinės įrangos kokybės valdymo proceso dalį. 116

118 10.1 pav. Programų sistemų šeimynos (Sommerville, 2007) Konfigūracijos vadovai yra atsakingi už skirtumų tarp versijų stebėjimą užtikrinant, kad naujų versijų gavimas yra kontroliuojamas ir tinkami klientai jas gauna reikiamu laiku. Konfigūracijų yra labai skirtingų dėl įvairių priežasčių: įvairių kompiuterių (Dell, HP); įvairių operacinių sistemų (Linux, Windows); skirtingų klientų poreikių (pavyzdį žr pav.) Konfigūracijos valdymas evoliucinio projektavimo procese Organizacijos, taikančios evoliucinį projektavimą, pasitelkia konfigūracijos valdymą, kuris palaiko lygiagretų sistemos projektavimą ir testavimą. Toks konfigūracijos valdymas remiasi dažnu (kasdieniu) visos sistemos kūrimu iš komponentų: organizacija fiksuoja laiką (tarkim, 14 val.), kai projektuotojai turi pateikti sistemos komponentus. Visos naujos versijos (net ir galutinai nebaigtos) turi būti pristatytos, tačiau turėtų būti suteikta galimybė testuoti; nauja sistemos versija kuriama iš šių komponentų, juos kompiliuojant ir jungiant; ši nauja versija pateikiama testuoti naudojant iš anksto apibrėžtus testus; lygiagrečiai programuotojai dirba su komponentais, pridėdami jiems naujo funkcionalumo ar taisydami aptiktas klaidas; testavimo metu aptiktos klaidos dokumentuojamos ir grąžinamos sistemos kūrėjams; jie rastas klaidas pataisys tolesnėse komponentų versijose. Šio kasdienio konstravimo iš komponentų privalumai akivaizdūs, nes pradžioje yra daug lengviau rasti klaidas ir komponentų sąveikavimo problemas. Be to, tai skatina testuoti kruopščiai kūrėjai psichologiškai spaudžiami netrukdyti surinkti sistemą. Todėl būtina griežtai valdyti konfigūracijos procesą. 117

119 Konfigūracijos valdymo planavimas Konfigūracijos valdymo plane aprašomi standartai ir procedūros, kurios turėtų būti naudojamos konfigūracijos valdymo procese. Plano kūrimo pradžia turėtų būti nustatyta konfigūracijos valdymo standartais, pritaikytais kiekvienam konkrečiam projektui. Konfigūracijos valdymo planas turėtų būti suskirstytas į skyrius: apibrėžti konfigūracijos elementus, kurie turi būti valdomi, ir schemas, kuriomis bus nustatomi šie elementai; nustatyti atsakingus už konfigūracijos valdymo procedūras ir reguliuojamų elementų pateikimą asmenis; apibrėžti konfigūracijos valdymo nuostatas, kuriomis visi komandos nariai turi vadovautis kontroliuodami pakeitimus ir valdydami versijas; nurodyti įrankius, kurie turi būti naudojami konfigūracijai valdyti, ir procesus naudojant įrankius; nustatyti konfigūracijos valdymo duomenų bazę. Svarbiausia plano dalis yra atsakomybės apibrėžimas: kas yra atsakingas už kiekvieno dokumento ir programinės įrangos komponento pristatymą komandai ir konfigūracijos valdymo grupei. Asmuo, atsakingas už dokumento pristatymą, ne visada yra tas pats, kuris jį ir gamino. Dažniausiai tai projektų vadovas / komandos lyderis, atsakingas už visus dokumentus, su kuriais komanda dirba Konfigūracijos vienetų identifikavimas 10.2 pav. Konfigūracijos hierarchija suteikiant komponentams vardus 118

120 Dideli projektai turi tūkstančius dokumentų, kurie privalo būti vienareikšmiškai identifikuojami. Kai kurie dokumentai turi būti palaikomi visą programų sistemos gyvavimo laiką. Dokumentų įvardijimo schema susietus dokumentus turi vadinti susietais vardais, kad jie nepasimestų. Lanksčiausias būdas yra hierarchinė schema su daugelio lygių vardais, pvz.: PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE PCL-TOOLS/HELP/QUERY/HELPFRAMES/FR Konfigūracijos duomenų bazė Konfigūracijos valdymo duomenų bazė reikalinga siekiant įrašyti visą svarbią informaciją, susijusią su konfigūracijomis. Duomenų bazė padeda įvertinti sistemos pokyčių poveikį ir pateikti valdymo informaciją apie konfigūracijos valdymo procesus. Duomenų bazė turi atsakyti į tokius klausimus apie konfigūraciją: Kas turi nurodytą sistemos versiją? Kokia techninės įrangos ir operacinės sistemos konfigūracija yra reikalinga paleidžiant nustatytą sistemos versiją? Kiek sistemos versijų yra sukurta ir kokios yra jų sukūrimo datos? Kuri sistemos versija gali būti paveikta, jei tam tikras komponentas būtų pakeistas? Kiek esminių pakeitimų yra tam tikroje versijoje? Kiek rasta klaidų tam tikroje versijoje? Konfigūracijos duomenų bazė gali būti integruota į versijų valdymo sistemą, kuri taikoma formaliems projekto dokumentams valdyti Keitimų valdymas Keitimai yra neatsiejami nuo didelės programų sistemos gyvavimo ciklo. Keitimų valdymo procedūros susijusios su keitimų kainos ir naudos analize, vertingų keitimų patvirtinimu ir sekimu, kurie sistemos komponentai buvo pakeisti. Keitimų procesą galima užrašyti tokiais sąlygos ir ciklo sakiniais: Prašoma atlikti keitimą užpildant keitimo prašymo formą Analizuojamas keitimo prašymas Jei keitimas tinkamas, tai Įvertinama, kaip keitimas gali būti įgyvendinamas Įvertinama keitimo kaina Valdymo grupei pateikiamas keitimo prašymas Jei keitimas patvirtintas, tai Kartoti Atliekamas programinės įrangos keitimas Teikiama programinės įrangos kokybės įvertinimui 119

121 Kol programinės įrangos kokybė yra tinkama, Sukuriama nauja programų sistemos versija Priešingu atveju atmetamas keitimo prašymas Priešingu atveju atmetamas keitimo prašymas Keitimo prašymo formoje aprašomi siūlomi pakeitimai, keitimų užsakovas, priežastis, kodėl keitimas buvo pasiūlytas, ir keitimo skubotumas. Taip pat pateikiamas keitimo vertinimas, įtakos analizė, keitimo kaštai ir atsakingas asmuo. Pagrindinė keitimų valdymo problema yra keitimo būsenos sekimas. Keitimo sekimo priemonės išsaugo kiekvieno keitimo eigą ir automatiškai užtikrina, kad keitimo prašymas laiku patektų pas reikiamus žmones. Priemonės, integruotos su elektroniniu paštu, paskirsto keitimo prašymus. Keitimų prašymus nagrinėja keitimų kontrolės tarnyba, kuri nusprendžia, ar tai efektyvu strateginiu ir organizaciniu požiūriais. Tarnyboje gali būti kliento ir partnerių atstovų Versijų valdymas ir identifikavimas Versijų ir leidimų valdymas tai procesai, skirti sekti ir identifikuoti skirtingų sistemos versijų procesus. Reikia parengti procedūras ir užtikrinti, kad versijos būtų gautos tada, kai reikia, ir nebūtų atsitiktinai pakeistos. Produktų versijų vadovai planuoja, kada įvyks ir bus paruoštas platinti naujos sistemos leidimas. Sistemos versija (angl. version) yra sistemos pavyzdys, kuris funkciškai skiriasi nuo kito sistemos pavyzdžio. Sistemos versijose gali skirtis funkcionalumas, pagerinti eksploataciniai parametrai, ištaisytos klaidos, versijos gali būti sukurtos kitai techninei įrangai ar programinės įrangos konfigūracijai. Versijos neišleidžiamos užsakovams, jos naudojamos pačioje organizacijoje tolesniam kūrimui ar testavimui. Variantas (angl. variant) sistemos versijos, kurios labai mažai skiriasi, vadinamos variantais. Sistemos leidimas (angl. release) tai sistemos versija, platinama užsakovams. Kiekvienas leidimas turi turėti naują funkcionalumą arba turi būti išleistas naudoti kitoje techninėje platformoje. Siekiant sukurti tam tikrą sistemos versiją, vienareikšmiškai turi būti identifikuotos komponentų versijos. Komponentų versijoms identifikuoti naudojamos trys bazinės metodikos: Versijų numeravimas (komponentui duodamas unikalus versijos numeris). Atributų identifikavimas (kiekvienas komponentas turi turėti vardą ir susijusią atributų aibę kiekvienoje versijoje). Identifikavimas, orientuotas į keitimus (kiekvieno komponento versija identifikuojama pagal atliktus komponentų keitimus). Sommerville 10.3 pav. aiškina skirtingų sistemos versijų sukūrimo būdą. Paprastai įvardijimo schemos nebūtinai vartoja tiesinį numeravimą: V1, V1.1, V1.2, V2.1, V2.2 ir t. t. Versijos gali būti kildinamos dėl įvairių priežasčių. 120

122 10.3 pav. Versijų kilmės struktūra (Sommerville, 2007) Sudarant versijų vardus gali būti naudojami įvairūs identifikavimo atributai: sukūrimo data, autorius, programavimo kalba, platforma, užsakovas, sistemos būklė. Praktikoje versijoms lengviau įsiminti reikia asocijuotų vardų. Pagrindinis privalumas tas, kad atributų identifikavimas įgalina vykdyti įvairias užklausas. Be to, užklausa išrenka versiją priklausomai nuo atributų reikšmių, pvz. : AC3D (kalba = Java, platforma = XP, data = Jan2003) Leidimų valdymas Sistemos leidimas (angl. release) yra sistemos versija, skirta klientams. Reikia priimti sprendimą, kada sistema gali būti išleista klientams, vadovauti leidimo kūrimo procesui ir paskirstyti bei dokumentuoti leidimą užtikrinant, kad jį bus galima tiksliai atkurti. Sistemos leidimas nėra tik sistemos įvykdomas kodas. Leidimą gali sudaryti: 1. Failų konfigūracija, apibrėžianti, kaip leidimas turėtų būti suformuotas konkrečiam instaliavimui. 2. Duomenų failai, reikalingi, kad sistema sėkmingai veiktų. 3. Instaliavimo programa, skirta sistemą į techninę įrangą instaliuoti. 4. Elektroniniai ir popieriniai dokumentai, aprašantys sistemą. 5. Pakuotės ir susijusios reklamos, skirtos tam leidimui. Pastaba:10A priede pateikti patarimai programų sistemos reklaminio skelbimo kūrėjui. Klientai ne visada pageidauja įsirašyti naują sistemos leidimą. Kai kurie sistemų vartotojai gali būti patenkinti esama sistema, nepageidauti papildomų išlaidų. Todėl naujas sistemos leidimas negali remtis ankstesnės sistemos įdiegimu. 121

123 Pavyzdžiui, saityno atveju, programinės įrangos platintojas negali manyti, kad reikalingi failai 3-iajam leidimui jau buvo įrašyti į visas svetaines. Kai kurios svetainės iš 1-ojo leidimo gali eiti į 3-iąjį leidimą, praleisdamos 2-ąjį. Kai kurios svetainės galbūt pakeitė informacijos failus, susijusius su 2-uoju leidimu. Todėl informacijos failai privalo būti paskirstyti ir įrašyti kartu su 3-iuoju sistemos leidimu Kada reikia rengti naują sistemos leidimą Paruošti ir paskirstyti sistemos leidimą yra brangus procesas. Jei leidimai vykdomi labai dažnai, klientai gali nepageidauti mokėti už naują leidimą. Jei sistemos leidimai vykdomi labai retai, rinkos dalis gali būti prarasta, klientai pereis prie alternatyvių sistemų. Aišku, tai negalioja specialiai konkrečiai organizacijai sukurtoms sistemoms. Įvairūs techniniai ir organizaciniai veiksniai, į kuriuos reikia atsižvelgti, sprendžiant, ar kurti naują sistemos leidimą, pateikti 10.1 lentelėje lentelė. Veiksniai, turintys įtakos sistemos leidimų strategijai (Sommerville, 2007) Veiksnys Techninė sistemos kokybė Platformos pakeitimas Penktas Lemano dėsnis Konkurencija Rinkodara Klientų siūlomi keitimai Aprašymas Jei daug sistemos vartotojų informuoja apie rimtas sistemos klaidas, būtina parengti leidimą ištaisius nurodytas klaidas. Gali tekti sukurti naują programinės įrangos versiją, kai išleidžiama nauja operacinė sistema. Funkcionalumas kiekvienoje naujoje išleistoje versijoje padidėja maždaug vienodai. Todėl po taisymų leidimo turi būti išleidžiama versija, ypač pasižyminti nauju funkcionalumu. Naujos sistemos leidimas gali būti būtinas, kai atsiranda konkuruojantis produktas. Rinkodaros skyrius gali būti nustatęs leidimų tvarkaraštį. Užsakytų sistemų klientai gali būti pateikę pageidavimus ir sumokėję už tam tikrus sistemos keitimus, kurie turi būti įgyvendinti naujose versijose Leidimo kūrimas ir dokumentavimas Leidimo kūrimas yra failų rinkinių ir dokumentų kūrimo procesas. Vykdomos programos kodas ir visi susiję informacijos failai turi būti surinkti. Konfigūracijos gali būti aprašytos skirtingoms programinėms įrangoms ir operacinėms sistemoms, todėl reikia parengti nurodymus klientams, kuriems reikia konfigūruoti jų nuosavas sistemas. Turi būti parašyti instaliavimo programos skriptai (angl. sripts). Galų gale kai visa informacija yra prieinama, leidimo katalogas atiduodamas platinti. Normalus sistemos leidimo platinimo būdas šiuo metu yra optiniai diskai (CD- ROM arba DVD). Papildoma programinė įranga gali būti platinama internetu, leidžiant klientams parsisiųsti ją, tačiau parsisiųsti didelius failus trunka ilgai, todėl vartotojai teikia pirmenybę platinimui diskais. Dokumentuojant leidimą, reikia įrašyti tas specifines komponentų kodo versijas, kurios buvo naudojamos kuriant vykdomąjį kodą. Reikia pasilikti kopijas: šaltinių, vykdomųjų kodų, duomenų ir konfigūracijos failų. Taip pat reikia užrašyti operacinės 122

124 sistemos versiją, bibliotekas, kompiliatorius ir kitus įrankius, naudotus kuriant programinę įrangą. To gali prireikti vėliau, atkuriant tą pačią sistemą. Tai reiškia, kad kartu su programų sistemos kodu reikia saugoti ir kopiją programinės įrangos: platformos ir įrankių, naudotų kuriant sistemą. Sistemą kuriant iš komponentų, reikia nepamiršti tokių klausimų: 1. Ar visi komponentai, kurie buvo naudoti sistemoje, įtraukti į diegimo instrukciją? 2. Ar kiekvieno komponento tinkamos versijos buvo įtrauktos? 3. Ar visi informacijos failai yra pateikti? 4. Jei komponentuose nurodyti duomenų failai, ar jų vardai tokie pat, kurie ir buvo vartoti? 5. Ar pasiekiami atitinkamos versijos kompiliatoriai ir kiti įrankiai? Esamos programinės įrangos versijos gali būti nesuderintos su senesne versija, naudota sistemai sukurti. REiKŠMINIAI ŽODŽIAI / KEY WORDS Konfigūracijos valdymas; įdiegimo paketas; išdėstymas; programinės įrangos aplinka; garantija Configuration management; Installation package; Deployment; Software environment; Warranty REKOMENDUOJAMI SKAITINIAI Bayer, N. et al., CARMEN: Resource Management and Abstraction in Wireless Heterogeneous Mesh Networks, SIGCOMM 10, August 30 September 3, 2010, New Delhi, India. ACM /10/08. The ITIL Foundation v2.0 (Part 3): Configuration, Change, and Release Management: Alimi, R., Wang, Y., Yang, R., Shadow Configuration as a Network Management Primitive, 2008: Whitehead, J., WebDAV and DeltaV: Collaborative Authoring, Versioning, and Configuration Management for the Web, Hypertext, The Twelfth ACM Conference on Hypertext and Hypermedia, NAUDOTA LITERATŪRA Henry, J., Software Project Management: A Real-World Guide to Success, Boston: Pearson Education / Addison Wesley, Somerville, I., Software Engineering, Eight Editon, Addison-Wesley,

125 10A Priedas: PATARIMAI PROGRAMŲ SISTEMOS REKLAMINIO SKELBIMO KŪRĖJUI Reklamos paskirtis Reklamą galima apibūdinti kaip sąmoningą, kryptingą ir planingą poveikį vartotojams, kai siekiama tam tikrų tikslų. Efektyvios reklamos savybės: reklamuojant prekę, reikia gerai žinoti vartotojų, kuriems siūlomos prekės ar paslaugos, interesus ar poreikius, problemas, su kuriomis jie susiduria vartodami analogiškus produktus, siūlomus kitų gamintojų; reklama turi atitinkamai parodyti siūlomų prekių ar paslaugų kokybinį išskirtinumą, vartojimo privalumus, naujoviškumą, parankumą ne tik vartojimo, bet ir realizavimo bei gamtosaugos požiūriais; įvertinant tai, kad vartotojai paprastai renkasi pigesnes prekes, reklamoje būtina pabrėžti siūlomos programų sistemos santykinį pigumą. Reklamos tikslai: supažindinti potencialų vartotoją su programų sistema, savybėmis, jos kaina, pateikimo vieta ir pan.; priversti potencialų vartotoją galvoti apie programų sistemos įsigijimą, parodant tokio įsigijimo naudą; priversti potencialų vartotoją norėti programų sistemos, sukeliant svajones apie ją. Reklaminio skelbimo elementai Klasikinį reklaminį skelbimą paprastai sudaro: iliustracija, antraštė, tekstas ir šūkis. Visus šiuos elementus susieja grafinis sumanymas. Iliustracija. Iliustracija turėtų sudominti: kas ir kodėl vaizduojama. Bet kokia vizuali reklamos priemonė pirmiausia turi būti pastebėta., t. y. patraukti dėmesį nesąmoningai. Bent vienas iš reklamos elementų turi būti skirtas tam tikslui. Tai gali būti ryški spalva, neįprasta pirmos raidės forma ar dydis, didelė spalvota fotografija, teksto kompozicija. Šiuo tikslu gali būti panaudota net tuščia erdvė, kuri labai neįprastai atrodo akiai, įpratusiai matyti užpildytus puslapius. Abstraktūs vaizdai ir piešiniai reklamoje visiškai netinka. Nuotraukos geriau įsidėmimos, tikroviškesnės, įtaigiau sieja viziją su tikrove. Galima parodyti produkto ar paslaugos galutinį rezultatą arba asmenis, atpažįstamus iš TV reklamos, galima vaizduoti nežinomus asmenis, keliančius susidomėjimą. Iliustracijoje paprastai vaizduojamas prekės ženklas ar daiktas, susijęs su reklamuojamos prekės naudojimu. Labai svarbus reklamos priemonių elementas yra spalvos, jos sukelia įvairias emocijas ir asociacijas priklausomai nuo šalies tradicijų, žmonių patirties. Antraštė. Antraštė turi nurodyti prekės rūšį. Tai labai svarbus reklamos elementas, nes jis atsakingas už tai, kad žmonės suprastų, apie ką bus kalbama reklamos tekste, ir norėtų jį perskaityti. Gera antraštė iš karto sudomina tą auditoriją, kuriai ji skirta. 124

126 Skelbimo antraštė turi dvelkti naujumu: naujas, pirmą kartą ir pan. Tačiau būtina, kad prekės rūšis ar paslauga būtų pelnytai vadinama naujove. Reklamos tekstas. Antraštė turi patraukti dėmesį, o tekstas turi užkariauti pirkėjo širdį. Reklamos tekste reikėtų paaiškinti, kuo naudingas siūlomas produktas ar paslauga. Tekstas turėtų būti trumpas (apie 50 žodžių), jį turėtų sudaryti trumpi, paprasti, aiškūs sakiniai. Informaciją galima pateikti tiesiogiai išdėstant prekės privalumus arba pasakojant kokią nors istoriją. Gali būti siūlomas bandomasis pavyzdys, primenamas nepriklausomos institucijos teigiamas įvertinimas, pristatomi žinomi žmonės, jau įsigiję prekę ar paslaugą. Rašant tekstus svarbu tinkamai pasirinkti šriftus. Geras šriftas neturi atkreipti dėmesio į savo ypatingą grožį, pirmiausia jo paskirtis atskleisti pranešimo žodžių prasmę, o kita estetinė paversti jį patraukliu akiai. Šūkis. Jis reikiamas reklamos įsiminimui sustiprinti ir padeda reklamos vartotojui identifikuoti paslaugą ar prekę. Kompanijos ir prekės šūkis kartojamos iš vienos reklamos į kitą, t. y. šūkis paprastai išlieka tas pats. Tai turi būti įsimintina frazė, skirta galutinai užbaigti reklamos idėją. Pavyzdžiui, The Wall Street Journal šūkis: Amerikietiškos svajonės dienraštis! Reklaminio skelbimo maketas. Reklaminį skelbimą sudaro antraštė, iliustracijos (tarp iliustracijų gali būti nurodomas firmos ar prekės ženklas), šūkis, tekstas (čia, be kitos informacijos, taip pat gali būti nurodomi įmonės pavadinimas, adresas, darbo laikas, telefonas, el. paštas). Jie turi būti gerai išdėstyti, kad būtų lengva juos įsiminti ir būtų patrauklu. Žinoma, kad sutvarkyti vizualiniai objektai yra lengviau atpažįstami, suprantami ir įsimenami. Dauguma skaitytojų peržiūri reklamą iš viršaus į apačią, iš kairiojo kampo į dešinįjį. Todėl pagrindinius elementus rekomenduojama išdėstyti tokioje įstrižainėje. Maketai turėtų turėti dominuojantį elementą. Dažniausiai tai būna vaizdas. Gali būti ir antraštė, jei jos šriftas pakankamai didelis ir užgožia kitus elementus. Tai centrinis pranešimo maketo taškas, pirmiausia, kas pamatoma reklamoje. Reklama yra bloga, jei niekas neišskirta. Reklamos publikavimo būdai Informaciją apie savo programų sistemą galima skleisti spausdintais reklaminiais leidinukais, pateikti kompiuterio ekrane parodose, mugėse, konferencijose, kursuose, paskaitose, internete. Pagal publikavimo būdus, reklamą sąlyginai galima skirstyti į tokias grupes: Spausdinta reklama. Pranašumas: reklaminius lankstinukus patogu platinti asmeniškai, nereikia papildomos įrangos. Pristatymas skaidrių ar filmukų pavidalu parodose, mugėse, konferencijose. Pranašumai: patogu pristatyti didelei auditorijai viešai, galima naudoti judesį, garsą, animaciją, patrauklu, galima automatizuoti. Trūkumas: būtina speciali įranga. Reklama internete: tinklalapiai, reklama reguliarioje elektroninėje spaudoje, reklaminiai skydeliai. Pranašumai: pasiekia konkrečią ir labai didelę geografiškai auditoriją, jei publikuojama tinkamoje vietoje verslo portale, pigumas. Trūkumai: klientas turi turėti prisijungimą prie interneto. Norintiesiems turėti įvairiais atvejais tinkamą reklamą, rekomenduojama parengti kelis skirtingų formatų reklaminius skelbimus. 125

127 11. Programų inžinerijos projekto užbaigimas. Užbaigimo apibūdinimas. Užbaigimo veiklos Įvadas Kai pagrindinė projekto dalis yra padaryta, labai norisi pereiti prie kito projekto, užuot tikrinus, ar projektas padarytas teisingai ir ar iš jo yra išgauta didžiausia nauda. Bath universiteto dėstytojas Maylor Harvey savo mokymo kurse ir knygoje Project management akcentuoja, kad norint užtikrinti projekto sėkmę negalima praleisti šio žingsnio. Šis paskutinis projekto žingsnis reikalauja daug projekto vadovo pastangų: organizuoti nešališkus tikrinimus, atsižvelgiant į visus projekto įvykius; susieti formalias procedūras su projekto vykdymu; sukurti ilgalaikius projekto atnaujinimo ir taisymo planus; patenkinti visas pagrindines užsakovų grupes. Proceso lygis Planavimas Vykdymas Valdymas Inicijavimas Analizė Užbaigimas Pradinė fazė Baigiamoji fazė 11.1 pav. Projekto valdymo procesų išsidėstymas projektavimo laike Tokias užduotis nėra lengva išspręsti, ypač kai iš projektą vykdančių žmonių reikalaujama, kad projektas būtų atliktas geriau ir greičiau, tačiau nepabrėžiama, kas ir kaip turi būti atlikta. 126

128 Jeigu organizacija nori ženkliai patobulinti savo projektų veiklą, reikia trumpam paskirti daugiau išteklių projekto baigiamajam etapui (11.1 pav. (1.1 pav.)). Organizacijos projektavimo proceso tobulinimas atneš ir piniginės naudos Projekto užbaigimas ir perdavimas naudoti Projekto užbaigimo metu reikia atkreipti dėmesį į tokius aspektus: paskatos projektui baigti garantavimas; garantavimas, kad visi darbai bus baigti; garantavimas dokumentacijos, kuri ateityje palengvins projekto aptarnavimą; projekto užbaigimas; visų projekto darbų atnaujinimas; projekto įvertinimas ir personalo perkėlimas; patikrinimas, ar visi užsakovai yra patenkinti; produktų pardavimas ir maksimalios naudos gavimas iš projekto Užbaigimas Nebaigtų projektų situacijos turi vengti kiekvienas projekto vadovas. Dažniausiai kyla mintis nutraukti darbus ir griebtis kito projekto, o baigus tą projektą grįžti prie nebaigtojo. Toks elgesys atima galimybę projektą baigti idealiai ir iš to gauti didžiausią naudą. Antraip uždarymo procesas užsitęs, išaugs išlaidos darbo užmokesčiui. Jei darbuotojams atlyginimas skaičiuojamas pagal dirbtų valandų skaičių, tai darbuotojų neskatina dirbti ir projektą baigti laiku. Iš tikrųjų jie net suinteresuoti, kad darbai vyktų šiek tiek blogai ir projekto baigimo laikas būtų pailgintas. Priedai prie atlyginimo turėtų paskatinti dirbti greičiau ir geriau. Užbaigimo darbai turėtų būti detalaus projekto plano dalis. Tačiau dažnai sunku tiksliai iš anksto suplanuoti, ko prireiks baigiant projektą. Todėl projekto vykdymo pabaigoje reikia papildomai suplanuoti užbaigimo darbus. Gali būti naudingas kontrolinis darbų sąrašas: 1. Darbų paskyrimai. 2. Dokumentai, kad užbaigimo užduotys buvo suplanuotos. 3. Įrodymai, kas, kada ir kokius darbus atliko. 4. Laisvi ištekliai. Formalus projekto užbaigimas daugelyje pramonės šakų būna problemiškas, nes reikia informuoti visą personalą ir kitas sistemas, kad nebereikia vykdyti projekto ir atlikti sprendimų. Pastebėta, kad projektui baigiantis darbai būna atliekami lėčiau dėl sumažėjusio išteklių ir darbų skaičiaus. Todėl ištekliai ir lėšos turi būti perskirstoma iš tų darbų, kurie jau nebevykdomi, užtikrinant, kad kokybė nenukentės. Projekte, vykdomajame pagal sutartį, legalus darbų nutraukimas reiškia, kai užsakovas pasirašo darbų priėmimo aktą. Iškilus darbų nutraukimo situacijai, dažnai 127

129 norima darbą bandyti tęsti toliau ir teikti užsakovui nemokamas konsultacijas. Tačiau jei tokia konsultacija pasidaro reikalinga, vadinasi, kad ir kiti projekto aspektai yra blogai apgalvoti. Todėl nerekomenduojama: visai nutraukti sutarties su užsakovu ir sugriauti visas ateities verslo galimybes; teikti nemokamas paslaugas Projekto tikrinimas (peržiūra) Pagrindiniai projekto patikros (peržiūros) elementai, sudarantys galimybes tolesnei kontrolei ar koregavimo veiksmams: neatidėliotina veiklų korekcija ir tobulinimo veiksmai; ilgalaikis auditas ir patikra (peržiūra) (angl. review); strateginiai ir vykdomieji pakeitimai. Formali ilgalaikė priežiūra gali pareikalauti pakeisti pagrindines procedūras. Pirmasis pakeitimas, kuris turėtų būti daromas projekto užbaigimo stadijoje, tai greitas reagavimas į darbuotojų ar sistemų veiksmus: Vertintojas ar kritikas turėtų būti asmuo, kuris per nustatytą laiką sugebėtų iškelti visas fizines, politines, aplinkos, finansines ir personalijų problemas, su kuriomis buvo susidurta vykdant projektą. Projekto vertintojas gali būti rėmėjas arba projekto vadovas. Deja, daugelis klaidingai mano, kad projekto vadovas gali būti neobjektyvus, vertindamas savo projektą ir jo procesą. Trumpalaikiams patobulinimams labai naudingas vadovavimo auditas, kurį atlieka komanda ir vadovas. Audito metu tikrinamos tokios charakteristikos: nuostatos, įgūdžiai, draugiškumas, atvirumas, gebėjimas būti įgaliotu, atsakingumas, gebėjimas savo komandą pristatyti kitiems ir stropumas. Tuo tikslu naudojamas tam tikras klausimynas, kuris padeda susidaryti nuomonę apie vadovavimą projekto komandai. Gauti rezultatai padeda įvertinti esamą situaciją, darbuotojų įgūdžius, elgesį ir nuspręsti, koks ir kada reikalingas pakeitimas. Ši informacija yra gyvybiškai svarbi norint valdyti žmogiškuosius išteklius, nustatyti, ar jų lūkesčiai yra patenkinami, ir juos priskirti atitinkamiems darbams. Tokia sistema taip pat padeda darbuotojus motyvuoti. Harvey teigia, kad vadovavimas vertinant personalą yra svarbiausia ugdant žmogiškąjį kapitalą projektavimo organizacijose. Tai yra vienas iš vadovo įgūdžių, kuris dažnai reprezentuoja vadovą. Realybė yra tokia, kad su šiuo gebėjimu negimstama, jis įgyjamas. Daugybė projektų vadovų pažymi, kad labai svarbu sukurti gerą darbuotojų komandą tinklą siekiant sėkmingai spręsti projekto darbus ir problemas ateityje. Rinkodara daro įtaką klientui, todėl vadovai siekia sustiprinti organizacijos įvaizdį. Kad projekto nauda būtų maksimali, būtų naudinga į projekto uždarymo etapą įtraukti rinkodaros specialistus, kadangi duomenys organizacijos įvaizdžiui formuoti gali būti surenkami projekto peržiūrų metu. 128

130 11.3. Proceso tobulinimas Pisano pasiūlė pasinaudoti kitų projektų peržiūrų ir audito metu surinkta informacija siekiant pagerinti projektavimo proceso kokybę. Pasiūlyta proceso tobulinimo strategija pateikta 11.2 paveiksle. Šis siūlymas labai tinka programų inžinerijos magistrantūros studijoms. Todėl aptarsime detaliau. Projekto vadovo veiklos, skirtos programų sistemų projektavimo procesų vykdymui pagerinti, yra suskirstytos į dvi grupes (11.2 pav.): mokytis prieš darant garantuojant, kad reikalingos žinios ir įgūdžiai jau yra įgyti darbui atlikti; mokytis darant tokie proceso elementai, kurie gali būti išmokti iš anksčiau užsiimtos veiklos. Projektas A Auditas ir peržiūra Mokytis darant Projektas B Mokytis prieš darant Išorinės žinios 11.2 pav. Programų inžinerijos proceso tobulinimas (Pisano, 1997) Išmokti prieš darant yra labai sunku. Reikia daug laiko ir išankstinių žinių siekiant rasti idėjų šaltinių ir perimti reikiamą informaciją. Yra du idėjų šaltiniai: pasisamdyti konsultantą, etaloniniai pavyzdžiai. Tačiau daugybė organizacijų pasaulyje ir toliau mokosi iš savo atliktų projektų. Tyrimai parodė, kad vienoje iš Hewlett Packard gamyklų senesnių projektų peržiūrų dokumentacijos buvo naudojamos planuojant ateities projektus. Sistemingai analizuojant buvo pasiekta aukšta projektavimo proceso kokybė. Tos firmos, kurios mokosi iš savo projektų, pasiekia geresnių rezultatų. Išsamiau nagrinėsime problemas, kurios kyla mokantis prieš darant ir mokantis darant. 129

131 Mokymasis prieš darant Pagrindiniai išorinių žinių šaltiniai yra švietimas ir mokymasis bei konsultantų veikla. Įmonės organizuoja projektų valdymo kvalifikacijos kėlimo kursus personalui. Tokie kursai kainuoja daug, maždaug kaip savaitinis darbuotojo darbo užmokestis, tačiau pasiektas efektas matomas ne iš karto. Negalima tikėtis, kad vienas kursuose apmokytas žmogus galės priversti visą grupę dirbti greičiau. Tik apmokius 80 % įmonės dirbančiųjų galima tikėtis sėkmės. Konsultacinės firmos teikia specialias paslaugas: buhalterija, strateginė analizė, žmogiškųjų išteklių mokymas arba informacinė technologija. Konsultantas projekte gali turėti tokius vaidmenis: integratorius užsakovui sujungia visas projekto valdymo paslaugas į vieną; sąžiningas makleris turi teikti nešališką informaciją apie projektą; pokyčių agentas telkti dėmesį darbams, vykdomiems po peržiūrų; tiekėjas žinių iš konkrečios srities ar apie specialų metodą; ištyeklių tiekėjas; tikrintojas, patikrinantis proceso vykdymo būdus; treneris, suteikiantis žinių tos organizacijos nariams per mokymus. Iš anksto sunku numatyti mokymo naudą, dažniausiai ji pasireiškia tik praėjus ilgesniam laikotarpiui. Vienas iš teigiamų dalykų yra tokių studijų objektyvumas. Konsultantui paskirtos užduotys turėtų būti paremtos informacija apie įmonėje kylančius konfliktus ir problemas. Konsultantas taip pat gali būti samdomas padėti vadovui apsispręsti renkantis projektą. Jeigu konsultantas yra tikrai geras, vėliau jis gali būti pasamdytas ilgam laikui ir naudojamas įmonės reikalams tvarkyti. Ateityje tokie konsultantai turės didelę įtaką projekto valdymo procese. Mokymasis atliekant auditą ir peržiūras Audito ir patikros (peržiūros) procesai yra normalus dalykas organizacijoje. Atlikus auditą ir patikrą tik po tam tikro laiko galima nustatyti, ar veiksmai ir būdai, kuriais jie buvo atlikti, atnešė naudos. Auditui ir peržiūroms atlikti reikia: priežasties juos vykdyti; laiko; informacijos; išteklių; patikimumo. Audito priežastis dažnai aprašoma kaip baisus dalykas. Tačiau pagrindinis tikslas yra užtikrinti, kad darbai vyktų pagal reikalavimus ir tvarkingai. Tai kartu yra ir atspirties taškas, kuriame galima išmatuoti, kaip dirba projekto vadovas. Prieš bandant ieškoti projekto vykdymo problemų, kurios siejamos su peržiūra, pirma užduotis būtų identifikuoti aspektus, pagal kuriuos projektas turi būti apžiūrimas. 130

132 Laikas šiai patikrai turėtų būti rezervuotas iš kitų veiklų ir paskirtas audito organizacijai. Projekto vykdytojas turėtų būti įtrauktas į audito procesą. Informacija turėtų būti suteikta iš anksto, su visa būtina prieiga ir galimybe gauti kitą informaciją. Visas šis procesas turi būti patikėtas projekto vykdytojui. Tyrimas turi būti atliktas griežtai, bet teisingai, nieko neslepiant. Audito procesą sudaro: procedūrų nustatymas formalus aprašymas, kokios ir kaip turėtų būti atliekamos veiklos; dokumentacijos ir kitų įrašų tikrinimas, siekiant nustatyti, ar visi darbai atliekami laiku ir teisingai; ataskaitos, kurioje išdėstomos klaidos ir neatitikimai, pristatymas. Auditas dažnai vertinamas kaip neigiamas procesas, kaip bandymas sugauti žmogų, kuris daro kažką ne taip. Dėl to dažnai įvyksta konfliktų tarp audito ir darbuotojų. Tačiau auditas yra atsakingas už nesuderinamumų išnagrinėjimą, dvigubą informacijos kontrolę ir vykdymo alternatyvų paiešką. Patikros procesą sudaro: vykdymo atsižvelgiant į apribojimus analizė; nustatymas vietų, kuriose procedūros nuvylė arba vyko ne pagal nurodymus; informavimas, kur yra vadovavimo spragos ir tobulinimo pasiūlymai lentelėje pateikti audito ir patikros vertinimo kriterijai lentelė. Audito ir patikros kriterijai Kriterijus Auditas Patikra Finansinis Apskaitos sistemos Kainų skirtumas Laikas Plano atitikimas Užsakovų patenkinimas Kokybė Kokybės patikrinimas Užsakovų supratimas Personalas Politikos atitikimas Motyvacija Aplinkos Politikos atitikimas Įvertinimas Planavimo Plano atitikimas Kainos, naudoti būdai Kontrolės Sistema kontrolei Pagrindas patobulinimams Atlikti gerą patikrą yra tikras menas, kuris reikalauja įgūdžių. Pagrindinė užduotis yra rasti tiesą arba daug jos variantų, išsiaiškinti konfliktų esmę. Tai visada buvo ir bus subjektyvus uždavinys. Dvi skirtingos patikros komandos, kurioms duodamas tas pats projektas, gauna skirtingus rezultatus tai ir yra įrodymas, kad toks darbas yra subjektyvus. Tai priklauso nuo komandos žinių ir įgūdžių. Patikra nuo audito turėtų skirtis dar vienu parametru dėmesiu aplinkai. Auditas tikrina vidaus reikalus, o patikra turėtų skirti dėmesį ir aplinkai. 131

133 Sunku rasti gerą auditorių. Daugybė specialistų neturi buhalterinių įgūdžių, patirties arba kvalifikacijos susidoroti su finansiniu auditu ir negali pateikti naudingų arba patikimų rezultatų. Vertintojas taip pat turi būti nešališkas. Vertintojas dirba su projekto rėmėju ir vykdytoju, ieškodami vietų, kurias būtų galima patobulinti. Tuo tikslu reikia kreiptis į darbuotojus, kurie yra tiesiogiai su tuo susiję. Dalyvaujant vertintojui surinktos žinios yra objektyvesnės ir teisingesnės. Pastebėta, kad nemaža organizacijų nesistengia rengti peržiūrų dėl daugelio priežasčių. Pagrindinė priežastis yra ta, kad žmonės lieka įsižeidę, kai juos pradeda mokyti, ką ir kaip daryti. Vadovas taip pat nukenčia, nes jis turi prisiimti atsakomybę už savo darbuotojus. Tai dar viena priežastis, kodėl tokios patikros nevyksta vadovas nenori būti nuvertintas. Tačiau esant skirtingoms direktyvoms, įmanoma gauti naudingus vidutinio ir sunkaus sudėtingumo projektų patikros rezultatus. Tai direktyvos: telkti dėmesį procesui, o ne individualiam žmogui; kur įmanoma naudoti faktinius duomenis; leisti alternatyvų repeticijas. Leisti personalui suprasti, kas būtų, jei būtų daroma kitaip; naudoti įrangą ir įvairias technikas sprendžiant problemas Kokybės kainos nustatymas Finansinių nesėkmių skaičiavimas gali būti panaudotas tobulinant projekto veiklas. Kaina dažniausiai yra milžiniška ir išreiškiama apyvartos procentais. Pagal skaičiavimo tikslus, kokybės kaina yra suskaidyta į tris kategorijas: prevencija, įkainojimas ir nepasisekimai. Veiklos, įtrauktos į kokybės kainos dedamąsias, pateiktos 11.2 lentelėje lentelė. Kokybės kainos elementai Kategorija Prevencija Įvertinimas Nepasisekimai Veikla Kokybės planavimas, mokymai ir auditas, tiekimo išvystymas, kokybės tobulinimo programos ar sistemos priežiūros kaina, visos testavimo įrangos priežiūra. Bet kokios kontroliuojančiosios veiklos, kokybės analizės duomenys, audito teikėjų kokybės sistemos, kokybės rezultatų saugojimas. Kokybės visos blogai atliktos veiklos, padarytos klaidos, visas prarastas laikas, perdarant ar keičiant atliktus darbus, generuojant nereikalingus dokumentus, kurie nebuvo skaitomi, sprendžiant problemas, kurios jau išspręstos. Išorinės keitimas blogų produktų, kurie buvo grąžinti, veiklų perdarymas, prarastas geras vardas dėl skundų ir profesinio neatsakingumo. Nepasisekimas gali būti suskaidytas į vidinį, aptinkamą pačioje organizacijos prieš produktą pateikiant užsakovui ir todėl galimą greitai ištaisyti, bei išorinį, kurį aptinka užsakovas. Apskritai galima konstatuoti, kad nepasisekimo kaštai yra eile aukštesni negu prevencijos ar įvertinimo. 132

134 Valdymo ir kokybės valdymo guru Philip Bayard Crosby ištyrė, kad Organizacijai, turinčiai gerą kokybės sistemą, viena klaida gali kainuoti du centus. Tuo tarpu organizacijai, turinčiai abejotiną kokybės sistemą, viena klaida gali kainuoti 20 centų (Crosby, 1979) Santrauka Projektas baigiamas (uždaromas), kai visi planai ir procesai įvykdyti. Projekto baigiamajame etape reikalaujama patikrinti, kad visos veiklos, susijusios su projektu, yra baigtos ir pats projektas yra parengtas galutinei patikrai. Auditas patikrina, ar projektas atitinka iškeltus reikalavimus. Trumpiau sakant, bus atsakyta į klausimus: ar padarėte viską taip, kaip buvo sutarta, ir ar viskas padaryta korektiškai, ar sukurtų produktų charakteristikos tinkamos ir ar produktai pateikti užsakovui? Peržiūros metu stengiamasi rasti galimybę, kuri būtų padėjusi projektą įgyvendinti lengviau. Aspektai parenkami pagal projekto įgyvendinimo strategiją, įtraukiami visi tarpininkai. Peržiūra naudinga mokymuisi. Vykdant naują projektą nebedaroma senojo projekto vykdymo metu padarytų klaidų ir gaunama naujų idėjų. Kaina, kuri turi būti sumokėta už klaidą, yra sėkmingo projekto matas, todėl ji turi būti skaičiuojama. Tai dažnai yra pagrindinis atspirties taškas ieškant projekto kaštų mažinimo. Ji taip pat duoda daug informacijos apie tai, kas ir kaip vyksta organizacijoje. Vykdomos duomenų archyvavimo, proceso tobulinimo veiklos. Organizacijos matavimų duomenų bazė papildoma paskutiniais projekto duomenimis ir atliekama projekto pabaigos analizė. REIKŠMINIAI ŽODŽIAI / KEY WORDS Programinės įrangos projekto uždarymas; baigimas; atidavimas; nutraukimas; apžiūra; kontrolinis patikrinimas; dokumentacija; tarpininko pasitenkinimas; produkto aplinka; kokybės kaina; prevencija; nesėkmės; kas kur kada. Software project close-out, closure, completion, handover, termination, review, audit, documentation, sign-off, stakeholder satisfaction, product sorround, cost of quality, prevention, failure, whereabouts. 133

135 REKOMENDUOJAMI SKAITINIAI A Guide to the Project Management Body of Knowledge (PMBOK Guide), 2008: PMI Project Management Institute. The World s Leading Professional Association for Project Management: Library of PMI Global Standards: Standards-Library-of-PMI-Global-Standards.aspx PRINCE2 Information. PRINCE2 Courses for Project Managers provided by ILX Group: IPMA. International Project Management Association: Project Management Community and Resources for Project Managers: Управление проектами, обучение управлению проектами: http//bogdanov-associates.com NAUDOTA LITERATŪRA Crosby, P. B., Quality is Free, McGaw-Hill, Harvey, M., Project management, Prentice Hall, 2003, p Henry, J., Software Project Management: A Real-World Guide to Success, Boston: Pearson Education / Addison Wesley, Pisano, G. P., The Developmentfactory, HBS Press, Boston, MA,

136 12. Projekto dokumentacija Dokumentacijos paskirtis Dokumentacijos tikslai yra šie: įrodyti, kad projektas buvo užbaigtas tinkamai, tenkinant ISO 9000 reikalavimus; suteikti produkto užsakovui patarimus dėl produkto valdymo ir priežiūros; sukaupti naudingų žinių ateities projektams. Dokumentacija turi būti rengiama, kai vykdomas projektas. Jeigu dokumentacijos kūrimas bus paliktas projekto pabaigai, informacija gali būti prarasta, nes darbuotojams gali būti sunku prisiminti, ką ir kada jie darė. Visa dokumentacija turi būti sudaryta iš formalių duomenų, surinktų per visą darbo laiką, bendravimo dokumentų ir kiekvieno darbuotojo asmeninių užrašų bei pastabų. Kiekvienas darbuotojas turi turėti savo nuosavą įvykių dienoraštį, į kurį rašytų savo nuveiktus darbus, iškilusius sunkumus ir kitą svarbią informaciją. Tokie užrašai teikia daug naudos ateityje, ypač kai projektas yra vykdomas ilgą laiką. Formalią dokumentaciją sudaro: pasirašytos sutartys, leidimai, laiškai ir pastabos. Visa ši dokumentacija turi būti saugoma numatytą laiką (visą projekto gyvavimo laiką arba septynerius metus). Turėtų būti numatyta elektroninių dokumentų ir el. laiškų tvarkymo politika, kada elektroniniai duomenys gali būti perduoti į duomenų saugyklą. Pagal ISO 9000, organizacija projekto duomenims privalo naudoti failų sistemą, įtraukdama nurodymus, kas, kur, kada, ką sukūrė, keitė konkretų informacijos elementą. Dokumentams, susietiems su PĮ sistema, keliama daugelis reikalavimų: 1. Jie turi būti projektavimo grupės narių bendravimo terpė; 2. Turi būti informacijos, kurią naudoja palaikymo grupės nariai, saugykla; 3. Turi būti informacijos šaltinis valdymui; 4. Jie turi informuoti vartotoją, kaip naudoti ir administruoti sistemą. Šiems reikalavimams patenkinti reikia įvairių tipų dokumentų, pradedant neformaliais darbo dokumentais ir baigiant profesionaliai parengtais vartotojų vadovais. PĮ inžinieriai yra atsakingi už beveik visos šios dokumentacijos sudarymą. 135

137 12.2. Dokumentų klasifikacija Sistemos dokumentacija skirstoma į dvi klases: 1. Proceso dokumentacija, aprašanti projektavimo procesą ir palaikymą. Tai planai, darbų grafikai, proceso kokybės dokumentai, standartai. 2. Produkto dokumentacija. Sistemos dokumentacija aprašo produktą iš inžinieriaus, projektuojančio ir palaikančio sistemą, taško, o vartotojo dokumentacija yra produkto aprašymas, orientuotas į vartotoją. Efektyvi vadyba reikalauja, kad procesas būtų matomas. O kadangi PĮ yra nemateriali, vienintelis būdas, leidžiantis sekti projektavimo procesą, yra proceso dokumentacija. Ji skirstoma taip: 1. Planai, sąnaudų įvertinimai, grafikai. Šiuos dokumentus sudaro vadybininkai. Jie naudojami proceso planavimui ir kontrolei. 2. Ataskaitos. Tai dokumentai, referuojantys, kaip projektavimo metu naudojami ištekliai; 3. Standartai. Tai dokumentai, aprašantys, kaip procesas turi būti realizuojamas. Jie gali būti sudaryti remiantis organizacijos, nacionaliniais arba tarptautiniais standartais. 4. Darbiniai dokumentai. Jie fiksuoja inžinierių idėjas ir mintis, aprašo realizacijos strategijas, išryškina iškilusias problemas. Praktiškai tai yra techniniai bendravimo dokumentai. 5. Atmintinės ir pranešimai elektroniniu paštu. Juose fiksuojamos kasdienio bendravimo tarp grupės narių ir tarp menedžerių bei PĮ inžinierių detalės. Produkto dokumentacija aprašo jau pagamintą produktą ir, skirtingai nuo proceso dokumentacijos, ji yra ilgalaikė Vartotojo dokumentacija Vartotojo dokumentacija turi tenkinti standartą IEEE Std : IEEE standard for software user documentation. Programų sistemos vartotojai nėra vienodi. Ypač reikia išskirti programų sistemos galinius vartotojus ir sistemos administratorius. Todėl vartotojo dokumentacijoje turėtų būti atskiri skyriai, suskirstyti pagal vartotojo patirtį ir sistemos taikymą (12.1 pav.). Sistemos funkciniame aprašyme trumpai apžvelgiamos sistemos galimybės ir paskirtis. Vartotojai, paskaitę šį dokumentą kartu su įžanginiu vadovu, turi būti pajėgūs nuspręsti, ar tai sistema, kurios jiems reikia. Vartotojo vadovas yra neformalus įvadas į sistemą, aprašantis jos normalų naudojimą. Neišvengiamai pradedantieji, nepriklausomai nuo patirties, daro klaidų. Lengvai randama informacija, kaip po šių klaidų grįžti prie naudingo darbo ir išvengti galimų klaidos padarinių, turi būti sudėtinė šio dokumento dalis. 136

138 Sistemos vertintojai Sistemos administrat. Pradedantieji vartotojai Patyrę vartotojai Sistemos administrat. Funkcinis aprašymas Instaliavimo dokumentas Įžanginis vadovas Detalus sist. vadovas Administrat. vadovas Galimybių aprašymas Sistemos instaliavimas Pirmi žingsniai Detalės apie sistemą Sistemos eksploatacija 12.1 pav. Vartotojai ir dokumentacijos tipai Detaliame sistemos vadove turi būti aprašytos visos sistemos funkcijos bei galimybės ir jų naudojimas. Jame privalo būti visas pranešimų apie klaidas sąrašas su nuorodomis, kaip atkurti darbą po galimos klaidos ir išvengti jos padarinių. Svarbiausias reikalavimas šiam dokumentui išsamumas. Sistemos įdiegimo dokumentas skirtas sistemos administratoriams. Jame turi būti nurodytos detalės, kaip konkrečioje aplinkoje instaliuoti sistemą, sudarantys sistemą failai, minimali reikalingos techninės įrangos konfigūracija. Sistemos administratoriaus vadove turi būti aprašyti pranešimai, kaip sistema bendrauja su kitomis sistemomis ir kaip reaguoti į šiuos pranešimus. Jei sistema apima ir techninę įrangą, jame turi būti aprašyti operatoriaus veiksmai palaikant šią techninę įrangą. Pvz., kaip prijungti naujus periferinius įrenginius ir t. t Sistemos dokumentacija Sistemos dokumentacija apima visus dokumentus, aprašančius sistemos realizavimą, pradedant reikalavimų specifikacija ir baigiant priėmimo testo planu. Dokumentai, aprašantys projektavimą, kodavimą ir testavimą, yra svarbūs, kad sistema būtų suprantama ir palaikoma. Sistemos dokumentacija turi apimti: 1. Reikalavimų specifikaciją. 2. Sistemos architektūrą. 3. Duomenų struktūrą. 4. Kiekvieno modulio specifikaciją. 5. Modulių išeities kodą. Jis turi būti tinkamai komentuotas. 6. Testavimo dokumentus, aprašančius, kaip kiekviena programa buvo testuojama, ir testų ryšius su reikalavimais. 7. Sistemos eksploatavimo vadovą, aprašantį žinomas problemas. Visiems žinoma palaikymo problema yra užtikrinimas, kad dokumentacija žengtų koja kojon su sistemos pakeitimais. Nelaimei, dažnai taip nėra. Natūrali tendencija yra tokia laiku modifikuoti kodą, o dokumentaciją sutvarkyti vėliau. 137

139 12.3. Dokumentų kokybė ir rašymo stilius Deja, daugelio sistemų dokumentacija yra blogai parašyta, sunkiai suprantama, pasenusi ir nepilna. Nors situacija gerėja, dar daug organizacijų per mažai kreipia dėmesio dokumentų kokybei. Dokumentų kokybė yra tiek pat svarbi kaip ir programos kokybė. Be geros informacijos, kaip naudoti sistemą, sistemos naudingumas krenta. Geros dokumentacijos gamyba nėra nei lengvas, nei pigus procesas. Standartai dokumentavimo srityje vaidina svarbų vaidmenį, tačiau dokumentų kokybė daugiausia priklauso nuo rašytojo sugebėjimų aiškiai ir glaustai dėstyti mintis. Keletas nuorodų, leidžiančių pagerinti rašymo stilių: 1. Nevartokite ilgų sakinių, aprašančių skirtingus faktus. Trumpesnius sakinius lengviau suprasti. Kad skaitytojas suprastų visą sakinį, jam nėra reikalo įsiminti keleto pastraipų informacijos. 2. Nerašykite ilgų paragrafų. Bendra taisyklė paragrafą turi sudaryti ne daugiau kaip 7 sakiniai. 3. Nebūkite iškalbingi. Jei Jūs galite išreikšti mintį penkiais žodžiais, tai taip ir darykite. Ilgas aprašymas nebūtinai yra nuodugnesnis. Kokybė yra svarbiau nei kiekybė. 4. Būkite tikslūs ir apibrėžkite vartojamas sąvokas. Informatikos terminologija nėra nusistovėjusi, ir daugelis sąvokų turi daugiau nei vieną prasmę. Jei Jūs vartojate sąvokas, pvz., modulis ar procesas, užtikrinkite, kad šios sąvokos būtų aiškios ir skaitytojui. Apibrėžimus sudėkite į specialiųjų terminų žodyną. 5. Jei aprašymas sudėtingas, pasikartokite. Dažnai visai nebloga idėja yra pateikti du ar daugiau skirtingomis frazėmis išreikštus to paties dalyko aprašymus. Jei skaitytojui nesiseka gerai suprasti vieno aprašymo, jis turės galimybę tą patį dalyką panagrinėti iš kito taško. 6. Vartokite antraštes. Jos suskaido medžiagą į dalis, kurios gali būti skaitomos atskirai. Užtikrinkite, kad skyrių numeravimo tvarka būtų nuosekli ir vienoda. 7. Kur tik galima, vartokite išvardijimą papunkčiui. Dažniausiai aiškiau yra pateikti faktus sąrašu nei sakinyje. Paryškinkite (pabraukite) tekstą, rašykite storesnėmis raidėmis ar kitokiu šriftu). 8. Nesikreipkite į nuorodas naudodami vien tik nuorodos numerį. Pvz., vietoje 2.5 poskyryje... geriau rašykite 2.5 poskyryje, kuriame aprašomas bazinis COCOMO modelis... Dokumentai turi būti tikrinami (angl. inspect) panašiai kaip ir programos. Inspekcijos metu tekstas yra kritikuojamas, nurodomi informacijos praleidimai ir siūloma, kaip pagerinti dokumentą. Todėl tai skiriasi nuo kodo inspekcijų, kurios yra klaidų paieškos, o ne jų koregavimo mechanizmas. 138

140 13. Intelektinių teisių apsauga programų sistemų kūrimo procese Licencijos Licencija (lot. licentia leidimas) yra leidimas verslo tikslams panaudoti teisiškai apsaugotą (patentuotą) išradimą, pramoninį dizainą, prekių ženklų ar gamybos paslaptį (angl. know-how). Licenciją išduodantis fizinis arba juridinis asmuo vadinamas licenciaru, o licenciją gaunantis licenciatu. Tobulėjant gamybai, didėjant tarptautiniam darbo pasidalijimui didėja tarptautinės prekybos apyvarta. Joje vis plačiau įsigali speciali mokslo ir technikos išradimų prekyba licencijų prekyba. Pasaulinė tarptautinės licencijų prekybos apimtis 1960 m. buvo tik apie 2 milijardus dolerių, 1970 m. apie 19 milijardų, o 1985 m. išaugo iki 50 milijardų dolerių per metus. Tais pačiais metais galiojo apie 150 tūkstančių licencinių sutarčių. Šios prekybos metinis prieaugis yra apie 15 % ir 2 3 kartus pralenkia bendrą tarptautinės prekybos augimo tempą. Pagal licencijas per metus pagaminama produkcijos maždaug už 500 milijardų dolerių. Licencijų prekyba ypač aktyvi šalyse, kuriose išvystyta pramonė ir moksliniai tyrimai, pavyzdžiui, JAV firmos yra sudariusios daugiau kaip dešimt tūkstančių tarptautinių licencinių sutarčių ir per metus gauna daugiau kaip milijardą dolerių pajamų. Pagal JAV firmų išduotas licencijas užsienyje gaminamų prekių produkcija yra apie 2,5 karto didesnė už visą JAV eksporto apimtį. Licencinėmis operacijomis užsiima apie 3000 JAV firmų. Licencijų prekyba taip pat labai aktyvi Anglijoje, Vokietijoje, Japonijoje ir kitose kapitalistinėse valstybėse. Minėtose valstybėse dabar beveik kiekviena firma turi bent keletą licencinių sutarčių. Pasyvus licencijų prekybos balansas nerodo firmos atsilikimo, nes daugeliu atvejų ekonomiškai naudingiau būna įsigyti teisę gaminti ar pardavinėti kokį nors objektą, taip pat gauti techninę dokumentaciją, gamybos paslaptis (know-how) negu patiems konstruoti, eikvoti lėšas ir laiką. Tokį būdą pokario metais buvo pasirinkusios ir Japonijos firmos jos pagal užsienio firmų licencijas labai išugdė savo pramonę ir pakėlė specialistų kvalifikaciją. Japonijos specialistai, išstudijavę nupirktą techniką, pradėjo patys ją tobulinti, patentuoti ir pardavinėti licencijas. 139

141 Licencijų rūšys 1. Paprastoji licencija. Pagal paprastąją licenciją verslo tikslams leidžiama naudoti licencijos objektą ne tik licenciatui, bet ir licenciarui. Be to, licenciaras gali išduoti licencijas ir kitiems. Ši licencija dažniausiai pasitaiko plataus vartojimo prekių, taip pat gamybos paslapčių (know-how) srityje. 2. Išimtinė licencija suteikia jos naudojimo teises tik licenciatui. Naudojimosi apimtis gali būti gana įvairi. Ji apibrėžiama, apibūdinant panaudojimo būdą (pavyzdžiui, gaminti ir parduoti), kiekį (pvz., 3000 vienetų per metus ), laiką (pvz., 6 metai), teritoriją (pvz., Suomija). Šiuo atveju licencinėje sutartyje nurodyta apimtimi verslo tikslais panaudoti licencijos objekto ar išduoti kitos licencijos negali ir licenciaras. Išimtinės licencijos objektas dažniausiai yra mašinos arba prietaisai. 3. Pilnutinė licencija. Pagal pilnutinę licenciją, perleidžiamos visos teisės naudotis jos objektu. Šiuo atveju licencijos objekto (kol galioja sutartis) negali panaudoti net ir pats licenciaras. Jis taip pat nepasilieka teisės išduoti licencijas ir kitiems asmenims arba organizacijoms. Pilnutinė licencija retas atvejis. 4. Sublicenciją, arba priklausomąją licenciją, gali išduoti licenciatas, įsigijęs išimtinę arba pilnutinę licenciją ir gavęs licenciaro sutikimą. Pasitaiko, kad gauta licencija perleidžiama kitiems gamintojams. 5. Tarpusavio licencijos (angl. cross-license). Tai licencijų mainai. Tokios licencijos neišvengiamos tada, kai du patentų savininkai turi susijusius patentus, ir vienas patento savininkas negali užpatentuoto išradimo naudoti be antrojo patento savininko leidimo. 6. Įpareigojančiosios licencijos tai licencijos, kurias išduodami licenciarai perduoda ne tik savo teises, bet ir kuo nors įpareigoja licenciatus, pvz., iš jų pirkti sutartas prekes. Kai tokios licencijos neteisėtai monopolizuoja teisiškai neapsaugotus objektus (pvz., įpareigoja licenciatą iš licenciaro pirkti patentais neapsaugotus gaminius), kai kuriose valstybėse, pvz., JAV, jos pripažįstamos neteisėtomis, ir licenciatas gali atsisakyti už jas mokėti. 7. Patentinės licencijos išduodamos laisvai arba priverstinai. 8. Aktyvi licencija yra tada, kai ji išduodama pagal licenciaro pasiūlymą. 9. Pasyvi licencija išduodama pagal licenciato pageidavimą. 10. Kai patento savininkas paskelbia, kad bet kada bet kam gali išduoti licenciją, tokia licencija vadinama atvirąja (viešąja). Tada daugelyje valstybių (taip pat ir Lietuvos Respublikoje) rinkliava už patentą sumažinama iki 50 %. Dabar daugelio valstybių patentiniai įstatymai, apribodami piktnaudžiavimą išradimais, numato, kad per tam tikrą laiką (3 5 metus) nepanaudojus užpatentuoto objekto ir neperleidus šios teisės kitam, jį panaudoti už nustatytą atlyginimą gali būti leista bet kuriam pageidaujančiam fiziniam ar juridiniam asmeniui. Tai priverstinė licencija, kurią išduoda teismas arba patentų žinyba. Lietuvos Respublikoje tai atlieka Vilniaus apygardos teismas, kai išradimas nenaudojamas arba nepakankamai naudojamas ketverius metus nuo paraiškos padavimo arba trejus metus nuo patento išdavimo. 140

142 12. Išankstinės sutartys sudaromos pradėjus tartis dėl licencinės sutarties. Jų tikslas apsaugoti licencijos objektą ir kitą licenciaro informaciją nuo paskelbimo ir panaudojimo, kol bus pasirašyta licencinė sutartis. Be to, šiose sutartyse licenciaras įsipareigoja derėtis dėl licencijos tik su tokią sutartį pasirašiusiu potencialiu licenciatu. Licenciatas įmoka šioje sutartyje numatytą užstatą. Šis užstatas negrąžinamas, jei potencialus licenciatas nepasirašo licencinės sutarties. 13. Opcioninė (lot. optio valia, laisvas pasirinkimas, noras) sutartis sudaroma suteikiant teisę nustatytu laikotarpiu licenciją gauti tik ją pasirašiusiam potencialiam licenciatui. Ją pasirašęs potencialus licenciaras pasižada šiuo laikotarpiu nesiūlyti šios licencijos kitiems ir su jais nesiderėti. Potencialus licenciatas pasižada neskelbti gautos konfidencialios informacijos, be to, jis įmoka sutartą mokestį. Opcioninė sutartis sudaroma, kai potencialus licenciatas nėra priėmęs galutinio sprendimo, tačiau nori užsitikrinti pirmenybę prieš potencialius konkurentus, kol apsispręs pirkti ar nepirkti licencijos. 14. Tariantis dėl išimtinių teisių į išradimo, saugomo galiojančiu patentu, perleidimo, taip pat dėl nepatentinės licencijos, gali būti sudarytos specialios sutartys išankstinės, opcioninės, licencinės. Tokių sutarčių objektai gana įvairūs. Tai teisiškai apsaugoti ar numatomi apsaugoti išradimai, pramoninis dizainas, prekių ženklai, gamybos paslaptys, inžinerinės paslaugos, teisiškai neapsaugoti pramoninės nuosavybės objektai. Pažymėtina, kad šie objektai yra nematerialūs. Taigi galima teigti, kad šių sutarčių objektas tai visuma tam tikrų teisių, kuriomis disponuoja licenciaras ir kurias nori įsigyti licenciatas. Šios sutartys sudaromos, siekiant tiksliai apibrėžti kuo daugiau teisių perdavimo sąlygų. Jos gali būti sudaromos tarp vienos valstybės arba skirtingų valstybinių fizinių bei juridinių asmenų, todėl daugeliu atvejų joms būdingi užsienio prekybos sutarčių ypatumai ir sutartys turi atitikti daugelį tarptautinės privatinės teisės reikalavimų. 15. Neišimtine licencija licenciaras suteikia licenciatui teisę panaudoti licencijos dalyką, pasilikdamas teisę suteikti tokią teisę kitiems asmenims ir pats naudoti licencijos dalyką Programinės įrangos licencijos Autoriui Įstatymo suteikta išimtinė teisė atgaminti kūrinį bet kokia forma ar būdu; išleisti kūrinį; adaptuoti ar kitaip perdirbti kūrinį; platinti kūrinio originalą ar jo kopijas juos parduodant, nuomojant, teikiant panaudai ar kitaip perduodant nuosavybėn arba juos valdyti; importuoti kūrinio originalą ar jo kopijas ir kt. Kitiems asmenims autorius perduoda savo teisę pasinaudoti kūriniu tik rašytine sutartimi (autorine sutartimi dėl teisių perdavimo arba suteikti autorine licencine sutartimi). Kai programos platinamos per prekybos tinklą, teisė naudotis jomis suteikiama 141

143 licencine sutartimi, kuri pirkėjui pateikiama programos pakuotėje (paketo licencija). Paketo licencijoje nurodytos sąlygos programos naudotojui yra privalomos. Licencinė sutartis sudaroma, kai licenciatas apsisprendžia tam tikram laikotarpiui įsigyti teisę verslo tikslais naudoti licencijos objektą. Licencinės sutartys turi būti įregistruotos nustatytuose valstybės organuose. Lietuvos Respublikoje licencinė sutartis registruojama Valstybiniame patentų biure. Sumokėjus nustatytą rinkliavą, ji įrašoma į Lietuvos Respublikos patentų ar kitų pramoninės nuosavybės objektų registrą ir įsigalioja nuo įrašymo datos Sutartys sudaromos, siekiant tiksliai apibrėžti kuo daugiau teisių perdavimo sąlygų. Jos gali būti sudaromos tarp vienos valstybės arba skirtingų valstybinių fizinių ir juridinių asmenų, todėl daugeliu atvejų joms būdingi užsienio prekybos sutarčių ypatumai ir sutartys turi atitikti daugelį tarptautinės privatinės teisės reikalavimų. Autorinėje sutartyje dėl teisių perdavimo turi būti aiškiai nurodytos autoriaus perduodamos turtinės teisės į kūrinį (nurodant konkretaus kūrinio pavadinimą). Asmuo, kuriam perduotos autoriaus turtinės teisės, laikomas autoriaus turtinių teisių perėmėju. Negali būti perduodamos teisės į visus būsimus autoriaus kūrinius (Ivanauskienė). Autorius ar jo turtinių teisių perėmėjas gali sudaryti autorinę licencinę sutartį dėl išimtinių teisių suteikimo (išimtinė licencija) arba autorinę licencinę sutartį dėl neišimtinių teisių suteikimo (neišimtinė licencija). Licencija laikoma išimtine tik tuo atveju, jei tai tiesiogiai nurodyta sutartyje. Autorinė sutartis dėl turtinių teisių perdavimo, autorinė licencinė sutartis ir autorinė kūrinio užsakymo sutartis sudaromos raštu. Rašytinė sutarties forma neprivaloma sutartims dėl kūrinio paskelbimo periodiniuose leidiniuose. Tuo atveju, kai kompiuterių programos ir elektroninės duomenų bazės platinamos per prekybos tinklą, teisė naudotis kompiuterių programa ar elektronine duomenų baze suteikiama licencine sutartimi, kuri pirkėjui pateikiama kompiuterių programos ar duomenų bazės pakuotėje (paketo licencija). Paketo licencijoje nurodytos sąlygos kompiuterio programos ar elektroninės duomenų bazės naudotojui yra privalomos. Autorinėje sutartyje dėl turtinių teisių perdavimo ar autorinėje licencinėje sutartyje turi būti numatytos šios esminės sąlygos: 1) kūrinio pavadinimas (užsienio autorių kūrinių pavadinimai nurodomi ir originalo kalba); 2) perduodamos ar suteikiamos autorių turtinės teisės (kūrinio panaudojimo būdai), licencijos rūšis (išimtinė ar neišimtinė licencija); 3) galiojimo teritorija; 4) galiojimo terminas; 5) autorinio atlyginimo dydis, mokėjimo tvarka ir terminai; 6) šalių ginčų sprendimo tvarka ir atsakomybė; 7) kitos sutarties sąlygos, kurias šalys laiko esminėmis. 142

144 13.3. Vartotojo licencija Dauguma komercinių kompiuterinių programų parduodamos pagal tam tikrą licenciją. Licencija paprastai nustato tokius dalykus: kompiuterių, kuriuose gali būti įdiegta programa, skaičių; vartotojų skaičių. Pagal licenciją asmeninio kompiuterio naudotojas dažniausiai gali tą programą vykdyti tik savo kompiuteryje ir pasidaryti atsarginę programos kopiją. Kai kurios licencijos leidžia vartotojui tūrėti kelias programos kopijas skirtinguose kompiuteriuose su sąlyga, kad vienu metu nebus vykdoma skirtinguose kompiuteriuose. Taip pat įsidėmėtina, kad rašytinė licencija taikoma tik vienai programai ir vienai kompiuterio darbo vietai. Jeigu sutartyje nenurodytas terminas, kuriam perduodamos turtinės teisės ar suteikiama licencija, bet kuri sutarties šalis gali nutraukti sutartį, prieš vienerius metus raštu pranešusi kitai šaliai apie sutarties nutraukimą Creative Commons licencijos Creative Commons licencijos nėra nuosavybės teisių (angl. copyright) alternatyva. Jos veikia kartu (angl. alongside copyright), ir autorius gali modifikuoti savo autoriaus teises pagal poreikius: Siekiama užtikrinti, kad CC licencijos veiktų pasaulyje globaliai. Autoriai gali pasirinkti kūrinio publikavimo sąlygas. Creative Commons (kūrybiškos bendruomenės) tai pelno nesiekianti organizacija, nustatanti viešinamas licencijų sutartis, kuriomis autoriai apibrėžia teisinį savo kūrinių naudojimo būdą. Creative Commons tikslas išplėsti laisvai pasiekiamų viešam ir teisiškai legaliam naudojimui kūrybinių darbų diapazoną. Organizacija išleido kelias autorinių teisių licencijas, vad. Creative Commons licencijas. Šios licencijos apriboja tik tam tikras (arba jokias) licencijuoto kūrinio naudojimo teises, kas iš esmės skiriasi nuo tradicinių autorinių teisių (angl. copyright), kur yra numatomos griežtos intelektinės nuosavybės teisės, stipriau ribojančios kūrinių naudojimą. CC licencijos suderintos su daugiau nei 50 šalių teisinėmis sistemomis ( Šalyse, taikančiose Creative Commons principus, licencinės sąlygos parengiamos trimis lygmenimis: Natūrali kalba licencija būtina paaiškinti pagrindines sąlygas, kad autorius galėtų paprastai ir suprantamai paaiškinti savo poziciją. Teisinė terminija reikalinga galimų ginčų atveju, kai sprendžia teismas. Lietuvos Respublikoje turi būti derinama su Civiliniu Kodeksu, Autorių teisių ir gretutinių teisių įstatymo, kitų susijusių teisės aktų terminija ir teisiniais reguliavimo principais. 143

145 Skaitmeninis kodas būtinas kūrinių panaudojimui automatizuoti. Pavyzdžiui, kai kurios interneto paieškos sistemos leidžia ieškoti kūrinių pagal iš anksto apibrėžtas Creative Commons kūrinių teises. Kalbant apie CC licencijas, Lietuvoje dabartinis autorių teisių reguliavimas yra problemiškas. Lietuvos autorių teisių ir gretutinių teisių įstatymas akivaizdžiai draudžia perduoti neturtines autoriaus teises. Kūrinio vartotojų interesai gali būti pažeisti, jei autorius vėliau pradėtų reikalauti nurodyti savo autorystę, drausti naudoti jo kūrinį. Todėl išvestinius kūrinius kuriantys autoriai patenka į tam tikrą neapibrėžtumą. Lygiai tokia pati abejonė gali būti keliama ir turtinių autoriaus teisių atveju lentelėje pateikta Creative Commons licencijų santrauka lentelė. Creative Commons licencijų trumpas aprašymas Ženklas Licencija by Autoriaus paminėjimas (angl. attribution). Autoriaus pavardė privalo būti paminėta. Patartina rinktis, kai autorius nesiekia materialinio uždarbio, tačiau nori gauti moralinį pasitenkinimą, kad jo kūrinį naudoja ir naudodami suvokia autoriaus įnašą. Naudinga autoriams, kurie siekia greitai išgarsėti. nc Naudojimas ne komerciniais tikslais (angl. noncommercial). Kūrinius galima laisvai naudoti asmeniniais tikslais, platinti, keisti, tačiau bet kokia pelno siekianti veikla draudžiama. sa Tokia pati licencija išvestiniams kūriniams (angl. share alike). Kūrinys ir po pakeitimų turi būti platinamas vien nurodytos licencijos sąlygomis. nd Nedaryti pakeitimų (angl. no derivative works). Keisti pradinį kūrinį draudžiama. Šią licenciją naudoja tie autoriai, kurie siekia išvengti panašių kūrinių paplitimo. REIKŠMINIAI ŽODŽIAI / KEY WORDS Licencija, intelektinės teisės, autorių teisės. Licenses, intellectual property rights. REKOMENDUOJAMI SKAITINIAI Various Licenses and Comments about Them GNU Project Free Software Foundation (FSF): 144