Programų sistemų inžinerija - Matematikos ir Informatikos fakultetas ...
Programų sistemų inžinerija - Matematikos ir Informatikos fakultetas ...
Programų sistemų inžinerija - Matematikos ir Informatikos fakultetas ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
EUROPOS SĄJUNGAEuropos socialinis fondasKURKIME ATEITĮ DRAUGE!Saulius RagaišisProgramų sistemų inžinerijaMokymo medžiagaVilnius2007
Mokymo medžiaga parengta vykdant projektą „Programų sistemų magistrantūrosįsteigimas”, įgyvendinantį 2004-2006 metų bendrojo programavimo dokumento 2.5 priemonę„Žmogiškųjų išteklių kokybės gerinimas mokslinių tyrimų <strong>ir</strong> inovacijų srityje”, finansuojamąEuropos Sąjungos struktūrinių fondų lėšomis <strong>ir</strong> Lietuvos Respublikos bendrojo finansavimolėšomis.
Programų sistemų inžinerijaTurinysPratarmė ..........................................................................................................................................61. Programų sistemų inžinerijos samprata.......................................................................................72. Programinės įrangos gyvavimo ciklo procesai pagal standartą ISO/IEC 12207 ......................13Procesų kategorijos ...............................................................................................................15Procesų apibrėžimai ..............................................................................................................17Kūrimo proceso apibrėžimas veiklomis <strong>ir</strong> užduotimis..........................................................17Kūrimo proceso apibrėžimas tikslais <strong>ir</strong> rezultatais ...............................................................18Įsigijimo proceso apibrėžimas...............................................................................................193. Programų kūrimo procesas........................................................................................................28Esminės sąvokos .......................................................................................................................32Standartas ISO/IEC 15504 ........................................................................................................34Procesų gebėjimo matavimo karkasas...................................................................................34Reikalavimai procesų modeliui.............................................................................................38Reikalavimai vertinimo modeliui..........................................................................................394. Integruotas gebėjimo brandos modelis......................................................................................43CMM ats<strong>ir</strong>adimas......................................................................................................................43CMMI struktūra.........................................................................................................................44Pakopinės architektūros CMMI modelis...................................................................................47Tolydinės architektūros CMMI modelis ...................................................................................49Bendra proceso sričių struktūra.................................................................................................51Atitikimas tarp organizacijos brandos lygio <strong>ir</strong> proceso sričių gebėjimo lygių..........................53Vertinimas pagal CMMI ...........................................................................................................54SCAMPI: standartinis vertinimo pagal CMMI proceso gerinimui metodas.........................555. Programų kūrimo proceso modelių sąryšis ...............................................................................596. Projektas PKP Branda ...............................................................................................................63Brandaus programų kūrimo proceso modelis............................................................................63Programų kūrimo proceso gerinimo metodika..........................................................................66Nagrinėti organizacijos verslo tikslus ...................................................................................67Inicijuoti proceso gerinimą....................................................................................................68Atlikti proceso vertinimą.......................................................................................................69Sudaryti veiksmų planą .........................................................................................................71Įgyvendinti gerinimo veiksmus.............................................................................................72Patv<strong>ir</strong>tinti proceso pakeitimus...............................................................................................72Paskleisti proceso pakeitimus................................................................................................73Stebėti proceso vykdymą ......................................................................................................73Programų kūrimo proceso instrumentinės priemonės...............................................................737. Asmeninis programų kūrimo procesas......................................................................................80PSP ats<strong>ir</strong>adimas.........................................................................................................................80PSP modelis...............................................................................................................................80PSP apimtis ...............................................................................................................................81PSP struktūra.............................................................................................................................82PSP metrikos .........................................................................................................................82PSP kokybės modelis ............................................................................................................83PSP prognozavimo modelis ..................................................................................................83PSP tobulinimo modelis........................................................................................................83Pagrindiniai principai ............................................................................................................83PSP praktikos ........................................................................................................................84Mokymo medžiaga 3
PSP principų <strong>ir</strong> praktikų sąryšiai...........................................................................................89PSP mokymų įtakos asmeniniam procesui tyrimai ...................................................................91PSP proceso taikymo pramonėje pavyzdžiai ............................................................................93PSP proceso duomenų kokybės problema ..............................................................................1008. Komandinis programų kūrimo procesas .................................................................................103TSP projektiniai sprendimai....................................................................................................103TSP struktūra <strong>ir</strong> eiga................................................................................................................104Pagrindiniai TSP principai ......................................................................................................115TSP praktikos ..........................................................................................................................116TSP principų <strong>ir</strong> praktikų sąryšiai.............................................................................................126TSP taikymų praktikoje rezultatų analizė ...............................................................................127PSP <strong>ir</strong> TSP taikymų pat<strong>ir</strong>ties analizės išvados....................................................................1299. Testavimo brandos modelis.....................................................................................................131TMM struktūra ........................................................................................................................134TMM vertinimo modelis .........................................................................................................135Vertinimo komandos parinkimas <strong>ir</strong> apmokymas ................................................................136Vertinimo procedūra ...........................................................................................................136Vertinimo klausimynas .......................................................................................................137Išvados.....................................................................................................................................13810. Judriosios programų kūrimo metodikos................................................................................140Judriųjų programų kūrimo metodikų manifestas ....................................................................140Ekstremalus programavimas ...................................................................................................142XP procesas .........................................................................................................................142Pagrindinės XP vertybės .....................................................................................................143XP praktikos........................................................................................................................144DSDM .....................................................................................................................................145DSDM procesas...................................................................................................................146Pagrindiniai DSDM principai..............................................................................................147Pagrindiniai DSDM metodai...............................................................................................148Scrum ......................................................................................................................................150Crystal .....................................................................................................................................152Judriųjų <strong>ir</strong> planais paremtų metodų derinimas ........................................................................15211. Projekto valdymas pagal PMBOK ........................................................................................157Kas yra projektas? ...................................................................................................................157Kas yra projektų valdymas? ....................................................................................................159Projektų valdymo žinių sritys..................................................................................................160Projekto valdymo procesų grupės ...........................................................................................163Projekto integravimo valdymas...........................................................................................163Projekto apimties valdymas ................................................................................................164Projekto laiko valdymas ......................................................................................................165Projekto kainos valdymas....................................................................................................165Projekto kokybės valdymas.................................................................................................165Projekto žmogiškųjų resursų valdymas...............................................................................166Projekto komunikavimo valdymas......................................................................................166Projekto rizikos valdymas ...................................................................................................167Projekto įsigijimų valdymas................................................................................................16712. Vadovavimas programų sistemų projektams ........................................................................169Programų sistemų projekto lyderis..........................................................................................169Lyderio tikslai .....................................................................................................................169Lyderio įsitikinimas.............................................................................................................169
Lyderiai <strong>ir</strong> jų pasekėjai........................................................................................................169Transformacinis lyderiavimas.............................................................................................169Pareigybinis lyderiavimas ...................................................................................................170Lyderiavimas iš apačios ......................................................................................................171Lyderio vizija ......................................................................................................................171Techninių profesionalų lyderis............................................................................................171Įsipareigojimų etika.................................................................................................................172Įsipareigojimų elementai .....................................................................................................172Atsakingų įsipareigojimų sudarymas ..................................................................................173Įsipareigojimai ar kryžiaus žygiai? .....................................................................................173Per griežti įsipareigojimai ...................................................................................................173Vadovybės įsipareigojimai..................................................................................................174Įsipareigojimų keitimas.......................................................................................................174Kruopštus darbo atlikimas...................................................................................................175Įsipareigojimų etikos kūrimas .............................................................................................175Įsipareigojimų nuosavybė ...................................................................................................17513. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektai ..................................................................................177Pagrindiniai etiniai principai ...................................................................................................178Etinis sprendimų pagrindimas.................................................................................................181Teisiniai programų sistemų inžinerijos aspektai .....................................................................182Programų sistemų inžinerijos kontrolinių klausimų pavyzdžiai .................................................185
Programų sistemų inžinerijaPratarmėPratarmėŠį mokymo medžiaga sk<strong>ir</strong>ta informatikos krypties magistrantūros gilinamajam programųsistemų inžinerijos kursui. Daroma prielaida, kad klausytojai jau yra išklausę bakalauro lygmensprogramų sistemų inžinerijos pagrindų kursą.Daugiausiai dėmesio sk<strong>ir</strong>iama temoms, susijusioms su programų kūrimo procesu, nes šiojeprogramų sistemų inžinerijos srityje labiausiai vystomi moksliniai tyrimai VU MIF.P<strong>ir</strong>miausia aptariama programų sistemų inžinerijos samprata, jos vieta tarp kitų disciplinų<strong>ir</strong> pagrindinės žinių sritys. Antrame skyriuje pateikiami programinės įrangos gyvavimo cikloprocesų apibrėžimai standarte ISO/IEC 12207.Trečiasis skyrius pradeda programų kūrimo proceso nagrinėjimą. P<strong>ir</strong>miausia apibrėžiamospagrindinės sąvokos, tada pristatomi labiausiai pasaulyje paplitę proceso modeliai ISO/IEC15504 <strong>ir</strong> CMM/CMMI bei naujausi jų sąryšių tyrimų rezultatai.Šeštame skyriuje aptariami pagrindiniai VU, KTU <strong>ir</strong> p<strong>ir</strong>maujančių Lietuvos IT įmonių„Alna“ <strong>ir</strong> „Sintagma“ atlikto projekto „Brandaus programų kūrimo proceso įdiegimo metodikos<strong>ir</strong> instrumentinių priemonių sukūrimas (PKP Branda)“ rezultatai: brandaus programų kūrimoproceso modelis, proceso gerinimo metodika <strong>ir</strong> ją palaikančios instrumentinės priemonės.Septintame <strong>ir</strong> aštuntame skyriuose nagrinėjami asmeninis <strong>ir</strong> komandinis programų kūrimoprocesai atitinkamai, o devintame skyriuje pateikiamas specializuoto gebėjimų brandos modeliųpavyzdys, sk<strong>ir</strong>tas testavimui.Paskutinį dešimtmetį pasaulyje labai išpopuliarėjo judriosios programų kūrimų metodikos,kurių pristatymui sk<strong>ir</strong>tas dešimtas skyrius.Esminis vaidmuo programų sistemų kūrime tenka projektų valdymo veikloms, todėlp<strong>ir</strong>miausia išnagrinėjami pagrindiniai bet kokių projektų valdymo procesai, apibrėžti de factostandartu tapusiame PMBOK, o po to aptariamas vadovavimas programų sistemų projektams.Paskutinis skyrius sk<strong>ir</strong>tas profesiniams, etiniams <strong>ir</strong> teisiniams programų sistemų inžinerijosaspektams, kurie tradiciškai ignoruojami Lietuvoje teikiamose studijų programose.Mokymo medžiaga 6
Programų sistemų inžinerija1. Programų sistemų inžinerijos samprata1. Programų sistemų inžinerijos samprataP<strong>ir</strong>miausia apibrėšime, kas yra informatika 1 (angl. Computing) <strong>ir</strong> kokią vietą joje užimaprogramų sistemų inžinerija (angl. Software Engineering). Pagal Computing Curricula 2005[CC2005] apibrėžimą, informatika „reiškia bet kokią tikslingą veiklą, reikalaujančią, gaunančiąnaudos iš ar kuriančią kompiuterius. Informatika apima projektavimą <strong>ir</strong> kūrimą techninės įrangosbei įva<strong>ir</strong>ios pask<strong>ir</strong>ties programų sistemų; apdorojimą, struktūrizavimą <strong>ir</strong> valdymą įva<strong>ir</strong>ių tipųinformacijos; mokslinius tyrimus naudojantis kompiuteriais; kūrimą intelektualių kompiuteriniųsistemų; naudojimą <strong>ir</strong> kūrimą komunikavimo bei laisvalaikio priemonių; radimą <strong>ir</strong> surinkimąkažkuriam tikslui reikalingos informacijos <strong>ir</strong> taip toliau. Šis sąrašas yra begalinis, o galimybėsneišmatuojamos.“.Informatikoje išsk<strong>ir</strong>iamos 5 savarankiškos disciplinos:- Kompiuterių inžinerija (angl. Computer Engineering);- Kompiuterių mokslas (angl. Computer Science);- Informacinės sistemos (angl. Information Systems);- Informacinės technologijos (angl. Information Technology);- Programų sistemų inžinerija (angl. Software Engineering).Sk<strong>ir</strong>tumai tarp šių disciplinų <strong>ir</strong> tai, kam kiekvienoje iš jų sk<strong>ir</strong>iama daugiausiai dėmesio,aiškiai matomi iš diagramų, pateiktų 1.1 <strong>ir</strong> 1.2 paveikslėliuose, bet pradiniam įspūdžiui susidarytitrumpai apibūdinkime jas visas.Kompiuterių inžinerija nagrinėja kompiuterių <strong>ir</strong> jų sistemų projektavimą <strong>ir</strong> kūrimą,pagrindinį dėmesį sk<strong>ir</strong>dama techninei <strong>ir</strong> įdėtinei programinei įrangai (angl. Embedded Software).Kompiuterių mokslas apima plačią sritį nuo teorinių <strong>ir</strong> algoritminių pagrindų iki įva<strong>ir</strong>iausiųtaikymų. Visą veiklą galima būtų susk<strong>ir</strong>styti į 3 sritis: programinės įrangos projektavimas <strong>ir</strong>kūrimas; naujų kompiuterių taikymų paieška (pvz., tokių tyrimų rezultate ats<strong>ir</strong>ado WWW);efektyvių sprendimų paieška (pvz., duomenų bazės efektyviam informacijos saugojimui <strong>ir</strong>apdorojimui). Kompiuterių mokslo studijų programose akcentuojamas ne pas<strong>ir</strong>uošimaskonkrečiam darbui, bet pagrindai, įgalinantys pereiti prie naujų technologijų <strong>ir</strong> idėjų.Informacinių sistemų pagrindinis sprendžiamas uždavinys yra organizacijos informaciniųporeikių patenkinimas diegiant informacines technologijas į verslo procesus. Ši disciplinapagrindinį dėmesį sk<strong>ir</strong>ia informacijai, verslo poreikiams, o technologijas nagrinėja kaippriemones verslo tikslams pasiekti. Informacinių sistemų specialistams tenka esminis vaidmuo1 Reikia specialiai atkreipti dėmesį, kad šioje medžiagoje terminas informatika naudojamas plačiąja prasme(atitinkančia anglišką terminą Computing), t.y. pagal Lietuvoje naudojamą mokslų klasifikaciją ji apima tiekinformatikos, tiek informatikos inžinerijos mokslų sritis. Lietuvoje informatika dažnai naudojama žymiai siauresneprasme (pavyzdžiui, <strong>Informatikos</strong> studijų programa), kuri atitinka klasikinį kompiuterių mokslą (angl. ComputerScience).Mokymo medžiaga 7
Programų sistemų inžinerija1. Programų sistemų inžinerijos samprataŽmonės30 %Žmonės30 %25 %25 %Organizacijos <strong>ir</strong> verslas20 %<strong>Informatikos</strong> teorijaOrganizacijos <strong>ir</strong> verslas20 %<strong>Informatikos</strong> teorija15 %15 %Valdymas10 %5 %MatematikaValdymas10 %5 %MatematikaInformacijaFizikaInformacijaFizikaPrograminė įrangaTechninė įranga <strong>ir</strong>architektūraPrograminė įrangaTechninė įranga <strong>ir</strong>architektūraInfrastruktūraInfrastruktūraKompiuterių inžinerijaŽmonės30 %Kompiuterių mokslasŽmonės30 %25 %25 %Organizacijos <strong>ir</strong> verslas20 %<strong>Informatikos</strong> teorijaOrganizacijos <strong>ir</strong> verslas20 %<strong>Informatikos</strong> teorija15 %15 %Valdymas10 %5 %MatematikaValdymas10 %5 %MatematikaInformacijaFizikaInformacijaFizikaPrograminė įrangaTechninė įranga <strong>ir</strong>architektūraPrograminė įrangaTechninė įranga <strong>ir</strong>architektūraInfrastruktūraInformacinės sistemosInfrastruktūraInformacinės technologijosOrganizacijos <strong>ir</strong> verslasValdymasŽmonės30 %25 %20 %15 %10 %5 %<strong>Informatikos</strong> teorijaMatematikaInformacijaFizikaPrograminė įrangaTechninė įranga <strong>ir</strong>architektūraInfrastruktūraProgramų sistemų inžinerija1.2 pav. Disciplinų nagrinėjamos sritys [Kon06]Programų sistemų inžinerija ats<strong>ir</strong>ado kaip kompiuterių mokslo sritis, kai patikimų sistemų,sk<strong>ir</strong>tų sudėtingų uždavinių sprendimui, kūrimas darėsi vis sunkesnis – vienas žmogus nebegalėjoaprėpti visos programos. Sistemos pradėtos naudoti <strong>ir</strong> kritinėse veiklose, kuriose netgi vienintelėMokymo medžiaga 9
Programų sistemų inžinerija1. Programų sistemų inžinerijos samprataprogramos klaida gali baigtis žmonių sužalojimu ar m<strong>ir</strong>timi. Tapo aišku, kad gerų programųkūrimas yra labai sudėtingas, labai brangus, bet labai reikalingas.Kiekvienai iš penkių disciplinų <strong>ir</strong> jos bakalauro lygmens 2 studijų programoms apibrėžti yrask<strong>ir</strong>tos atsk<strong>ir</strong>os Computing Curricula 2005 dalys. Programų sistemų inžinerijai sk<strong>ir</strong>ta dalis[SE2004].Programų sistemų inžinerija – gana jauna sritis. Pats terminas „programų sistemųinžinerija“ paplito iš NATO remiamos konferencijos, vykusios Vokietijoje 1968 metais.Kompiuterių mokslas (kaip <strong>ir</strong> kiti mokslai) koncentruojasi į naujų žinių kūrimą, oprogramų sistemų inžinerija (kaip <strong>ir</strong> kitos inžinerinės disciplinos) koncentruojasi į apibrėžimąmetodų projektavimui <strong>ir</strong> kūrimui patikimų „daiktų“, atliekančių tai, kam jie buvo sk<strong>ir</strong>ti.Programų sistemų inžinerija yra disciplina, t<strong>ir</strong>ianti kūrimą <strong>ir</strong> priežiūrą programų sistemų,veikiančių patikimai <strong>ir</strong> efektyviai bei tenkinančių visus užsakovų joms iškeltus reikalavimus. Jiiš esmės sk<strong>ir</strong>iasi nuo kitų inžinerijos disciplinų tuo, kad kuriami produktai (programų sistemos)yra nematerialūs (neapčiuopiami), o jų naudojimo sritys begalinės. Ji siekia apjungtimatematikos <strong>ir</strong> kompiuterių mokslo principus su inžineriniais metodais, sk<strong>ir</strong>tais materialiųproduktų kūrimui.Kompiuterių mokslo <strong>ir</strong> programų sistemų studijų programos turi daug bendrų kursų, betprogramų sistemų inžinerijoje yra labiau akcentuojami sistemų kūrimo <strong>ir</strong> priežiūros metodai,užtikrinantys jų naudojamumą <strong>ir</strong> patikimumą; net rekomenduojama, kad studijų metu būtųdalyvaujama kūrime realios sistemos, kurią naudos kiti, taip formuojant supratimą <strong>ir</strong> įgūdžiussuprasti užsakovų poreikius <strong>ir</strong> sukurti juos tenkinančią sistemą.Pagrindinis programų sistemų inžinerijos tikslas yra sukurti modelius <strong>ir</strong> patikimus metoduskūrimui kokybiškų sistemų laiku <strong>ir</strong> su numatytu biudžetu, apimant tiek teoriją, tiek jos taikymąpraktikoje.Projektas SWEBOKDetalesnę programų sistemų inžinerijos sampratą galima susidaryti iš IEEE ComputerSociety iniciatyva yra vykdomos projekto SWEBOK (angl. SoftWare Engineering Body OfKnowledge) [SWEBOK]. Šio projekto tikslas apibrėžti pagrindines programų sistemųinžinieriams būtinų žinių sritis.Buvo sukurtos kelios versijos:1. Šiaudų amžiaus žmogaus versija (angl. Straw Man Version) 1998 metais;2. Akmens amžiaus žmogaus versijos (angl. Stone Man Versions) 1999-2001 metais;2 Magistro lygmens studijų programos nėra detaliau apibrėžiamos, nes jos turi remtis moksliniais tyrimais,atliekamais universitete, todėl praktiškai neįmanoma sk<strong>ir</strong>tinguose universitetuose rasti vienodas magistro lygmensstudijų programas.Mokymo medžiaga 10
Programų sistemų inžinerija1. Programų sistemų inžinerijos samprata3. Geležies amžiaus žmogaus versija (angl. Iron Man Version) 2004 metais.SWEBOK išsk<strong>ir</strong>iamos pagrindinės žinių sritys <strong>ir</strong> įvardinamos esminės temos (1 lentelė),nurodoma svarbiausia literatūra <strong>ir</strong> joje nagrinėjamos temos.Nr.Žinių sritis <strong>ir</strong> esminės jos temos1 Programų sistemų reikalavimai (angl. Software Requ<strong>ir</strong>ements):- Reikalavimų pagrindai (angl. Software Requ<strong>ir</strong>ements Fundamentals)- Reikalavimų procesas (angl. Requ<strong>ir</strong>ements Process)- Reikalavimų išgavimas (angl. Requ<strong>ir</strong>ements Elicitation)- Reikalavimų analizė (angl. Requ<strong>ir</strong>ements Analysis)- Reikalavimų specifikavimas (angl. Requ<strong>ir</strong>ements Specification)- Reikalavimų validavimas (angl. Requ<strong>ir</strong>ements Validation)- Praktiniai aspektai (angl. Practical Considerations)2 Programų sistemų projektavimas (angl. Software Design):- Projektavimo pagrindai (angl. Software Design Fundamentals)- Esminės projektavimo problemos (angl. Key Issues in Software Design)- Programų sistemų struktūra <strong>ir</strong> architektūra (angl. Software Structure and Architecture)- Projekto kokybės analizė <strong>ir</strong> vertinimas (angl. Software Design Quality Analysis andEvaluation)- Projektavimo notacijos (angl. Software Design Notations)- Projektavimo strategijos <strong>ir</strong> metodai (angl. Software Design Strategies and Methods)3 Programų sistemų kūrimas (angl. Software Construction):- Kūrimo pagrindai (angl. Software Construction Fundamentals)- Kūrimo valdymas (angl. Managing Construction)- Praktiniai aspektai (angl. Practical Considerations)4 Programų sistemų testavimas (angl. Software Testing):- Testavimo pagrindai (angl. Software Testing Fundamentals)- Testavimo lygiai (angl. Test Levels)- Testavimo metodai (angl. Testing Techniques)- Matavimai, susiję su testavimu (angl. Test Related Measures)- Testavimo procesas (angl. Test Process)5 Programų sistemų priežiūra (angl. Software Maintenance):- Priežiūros pagrindai (angl. Software Maintenance Fundamentals)- Esminės priežiūros problemos (angl. Key Issues in Software Maintenance)- Priežiūros procesas (angl. Maintenance Process)- Priežiūros metodai (angl. Techniques for Maintenance)6 Programų sistemų konfigūracijos valdymas (angl. Software Configuration Management):- Konfigūracijos valdymo procesas (angl. Management of the SCM Process)- Konfigūracijos identifikavimas (angl. Software Configuration Identification)- Konfigūracijos kontroliavimas (angl. Software Configuration Control)- Konfigūracijos būsenos valdymas (angl. Software Configuration Status Accounting)- Konfigūracijos auditas (angl. Software Configuration Auditing)- Konfigūracijos išleidimų valdymas <strong>ir</strong> pateikimas (angl. Software ConfigurationRelease Management and Delivery)7 Programų sistemų projektų valdymas (angl. Software Engineering Management):- Inicijavimas <strong>ir</strong> apimties apibrėžimas (angl. Initiation and Scope Definition)- Projekto planavimas (angl. Software Project Planning)- Projekto vykdymas (angl. Software Project Enactment)- Peržiūra <strong>ir</strong> vertinimas (angl. Review and Evaluation)- Uždarymas (angl. Closure)- Programų inžinerijos matavimai (angl. Software Engineering Measurement)Mokymo medžiaga 11
Programų sistemų inžinerija1. Programų sistemų inžinerijos samprataNr.Žinių sritis <strong>ir</strong> esminės jos temos8 Programų sistemų kūrimo procesas (angl. Software Engineering Process):- Proceso įgyvendinimas <strong>ir</strong> keitimas (angl. Process Implementation and Change)- Proceso apibrėžimas (angl. Process Definition)- Proceso vertinimas (angl. Process Assessment)- Proceso <strong>ir</strong> produkto matavimai (angl. Process and Product Measurement)9 Programų sistemų metodai <strong>ir</strong> įrankiai (angl. Software Engineering Tools and Methods):- Reikalavimų įrankiai (angl. Software Requ<strong>ir</strong>ements Tools)- Projektavimo įrankiai (angl. Software Design Tools)- Kūrimo įrankiai (angl. Software Construction Tools)- Testavimo įrankiai (angl. Software Testing Tools)- Priežiūros įrankiai (angl. Software Maintenance Tools)- Konfigūracijos valdymo įrankiai (angl. Software Configuration Management Tools)- Projektų valdymo įrankiai (angl. Software Engineering Management Tools)- Programų kūrimo proceso įrankiai (angl. Software Engineering Process Tools)- Kokybės užtikrinimo įrankiai (angl. Software Quality Tools)- Įva<strong>ir</strong>ialypiai įrankiai (angl. Miscellaneous Tools Issues)- Euristiniai metodai (angl. Heuristic Methods)- Formalūs metodai (angl. Formal Methods)- Prototipavimo metodai (angl. Prototyping Methods)10 Programų sistemų kokybė (angl. Software Quality):- Kokybės pagrindai (angl. Software Quality Fundamentals)- Kokybės valdymo procesas (angl. Software Quality Management Process)- Praktiniai aspektai (angl. Practical Considerations)11 Susijusių disciplinų žinios (angl. Knowledge Areas of the Related Disciplines):- Kompiuterių inžinerija (angl. Computer Engineering)- Kompiuterių mokslas (angl. Computer Science)- Valdymas (angl. Management)- Matematika (angl. Mathematics)- Projektų valdymas (angl. Project Management)- Kokybės valdymas (angl. Quality Management)- Programų sistemų ergonomika (angl. Software Ergonomics)- Sistemų inžinerija (angl. System Engineering)Literatūra papildomam skaitymui[CC2005] Computing Curricula 2005: The Overview Report. ACM and IEEE, 2006.http://www.acm.org/education/curric_vols/CC2005-March06Final.pdf[SE2004][Kon06][SWEBOK]Software Engineering 2004. Curriculum Guidelines for Undergraduate DegreePrograms in Software Engineering. A Volume of the Computing Curricula Series.ACM and IEEE, 2004. http://sites.computer.org/ccse/Karoly Kondorosi, Towards a Common Frame for European CS/InformaticsEducation. euroTICS2006, 17 October 2006.http://www.informatics-europe.org/talks/Kondorosi_eurotics_2006.pdfGuide to the Software Engineering Body of Knowledge, 2004 Version,SWEBOK®. IEEE, 2004. http://www.swebok.org/.Mokymo medžiaga 12
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesai2. Programinės įrangos gyvavimo ciklo procesai pagal standartąISO/IEC 12207Viena iš esminių sąvokų programų sistemų inžinerijoje yra programinės įrangos gyvavimociklas. Kaip matėme praeitame skyriuje, didžioji dalis žinių sričių yra siejamos su gyvavimociklo procesais.Apibrėždami programinės įrangos gyvavimo ciklą, įva<strong>ir</strong>ūs autoriai įvardina sk<strong>ir</strong>tingus jįsudarančius procesus. Procesų rinkinys kaip taisyklė priklauso ne tik nuo autoriaus, bet <strong>ir</strong> nuonagrinėjamo gyvavimo ciklo modelio: pavyzdžiui, nuosekliame (angl. waterfall) gyvavimo cikleišsk<strong>ir</strong>iami vienokie procesai, o evoliuciniame (angl. evolutionary) – kitokie. Tačiau bet kuriuoatveju programinė įrangos sukūrimui reikia atlikti iš esmės tas pačias veiklas, todėl pageidautinas<strong>ir</strong> vieningas procesų rinkinys. Pavyzdžiui, R.S.Pressman [Pre05] visų gyvavimo ciklo modeliųapibrėžimuose išsk<strong>ir</strong>ia tokius procesus:- Bendravimas (angl. Communication) apima projekto inicijavimą <strong>ir</strong> reikalavimųsurinkimą;- Planavimas (angl. Planning) apima vertinimą, plano sudarymą <strong>ir</strong> stebėjimą;- Modeliavimas (angl. Modeling) apima reikalavimų analizę <strong>ir</strong> projektavimą;- Kūrimas (angl. Construction) apima kodavimą <strong>ir</strong> testavimą;- Pateikimas (angl. Deployment) apima įdiegimą, palaikymą <strong>ir</strong> atsiliepimų gavimą.Būtina pažymėti, kad toks procesų rinkinys turi 2 esminius trūkumus:1) nagrinėjami tik kūrėjų vykdomi procesai, tarsi pam<strong>ir</strong>štant, kad daugeliu atvejutinkamos programų sistemos sukūrimas beveik neįmanomas be įsigyjančiosorganizacijos tinkamo dalyvavimo;2) nagrinėjimas baigiamas programų sistemos sukūrimu <strong>ir</strong> įdiegimu, o juk tuo metuprogramų sistema, jei ji naudojama, tik pradeda savo „gyvenimą“ <strong>ir</strong> reikalaujanuolatinės priežiūros – tiek rastų klaidų taisymo, tiek tobulinimo, pritaikymopasikeitusioms veiklos ar techninėms sąlygoms.Galima papildyti, kad programų sistemų inžinerijos pagrindinis objektas yra kūrėjųatliekami procesai <strong>ir</strong> dauguma ne tik vadovėlių, bet <strong>ir</strong> mokslinių tyrimų nagrinėja tik juos, tačiauignoravimas, nežinojimas užsakovams (naudotojams) būtinų procesų tikrai nepadės sėkmingaiįvykdyti projektą, o dažnu atveju gali <strong>ir</strong> stipriai pakenkti kokybiškos (atitinkančios poreikius)sistemos sukūrimui. Tiesa, didžioji dalis Lietuvos įmonių <strong>ir</strong> organizacijų dar nesupranta įsigijimoproceso svarbos <strong>ir</strong> mano, kad įsigyti programų sistemą yra beveik taip pat paprasta kaipnusip<strong>ir</strong>kti sąvaržėlių dėžutę.Mokymo medžiaga 13
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesaiO programų sistemų priežiūros (angl. maintenance) svarbą galima pagrįsti <strong>ir</strong> tuo, kad pagalatliktus tyrimus priežiūros kaštai sudaro 50-70 % viso programų sistemos gyvavimo ciklo kaštų.Žinoma, tai teisinga tik kokybiškoms programoms, kurios yra naudojamos ne vienerius metus.Vieningos procesų sampratos <strong>ir</strong> terminologijos nebuvimas trukdo IT pramonės vystymuisi,todėl natūralu, kad tarptautinė standartų organizacijos (ISO) iniciatyva buvo sukurtas specialusstandartas.ISO/IEC 12207 - Programinės įrangos gyvavimo ciklo procesų standartasPagrindinis šio standarto tikslas yra apibrėžti programinės įrangos gyvavimo cikloprocesus, suteikti bendrą sampratą <strong>ir</strong> terminologiją, kas palengvintų, iš vienos pusės,programinių produktų ar paslaugų įsigijimą, o iš kitos pusės, jų sukūrimą, pateikimą <strong>ir</strong> priežiūrą.Šiuo metu galiojanti standarto versija yra sudaryta iš 3 dokumentų:1. Pagrindinio standarto [ISO95], kuris buvo priimtas 1995 metais <strong>ir</strong> apibrėžė procesųkategorijas, pačius procesus, jų veiklas <strong>ir</strong> užduotis bei pateikė procesų pritaikymo ga<strong>ir</strong>essk<strong>ir</strong>tingoms organizacijoms.2. 1-o papildymo[ISO02], kuris buvo priimtas 2002 metais <strong>ir</strong> papildė procesų rinkinį beiapibrėžė visus procesus, nurodydamas jų tikslus <strong>ir</strong> rezultatus.3. 2-o papildymo[ISO04], kuris buvo priimtas 2004 metais <strong>ir</strong> tik patikslino kai kuriųprocesų apibrėžimą.Kaip <strong>ir</strong> daugelis standartų, ISO/IEC 12207 sudarytas iš normatyvinių (privalomųtaikantiems standartą) <strong>ir</strong> informacinių (pateikiančių papildomą informaciją <strong>ir</strong> palengvinančiųstandarto taikymą) dalių.Šiuo metu galiojančią standarto versiją sudaro 3 normatyvinės dalys:- Pagrindinis standarto tekstas [ISO95], apibrėžiantis naudojamus terminus, procesųkategorijas <strong>ir</strong> pačius procesus, nurodydamas jų veiklas <strong>ir</strong> užduotis.- Priedas A [ISO95], apibrėžiantis standarto pritaikymo (angl. tailoring) procesą, t.y.standarto pritaikymo konkrečiam projektui pagrindinius žingsnius: projekto aplinkosidentifikavimas; informacijos surinkimas; procesų, veiklų <strong>ir</strong> užduočių pas<strong>ir</strong>inkimas;priimtų sprendimų <strong>ir</strong> jų pagrindimo dokumentavimas (standarte žingsniai aprašyti labailakoniškai – šio priedo apimtis tik1 puslapis).- Priedas F [ISO02, ISO04], apibrėžiantis programinės įrangos gyvavimo ciklo procesus,nurodydamas jų tikslus <strong>ir</strong> rezultatus.<strong>ir</strong> 6 informacinės dalys:- Priedas B [ISO95], pateikiantis ga<strong>ir</strong>es standarto pritaikymui (angl. tailoring).- Priedas C [ISO95], pateikiantis organizacijų <strong>ir</strong> gyvavimo ciklo procesų sąryšį, kokiomsorganizacijoms kurie procesai yra svarbesni.Mokymo medžiaga 14
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesai- Programinės įrangos projektavimas (angl. software design);- Programinės įrangos konstravimas (angl. software construction);- Programinės įrangos integravimas (angl. software integration);- Programinės įrangos testavimas (angl. software testing);- Sistemos integravimas (angl. system integration);- Sistemos testavimas (angl. system testing);- Programinės įrangos instaliavimas (angl. software installation).Galima pastebėti, kad šiame apibrėžime detalesni kūrimo procesai iš esmės atitinkap<strong>ir</strong>mojo tipo apibrėžimo veiklas. Galima atkreipti dėmesį, kad į atsk<strong>ir</strong>ą procesą buvo išsk<strong>ir</strong>tasreikalavimų surinkimas, siekiant pabrėžti jo svarbą; aukšto <strong>ir</strong> detalaus lygio projektavimasapjungtas į vieną procesą, nes abiem atvejais siekiama to paties tikslo; nėra procesoįgyvendinimo veiklos, nes ji neatitinka šio tipo apibrėžimo tikslų – sudaryti sąlygas procesogebėjimo vertinimui; patikslinti pavadinimai, jie labiau atitinka šiuo metu naudojamus.Kiekvienam iš detalesnių procesų <strong>ir</strong>gi yra apibrėžti tikslai <strong>ir</strong> rezultatai. Pavyzdžiui,sistemos reikalavimų analizės tikslas yra transformuoti suinteresuotų asmenų (angl.stakeholders) apibrėžtus reikalavimus (poreikius) į techninius reikalavimus, kuriais remiantis busprojektuojama sistema.Sėkmingai įgyvendinta sistemos reikalavimų analizė turi pasiekti tokius rezultatus:- apibrėžti funkciniai <strong>ir</strong> nefunkciniai reikalavimai sprendžiamam uždaviniui reikalingaisistemai;- panaudoti tinkami metodai pageidaujamo projektinio sprendimo optimizavimui;- išanalizuotas sistemos reikalavimų korektiškumas <strong>ir</strong> testuojamumas;- suprasta sistemos reikalavimų įtaka naudojimo aplinkai;- reikalavimams suteikti prioritetai, jie patv<strong>ir</strong>tinti <strong>ir</strong> atnaujinti, kai pr<strong>ir</strong>eikia;- patikrintas sistemos reikalavimų <strong>ir</strong> užsakovo reikalavimų (poreikių) bazinio komplekto(angl. baseline) suderinamumas <strong>ir</strong> atsekamumas (angl. traceability);- bazinio komplekto (angl. baseline) pakeitimų įtaka kainai, tvarkaraščiui <strong>ir</strong> techniniamįgyvendinimui yra įvertinta;- sistemos reikalavimai yra pateikti visiems suinteresuotiems asmenims <strong>ir</strong> įtraukti įbazinį komplektą.Įsigijimo proceso apibrėžimasKadangi programų sistemų inžinerijos literatūroje yra nepakankamai dėmesio sk<strong>ir</strong>iamaįsigijimo procesui <strong>ir</strong> praktikoje (bent jau Lietuvoje) dar nėra susiformavęs šio proceso poreikiosupratimas, panagrinėkime detaliau, kaip įsigijimo procesas yra apibrėžtas standarteISO/IEC 12207. Nagrinėsime procesų apibrėžimus tikslais <strong>ir</strong> rezultatais.Mokymo medžiaga 19
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesaiKaip buvo minėta, programinės įrangos įsigijimas apibrėžiamas standarto priede F <strong>ir</strong>detalizuojamas priede H.Priede F apibrėžiami tokie programinės įrangos įsigijimo procesai:- Pas<strong>ir</strong>uošimas įsigijimui;- Tiekėjo išrinkimas;- Tiekėjo stebėjimas;- Programinės įrangos priėmimas.Programinę įrangą įsigyjanti organizacija taip pat turi iš esmės dalyvauti sutartiessudaryme, nors šis procesas <strong>ir</strong> prisk<strong>ir</strong>tas tiekėjo kategorijai.Panagrinėkime šiuos procesus detaliau.F1. Pas<strong>ir</strong>uošimas įsigijimuiTikslas. Nustatyti įsigijimo poreikius <strong>ir</strong> tikslus bei perduoti juos potencialiems tiekėjams.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- nustatyta koncepcija arba poreikis įsigijimui, sukūrimui arba patobulinimui;- apibrėžti <strong>ir</strong> patikrinti įsigijimo reikalavimai, atitinkantys projekto poreikius;- apibrėžti <strong>ir</strong> patikrinti p<strong>ir</strong>kėjo žinomi reikalavimai;- sukurta įsigijimo strategija;- apibrėžti tiekėjo parinkimo kriterijai.F2. Tiekėjo išrinkimasTikslas. Išrinkti organizaciją, atsakingą už programinės įrangos tiekimą pagal projektoreikalavimus.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- tiekėjo išrinkimo kriterijai nustatyti <strong>ir</strong> naudojami potencialių tiekėjų įvertinimui;- remiantis tiekėjų pateiktais pasiūlymais, procesų gebėjimu bei kitais faktoriais išrinktastiekėjas;- sudaryta <strong>ir</strong> suderinta sutartis tarp p<strong>ir</strong>kėjo <strong>ir</strong> tiekėjo.F3. Tiekėjo stebėjimasTikslas. Stebėti <strong>ir</strong> vertinti tiekėjo darbą pagal sutartus reikalavimus.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- esant reikalui atliekamos jungtinės p<strong>ir</strong>kėjo <strong>ir</strong> tiekėjo veiklos;- su tiekėju reguliariai apsikeičiama informacija apie techninį progresą;- tiekėjo darbas stebimas remiantis sutartais reikalavimais;- jei reikia, pakeitimai sutartyje derinami tarp p<strong>ir</strong>kėjo <strong>ir</strong> tiekėjo bei dokumentuojamisutartyje.Mokymo medžiaga 20
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesaiF4. Programinės įrangos priėmimasTikslas. Aprobuoti tiekėjo pateiktus darbo produktus, kai patenkinami priėmimo kriterijai.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- pristatytas programinės įrangos produktas <strong>ir</strong>/arba paslauga įvertinti pagal sutartyjepateiktus reikalavimus;- produkto priėmimas yra paremtas sutartais priėmimo kriterijais;- priimtas programinės įrangos produktas <strong>ir</strong>/arba paslauga;F5. Sutarties sudarymasTikslas. Suderinti <strong>ir</strong> patv<strong>ir</strong>tinti sutartį, kuri aiškiai <strong>ir</strong> vienareikšmiškai nustatytųprograminės įrangos tiekėjo <strong>ir</strong> užsakovo lūkesčius, įsipareigojimus, darbo produktus beiatsakomybes.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- suderinta, peržiūrėta, patv<strong>ir</strong>tinta <strong>ir</strong> pas<strong>ir</strong>ašyta sutartis su tiekėju;- peržiūrėti <strong>ir</strong> apsvarstyti įtraukimui į sutarties sąlygas tiekėjo(ų) gebėjimo <strong>ir</strong> darbokontrolės bei rizikos švelninimo mechanizmai;- konkurso dalyviai informuoti apie išrinktą tiekėją;- pasiektas formalus sutarties patv<strong>ir</strong>tinimas.Siekiant sudaryti sąlygas tikslesniam proceso gebėjimo vertinimui <strong>ir</strong> gerinimui standartopriede H apibrėžiama 17 detalesnių programinės įrangos įsigijimo procesų.H1. Įsigijimo poreikiaiTikslas. Nustatyti bendruosius aukšto lygio tikslus, įsigijimo poreikių pagrindą <strong>ir</strong> metodus,kurie bus įdiegti įsigijimui valdyti.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- nustatytas poreikis organizacijai įdiegti bendrą įsigijimo politiką;- nustatytas sisteminis pagrindas arba pageidavimai technologijoms, procesams,metodams, pardavėjams, standartams bei teisiškai įvykdomiems reikalavimams, kadbūtų optimizuotas įsigijimas;- nustatytas poreikis užtikrinti pakankamus įsigijimo valdymo resursus, tokius kaipsutartiniai, techniniai, finansiniai bei projekto valdymo įgūdžiai;- nustatytas poreikis apibrėžti kokybės standartus tiekėjo pateikiamiems darboproduktams, kurie priimami pagal užfiksuotus <strong>ir</strong> numanomus p<strong>ir</strong>kėjo poreikius;- nustatytas poreikis nustatyti efektyvius <strong>ir</strong> produktyvius ryšius su tiekėju <strong>ir</strong> kitomissusijusiomis grupėmis.Mokymo medžiaga 21
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesai- reikiamą kvalifikaciją turintys tiekėjai atrinkti pasiūlymų vertinimui;- nustatyti <strong>ir</strong> įvertinti bet kokie trūkumai;- įvertinti <strong>ir</strong> atlikti reikalaujami koreguojamieji veiksmai.H10. Pasiūlymų vertinimasTikslas. Įvertinti pateiktus pasiūlymus <strong>ir</strong>/arba asocijuotus parduodamus OTS (angl. Off TheShelf) produktus, kad būtų galima pradėti sutarties derinimą.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- pateikti pasiūlymai įvertinti pagal kvietime teikti pasiūlymus pateiktus reikalavimus;- nustatyti OTS produktų vertinimo kriterijai, jei tokie produktai yra pateikiami kaippasiūlymas arba pasiūlymo dalis;- OTS produktai įvertinti pagal apibrėžtą planą, įvertinant jų atitikimo gavėjo poreikiams<strong>ir</strong> lūkesčiams laipsnį;- atrinkto pasiūlymo(ų) tiekėjas(ai) pakviesti pradėti sutarties derybas.H11. Sutarties parengimasTikslas. Suderinti <strong>ir</strong> patv<strong>ir</strong>tinti sutartį, kuris aiškiai <strong>ir</strong> vienareikšmiškai specifikuotų tiektiekėjo(ų), tiek gavėjo lūkesčius, įsipareigojimus, darbo produktus bei atsakomybes.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- sutartis bus suderinta, peržiūrėta, patv<strong>ir</strong>tinta <strong>ir</strong> pas<strong>ir</strong>ašyta;- peržiūrėti <strong>ir</strong> apsvarstyti įtraukimui į sutarties sąlygas tiekėjo(ų) gebėjimo <strong>ir</strong> darbokontrolės bei rizikos švelninimo mechanizmai;- pasiūlymų teikėjai informuoti apie pas<strong>ir</strong>inktą pasiūlymą.H12. Tiekėjo stebėjimasTikslas. Kontroliuoti <strong>ir</strong> įgalinti tiekėjo veiklų integraciją į įsigijimo proceso vykdymą,laikantis susijusių reikalavimų <strong>ir</strong> valdymo būdų.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- reikiamu metu vykdomos jungtinės tiekėjo <strong>ir</strong> gavėjo veiklos;- su tiekėju reguliariai apsikeičiama informacija <strong>ir</strong> duomenimis apie įsigijimo projektopažangą;- tiekėjo darbas kontroliuojamas pagal sutartus reikalavimus;- iškilusios problemos užfiksuotos <strong>ir</strong> sekamos iki išsprendimo.H13. PriėmimasTikslas. Pagal priėmimo kriterijus priimti <strong>ir</strong> patv<strong>ir</strong>tinti išleistą produktą. Procesas apimssuplanuotus <strong>ir</strong> integruotus būdus sumažinti gavėjo <strong>ir</strong> tiekėjo veiklų dubliavimąsi.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:Mokymo medžiaga 25
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesai- pagal suplanuotą <strong>ir</strong> dokumentuotą įsigijimo strategiją atliekamas patikrinimas <strong>ir</strong>patv<strong>ir</strong>tinimas;- priėmimas atliekamas remiantis įsigijimo strategija <strong>ir</strong> pagal sutartus reikalavimus;- pristatytas produktas įvertintas pagal sutartus reikalavimus;- reikiamose vietose patv<strong>ir</strong>tintos garantijos detalės.H14. Sutarties užbaigimasTikslas. Užtikrinti išsamios informacijos, susijusios su projekto vykdymu <strong>ir</strong> užbaigimu,surinkimą bei suderinimą tarp dalyvaujančių šalių.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- sutarta dėl apmokėjimų užbaigimo <strong>ir</strong> tolimesnių apmokėjimų planų;- patv<strong>ir</strong>tintas tiek tiekėjo, tiek gavėjo pateiktos konfidencialios informacijosišsaugojimas <strong>ir</strong> grąžinimas;- apsikeista (tarp dalyvaujančių šalių) įsigijimo rezultatų informacija;- pagal iškeltus reikalavimus <strong>ir</strong> tikslus įvertinti projekto sutartinių, projektinių, techninių<strong>ir</strong> finansinių aspektų rezultatai;- įvertintas visų dalyvaujančių šalių darbas;- svarbi su projektu susijusi informacija padėta į archyvą <strong>ir</strong> prieinama ateityje, atliekantgerinimus <strong>ir</strong> kitus įsigijimo projektus;H15. Tiekėjo santykiaiTikslas. Pagerinti gavėjo-tiekėjo santykius teikiamų paslaugų kokybės bei kainos-kokybėsatžvilgiu, kad būtų pasiektas geresnis abiejų šalių poreikių supratimas.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- nustatyti dabartiniams <strong>ir</strong> būsimiems poreikiams svarbūs ryšiai su tiekėjais;- apibrėžta ryšių nuosavybė <strong>ir</strong> koordinavimas;- aiškiai suprasti ryšiai, labiausiai įtakojantys verslo tikslų pasiekimą;- nustatyta potenciali pagerintų ryšių nauda bei atitinkamos pakeitimų neįgyvendinimorizikos;- peržiūrimas <strong>ir</strong> kontroliuojamas tiekėjo ryšių efektyvumas.H16. Naudotojo santykiaiTikslas. Pagerinti gavėjo-naudotojo ryšius teikiamų paslaugų kokybės terminais tam, kadbūtų pasiektas geresnis abiejų šalių poreikių supratimas.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- apibrėžta ryšių nuosavybė <strong>ir</strong> koordinavimas;- aiškiai suprasti ryšiai, labiausiai įtakojantys verslo tikslų pasiekimą;Mokymo medžiaga 26
Programų sistemų inžinerija2. Programinės įrangos gyvavimo ciklo procesai- nustatyta potenciali pagerintų ryšių nauda bei atitinkamos pakeitimų neįgyvendinimorizikos;- peržiūrimas <strong>ir</strong> kontroliuojamas tiekėjo ryšių efektyvumas.H17. Finansų valdymasTikslas. Užtikrinti, kad įsigijimo išlaidos <strong>ir</strong> biudžetas yra nustatyti <strong>ir</strong> valdomi pagalsuderintus planus <strong>ir</strong> tikslus.Rezultatai. Sėkmingai įgyvendintas procesas turi pasiekti tokius rezultatus:- nustatyti <strong>ir</strong> palaikomi finansiniai planai <strong>ir</strong> tikslai;- paruoštas <strong>ir</strong> patv<strong>ir</strong>tintas biudžetas;- palaikomi įrašai tam, kad būtų patenkinti finansinio audito reikalavimai;- už projekto valdymą atsakingiems asmenims pranešta apie esamas projekto išlaidas;- analizuojami bei raportuojami nuokrypiai tarp suplanuotų <strong>ir</strong> esamų išlaidų;- imtasi sprendimų, kad būtų užtikrintas finansinių tikslų pasiekimas.Literatūra papildomam skaitymui[ISO95] ISO/IEC 12207 Information technology – Software life cycle processes, 1995.[ISO02] ISO/IEC 12207 Information technology – Software life cycle processes,AMENDMENT 1, 2002.[ISO04] ISO/IEC 12207 Information technology – Software life cycle processes,AMENDMENT 2, 2004.[Pre05] R.S. Pressman, Software Engineering: A Practitioner's Approach. 6th edition,McGraw-Hill, 2005, ISBN: 0072853182.Mokymo medžiaga 27
Programų sistemų inžinerija3. Programų kūrimo procesas3. Programų kūrimo procesasDaugiau kaip prieš dešimtį metų pasauliniu mastu imta vis labiau akcentuoti „programinėsįrangos krizę” <strong>ir</strong> ieškoti adekvačių priemonių jos įveikimui. Tyrimais nustatyta, kad vos keliprocentai sukurtos programinės įrangos yra naudojama. Be to, daugelio programinės įrangosprojektų faktiniai kaštai <strong>ir</strong> terminai net kelis kartus v<strong>ir</strong>šija planinius. Programinės įrangos kūrimoproblemų (kainos, laiko, kokybės) sprendimo bandymai technologinėmis priemonėmis priminėkovą su vaiduokliu [Bro87], ieškant stebuklingos sidabrinės kulkos tam vaiduokliui nušauti, <strong>ir</strong>nedavė laukiamų rezultatų, todėl vis didesnis dėmesys sk<strong>ir</strong>iamas organizacinių <strong>ir</strong> metodiniųaspektų nagrinėjimui. Buvo suprasta, kad programinės įrangos kokybė tiesiogiai priklauso nuojos kūrimo proceso kokybės.Programinei įrangai bei sistemoms, veikiančioms programinės įrangos pagrindu, visą laikąkeliami vis nauji reikalavimai <strong>ir</strong> programinės įrangos kūrėjai kiekvieną kartą atsiduria priešnaują, jiems nežinomą uždavinį: su duotais resursais per duotą laiką sukurti programinį produktąsu duotomis savybėmis.Bent kiek didesnio programinio produkto kūrimas yra kolektyvinis darbas. Jeikolektyviniame darbe nėra apibrėžtų “žaidimo” taisyklių, tuomet kiekvienas narys vadovaujasisavo įsivaizduojamomis taisyklėmis <strong>ir</strong> vertybėmis, ko pasekoje kiekvieno darbo sėkmingasužbaigimas <strong>ir</strong> atsiskaitymas su užsakovu - tai heroizmo demonstravimas taikos metu. Nenaujiena, kad naudojant standartinius inžinerinius <strong>ir</strong> mokslinius principus galima pasiekti sėkmėsprofesijoje, tame tarpe <strong>ir</strong> programinių produktų kūrime. Atsk<strong>ir</strong>i profesionalai asmeninėsintuicijos dėka sugebėjo pasiekti aukštų rezultatų profesinėje <strong>ir</strong> organizacinėje veikloje. Tikslasyra tokių bendrųjų principų įdiegimą pervesti iš intuicijos lygmens į metodo, procedūroslygmenį.Programų kūrimo proceso brandos modeliavimas pripažįstamas kaip viena iš labiausiaibesivystančių <strong>ir</strong> daugiausia pasiekusių per pastarąjį dešimtmetį programų sistemų inžinerijossričių. Pagrindinis uždavinys, kurį turėjo išspręsti programų kūrimo proceso tyrimai, buvoatsakyti į klausimą, kodėl žlunga programų kūrimo projektai: net <strong>ir</strong> išvystytų planavimo <strong>ir</strong>įgyvendinimo įrankių naudojimas nesumažino projektų, v<strong>ir</strong>šijusių suplanuotą biudžetą, terminus,ar visai nutrauktų, skaičiaus. Programų kūrimo proceso tyrimo <strong>ir</strong> modeliavimo darbais siekiamanustatyti proceso charakteristikas, sk<strong>ir</strong>iančias gerą <strong>ir</strong> blogą procesą, „gerumu“ įvardinant procesogebėjimą pateikti rezultatą suplanuotais terminais <strong>ir</strong> nev<strong>ir</strong>šijant suplanuoto biudžeto.Nors programų kūrimo proceso modeliavimo, vertinimo <strong>ir</strong> gerinimo srityje pasiekta tikrainemažai, bet problema <strong>ir</strong> toliau išlieka labai aktuali.Mokymo medžiaga 28
Programų sistemų inžinerija3. Programų kūrimo procesas200028%23%49%1998199626%27%28%40%46%33%SėkmingiŽlugęPažeisti199416%31%53%3.1 pav. Projektų rezultatų tyrimas [StG01]Kaip rodo Standish Group atlikto tyrimo CHAOS [StG01] rezultatai, nors sėkmingųprojektų – atliktų laiku <strong>ir</strong> su planuotu biudžetu bei įgyvendinusių visas numatytas savybes <strong>ir</strong>funkcionalumą – dalis <strong>ir</strong> išaugo, tačiau pažeistų projektų dalis išlieka beveik nepakitusi.Pažeistiems projektams prisk<strong>ir</strong>iami baigti projektai, kuriuose sukurtos programų sistemos yranaudojamos, bet v<strong>ir</strong>šiję planinį biudžetą, tvarkaraštį <strong>ir</strong>/ar įgyvendinę mažiau savybių <strong>ir</strong>funkcionalumo nei buvo numatyta pradžioje. 3.1 pav. pateikia daugiau kaip 30,000 StandishGroup t<strong>ir</strong>tų projektų rezultatus.Programų kūrimo proceso sąvoka buvo pasiūlyta Carnegie Melon universiteto profesoriausW. Humphrey darbuose, atliktuose JAV gynybos departamento finansuojamame Programųinžinerijos institute (angl. Software Engineering Institute – SEI). Europoje p<strong>ir</strong>mieji analogiškidarbai inicijuoti Europos Bendrijos Komisijos ESPRIT programos rėmuose, žinomiBOOTSTRAP metodo vardu, <strong>ir</strong> yra tęsiami Europos programų inžinerijos institute (angl.European Software Institute – ESI).Per dešimtmetį buvo sukurta nemažai modelių, kurie specifikuoja gero programų kūrimoproceso charakteristikas. Keletas iš jų tapo de facto standartais, o kai kurie įteisinti <strong>ir</strong> kaiptarptautiniai arba atsk<strong>ir</strong>ų valstybių standartai.Vienas iš plačiausiai pripažįstamų <strong>ir</strong> vertinamų vardų, tame tarpe <strong>ir</strong> informaciniųtechnologijų srityje, yra tarptautinis bendrinis kokybės standartas ISO 9000, kuris dažnai tampaprivalomu reikalavimu įmonei, norinčiai atlikti tam tikrą projektą. ISO 9000 standartas nusakotik minimalius bendruosius reikalavimus, kurie turi būti užtikrinti įmonės veikloje, kad įmonębūtų galima laikyti dedančia „pakankamas“ pastangas užtikrinti produkto kokybę. Tačiaubendrinis kokybės standartas negali atsižvelgti į taikymo srities specifiką. Programinės įrangoskūrimo industrijoje įsitv<strong>ir</strong>tino specializuoti standartai.Jungtinėse Amerikos Valstijose neabejotinai didžiausią autoritetą šioje srityje turiProgramų sistemų inžinerijos institutas (SEI), p<strong>ir</strong>masis 1993 metais parengęs išbaigtą programųkūrimo proceso brandos modelį SW-CMM (angl. Capability Maturity Model for Software). PoMokymo medžiaga 29
Programų sistemų inžinerija3. Programų kūrimo procesasdviejų metų SEI parengė sistemų kūrimo brandos modelį SE-CMM (angl. Systems EngineeringCapability Maturity Model), o 1999 metais pradėjo integruoto brandos modelio CMMI (angl.Capability Maturity Model Integration) rengimą, šiuo metu išleistą keturiomis versijomis,sk<strong>ir</strong>tomis atitinkamai tik programų kūrimui CMMI-SW (angl. CMMI for Software Engineering),sistemų kūrimui CMMI-SE/SW (angl. CMMI for Systems Engineering/ Software Engineering),integruoto produkto <strong>ir</strong> proceso kūrimui CMMI-SE/SW/IPPD (angl. CMMI for SystemsEngineering/ Software Engineering/ Integrated Product and Process Development) bei sistemųįsigijimui CMMI-SE/SW/IPPD/SS (angl. CMMI for Systems Engineering/ SoftwareEngineering/ Integrated Product and Process Development/ Supplier Sourcing). CMMI modelislaikomas pačiu išsamiausiu programų kūrimo brandos modeliu, tinkamu panaudoti programiniųproduktų <strong>ir</strong> paslaugų kūrimo <strong>ir</strong> priežiūros gerinimui. Šis modelis apima visas SW-CMM modeliogeriausias praktikas <strong>ir</strong> daugelį kitų proceso gerinimo modelių žinių, tačiau jis dar nėra taipplačiai paplitęs kaip jo p<strong>ir</strong>mtakas: SEI pateikiamais duomenimis iki 2003 metų atlikta daugiaukaip 2600 vertinimų pagal CMM <strong>ir</strong> tik kiek daugiau nei 70 vertinimų pagal CMMI.1995 metais lygiagrečiai sukurtas <strong>ir</strong> publikuotas kitas brandos modelis SPICE (angl.Software Process Improvement and Capability dEtermination), aprašantis programų kūrimoproceso vertinimo reikalavimus, nusakydamas proceso sudedamąsias dalis bei kriterijus jomsįvertinti. Modelio SPICE <strong>ir</strong> jo vėlesnės versijos, tapusios standartu ISO/IEC 15504, pask<strong>ir</strong>tis –apibrėžti vertinimo kriterijus <strong>ir</strong> principus, kurių pagrindu būtų galima kurti kitus programųkūrimo proceso brandos įvertinimo <strong>ir</strong> gerinimo modelius. Kuriant paskutines CMMI versijas,buvo siekiama suderinamumo su ISO/IEC 15504 standartu <strong>ir</strong> jo bus siekiama vėlesnėseversijose.Be jau minėto Europos programų inžinerijos instituto tarp didžiausių programų kūrimoproceso brandos tyrimų centrų yra 1993 metais Europos Komisijos įsteigtas Europos programųkūrimo proceso gerinimo fondas (angl. ESPI Foundation). Abi šios institucijos užsiimaprogramų kūrimo proceso standartų propagavimu, konsultavimu bei įmonių vertinimu, o taip patkartu su SEI organizuoja kasmetines mokslines-technines konferencijas programų kūrimoproceso brandos gerinimo klausimais (angl. SEPG Conference).Tiek CMMI, tiek ISO/IEC 15504 autoriai supranta, kad modeliai negalės išlikti aktualūstokie, kokie yra sukurti, todėl yra numatyti modelių tobulinimo tvarkaraščiai, pagal kuriuosmodelis turi būti peržiūrimas <strong>ir</strong> papildomas kas ketverius metus.Programų kūrimo proceso brandos modelių ats<strong>ir</strong>adimas davė impulsą specializuotųbrandos modelių tyrimams – smarkai suaktyvėjo <strong>ir</strong> pradėjo duoti rezultatus tyrimai tokiosesrityse kaip: reikalavimų specifikavimo branda, programų sistemų testavimo branda, programųsistemų priežiūros branda, informacinių sistemų paslaugų valdymo branda.Mokymo medžiaga 30
Programų sistemų inžinerija3. Programų kūrimo procesasProgramų kūrimo įmonės palankiai sutiko sukurtus brandos modelius <strong>ir</strong> ėmėsi juos taikyti.SEI pateikiamais duomenimis atliktų vertinimų vien pagal CMM <strong>ir</strong> ISO/IEC 15504 (SPICE)modelius skaičius siekia beveik 5000. Nuo p<strong>ir</strong>mųjų modelių <strong>ir</strong> vertinimo metodikų ats<strong>ir</strong>adimodaugelis įmonių ėmėsi „kopti“ brandos įvertinimo laipteliais. 2003 metų pradžios duomenimisaukščiausių brandos lygių pagal CMM organizacijų sąraše yra 72 ketv<strong>ir</strong>to <strong>ir</strong> 74 penkto lygioorganizacijos. Tokio brandos lygio sertifikatas yra liudijimas, kad organizacija kokybiškai <strong>ir</strong>patikimai atlieka savo darbą.Organizacijos vertinimas atliekamas, turint du pagrindinius tikslus: programų kūrimoproceso gerinimą <strong>ir</strong> projekto vykdytojo (sistemos tiekėjo) pas<strong>ir</strong>inkimą. Pavyzdžiui, JAV gynybosdepartamentas jau prieš keletą metų yra priėmęs sprendimą patikėti projektus tik organizacijoms,turinčioms ne žemesnį nei antrą brandos lygį pagal CMM.Mokslininkų pastangos, t<strong>ir</strong>iant programų kūrimo proceso brandą, leido suprasti <strong>ir</strong> aiškiainusakyti programų kūrimo metu atliekamas veiklas, apibrėžti programų kūrimo procesovaldymą, programinio produkto kokybę išreikšti per kūrimo proceso kokybę bei sukurti darniusprogramų kūrimo proceso modelius, padedančius įvertinti <strong>ir</strong> išmatuoti tiek programų kūrimoprocesą, tiek pačią organizaciją apskritai.Programų kūrimo proceso vertinimas <strong>ir</strong> gerinimas yra sudėtinga <strong>ir</strong> didelių darbo sąnaudųreikalaujanti veikla. Remiantis pasauline pat<strong>ir</strong>timi, galima teigti, kad pradinis proceso gerinimoprojektas organizacijoje trunka ne mažiau kaip metus <strong>ir</strong> jo sėkmė be kitų veiksnių nemaža dalimipriklauso <strong>ir</strong> nuo tinkamo proceso vertinimo <strong>ir</strong> palaikymo instrumentinių priemonių pas<strong>ir</strong>inkimo.Įmonių vadovams kyla natūralus, ar proceso vertinimas yra ekonomiškai naudingasorganizacijai. Žinoma, yra daug kitų svarbių aspektų (sauga, saugumas, sistemos stabilumas <strong>ir</strong>kt.), kuriuos padeda užtikrinti brandus programų kūrimo procesas, tačiau netgi aps<strong>ir</strong>ibojus tikfinansiniu požiūriu galima drąsiai teigti, jog proceso branda yra vertinga. Tai galima pagrįstistatistiniais CMM taikymo duomenimis.Tai, kad aukštesnis brandos lygis sumažina kaštus, sutrumpina sistemos kūrimo laiką,pagerina kokybę <strong>ir</strong> prisiimamų įsipareigojimų įvykdymo tikimybę, akivaizdžiai parodo 3.1lentelėje pateikti 1.300 projektų statistiniai duomenys [Kea02]. Buvo analizuojami dideliprojektai, turintys apie 200.000 kodo eilučių. Kaštai buvo skaičiuojami pagal vieno žmogausmetinį įkainį 110.000 $. Nauda organizacijai pasiekus aukštesnį brandos pakankamai akivaizdi,pavyzdžiui, 2-o lygio organizacijos darbo sąnaudos yra maždaug 4 kartus mažesnės nei 1-o lygioorganizacijos. Be to, tokios organizacijos sukurtame produkte lieka maždaug 5 kartus mažiaudefektų, kas tiesiogiai įtakoja užsakovų <strong>ir</strong> vartotojų pasitenkinimą, todėl nėra abejonių kurią iššių organizacijų jie pas<strong>ir</strong>inks.Mokymo medžiaga 31
Programų sistemų inžinerija3. Programų kūrimo procesasOrganizacijosCMM lygisTrukmė(mėnesiais)Pastangos(žmogausmėnesiais)SistemosdefektųskaičiusVidutinėkaina($M)Minimalikaina($M)Maksimalikaina($M)Lygis 1 30 600 61 5,5 1,8 100+Lygis 2 18.5 143 12 1,3 0,96 1.7Lygis 3 15 80 7 0,728 0,518 0,9333.1 lentelė. Didelių projektų statistika [Kea02]Kitas svarbus aspektas yra laikas, reikalingas aukštesnio brandos lygio pasiekimui.Remiantis SEI sukaupta informacija [SEI04], galima teigti, kad organizacijoms, gerinančiomsprocesą pagal CMM, vidutinis laikas pasiekti aukštesnį brandos lygį yra toks:• 22 mėnesiai perėjimui iš 1-o brandos lygio į 2-ą;• 19 mėnesių perėjimui iš 2-o brandos lygio į 3-ą;• 25 mėnesiai perėjimui iš 3-o brandos lygio į 4-ą;• 13 mėnesių perėjimui iš 4-o brandos lygio į 5-ą.Taigi tik pradėjusiai rūpintis proceso gerinimu organizacijai (beveik akivaizdu, kad ji busžemiausio, 1-o brandos lygio) pasiekti aukščiausią brandos lygį pagal CMM tikėtinai pr<strong>ir</strong>eiksdaugiau nei 6 metų.Esminės sąvokosProgramų kūrimo procesas apima visas veiklas, vykdomas organizacijoje, kuriantprograminį produktą ar teikiant paslaugas, todėl jis dar vadinamas visuminiu procesu. Šisprocesas nėra vienalytis <strong>ir</strong> modeliavimui tikslinga jį suskaidyti į sudedamąsias dalis, atitinkamaigrupuojant veiklas. Vienas iš taikomų principų yra išsk<strong>ir</strong>ti grupes veiklų, susijusių pagal tikslusprograminio produkto gyvavimo cikle. Toks veiklų rinkinys vadinamas vardiniu procesu.Veiklų susk<strong>ir</strong>stymas į vardinius procesus nėra unikalus <strong>ir</strong> priklauso nuo modelio pask<strong>ir</strong>ties <strong>ir</strong>autorių požiūrio. Naudojamas <strong>ir</strong> kitas principas: grupuoti veiklas pagal jų prisidėjimą prieproceso gebėjimo didinimo, o ne pagal prisidėjimą prie tų pačių darbo rezultatų sukūrimo.Remiantis šiuo principu, gautos veiklų grupės vadinamos proceso sritimis.Gebėjimas yra proceso charakteristika, nusakanti rezultatų, kuriuos galima gauti taikant tąprocesą, pasisk<strong>ir</strong>stymą (diapazoną), t.y. galimybę (tikimybę), kad procesas įvykdys jam keliamustikslus. Tradiciškai gebėjimo sąvoka taikoma vardiniam procesui, nors ją galima taikyti <strong>ir</strong>visuminiam programų kūrimo procesui. Gebėjimas yra proceso charakteristika, išreiškiamagaunamais proceso darbo rezultatais. Aukštesnis proceso gebėjimas rodo, kad yra didesnėtikimybė, kad procesas gaus numatytus rezultatus, mažiau nukrypdamas nuo užsibrėžtų kainos,terminų, kokybės tikslų.Mokymo medžiaga 32
Programų sistemų inžinerija3. Programų kūrimo procesasGebėjimo lygis yra įvertis diskrečioje skalėje, nusakantis tam tikrą proceso gebėjimopasiekimą. Tačiau praktiškai yra neįmanoma išmatuoti galimybės gauti siekiamus rezultatus,todėl remiamasi praktikoje patv<strong>ir</strong>tinta prielaida, kad kokybiškų rezultatų gavimo tikimybėtiesiogiai priklauso nuo paties proceso charakteristikų, todėl proceso gebėjimo lygisapibrėžiamas konstruktyviai, nurodant proceso indikatorius - veiklas, kurias atliekant sukuriamaproceso aplinka, užtikrinanti proceso rezultatų stabilumą.Visuminio proceso gebėjimui apibūdinimui tradiciškai naudojamos brandos <strong>ir</strong> brandoslygio sąvokos, kurios apibrėžiamos konstruktyviai. Branda yra proceso charakteristika,nusakanti, kiek procesas yra apibrėžtas, valdomas, matuojamas, kontroliuojamas <strong>ir</strong> nuolatosgerinamas, o brandos lygis yra aiškiai apibrėžta pakopa proceso brandos evoliucijoje, nusakomarinkiniu veiklų, kurių tikslai turi būti įgyvendinami, kad būtų pasiektas tam tikras to procesogebėjimas. Branda gali būti suprantama kaip konkrečios organizacijos palyginimas suįsivaizduojama „idealia“ organizacija, o brandos lygis – kaip artumas iki „idealios“organizacijos. Organizacija, pasiekusi aukštesnį proceso brandos lygį, tarsi pakyla į tam tikrąstabilią būseną arba kokybinį lygmenį, kuriame ji kokybinėmis charakteristikomis iš esmėssk<strong>ir</strong>iasi nuo žemesnio lygio organizacijų. Akivaizdu, kad aukštesnis brandos lygis implikuojaaukštesnį proceso gebėjimą. Matavimui brandos lygiai išreiškiami rinkiniais veiklų – procesosritimis – kurias organizacija turi vykdyti, kad pasiektų tą brandos lygį.Visus programų kūrimo proceso brandos modelius pagal architektūrą galima susk<strong>ir</strong>styti įpakopinius <strong>ir</strong> tolydinius.Programų kūrimo proceso modelis, leidžiantis vertinti visuminio organizacijos procesobrandą, vadinamas pakopinės architektūros brandos modeliu, kadangi nustato stambius(paprastai penkis) brandos lygmenis – pakopas. Organizacija (jos programų kūrimo procesas) yraįvertinama tam tikru brandos lygiu.Programų kūrimo proceso modelis, leidžiantis įvertinti kiekvieno vardinio procesogebėjimą, vadinamas tolydinės architektūros brandos modeliu, kadangi leidžia įvertinti procesogebėjimą detalesniame – vardinio proceso – lygmenyje. Šiuo atveju organizacijos įvertinimas yravardinių procesų gebėjimų lygių profilis, akivaizdžiai parodantis „atsiliekančius“ – žemesniogebėjimo lygio – procesus. Atrodytų, kad galima būtų siekti maksimaliai pakelti tik kažkuriovieno pas<strong>ir</strong>inkto vardinio proceso gebėjimus, tačiau iš tikrųjų vardiniai procesai yra tarpusavyjesusiję: norint iš esmės pakelti vieno vardinio proceso gebėjimą reikia didinti <strong>ir</strong> susijusių procesųgebėjimus.Kurios architektūros modelis tinkamesnis, apibrėžtų taisyklių nėra. Įva<strong>ir</strong>ių brandosmodelių taikymo pat<strong>ir</strong>tis rodo, kad pas<strong>ir</strong>enkant architektūrą, naudotini modelių detalumo <strong>ir</strong>taikymo tikslų argumentai. Tolydinės architektūros modelis leidžia detaliau vertinti organizacijosMokymo medžiaga 33
Programų sistemų inžinerija3. Programų kūrimo procesasprocesus, todėl yra lankstesnis proceso tobulinimo kelių pas<strong>ir</strong>inkimo <strong>ir</strong> investicijų į tobulinimąatžvilgiu, tačiau pagal jo duodamus vertinimo rezultatus sudėtinga palyginti organizacijastarpusavyje. Pakopinis modelis leidžia gauti vertinimo rezultatą kaip vieną skaičių, kuris lengvaipalyginamas su kitos organizacijos vertinimu, todėl tinka konkurenciniam vertinimui, bet jis nėratiek detalus <strong>ir</strong> lankstus, siūlydamas pakankamai vienareikšmį proceso gerinimo kelią <strong>ir</strong>nesuteikdamas galimybės detaliau stebėti proceso pagerėjimo. Taigi, jei pagrindinis tikslas yraprogramų kūrimo proceso gerinimas, labiau tinkamas yra tolydinis modelis.Procesų gebėjimo lygių <strong>ir</strong> brandos lygių panašumas leidžia teigti, kad galima atrastipakopinės <strong>ir</strong> tolydinės architektūrų modelių dualumą, t.y. galima parinkti vardinių procesųgebėjimų lygių profilį pagal tolydinės architektūros modelį, atitinkantį visuminį procesą subrandos lygio įverčiu pagal pakopinę architektūrą. Tokio atitikimo egzistavimas leidžiaorganizacijai taikyti tolydinės architektūros brandos modelį, o pasiekus tam tikrą vardiniųprocesų gebėjimų lygių profilį, patv<strong>ir</strong>tinti, kad visuminis organizacijos procesas yra tam tikrobrandos lygio pagal pakopinės architektūros modelį.Standartas ISO/IEC 15504Standartas ISO/IEC 15504 išsivystė iš SPICE modelio. Nuo pat pradžios jo pask<strong>ir</strong>tis buvoapibrėžti vertinimo kriterijus <strong>ir</strong> principus, kurių pagrindu būtų galima kurti kitus programųkūrimo proceso gebėjimo vertinimo <strong>ir</strong> gerinimo modelius.Būtina pažymėti, kad su 2004 metų versijos išleidimu ISO/IEC 15504 tapo bet kokiųprocesų gebėjimo vertinimo standartu, t.y. pas<strong>ir</strong>inkus programinės įrangos gyvavimo cikloprocesų modelį ISO/IEC 12207, jis gali būti taikomas programų kūrimo proceso vertinimui, opas<strong>ir</strong>inkus kitos srities procesų modelį, jis gali būti taikomas tos srities procesų gebėjimovertinimui. Todėl normatyvinė standarto dalis ISO/IEC 15504-2 [ISO04b] apibrėžia tik:- proceso gebėjimo matavimo karkasą;- reikalavimus procesų modeliui;- reikalavimus vertinimo modeliui.Procesų gebėjimo matavimo karkasasProcesų gebėjimas apibrėžiamas 6 lygiais, kurie sudaro proceso vertinimo skalę: nuonevykdomo, kai proceso tikslai yra nepasiekiami, iki optimizuojamo. Vertinimo rezultateprocesas yra prisk<strong>ir</strong>iamas vienam iš tų šešių proceso gebėjimo lygių, kuris yra nustatomas pagalproceso atributų reikšmes. Kiekvienas atributas, esantis vertinamo proceso atributų rinkinyje,apibrėžia tam tikrą proceso gebėjimo aspektą. Proceso atributų pasiekimo apimtis yracharakterizuojama vertinimo skalėje. Proceso atributų pasiekimas <strong>ir</strong> apibrėžtas tų atributųgrupavimas kartu nusako proceso gebėjimo lygį.Mokymo medžiaga 34
Programų sistemų inžinerija3. Programų kūrimo procesasLygis 0: Nevykdomas procesas. Procesas yra nevykdomas, arba nepasiekiami procesotikslai. Šiame lygyje nesurenkama jokių arba surenkama mažai įrodymų, kad proceso tikslai yrapasiekiami.Lygis 1: Vykdomas procesas. Vykdant procesą yra pasiekiami proceso tikslai. P<strong>ir</strong>mo lygiopasiekimą rodo vienas proceso atributas:PA 1.1 Proceso atlikimo atributas. Proceso atlikimo atributas nusako, kokiu laipsniu(kokia apimtimi) yra pasiekiami proceso tikslai. Pilno šio atributo pasiekimo (įgyvendinimo,išpildymo) rezultatas: procesas pasiekia apibrėžtą tikslą.Lygis 2: Valdomas procesas. P<strong>ir</strong>mo lygio (vykdomo) proceso atlikimas šiame lygyje yravaldomas (planuojamas, stebimas, koreguojamas), o proceso darbo produktai yra atitinkamai(tinkamai) sukuriami, kontroliuojami <strong>ir</strong> palaikomi. Antro lygio pasiekimą kartu su p<strong>ir</strong>mo lygioatributais rodo du proceso atributai:PA 2.1 Proceso vykdymo valdymo atributas. Proceso atlikimo atributas nusako, kokiulaipsniu (kokia apimtimi) yra valdomas proceso vykdymas (atlikimas). Pilno šio atributopasiekimo (įgyvendinimo, išpildymo) rezultatai: proceso vykdymo tikslai yra identifikuoti,proceso vykdymas yra planuojamas <strong>ir</strong> stebimas, proceso vykdymas yra koreguojamas, kadatitiktų planus, proceso vykdymo atsakomybės <strong>ir</strong> įgaliojimai yra apibrėžti <strong>ir</strong> prisk<strong>ir</strong>ti, o susijusiosšalys informuotos, proceso vykdymui reikalingi resursai <strong>ir</strong> informacija yra identifikuoti,pasiekiami, prisk<strong>ir</strong>ti <strong>ir</strong> naudojami, sąveika tarp susijusių šalių yra valdoma, kad užtikrintųefektyvią komunikaciją <strong>ir</strong> aiškų atsakomybių priskyrimą.PA 2.2 Darbo produktų valdymo atributas. Darbo produktų valdymo atributas nusakokokiu laipsniu (kokia apimtimi) yra tinkamai valdomi proceso vykdymo metu (proceso)sukuriami darbo produktai. Pilno šio atributo pasiekimo (įgyvendinimo, išpildymo) rezultatai:reikalavimai proceso darbo produktams yra apibrėžti, reikalavimai dokumentacijai <strong>ir</strong> darboproduktų kontrolei yra apibrėžti, darbo produktai yra tinkamai identifikuoti, dokumentuoti <strong>ir</strong>kontroliuojami, darbo produktai yra peržiūrėti pagal planinius susitarimus, <strong>ir</strong> kur būtinakoreguojami, kad atitiktų reikalavimus.Lygis 3: Apibrėžtas procesas. Antro lygio (valdomo) proceso vykdymas šiame lygyje yraapibrėžtas. Proceso atlikimas yra apibrėžtas taip, kad procesas pasiektų apibrėžtus rezultatus.Trečio lygio pasiekimą kartu su p<strong>ir</strong>mo <strong>ir</strong> antro lygių atributais rodo šie proceso atributai:PA 3.1 Proceso apibrėžimo atributas. Proceso apibrėžimo atributas nusako kokia apimtimistandartinis procesas yra palaikomas, kad paremtų apibrėžto proceso įdiegimą. Pilno šio atributopasiekimo (įgyvendinimo, išpildymo) rezultatai: standartinis procesas, įskaitant pritaikymoga<strong>ir</strong>es, yra apibrėžtas <strong>ir</strong> aprašo pagrindinius, į apibrėžtą procesą įeinančius elementus,standartinio proceso <strong>ir</strong> kitų procesų seka bei sąveika tarp jų yra nustatyta, reikalaujamaMokymo medžiaga 35
Programų sistemų inžinerija3. Programų kūrimo procesaskompetencija <strong>ir</strong> proceso atlikimo rolės yra identifikuotos kaip standartinio proceso dalys,proceso atlikimui reikiama infrastruktūra <strong>ir</strong> darbo aplinka yra identifikuotos kaip standartinioproceso dalys, proceso efektyvumo <strong>ir</strong> tinkamumo stebėjimo metodai yra nustatyti.PA 3.2 Proceso įdiegimo atributas. Proceso įdiegimo atributas nusako kokiu laipsniu(kokia apimtimi) standartinis procesas yra efektyviai įdiegiamas kaip apibrėžtas procesas, kadpasiektų proceso rezultatus. Pilno šio atributo pasiekimo (įgyvendinimo, išpildymo) rezultatai:apibrėžtas procesas yra įdiegtas pagal tinkamai parinktą <strong>ir</strong>/arba pritaikytą standartinį procesą,apibrėžto proceso atlikimui reikalaujamos rolės, atsakomybės <strong>ir</strong> įgaliojimai yra prisk<strong>ir</strong>ti <strong>ir</strong>išplatinti, personalas, vykdantis apibrėžtą procesą, yra kompetentingas - turi reikiamąišsilavinimą, pat<strong>ir</strong>tį bei yra tinkamai apmokytas, apibrėžto proceso vykdymui reikalingi resursai<strong>ir</strong> informacija yra pasiekiami, prisk<strong>ir</strong>ti <strong>ir</strong> naudojami, apibrėžto proceso vykdymui reikalingainfrastruktūra bei darbo aplinka yra pasiekiamos, valdomos <strong>ir</strong> palaikomos, atitinkami duomenysyra surenkami <strong>ir</strong> analizuojami tam, kad suprastas proceso funkcionavimas (elgesys), kad būtųparodytas proceso tinkamumas <strong>ir</strong> efektyvumas <strong>ir</strong>, kad būtų įvertintos sritys, kuriose turėtų būtiatliekamas ištisinis proceso gerinimas.Lygis 4: Prognozuojamas procesas. Trečio lygio (apibrėžtas) procesas šiame lygyje yravykdomas apibrėžtose ribose tam, kad pasiektų proceso rezultatus. Ketv<strong>ir</strong>to lygio pasiekimąkartu su p<strong>ir</strong>mo, antro <strong>ir</strong> trečio lygių atributais rodo šie proceso atributai:PA 4.1 Proceso matavimo atributas. Proceso matavimo atributas nusako kokia apimtimiyra naudojami matavimo rezultatai, kad būtų užtikrinta, kad proceso vykdymas užtikrina procesotikslų pasiekimą remiant apibrėžtus verslo tikslus. Pilno šio atributo pasiekimo rezultatai:procesoinformacijos poreikiai verslo tikslų siekimui yra nustatyti, iš proceso informacijos poreikių yragauti proceso matavimo tikslai, kiekybiškai išreikšti proceso vykdymo tikslai remiantysatitinkamus verslo tikslus yra nustatyti, matavimai <strong>ir</strong> matavimų dažnumas yra identifikuoti beiapibrėžti remiantis proceso matavimo tikslais <strong>ir</strong> proceso vykdymo kiekybiniais tikslais,matavimų rezultatai yra surinkti, išanalizuoti <strong>ir</strong> išdėstomi ataskaitoje, kad būtų galima stebėtikokia apimtimi yra pasiekiami kiekybiniai proceso vykdymo tikslai, matavimų rezultatai yranaudojami proceso vykdymo apibūdinimuiPA 4.2 Proceso kontrolės atributas. Proceso kontrolės atributas nusako kokia apimtimiprocesas yra kiekybiškai valdomas, kad būtų stabilus, gebantis <strong>ir</strong> prognozuojamas apibrėžtoseribose. Pilno šio atributo pasiekimo rezultatai: analizės <strong>ir</strong> kontrolės metodai yra apibrėžti <strong>ir</strong>taikomi tinkamose vietose, nukrypimų valdymo ribos yra nustatytos normaliam procesovykdymui, matavimo duomenys yra analizuojami atsk<strong>ir</strong>iems nukrypimų atvejams, atsk<strong>ir</strong>iemsnukrypimų atvejams yra daromi koreguojantys veiksmai, jeigu reikia, įvykdžius korekciniusveiksmus yra iš naujo nustatomos nukrypimų valdymo ribos.Mokymo medžiaga 36
Programų sistemų inžinerija3. Programų kūrimo procesasLygis 5: Optimizuojamas procesas. Ketv<strong>ir</strong>to lygio (prognozuojamas) procesas šiame lygyjeyra be perstojo gerinamas, kad pasiektų aktualius esamus bei numatomus verslo tikslus. Penktolygio pasiekimą kartu su p<strong>ir</strong>mo, antro, trečio <strong>ir</strong> ketv<strong>ir</strong>to lygių atributais rodo šie proceso atributai:PA 5.1 Proceso inovatyvumo atributas. Proceso inovatyvumo atributas nusako kokiaapimtimi yra identifikuojami proceso pakeitimai, kurie ats<strong>ir</strong>anda analizuojant proceso vykdymonukrypimo nuo normos priežastis bei tyrinėjant naujoviškus proceso apibrėžimo <strong>ir</strong> įdiegimobūdus. Pilno šio atributo pasiekimo rezultatai: verslo tikslus remiantys proceso gerinimo tikslaiyra apibrėžti, reikiami duomenys yra analizuojami, kad būtų nustatytos pasikartojančios procesovykdymo nukrypimų nuo normos priežastys, reikiami duomenys yra analizuojami, kad būtųnustatytos geriausių praktikų bei naujovių įdiegimo galimybės, gerinimo galimybės, kylančios išnaujų technologijų bei proceso koncepcijos, yra identifikuotos, proceso įgyvendinimo strategijayra nustatyta, kad būtų pasiekti proceso gerinimo tikslai.PA 5.2 Proceso optimizavimo atributas. Proceso optimizavimo atributas nusako kokiaapimtimi pakeitimai proceso apibrėžime, valdyme <strong>ir</strong> vykdyme įtakoja efektyvius pokyčiusproceso gerinimo tikslų siekimui. Pilno šio atributo pasiekimo rezultatai: visų pasiūlytųpakeitimų įtaka yra įvertinama atsižvelgiant į apibrėžto <strong>ir</strong> standartinio proceso tikslus, patv<strong>ir</strong>tintųpakeitimų įgyvendinimas yra valdomas, kad būtų užtikrinta, kad bet kokie proceso vykdymonesklandumai būtų suprasti <strong>ir</strong> į juos būtų tinkamai reaguojama, proceso pakeitimo efektyvumasyra vertinamas esamo vykdymo atžvilgiu pagal apibrėžtus reikalavimus produktui <strong>ir</strong> procesotikslus, kad būtų nustatyta, ar gauti rezultatai yra bendrinis ar išsk<strong>ir</strong>tinis atvejis.Proceso atributo įverčiaiN – Nepasiektas (0 - 15% pasiekimo). Yra mažai arba visai nesurenkama jokių įrodymųapie vertinamo proceso nagrinėjamo atributo pasiekimą.P – Iš dalies pasiektas (16% - 50% pasiekimo). Yra dalis įrodymų apie priartėjimą prievertinamo proceso atributo <strong>ir</strong> dalinį jo pasiekimą. Kai kurie atributo pasiekimo aspektai gali būtinenusakomi.L – Didžiąja dalimi pasiektas (51% - 85% pasiekimo). Yra įrodymų apie sisteminįpriartėjimą prie vertinamo proceso atributo <strong>ir</strong> žymų jo pasiekimą. Vertinamame procese gali būtidalis su atributu susijusių silpnų vietų.F – Pilnai pasiektas (6% - 100% pasiekimo). Yra įrodymų apie pilną <strong>ir</strong> sisteminį priėjimąprie vertinamo proceso atributo <strong>ir</strong> pilną jo pasiekimą. Neaptinkama jokių reikšmingų trūkumųsusijusių su vertinamo proceso atributu.Lygis Proceso atributai ĮvertinimasLygis 1 Proceso atlikimo atributas L arba FMokymo medžiaga 37
Programų sistemų inžinerija3. Programų kūrimo procesasLygis 2Lygis 3Lygis 4Lygis 5Proceso atlikimo atributasProceso vykdymo valdymo atributasDarbo produktų valdymo atributasProceso atlikimo atributasProceso vykdymo valdymo atributasDarbo produktų valdymo atributasProceso apibrėžimo atributasProceso įdiegimo atributasProceso atlikimo atributasProceso vykdymo valdymo atributasDarbo produktų valdymo atributasProceso apibrėžimo atributasProceso įdiegimo atributasProceso matavimo atributasProceso kontrolės atributasProceso atlikimo atributasProceso vykdymo valdymo atributasDarbo produktų valdymo atributasProceso apibrėžimo atributasProceso įdiegimo atributasProceso matavimo atributasProceso kontrolės atributasProceso inovacijos atributasProceso optimizavimo atributas3.2 lentelė. Proceso atributų įverčiai būtini gebėjimo lygiamsFL arba FL arba FFFFL arba FL arba FFFFFFL arba FL arba FFFFFFFFL arba FL arba FReikalavimai procesų modeliuiTam, kad procesus būtų galima įvertinti, jie procesų modelyje turi būti apibrėžti tinkamubūdu, įgalinančiu sukurti procesų modeliu paremtą vertinimo modelį, pagal kurį tie procesai būtųvertinami. Normatyvinėje standarto dalyje ISO/IEC 15504-2 [ISO04b] pateikiami tokiereikalavimai procesų modeliui:1. Procesų modelyje turi būti:a. Procesų modelio taikomosios srities apibūdinimas;b. Procesų modelio taikomosios srities procesų aprašymas, atitinkantis procesoaprašymui keliamus reikalavimus;c. Ryšių tarp procesų modelio <strong>ir</strong> numatomo jo panaudojimo konteksto aprašymas;d. Sąryšių tarp procesų, esančių procesų modelyje, aprašymas.2. Procesų modelyje turi būti dokumentuota modeliu suinteresuota bendrija <strong>ir</strong> veiksmai,kurių imtasi pasiekti pritarimą modeliui toje bendrijoje:a. Turi būti apibūdinta arba specifikuota tiesiogiai su procesų modeliu susijusisuinteresuota bendrija;b. Turi būti dokumentuotas pritarimo procesų modeliui laipsnis;Mokymo medžiaga 38
Programų sistemų inžinerija3. Programų kūrimo procesasc. Jei nėra imtasi jokių veiksmų pasiekti pritarimą procesų modeliui suinteresuotojebendrijoje, tokia situacija turi būti pagrįsta.3. Procesų modelyje apibrėžti procesai turi turėti unikalius identifikatorius <strong>ir</strong> aprašymus.Reikalavimai proceso aprašymuiEsminė procesų modelio dalis yra procesų modelio taikomosios srities procesų aprašymas.Proceso aprašymas procesų modelyje susideda iš proceso pask<strong>ir</strong>ties formulavimo, kurioje aukštulygiu apibūdinami bendrieji proceso vykdymo tikslai, <strong>ir</strong> proceso rezultatų rinkinio, parodančiosėkmingą proceso tikslų pasiekimą. Proceso aprašymas turi tenkinti šiuos reikalavimus:1. Proceso aprašyme turi būti pateikti proceso tikslai <strong>ir</strong> rezultatai;2. Proceso aprašyme pateiktas proceso rezultatų rinkinys turi būti būtinas <strong>ir</strong> pakankamaspasiekti proceso tikslus;3. Proceso aprašyme neturi būti tiesiogiai ar netiesiogiai pateikti jokie aukštesnių užp<strong>ir</strong>mąjį gebėjimo lygių aspektai.Proceso rezultatas aprašo:1) darbo produkto sukūrimą arba2) svarbų organizacijos būsenos pasikeitimą, arba3) apibrėžtų sąlygų, tokių kaip reikalavimai, tikslai <strong>ir</strong> pan. išpildymą.Reikalavimai vertinimo modeliuiProcesų vertinimo modelis yra susietas su vienu arba daugiau procesų modelių. Vertinimomodelis suformuoja įrodymų rinkimo <strong>ir</strong> procesų gebėjimo vertinimo pagrindą. Šis modelispateikia dviejų dimensijų požiūrį į proceso gebėjimą. Vienoje iš dimensijų – procesųdimensijoje, aprašomi procesai kurie atitinka procesų modelyje aprašytus taikomosios sritiesprocesus. Kitoje – gebėjimų dimensijoje, vertinimo modelis aprašo gebėjimus kurie išreiškiamigebėjimo lygiais <strong>ir</strong> procesų atributais. Normatyvinėje standarto dalyje ISO/IEC 15504-2[ISO04b] pateikiami tokie reikalavimai vertinimo modeliui:modelio(ų);Vertinimo modelyje turi būti pateikta:1. Procesų vertinimo modelio tikslas, apimtis <strong>ir</strong> sudedamieji elementai;2. Procesų gebėjimo matavimo karkaso <strong>ir</strong> procesų modelio susiejimas;3. Pastovaus rezultatų išreiškimo mechanizmas.Vertinimo modelio apimtisISO/IEC 15504-2 pateikia tokius reikalavimus vertinimo modelio apimčiai:1. Procesų vertinimo modelis turi susieti bent vieną procesą iš pateikto(ų) procesųMokymo medžiaga 39
Programų sistemų inžinerija3. Programų kūrimo procesas2. Duotam procesui procesų vertinimo modelis turi susieti visus procesų gebėjimomatavimo karkaso gebėjimo lygius arba ištisinį šių gebėjimo lygių rinkinį (pradedant p<strong>ir</strong>mulygiu);3. Procesų vertinimo modelyje turi būti apibrėžta jo apimtis pateikiant:a. pas<strong>ir</strong>inktą(us) procesų modelį(ius),b. pas<strong>ir</strong>inktus procesų modelio procesus,c. pas<strong>ir</strong>inktus procesų gebėjimo matavimo karkaso lygius.Vertinimo modelio indikatoriaiISO/IEC 15504-2 nurodo, kad procesų vertinimo modelyje turi būti rinkinys indikatorių,kurie:1. Aiškiai, tokia pat forma kaip <strong>ir</strong> pas<strong>ir</strong>inktame procesų modelyje, nurodo proceso tikslus <strong>ir</strong>rezultatus procesų vertinimo modelyje pas<strong>ir</strong>inktiems procesams;2. Rodo proceso atributų pasiekimą procesų vertinimo modelyje pas<strong>ir</strong>inktuose procesųgebėjimo lygiuose.Indikatoriai operuoja procesų vertinimo modelyje pas<strong>ir</strong>inktų procesų įgyvendinimolygmeniu.Vertinimo modelio <strong>ir</strong> procesų modelio susiejimasISO/IEC 15504-2 sakoma, kad vertinimo modelyje turi būti pateiktas aiškus susiejimastarp vertinimo modelio sudedamųjų elementų <strong>ir</strong> pas<strong>ir</strong>inkto procesų modelio procesų beiatitinkamų proceso atributų iš procesų gebėjimo matavimo karkaso.Susiejimas turi būti pilnas, aiškus <strong>ir</strong> vienareikšmis. Procesų vertinimo modelio indikatoriaituri susieti:1) pas<strong>ir</strong>inkto procesų modelio procesus, apibrėžtus tikslais <strong>ir</strong> rezultatais <strong>ir</strong>2) proceso atributus iš procesų gebėjimo vertinimo karkaso (įskaitant kiekvieno procesoatributų pasiekimo rezultatus).Tai įgalima procesų vertinimo modelius susieti su atitinkamais procesų modeliais, nors tųmodelių struktūra sk<strong>ir</strong>iasi.Vertinimo rezultatų išreiškimasISO/IEC 15504-2 sakoma, kad vertinimo modelyje turi būti pateiktas formalus <strong>ir</strong>patikrinamas vertinimo rezultatų pateikimo mechanizmas. Vertinimo rezultatai turi būti pateiktikaip kiekvieno proceso, pas<strong>ir</strong>inkto iš naudojamo procesų modelio, atributų įvertinimų rinkinys.Pavyzdinis ISO/IEC 15504-2 reikalavimus atitinkantis programų kūrimo procesų gebėjimovertinimo modelis pateiktas penktojoje informacinėje ISO/IEC 15504 standarto dalyje. EsamosCMMI versijos neatitinka ISO/IEC 15504 standarto reikalavimų: proceso sričių apibrėžimai turigebėjimo bruožų.Mokymo medžiaga 40
Programų sistemų inžinerija3. Programų kūrimo procesasLiteratūra papildomam skaitymui[Bro87]F.P. Brooks. No Silver Bullet; Essence and Accidents of Software Engineering.IEEE Computer Magazine, April 1987.[EDM98] K.E.Emam, J.N.Drouin, W. Melo, SPICE: The Theory and Practice of SoftwareProcess Improvement and Capability Determination. IEEE Computer SocietyPress, 1998.[ISO98] ISO/IEC 15504: Information technology – Software process assessment, (parts 1-9). International Organization for Standardization and the InternationalElectrotechnical Commission, 1998[ISO04a] ISO/IEC 15504-1:2004. Information technology – Process Assessment. Part 1:Concepts and vocabulary.[ISO04b] ISO/IEC 15504-2:2003. Information technology – Process Assessment. Part 2:Performing an assessment.[ISO04c] ISO/IEC 15504-3:2004. Information technology – Process Assessment. Part 3:Guidance on performing an assessment.[ISO04d] ISO/IEC 15504-4:2004. Information technology – Process Assessment. Part 4:Guidance on use for process improvement and process capability determination.[Kea02]Keane, Outsourcing and the Capability Maturity Model (CMM): Using the CMMin Selecting Application Outsourcing Service Providers. Keane’s White Papers,2002.[Loo04a] H.V. Loon, Process Assessment and Improvement. A practical guide for managers,quality professionals and assessors. Springer, 2004.[Loo04b] H.V. Loon, Process Assessment and ISO/IEC 15504. A Reference Book. Springer,2004.[PCC+93] M.C. Paulk, B. Curtis, M. B.Chrissis, C.V. Weber, Capability Maturity Model forSoftware, Version 1.1 (CMU/SEI-93-TR-024). Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University, 1993[SEI04] Software Engineering Institute, Process Maturity Profile. Software CMM® 2004Mid-Year Update. Software Engineering Institute, Carnegie Mellon University,August 2004[StG01] Standish Group, Extreme CHAOS. The Standish Group International, Inc, 2001.Mokymo medžiaga 41
Programų sistemų inžinerija3. Programų kūrimo procesasMokymo medžiaga 42
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelis4. Integruotas gebėjimo brandos modelisMotyvacija domėtis procesu IT sferoje buvo paskatinta sėkmės proceso efektyvumogerinime kitose pramonės šakose. Orientacijos į procesą ištakomis galima laikyti 1930 WalterShewhart pasiūlytus statistinės kokybės kontrolės principus, kuriuos toliau išvystė W. EdwardsDeming <strong>ir</strong> Joseph Juran.Šių principų taikymo programų sistemoms pionieriumi galima laikyti Watts Humphrey <strong>ir</strong>jo su kolegomis darbus, atliktus IBM <strong>ir</strong> SEI. Juose paskelbti principai <strong>ir</strong> sąvokos tapo gebėjimobrandos modelių (angl. Capability Maturity Model - CMM) pagrindu.CMM ats<strong>ir</strong>adimasGebėjimo brandos modelis buvo sukurtas JAV vyriausybės užsakymu kaip metodasprogramų sistemų kūrimo paslaugų teikėjų gebėjimo įvertinimui <strong>ir</strong> p<strong>ir</strong>mą kartą paskelbtas 1987metais. CMM pateikia evoliucinį kelią programų kūrimo proceso gerinimui. 1991 metais SEIpaskelbė gebėjimo brandos modelio programų sistemų kūrimui SW-CMM (angl. CapabilityMaturity Model for Software) versiją 1.0, o 1993 metais – versiją 1.1. Buvo planuota rengti <strong>ir</strong>versiją 2.0, bet atliktų darbų rezultatai buvo panaudoti CMMI kūrimui, pradėtam 1997 metais.Nuo daugybės CMM prie vieno CMMINuo 1991 buvo sukurta visa eilė CMM modelių, sk<strong>ir</strong>tų įva<strong>ir</strong>ioms disciplinoms: programųsistemų inžinerijai, sistemų inžinerijai, programų sistemų įsigijimui, darbo jėgos valdymui <strong>ir</strong>ugdymui, integruotam produkto <strong>ir</strong> proceso kūrimui <strong>ir</strong> kt. Buvo suprasta, kad naudinga būtų turėtivieną modelį, apimantį daugelį disciplinų. Tuo tikslu JAV Gynybos departamentas inicijavointegruoto modelio CMM (angl. Capability Maturity Model Integration) kūrimą. Integruotasmodelis turėjo suteikti tokius privalumus:- daugelio modelių integravimas leidžia pašalinti nesuderinamumus <strong>ir</strong> sumažintidubliavimąsi;- bendras karkasas leidžia padidinti aiškumą <strong>ir</strong> suprantamumą, nes naudojama vieningaterminologija, stilius <strong>ir</strong> bendri komponentai;- tolydinės architektūros versija įgalina suderinamumą su ISO 15504;- pakopinės architektūros versija užtikrina tiesioginį ryšį su CMM <strong>ir</strong> palengvinamigravimą nuo CMM prie CMMI;- CMMI suteiks lankstų išplečiamą karkasą, kuris gali būti naudojamas kaip pagrindaskuriant brandos modelius kitoms disciplinoms.Šiuo metu yra išleistos keturios CMMI versijos, sk<strong>ir</strong>tos atitinkamai:- programų sistemų kūrimui CMMI-SW (angl. CMMI for Software Engineering),Mokymo medžiaga 43
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelis- programų sistemų <strong>ir</strong> sistemų kūrimui CMMI-SE/SW (angl. CMMI for SystemsEngineering/ Software Engineering),- programų sistemų, sistemų bei integruoto produkto <strong>ir</strong> proceso kūrimui CMMI-SE/SW/IPPD (angl. CMMI for Systems Engineering/ Software Engineering/ IntegratedProduct and Process Development),- programų sistemų, sistemų bei integruoto produkto <strong>ir</strong> proceso kūrimui bei sistemųįsigijimui CMMI-SE/SW/IPPD/SS (angl. CMMI for Systems Engineering/ SoftwareEngineering/ Integrated Product and Process Development/ Supplier Sourcing).Trumpa CMMI istorija1997 metais: JAV Gynybos departamentas inicijavo CMMI kūrimą1998 metais: paskelbta CMMI modelio versija 1.01999 metais: paskelbta CMMI modelio versija 2.02000 metais: paskelbtas CMMI-SE/SW/IPPD2002 metais: paskelbtas CMMI-SE/SW/IPPD/SSPagrindiniai CMMI šaltiniaiCMMI kūrimo komandos užduotis buvo suderinti tris modelius:- programų sistemų CMM (SW-CMM v2.0 draft C);- sistemų inžinerijos gebėjimo modelį (EIA/IS 731);- integruoto produkto kūrimo CMM (IPD-CMM v 0.98).CMMI struktūraKaip jau buvo minėta, CMMI turi tiek pakopinės (palengvinimui migravimo iš CMM), tiektolydinės (suderinamumui su ISO 15504) architektūros modelius.Proceso sritys abiejų architektūrų modeliuose yra vienodos. Jos pateikiamos lentelėje(abreviatūros naudojamos originalios, angliškos):CARCMPavadinimasPriežasčių analizė <strong>ir</strong> panaikinimas(angl. Causal Analysis andResolution)Konfigūracijos valdymas (angl.Configuration Management)TikslasIdentifikuoti defektų <strong>ir</strong> kitų problemų priežastis <strong>ir</strong>imtis prevencinių veiksmų, siekiant išvengtiproblemų ateityje.Nustatyti <strong>ir</strong> valdyti darbo produktų integralumą,naudojant konfigūracijos identifikavimą,konfigūracijos valdymą, konfigūracijos būsenosapskaitą <strong>ir</strong> konfigūracijos auditus.Mokymo medžiaga 44
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisDARIPMISMITMAOEIOIDOPDOPFPavadinimasSprendimų analizė <strong>ir</strong> priėmimas(angl. Decision Analysis andResolution)Integruotas projekto valdymas(angl. Integrated ProjectManagement)Integruotas tiekėjo valdymas(angl. Integrated SupplierManagement)Integruotas komandų valdymas(angl. Integrated Teaming)Matavimai <strong>ir</strong> analizė (angl.Measurement and Analysis)Organizacinė aplinkaintegravimui (angl.Organizational Env<strong>ir</strong>onment forIntegration)Organizacinės inovacijos <strong>ir</strong>skleidimas (angl. OrganizationalInnovation and Deployment)Organizacinis procesoapibrėžimas (angl.Organizational ProcessDefinition)Organizacinis dėmesys procesui(angl. Organizational ProcessFocus)TikslasAnalizuoti galimus sprendimus, naudojant formalųvertinimo procesą, kuris įvertina identifikuotasalternatyvas pagal nustatytus kriterijus.Valdyti projektą <strong>ir</strong> suinteresuotų asmenų įtraukimąpagal integruotą <strong>ir</strong> apibrėžtą procesą, kuris yrapritaikomas konkrečiam projektui iš organizacijosstandartinių procesų aibės.Iniciatyviai identifikuoti šaltinius produktų, kuriegali būti panaudoti projekto reikalavimamspatenkinti, <strong>ir</strong> valdyti pas<strong>ir</strong>inktus tiekėjus, užmezgantbendradarbiavimo ryšius.Suformuoti <strong>ir</strong> palaikyti integruotą komandą darboproduktų kūrimui.Sukurti <strong>ir</strong> palaikyti matavimų sistemą valdymoinformaciniams poreikiams patenkinti.Pateikti infrastruktūrą integruoto produkto <strong>ir</strong>proceso kūrimui <strong>ir</strong> valdyti personalo integravimą.Parinkti <strong>ir</strong> paskleisti inkrementinius <strong>ir</strong> inovatyviusproceso pagerinimus, kurie išmatuojamai pagerinaorganizacijos procesus <strong>ir</strong> naudojamas technologijas.Pagerinimai palaiko organizacijos kokybės <strong>ir</strong>proceso efektyvumo tikslus, išplaukiančius išorganizacijos verslo tikslų.Apibrėžti <strong>ir</strong> valdyti aibę vartotinų organizacijosprocesų apibrėžimų.Planuoti <strong>ir</strong> įgyvendinti organizacijos procesogerinimą, remiantis giliu supratimu einamojoorganizacijos proceso stipriųjų <strong>ir</strong> silpnųjų pusių.Mokymo medžiaga 45
Programų sistemų inžinerijaPavadinimasOPP Organizacinis proceso vykdymas(angl. Organizational ProcessPerformance)OT Organizaciniai mokymai(angl. Organizational Training)PI Produkto integravimas(angl. Product Integration)PMC Projekto stebėjimas <strong>ir</strong> kontrolė(angl. Project Monitoring andControl)PP Projekto planavimas(angl. Project Planning)PPQA Proceso <strong>ir</strong> produkto kokybėsužtikrinimas (angl. Process andProduct Quality Assurance)QPM Kiekybinis projekto valdymas(angl. Quantitative ProjectManagement)RD Reikalavimų apibrėžimas (angl.Requ<strong>ir</strong>ements Development)REQM Reikalavimų valdymas (angl.Requ<strong>ir</strong>ements Management)RSKM Rizikos valdymas (angl. RiskManagement)4. Integruotas gebėjimo brandos modelisTikslasSuformuoti <strong>ir</strong> valdyti kiekybinę organizacijosprocesų vykdymo efektyvumo sampratą, palaikantkokybės <strong>ir</strong> proceso efektyvumo tikslus, pateiktiproceso efektyvumo duomenis, baziniuskomplektus <strong>ir</strong> modelius kiekybiniam organizacijosvykdomų projektų valdymui.Vystyti žmonių įgūdžius <strong>ir</strong> žinias taip, kad jie galėtųatlikti savo roles tinkamai <strong>ir</strong> efektyviai.Surinkti produktą iš produkto komponentų,užtikrinti, kad integruotas produktas funkcionuojatinkamai, <strong>ir</strong> pateikti produktą.Pateikti supratimą apie projekto progresą taip, kadbūtų galima imtis tinkamų korekcinių veiksmų, kaiprojekto vykdymas iš esmės sk<strong>ir</strong>iasi nuo plano.Sukurti <strong>ir</strong> valdyti planus, apibrėžiančius projektoveiklas.Pateikti darbuotojams <strong>ir</strong> vadovybei objektyvųprocesų <strong>ir</strong> susijusių darbo produktų supratimą.Kiekybiškai valdyti apibrėžtas projekto veiklas, kadpasiekti nustatytus projekto kokybės <strong>ir</strong> procesoefektyvumo tikslus.Sukurti <strong>ir</strong> analizuoti užsakovo, produkto <strong>ir</strong> produktokomponentų reikalavimus.Valdyti reikalavimus projekto produktams <strong>ir</strong>produktų komponentams <strong>ir</strong> identifikuotineatitikimus tarp šių reikalavimų <strong>ir</strong> projekto planųbei darbo produktų.Identifikuoti potencialias problemas prieš jomsįvykstant taip, kad rizikos valdymo veiklos gali būtisuplanuotos <strong>ir</strong> pr<strong>ir</strong>eikus panaudotos produkto arprojekto gyvavimo metu tam, kad sumažintineigiamą įtaką tikslų pasiekimui.Mokymo medžiaga 46
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisSAMTSVALVERPavadinimasSutarties su tiekėju valdymas(angl. Supplier AgreementManagement)Techninis sprendimas(angl. Technical Solution)Validavimas(angl. Validation)Verifikavimas(angl. Verification)TikslasValdyti įsigijimą produktų iš tiekėjų, su kuriais yraformalūs susitarimai.Suprojektuoti, sukurti <strong>ir</strong> įgyvendinti sprendimą,tenkinantį reikalavimus. Sprendimas, projektavimas<strong>ir</strong> įgyvendinimas pagal poreikius apima atsk<strong>ir</strong>usproduktus, produktų komponentus, produktogyvavimo ciklo procesus ar jų kombinacijas.Parodyti, kad produkto komponentas, patalpintas įtikslinę aplinką, tenkina numatyto naudojimoreikalavimus.Užtikrinti, kad darbo produktai tinka jiemsapibrėžtai aplinkai.Pakopinės architektūros CMMI modelisPakopinės architektūros CMMI modelio struktūra pateikta 4.1 paveikslėlyje.Brandos lygiaiProceso sritis 1 (PA1) Proceso sritis 2 (PA2) Proceso sritis n (PAn)Specifiniai tikslaiBendrieji tikslaiBendrieji bruožaiSpecifinės praktikosĮsipareigojimasatliktiSugebėjimasatliktiTiesioginisįgyvendinimasVerifikavimoįgyvendinimasBendrosios praktikos4.1 pav. Pakopinės architektūros CMMI modelio struktūraPakopinėje architektūroje proceso sritys yra sugrupuotos į penkis brandos lygius. Tokiubūdu nurodomas organizacijos proceso gerinimo kelias – kokios proceso sritys turi būtiMokymo medžiaga 47
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisįgyvendintos, kad pasiekti atitinkamą brandos lygį. Tam, kad brandos lygis būtų pasiektas turibūti įgyvendintos to lygio <strong>ir</strong> visų žemesnių brandos lygių proceso sritys.Brandos lygiai numeruojami nuo 1 iki 5.Brandos lygis Pakopinės architektūros brandos lygis1 Pradinis (angl. Initial)2 Valdomas (angl. Managed)3 Apibrėžtas (angl. Defined)4 Kiekybiškai valdomas (angl. Quantitatively Managed)5 Optimizuojamas (angl. Optimizing)Kiekvienam brandos lygiui, išskyrus p<strong>ir</strong>mą, yra prisk<strong>ir</strong>tos tokios proceso sričių aibės:Brandos lygisPrisk<strong>ir</strong>tos proceso sritys1: Pradinis -2: Valdomas 7 proceso sritys:REQM: Reikalavimų valdymas,PP: Projekto planavimas,PMC: Projekto stebėjimas <strong>ir</strong> kontrolė,SAM: Sutarties su tiekėju valdymas,MA: Matavimai <strong>ir</strong> analizė,PPQA: Proceso <strong>ir</strong> produkto kokybės užtikrinimas,CM: Konfigūracijos valdymas3: Apibrėžtas 14 proceso sričių:RD: Reikalavimų apibrėžimas,TS: Techninis sprendimas,PI: Produkto integravimas,VER: Verifikavimas,VAL: Validavimas,OPF: Organizacinis dėmesys procesui,OPD: Organizacinis proceso apibrėžimas,OT: Organizaciniai mokymai,IPM: Integruotas projekto valdymas,RSKM: Rizikos valdymas,IT: Integruotas komandų valdymas,ISM: Integruotas tiekėjo valdymas,DAR: Sprendimų analizė <strong>ir</strong> priėmimas,Mokymo medžiaga 48
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisBrandos lygisPrisk<strong>ir</strong>tos proceso sritysOEI: Organizacinė aplinka integravimui.4: Kiekybiškai valdomas 2 proceso sritys:OPP: Organizacinis proceso vykdymas,QPM: Kiekybinis projekto valdymas.5: Optimizuojamas 2 proceso sritys:OID: Organizacinės inovacijos <strong>ir</strong> skleidimas,CAR: Priežasčių analizė <strong>ir</strong> panaikinimas.Tolydinės architektūros CMMI modelisTolydinės architektūros CMMI modelio struktūra pateikta 4.2 paveikslėlyje.Proceso sritis 1 (PA1) Proceso sritis 2 (PA2) Proceso sritis n (PAn)Specifiniai tikslaiBendrieji tikslaiSpecifinės praktikosGebėjimo lygiaiBendrosios praktikos4.2 pav. Tolydinės architektūros CMMI modelio struktūraTolydinės architektūros modelis nagrinėja kiekvienos proceso srities gebėjimą (gebėjimolygį) atsk<strong>ir</strong>ai. Tai įgalina organizaciją gerinimo pastangas nukreipti į vieną proceso sritį ar jųaibę, tikėtinai silpniausią toje organizacijoje, vertinant pagal organizacijos verslo tikslus.Tolydinės architektūros modelyje gebėjimo lygiai taikomi kiekvienai proceso sričiai.Modelyje yra numatyti 6 gebėjimo lygiai: nuo 0 iki 5:Gebėjimo lygis Tolydinės architektūros gebėjimo lygis0 Nevykdomas (Incomplete)1 Vykdomas (Performed)2 Valdomas (Managed)3 Apibrėžtas (Defined)4 Kiekybiškai valdomas (Quantitatively Managed)5 Optimizuojamas (Optimizing)Mokymo medžiaga 49
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisSvarbu atkreipti dėmesį, kad pakopinėje architektūroje bet kuri organizacija automatiškaituri 1-ą brandos lygį, t.y. šiam lygiui nėra jokių reikalavimų. Kad tolydinėje architektūrojeproceso sritis atitiktų 1-ą gebėjimo lygį, ji pati turi būti „pilnai“ įgyvendinta, t.y. turi vykdomosvisos šios proceso srities specifinės praktikos. Taigi tam, kad pripažinti proceso sričiai 1-ągebėjimo lygį, reikalingas vertinimas.Pakopinėje architektūroje proceso sritys yra grupuojamos pagal priskyrimą brandoslygiams. Tolydinėje architektūroje proceso sritys grupuojamos į 4 kategorijas: inžineriniaiprocesai, projekto valdymo procesai, proceso valdymo procesai <strong>ir</strong> palaikantys procesai.Kiekvienai kategorijai prisk<strong>ir</strong>iamos tokios proceso sričių aibės:KategorijaPrisk<strong>ir</strong>tos proceso sritysProceso valdymo 5 proceso sritys:OPD: Organizacinis proceso apibrėžimas,OPF: Organizacinis dėmesys procesui,OPP: Organizacinis proceso vykdymas,OT: Organizaciniai mokymai,OID: Organizacinės inovacijos <strong>ir</strong> skleidimas.Projekto valdymo 8 proceso sritys:PP: Projekto planavimas,PMC: Projekto stebėjimas <strong>ir</strong> kontrolė,IPM: Integruotas projekto valdymas,RSKM: Rizikos valdymas,SAM: Sutarties su tiekėju valdymas,QPM: Kiekybinis projekto valdymas,ISM: Integruotas tiekėjo valdymas,IT: Integruotas komandų valdymas.Inžinerinė6 proceso sritys:RD: Reikalavimų apibrėžimas,REQM: Reikalavimų valdymas,TS: Techninis sprendimas,VAL: Validavimas,VER: Verifikavimas,PI: Produkto integravimas.Palaikymo6 proceso sritys:CAR: Priežasčių analizė <strong>ir</strong> panaikinimas,CM: Konfigūracijos valdymas,Mokymo medžiaga 50
Programų sistemų inžinerijaKategorija4. Integruotas gebėjimo brandos modelisPrisk<strong>ir</strong>tos proceso sritysDAR: Sprendimų analizė <strong>ir</strong> priėmimas,MA: Matavimai <strong>ir</strong> analizė,PPQA: Proceso <strong>ir</strong> produkto kokybės užtikrinimas,OEI: Organizacinė aplinka integravimui.Bendra proceso sričių struktūraVisų proceso sričių aprašymas CMMI pateikiamas pagal tokią bendrą struktūrą: Proceso srities vardas• Tikslas• Įvadinės pastabos• Susijusios proceso sritys• Specifiniai tikslaio Specifinės praktikos- Tipiniai darbo produktai- Veiklos• Bendrieji tikslaio Bendrosios praktikos- Bendrųjų praktikų detalizavimasProceso srities komponentus galima susk<strong>ir</strong>styti į tris klases, nusakančias komponentųsvarbumą, patenkinant gebėjimo lygio reikalavimus. Siūlomas toks komponentų klasifikavimas:1. Privalomi komponentaiPrivalomi komponentai aprašo, ką organizacija turi pasiekti, kad įgyvendinti gebėjimolygio reikalavimus. Šis pasiekimas turi būti matomas organizacijos procese, t.y. turi egzistuotiįgyvendinimo įrodymai.Privalomus komponentus naudoja vertinimo komanda tam, kad priimtų sprendimą, arproceso sritis įgyvendinta.CMMI privalomi komponentai yra specifiniai tikslai <strong>ir</strong> bendrieji tikslai.2. Tikėtini komponentaiTikėtini komponentai aprašo, ką organizacija tipiškai įgyvendina, norėdama pasiektiprivalomus komponentus. Tikėtinus komponentus kaip ga<strong>ir</strong>es naudoja:- įgyvendinantys proceso gerinimą;- atliekantys proceso vertinimą.CMMI tikėtini komponentai yra specifinės praktikos <strong>ir</strong> bendrosios praktikos.Mokymo medžiaga 51
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelis3. Informaciniai komponentaiInformaciniai komponentai pateikia detales, padedančias organizacijai susiformuoti kelią,kaip įgyvendinti privalomus <strong>ir</strong> tikėtinus komponentus.CMMI pateikia informacinius komponentus veiklų aprašymuose. Galima išsk<strong>ir</strong>ti tokių tipųinformacinius komponentus: tipiniai darbo produktai, bendrųjų praktikų detalizavimas,disciplinos plėtojimas, uždaviniai, praktiniai patarimai <strong>ir</strong> nuorodos.Privalomi komponentaiSpecifiniai tikslaiBendrieji tikslaiTikėtini komponentaiSpecifinės praktikosBendrosios praktikosInformaciniai komponentaiTipiniai darbo produktaiVeiklosDisciplinos plėtojimasBendrųjų praktikų detalizavimasUždaviniai, praktiniai patarimaiNuorodos4.3 pav. CMMI proceso sričių struktūraBendrieji tikslaiBendrųjų tikslų <strong>ir</strong> gebėjimo lygių sampratos yra labai glaudžiai susijusios. Štai kodėlgebėjimo lygiai 2-5 <strong>ir</strong> bendrieji tikslai 2-5 formuluojami vienodais terminais. Bendrieji tikslaiatitinka gebėjimo lygiams tokiu būdu:Bendrasis tikslas 1: Pasiekti specifinius tikslus.Bendrasis tikslas 2: Institucionalizuoti valdomą procesą.Bendrasis tikslas 3: Institucionalizuoti apibrėžtą procesą.Bendrasis tikslas 4: Institucionalizuoti kiekybiškai valdomą procesą.Bendrasis tikslas 5: Institucionalizuoti optimizuojamą procesą.Mokymo medžiaga 52
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisBendrasis tikslas 1 yra susijęs su paties proceso įgyvendinimu, o kiti bendrieji tikslaiatitinka sk<strong>ir</strong>tingus proceso institucionalizavimo lygius. Reikia pastebėti, kad bendrieji tikslai yraorientuoti į proceso palaikymo infrastruktūros sukūrimą.Atitikimas tarp organizacijos brandos lygio <strong>ir</strong> proceso sričių gebėjimo lygiųAbi – pakopinė <strong>ir</strong> tolydinė – architektūros turi savų privalumų <strong>ir</strong> trūkumų, todėl kylanatūralus klausimas: kaip brandos lygiai yra susiję su proceso sričių gebėjimais? Arba kitaipsakant: jei žinome, kad organizacijos brandos lygis yra, pavyzdžiui, 2, ar galime pasakyti, kokiogebėjimo lygio kiekviena proceso sritis toje organizacijoje? Arba jei žinome organizacijosproceso sričių gebėjimo lygius, ar galime nustatyti organizacijos brandos lygį?Atsakymai į šiuos klausimus nėra vienareikšmiai. P<strong>ir</strong>miausia reikia pastebėti, kadvertinimas pagal tolydinį modelį yra detalesnis, t.y. informacija apie proceso sričių gebėjimą yradetalesnė, todėl įvertinimą pagal tolydinį modelį galima nesudėtingai atvaizduoti į vertinimopagal pakopinį modelį rezultatą – organizacijos brandos lygį. Taigi atvaizdavimas į gautųgebėjimo įvertinimų į brandos lygį yra galimas.Prieš atsakant į klausimą dėl atv<strong>ir</strong>kštinio atvaizdavimo – iš brandos lygio į gebėjimų lygius– būtina pasitikslinti jo formuluotę: ar turimas omenyje atvaizdavimas tik pagal galutinįvertinimo rezultatą (1 skaičių, atitinkantį organizacijos brandos lygį)? Tokiu atveju iš esmėskalbame apie atvaizdavimą tarp vertinimų pagal sk<strong>ir</strong>tingos architektūros CMM modelius.Realios organizacijos vertinimo metu surenkama daugiau informacijos, todėl dviejų organizacijų,turinčių tą patį brandos lygį, bent jau kai kurių proceso sričių gebėjimo lygiai gali būti sk<strong>ir</strong>tingi.Nagrinėjant abu modelius tolydinėje architektūroje galima apibrėžti proceso sričiųtikslinius profilius, kurie atitiktų gebėjimo lygius pakopinėje architektūroje.Atitikimas tarp CMMI proceso sričių gebėjimo lygių (GL1-GL5) <strong>ir</strong> brandos lygių (BL),pateikiamas 4.4 pav.Proceso sritis BL GL1 GL2 GL3 GL4 GL5Reikalavimų valdymas 2Matavimai <strong>ir</strong> analizė 2Projekto stebėjimas <strong>ir</strong> kontrolė 2Projekto planavimas 2Proceso <strong>ir</strong> produkto kokybės užtikrinimas 2Sutarties su tiekėju valdymas 2Konfigūracijos valdymas 2Sprendimų analizė <strong>ir</strong> priėmimas 3Produkto integravimas 3Reikalavimų apibrėžimas 3Techninis sprendimas 3Validavimas 3Verifikavimas 3Tikslinisprofilis2Tikslinisprofilis3Mokymo medžiaga 53
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisOrganizacinis proceso apibrėžimas 3Organizacinis dėmesys procesui 3Integruotas projekto valdymas 3Rizikos valdymas 3Organizaciniai mokymai 3Organizacinis proceso vykdymas 4Kiekybinis projekto valdymas 4Organizacinės inovacijos <strong>ir</strong> skleidimas 5Priežasčių analizė <strong>ir</strong> panaikinimas 5Tikslinisprofilis 4Tikslinisprofilis 54.4 pav. Atitikimas tarp CMMI proceso sričių gebėjimo lygių <strong>ir</strong> organizacijos brandos lygiųVertinimas pagal CMMIVertinimas gali būti atliekamas dviem pagrindiniais tikslais:- nustatyti tiekėjo gebėjimą (brandą);- proceso gerinimui atlikti.Kaip CMMI produktų šeimos dalis buvo apibrėžti reikalavimai vertinimo metodams ARC(angl. Appraisal Requ<strong>ir</strong>ements for CMMI). Išsk<strong>ir</strong>iamos 3 pagrindinės vertinimo pagal CMMImetodų klasės:KlasėA klasės vertinimometodasB klasės vertinimometodasC klasės vertinimometodasPagrindinės metodo charakteristikos Pilnai įgyvendina visus ARC reikalavimus CMMI įvertinimai yra užfiksuoti, apie juos oficialiai informuota <strong>ir</strong>jie gali būti naudojami organizacijų palyginimui Rezultatai gali būti transformuoti į ISO 15504* Dalinai įgyvendina ARC reikalavimus P<strong>ir</strong>minių vertinimo rezultatų pateikimas nebūtinas Nėra nurodymų galutinių rezultatų pateikimui Įvertinimai nėra aprašyti Rezultatai negali būti transformuoti į ISO 15504 Dalinai įgyvendina ARC reikalavimus P<strong>ir</strong>minių vertinimo rezultatų pateikimas nebūtinas Nėra nurodymų galutinių rezultatų pateikimui Įvertinimai nėra aprašyti Rezultatai negali būti transformuoti į ISO 15504 Pastebėjimų validavimas <strong>ir</strong> įrodymų pateikimas nėra būtinas Vertinimo komandos narių konsensusas nėra būtinasMokymo medžiaga 54
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelis* Būtina pažymėti, kad šiuo metu dar nėra žinoma vertinimo metodų, kurie pateiktų metodą rezultatųtransformavimui į ISO 15504. Yra netgi siūloma įvesti 2 A klasės metodų poklasius: su rezultatų atvaizdavimu įISO 15504 <strong>ir</strong> be tokio atvaizdavimo.SCAMPI: standartinis vertinimo pagal CMMI proceso gerinimui metodasVertinimas pagal SCAMPI įgalina:- nustatyti dabartinio organizacijos darbo proceso stipriąsias <strong>ir</strong> silpnąsias vietas;- sutelkti dėmesį į darbo proceso tobulinimus, kurie šiuo metu naudingiausiorganizacijai;- nustatyti organizacijos gebėjimų brandos lygį.Vertinimas pagal SCAMPI susideda iš trijų fazių <strong>ir</strong> vienuolikos esminių veiklų.Fazė1. Planavimas <strong>ir</strong>pas<strong>ir</strong>uošimas vertinimui2. Vertinimas3. Rezultatų pateikimasVeiklos1.1 Reikalavimų analizė1.2 Planavimas1.3 Komandos subūrimas <strong>ir</strong> paruošimas1.4 Reikiamų duomenų nustatymas1.5 Pas<strong>ir</strong>uošimas duomenų rinkimui2.1 Duomenų rinkimas2.2 Gautų duomenų tikrinimas <strong>ir</strong> įvertinimas2.3 Surinktos informacijos dokumentavimas2.4 Vertinimo rezultatų generavimas3.1 Vertinimo rezultatų paskelbimas3.2 Vertinimo rezultatų <strong>ir</strong> aprašų surinkimas <strong>ir</strong> perdavimas į archyvąReikalavimų analizės tikslas - nustatyti organizacijos verslo poreikius <strong>ir</strong> susieti vertinimotikslus su organizacijos verslo tikslais. Reikalavimų analizė numato vertinimo tikslų, apribojimų(terminai, finansavimas <strong>ir</strong> kt.), apimties <strong>ir</strong> rezultatų nustatymą.Planavimas apima reikalavimų (reikalingų resursų), susitarimų <strong>ir</strong> rizikų, susijusių suvertinimu, dokumentavimą, darbų grafiko sudarymą.Komandos subūrimo <strong>ir</strong> paruošimo tikslas – užtikrinti, kad komanda gali <strong>ir</strong> yra pas<strong>ir</strong>uošusiatlikti vertinimą. Veikla numato 3 žingsnius: nustatyti lyderį, parinkti komandos narius, paruoštikomandą vertinimui (komandos nariai turi susipažinti su SCAMPI metodika, vertinimo planu <strong>ir</strong>pan.).Reikiami duomenys – duomenys, betarpiškai reikalingi galutiniam įvertinimui gauti, o taippat palengvinantys pas<strong>ir</strong>uošimą vertinimui, padedantys suprasti, kaip vyksta organizacijos darboprocesas. Reikiamų duomenų nustatymas apima vertinimo procesui reikalingų duomenų <strong>ir</strong>Mokymo medžiaga 55
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisinstrumentų (anketų, duomenų bazių <strong>ir</strong> t.t.) dokumentavimas (sąrašo sudarymas), roliųkomandoje pask<strong>ir</strong>stymą.Pas<strong>ir</strong>uošimas duomenų rinkimui numato reikiamų duomenų šaltinių nustatymą,instrumentų <strong>ir</strong> technologijų, kurias nuspręsta naudoti, aprašymą (pvz. anketų sudarymą) beiplano sudarymą. Pagal šį planą yra vykdomas duomenų rinkimas iš visų numatytų šaltinių(dokumentų, pristatymų, instrumentų, apklausų).Iš surinktų duomenų nustatoma, kaip yra realizuotos visos organizacijos veiklos,sudaromos preliminarios išvados, aprašomi <strong>ir</strong> įvertinami veiklų realizavimo trūkumai.Kiekvienos veiklos realizavimas įvertinamas taip, kad jį būtų galima palyginti su CMMIveiklomis. Yra keturi galimi įvertinimai:• veikla yra pilnai realizuota, jeigu:o egzistuoja tiesioginiai veiklos produktai <strong>ir</strong> jie pripažinti (vertinimo komandos)tinkamais;o yra bent vienas netiesioginis veiklos produktas ar veiklos įgyvendinimo patv<strong>ir</strong>tinimas;o veiklos įgyvendinime nepastebėta nei vieno esminio trūkumo;• veikla yra didžia dalimi realizuota, jeigu:o egzistuoja tiesioginiai veiklos produktai <strong>ir</strong> jie pripažinti (vertinimo komandos)tinkamais;o yra bent vienas netiesioginis veiklos produktas ar veiklos įgyvendinimo patv<strong>ir</strong>tinimas;o veiklos įgyvendinime pastebėta vienas ar daugiau trūkumų;• veikla yra iš dalies realizuota, jeigu:o tiesioginiai veiklos produktai neegzistuoja, arba jie pripažinti netinkamais;o yra bent vienas netiesioginis veiklos produktas ar veiklos įgyvendinimo patv<strong>ir</strong>tinimas;o veiklos įgyvendinime pastebėta vienas ar daugiau trūkumų;• visais kitais atvejais veikla yra nerealizuota.Surinkta informacija yra pertvarkoma į dokumentus, kurie aprašo organizacijos veiklųrealizavimą, silpnąsias (trūkumus) <strong>ir</strong> stipriąsias vietas. Surinktos informacijos dokumentavimoveikla taip pat numato duomenų rinkimo plano peržiūrą <strong>ir</strong> (jeigu reikia) taisymą.Organizacijos gebėjimų brandos vertinimas susideda iš keturių etapų:- CMMI praktikų realizavimo charakteristika (projekto lygyje);- CMMI praktikų realizavimo charakteristika (organizacijos lygyje);- praktikų tikslų realizavimo įvertinimas;- gebėjimų <strong>ir</strong>/ar brandos lygio įvertinimas.Visi daromi pastebėjimai <strong>ir</strong> charakteristikos yra fiksuojami raštu. P<strong>ir</strong>miausia yranagrinėjamos silpnosios proceso veiklų vietos, lyginant su atitinkamų CMMI modelio praktikųMokymo medžiaga 56
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelistikslais. Stipriųjų vietų apžvalga turi apimti tik tas realizuotas proceso veiklas, kurios yraišsk<strong>ir</strong>tinai efektyvios, „nereikalingos“ stipriosios vietos, kurios tik pavaizduoja pakankamąpraktikų realizavimą, gali stipriai apsunkinti duomenų valdymą. Gali būti nagrinėjamos <strong>ir</strong>veiklos, naudojamos kaip alternatyva CMMI praktikoms <strong>ir</strong> padedančios pasiekti atitinkamosproceso srities tikslus.Vertinimo rezultatų generavimas. Remiantis visa surinkta informacija yra vertinamaskiekvieno CMMI tikslo pasiekiamumas. Tikslas yra pasiektas, jeigu:- visos susijusios su tuo tikslu veiklos organizacijoje yra pilnai ar didžia dalim<strong>ir</strong>ealizuotos, <strong>ir</strong>- trūkumai, susiję su tuo tikslu, neturi reikšmingos įtakos tikslo pasiekiamumui.Vertinimo rezultatų paskelbimo tikslas – pateikti organizacijos vadovybei patikimus atliktovertinimo rezultatus, kurie gali naudojami tolimesnių sprendimų priėmimui, pristatyti dabartinioorganizacijos darbo proceso stipriąsias <strong>ir</strong> silpnąsias vietas, pateikti darbo proceso brandosįvertinimą.Vertinimo rezultatai, organizacijos pageidavimu, tampa konfidencialia informacija. TodėlSCAMPI numato vertinimo rezultatų surinkimo <strong>ir</strong> perdavimo į organizacijos archyvą procedūrą.Literatūra papildomam skaitymui[SWc02][SWs02][SEc02][SEs02][IPPDc02]Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for SoftwareEngineering, Continuous Representation (CMU/SEI-2002-TR-028). Pittsburgh,PA: Software Engineering Institute, Carnegie Mellon University, 2002.Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for SoftwareEngineering, Staged Representation (CMU/SEI-2002-TR-029). Pittsburgh, PA:Software Engineering Institute, Carnegie Mellon University, 2002.Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for SystemsEngineering and Software Engineering, Continuous Representation (CMU/SEI-2002-TR-001). Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, 2002.Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for SystemsEngineering and Software Engineering, Staged Representation (CMU/SEI-2002-TR-002). Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, 2002.Capability Maturity Model Integration (CMMI), Version 1.1 CMMI for SystemsEngineering/Software Engineering/Integrated Product and Process Development,Mokymo medžiaga 57
Programų sistemų inžinerija4. Integruotas gebėjimo brandos modelisContinuous Representation (CMU/SEI-2002-TR-003). Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University, 2002.[IPPDs02][SSc02][SSs02][ARC01][SCA01][KJ03]Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for SystemsEngineering/Software Engineering/Integrated Product and Process Development,Staged Representation (CMU/SEI-2002-TR-004). Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University, 2002.Capability Maturity Model Integration (CMMI), Version 1.1 CMMI for SystemsEngineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Continuous Representation (CMU/SEI-2002-TR-011).Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for SystemsEngineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Staged Representation (CMU/SEI-2002-TR-012). Pittsburgh,PA: Software Engineering Institute, Carnegie Mellon University, 2002.Appraisal Requ<strong>ir</strong>ements for CMMI, Version 1.1 (ARC, V1.1) (CMU/SEI-2001-TR-034) Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, 2001.Standard CMMI® Appraisal Method for Process Improvement (SCAMPI),Version 1.1: Method Definition Document (CMU/SEI-2001-HB-001) Pittsburgh,PA: Software Engineering Institute, Carnegie Mellon University, 2001.M.K. Kulpa, K.A. Johnson, Interpreting the CMMI: A Process ImprovementApproach. Auerbach Publications, 2003, ISBN: 0849316545Mokymo medžiaga 58
Programų sistemų inžinerija5. Programų kūrimo proceso modelių sąryšis5. Programų kūrimo proceso modelių sąryšisDu pagrindiniai programų kūrimo proceso vertinimo <strong>ir</strong> gerinimo modeliai yra CMMI <strong>ir</strong>ISO/IEC 15504. CMMI pakopinės architektūros modelis pateikia standartinį proceso gerinimokelią <strong>ir</strong> patrauklų bei paprastą organizacijos programų kūrimo proceso brandos matą.ISO/IEC 15504 užtikrina organizacijos programų kūrimo procesų gebėjimo detalaus profiliosudarymo galimybę <strong>ir</strong> įgalina individualų programų kūrimo procesų gerinimo kelią.Priklausomai nuo veiklos tikslų organizacijos pas<strong>ir</strong>enka pakopinės ar tolydinėsarchitektūros modeliu paremtą programų kūrimo proceso gerinimo kelią. Tačiau net <strong>ir</strong> pas<strong>ir</strong>inkęvieną iš modelių, organizacijos nori pasinaudoti kito modelio teikiamais privalumais.Pavyzdžiui, organizacija pas<strong>ir</strong>inkusi pakopinį gerinimo kelią, kur vienos pakopos siekimotrukmė tęsiasi iki 2 metų, smulkesnių žingsnių atlikimui gali pas<strong>ir</strong>emti tolydiniu procesųmodeliu. Antra vertus, organizacija taikanti tolydinį veiklos gerinimo modelį, kuris operuojaprocesų gebėjimo profiliu, gali norėti savo veiklos brandą pasilyginti paprastu brandos lygiomatu, o taip pat gali norėti pasinaudoti CMMI siūlomu standartiniu organizacijos programųkūrimo proceso gerinimo keliu.ISO/IEC 15504CMMIProcessProcess AreaPA1.1Specific PracticeOutcomePA2-PA5Generic PracticeAchievement5.1 pav. Modelių sąryšio schemaIšnagrinėjus atitinkamybę tarp CMMI brandos lygių <strong>ir</strong> ISO/IEC 15504 procesų gebėjimųprofilių, remiantis Software Quality Institute (Australija) mokslininkų darbais [RTC01], vis darMokymo medžiaga 59
Programų sistemų inžinerija5. Programų kūrimo proceso modelių sąryšiscituojamais naujausiose knygose [Loo04a, Loo04b], gauti nauji rezultatai, patikslinantysatitinkamybę tarp CMMI brandos lygių <strong>ir</strong> ISO/IEC 15504 procesų gebėjimų profilių [MR06].Supaprastinta modelių struktūra <strong>ir</strong> sąryšiai tarp jų elementų, naudojami atvaizdavimui,pateikti 5.1 paveikslėlyje.Darbe [RTC01] nustatomas aukšto lygio sąryšis tarp CMMI brandos lygių <strong>ir</strong>ISO/IEC 15504 procesų gebėjimo profilių (žiūr. 5.2 pav.: “ML” yra CMMI pakopinėsarchitektūros modelio brandos lygiai, “CL1”-“CL5” yra ISO/IEC 15504 gebėjimo lygiai).Sąryšis aukšto lygio, nes sudaromas pagal tokią taisyklę:ISO/IEC 15504 procesas prisk<strong>ir</strong>iamas “brandos lygio N” profiliui, jei jo gebėjimo lygis yra NMokymo medžiaga 60
Programų sistemų inžinerija5. Programų kūrimo proceso modelių sąryšis5.2 pav. ISO/IEC 15504 procesų gebėjimo profiliai, atitinkantys CMMI brandos lygius [RTC01]Todėl į gebėjimo profilius nėra įtraukti procesai, kurie nepasiekia atitinkamo lygio, norsdalis jų rezultatų (outcomes) <strong>ir</strong> pasiekimų (achievements) yra užtikrinami atitinkamo brandoslygio CMMI proceso sritimis. Norėtųsi detalesnio modelių atvaizdavimo, kuris parodytų tiksliusgebėjimo profilius, kuriuos užtikrina CMMI brandos lygiai.Be to, kyla abejonės dėl 4-o <strong>ir</strong> 5-o brandos lygio atvaizdavimo, nes remiantis sąryšiu tarpCMMI pakopinio <strong>ir</strong> tolydinio modelių galima teigti, kad 4-as <strong>ir</strong> 5-as brandos lygiai negaligarantuoti 4-o ar 5-o gebėjimo lygio nė vienai proceso sričiai, taigi natūralu, kad <strong>ir</strong> nė vienamISO/IEC 15504 modelio procesui. Žinoma, realioje 4-o ar 5-o brandos lygio organizacijoje turėtųbūti 4-o <strong>ir</strong> 5-o gebėjimo lygio proceso sričių/procesų, bet pats CMMI pakopinis modelisnesuteikia pakankamai informacijos nustatymui, kokios konkrečios proceso sritys/procesai bus4-o <strong>ir</strong> 5-o gebėjimo lygio.5.3 pav. Patikslinti ISO/IEC 15504 procesų gebėjimo profiliai, atitinkantys CMMI brandos lygius [MR06]Mokymo medžiaga 61
Programų sistemų inžinerija5. Programų kūrimo proceso modelių sąryšisRemiantis ta pačia CMMI proceso sričių atvaizdavimo į ISO/IEC 15504 proceso dimensijąschema, procesų vykdymas (1-as gebėjimo lygis) <strong>ir</strong> gebėjimo atributų pasiekimas buvo įvertintiprocentais, darant prielaidą, kad visi procesų rezultatai (outcomes) <strong>ir</strong> pasiekimai turi vienodussvorius.Proceso atributų (PA) pasiekimas įvertintas procentais (N – iki 15 %, P – nuo 15 % iki50 %, L – nuo 50 % iki 85 %, F - v<strong>ir</strong>š 85 %) <strong>ir</strong> šių įvertinimų pagrindu nustatyti procesųgebėjimo lygiai.Patikslinti ISO/IEC 15504 procesų gebėjimo profiliai, atitinkantys CMMI brandos lygiuspateikti 5.3 pav.Darytina bendra išvada, kad pakopinės architektūros modeliai yra atsk<strong>ir</strong>as atvejis tolydinėsarchitektūros modelių, nes pakopinės architektūros brandos lygiai gali būti išreikšti tolydinėsarchitektūros modelių procesų gebėjimo profiliais. Šių dviejų architektūrų modeliai gali būtisuderinti: smulkius gerinimo veiksmus valdant tolydinio modelio priemonėmis, o sudarytigerinimo veiksmų programą <strong>ir</strong> fiksuoti etapinius brandos pasiekimus remiantis pakopinėsarchitektūros modeliais.Literatūra papildomam skaitymui[MR06]A. Mitasiunas, S. Ragaisis, Relationship between CMMI Maturity Levels andISO/IEC 15504 Processes Capability Profiles, 2006.[RTC01] T.P.Rout, A.Tuffley, B.Cahill. CMMI Evaluation: Capability Maturity ModelIntegration Mapping to ISO/IEC 15504 2:1998, Software Quality Institute, GriffithUniversity, Brisbane, 2001.[Loo04a] H.V. Loon, Process Assessment and Improvement. A practical guide for managers,quality professionals and assessors. Springer, 2004.[Loo04b] H.V. Loon, Process Assessment and ISO/IEC 15504. A Reference Book. Springer,2004.Mokymo medžiaga 62
Programų sistemų inžinerija6. Projektas PKP Branda6. Projektas PKP BrandaŠiame skyriuje aptariami Vilniaus universiteto, Kauno technologijos universiteto <strong>ir</strong>p<strong>ir</strong>maujančių Lietuvos IT įmonių „Alna“ <strong>ir</strong> „Sintagma“ atlikto projekto „Brandaus programųkūrimo proceso įdiegimo metodikos <strong>ir</strong> instrumentinių priemonių sukūrimas (PKP Branda)“[VU05] rezultatai. Projektą rėmė Lietuvos valstybinio mokslo <strong>ir</strong> studijų fondas pagal „Aukštųjųtechnologijų plėtros programą“, kurios pagrindinis tikslas buvo sudaryti sąlygas Lietuvosįmonėms eksportuoti produktus <strong>ir</strong> paslaugas.Vienas iš projekto rezultatų yra brandaus programų kūrimo proceso modelis, sukurtasorientuojantis į programų kūrimo proceso vertinimą <strong>ir</strong> gerinimą Lietuvos IT įmonėse. Jam buvoparinkta tolydinė architektūra, nes ji geriau tinkama proceso gerinimui.Brandaus programų kūrimo proceso modelisBrandaus programų kūrimo proceso modelio pask<strong>ir</strong>tis – suteikti pagrindą procesoapibrėžimui <strong>ir</strong> vertinimui, užtikrinant, kad proceso apibrėžimas bei vertinimo rezultatai remiasiprogramų kūrimo proceso inžinerijos geriausia pat<strong>ir</strong>timi, yra sulyginami su kitų vertinimųrezultatais bei dera su pasaulyje pripažintais standartais.Per paskutinius metus įvyko esminė evoliucija programų kūrimo proceso vertinimo <strong>ir</strong>gerinimo standartizacijoje. Evoliucijos kryptis – abstrahavimasis nuo programų kūrimo proceso<strong>ir</strong> aplamai nuo konkrečių vertinamų procesų <strong>ir</strong> akcentavimas procesų vertinimo, paliekantproceso gerinimo aspektus informatyviame lygmenyje.Šios evoliucijos pasekoje priimta procesų vertinimo standarto dalis ISO/IEC 15504-2bendroji dalis, kurioje apibrėžta vertinamų procesų gebėjimo (brandos) dimensija, suformuluot<strong>ir</strong>eikalavimai vertinamų procesų dimensijai <strong>ir</strong> vertinimo modeliui, susiejančiam vertinamųprocesų dimensiją su procesų gebėjimo dimensija. Programų kūrimo proceso dimensija, buvusiankstesnių versijų standarto ISO/IEC 15504 sudėtine dalimi, pašalinta iš šio standarto <strong>ir</strong> perėjo įadaptuotą programų kūrimo proceso gyvavimo ciklo standartą ISO/IEC 12207:2002 amd1 <strong>ir</strong>ISO/IEC 12207:2004 amd2.ISO/IEC 15504-2 reikalavimus vertinamų procesų dimensijai taip pat tenkina sistemųgyvavimo ciklo standartas ISO/IEC 15288.Procesų gebėjimo vertinimui turi būti naudojamas dvidimensinis modelis, tenkinantisISO/IEC 15504-2 reikalavimus procesų gebėjimo vertinimo modeliui. Pagrindinis reikalavimasnaudojamam vertinimo modeliui yra gebėjimo dimensijoje apimti ištisinę sritį, pradedantp<strong>ir</strong>muoju lygiu, o procesų dimensijoje apimti bent vieną vertinamą procesą. Pavyzdinisprogramų kūrimo procesų gebėjimo vertinimo modelis yra rengiamas kaip standarto dalisISO/IEC 15504-5, o pavyzdinis sistemų kūrimo procesų gebėjimo vertinimo modelis yraMokymo medžiaga 63
Programų sistemų inžinerija6. Projektas PKP Brandarengiamas kaip standarto dalis ISO/IEC 15504-6. Standarto dalis ISO/IEC 15504-5 turėjopas<strong>ir</strong>odyti 2005 metais, o ISO/IEC 15504-6 – 2006 metais.Brandaus programų kūrimo proceso modelis atitinka ISO/IEC 12207:2002 procesųdimensiją, tenkina ISO/IEC 15504-2 reikalavimus procesų gebėjimo vertinimo modeliui <strong>ir</strong> yrasuderinamas su pavyzdiniu programų kūrimo proceso vertinimo modeliu ISO/IEC 15504-5.PKP Branda programųkūrimo proceso modelisProcesų dimensijaBrandos dimensijaProcesųkategorijosGebėjimolygiaiProcesaiProcesoatributaiBazinėspraktikosDarboproduktaiBendrosiospraktikosBendrinia<strong>ir</strong>esursaiBendriniaidarbo produktai6.1 pav. PKP Branda programų kūrimo proceso modelio architektūraModelyje visuminio proceso veiklos grupuojamos į vardinius procesus. Vardiniai procesaiapibrėžiami jiems keliamais tikslais <strong>ir</strong> tuos tikslus įgyvendinančiomis veiklomis, modelyjevadinamomis bazinėmis praktikomis. Taip pat su kiekvienu vardiniu procesu asocijuojamisukuriami <strong>ir</strong> naudojami darbo produktai.Kiekvieno vardinio proceso gebėjimo lygis nustatomas pagal bendrinių procesocharakteristikų, esminių proceso gebėjimui užtikrinti, buvimą. Bendrinės procesocharakteristikos modelyje vadinamos proceso atributais <strong>ir</strong> apibrėžiamos bendrosiomispraktikomis, bendriniais resursais bei susijusiais darbo produktais, kurie padeda pasiekti procesocharakteristikas.Brandaus programų kūrimo proceso charakteristikos išsk<strong>ir</strong>iamos į proceso <strong>ir</strong> brandosdimensijas. Proceso dimensija apibrėžiama, nusakant programų kūrimo procesų kategorijas,pačius vardinius procesus, procesų tikslus, bazines praktikas <strong>ir</strong> darbo produktus. Brandosdimensija apibrėžiama proceso atributais, kuriais turi pasižymėti vardiniai procesai <strong>ir</strong> kurieMokymo medžiaga 64
Programų sistemų inžinerija6. Projektas PKP Brandamodeliuoja minėtas išmatuojamas proceso charakteristikas, įgyvendinamas bendrosiomispraktikomis, bendriniais resursais <strong>ir</strong> susijusiais darbo produktais.Brandaus programų kūrimo proceso modelio proceso dimensiją sudaro 9 procesųkategorijos <strong>ir</strong> 48 vardiniai procesai:ACQ.1 Pas<strong>ir</strong>uošimas įsigijimuiENG.1 Reikalavimų išsiaiškinimasACQ.2 Tiekėjo pas<strong>ir</strong>inkimasENG.2 Sistemos reikalavimų analizėACQ.3 Susitarimas dėl kontrakto ENG.3 Sistemos architektūros projektavimasACQ.4 Tiekėjo stebėjimasENG.4 Programinės įrangos reikalavimų analizėACQ.5 Kliento apsisprendimasENG.5 Programinės įrangos projektavimasSPL.1 Tiekėjo pasiūlymaiENG.6 Programinės įrangos projekto realizavimasSPL.2 Produkto laidaENG.7 Programinės įrangos integravimasSPL.3 Produkto priėmimo palaikymas ENG.8 Programinės įrangos testavimasOPE.1 Eksploatacinis naudojimas ENG.9 Sistemos integravimasOPE.2 Kliento palaikymasENG.10 Sistemos testavimasSUP.1 Kokybės užtikrinimasENG.11 Programinės įrangos instaliavimasSUP.2 VerifikavimasENG.12 Programinės įrangos <strong>ir</strong> sistemos priežiūraSUP.3 ValidavimasMAN.1 Organizacijos vieningumo užtikrinimasSUP.4 Jungtinės peržiūrosMAN.2 Organizacijos valdymasSUP.5 AuditasMAN.3 Projekto valdymasSUP.6 Produkto vertinimasMAN.4 Kokybės valdymasSUP.7 DokumentavimasMAN.5 Rizikos valdymasSUP.8 Konfigūracijos valdymasMAN.6 MatavimaiSUP.9 Problemų sprendimo valdymas PIM.1 Proceso įtv<strong>ir</strong>tinimasSUP.10 Keitimų poreikio valdymas PIM.2 Proceso vertinimasRIN.1 Personalo vadybaPIM.3 Proceso gerinimasRIN.2 ApmokymaiREU.1 Inventoriaus valdymasRIN.3 Žinių valdymasREU.2 Pakartotinio panaudojimo valdymasRIN.4 InfrastruktūraREU.3 Dalykinės srities inžinerijaModelio brandos dimensiją sudaro 6 lygiai <strong>ir</strong> 9 atributai:0 lygis: Nevykdomas -1 lygis: Vykdomas PA1.1 Proceso atlikimo atributas2 lygis: Valdomas PA2.1 Proceso atlikimo valdymo atributasPA2.2 Darbo produktų valdymo atributas3 lygis: Apibrėžtas PA3.1 Proceso apibrėžimo atributasMokymo medžiaga 65
Programų sistemų inžinerija6. Projektas PKP BrandaPA3.2 Proceso paplitimo atributas4 lygis: Nusakomas PA4.1 Proceso matavimo atributasPA4.2 Proceso kontroliavimo atributas5 lygis: Optimizuojamas PA5.1 Proceso inovatyvumo atributasPA5.2 Proceso gerinimo atributasProgramų kūrimo proceso gerinimo metodikaProceso gerinimo iniciatyva gali ats<strong>ir</strong>asti bet kuriame organizacijos hierarchiniame lygyje,tačiau bet kuriuo atveju būtinas vadovybės dalyvavimas, nes be jo proceso gerinimui nebussuteiktas reikiamas prioritetas <strong>ir</strong> nebus užtikrinti būtini resursai.Proceso gerinimas reikalauja einamojo proceso supratimo <strong>ir</strong> aiškių gerinimo tikslų. Tam,kad proceso gerinimas būtų sėkmingas, reikia investicijų, planavimo, dedikuotų žmonių,vadovybės laiko <strong>ir</strong> pastangų. Proceso gerinimas turi teikti naudą organizacijai <strong>ir</strong> suinteresuotumądalyvaujantiems žmonėms. Gerinimas turi būti pastovus, evoliucionuojantis, apimantis visusorganizacijos darbuotojus <strong>ir</strong> nuolatinį mokymąsi. Proceso pakeitimai nebus išlaikyti besąmoningų pastangų <strong>ir</strong> reguliaraus palaikymo. Organizacijos poreikiai <strong>ir</strong> verslo tikslai nusakoproceso gerinimo tikslus <strong>ir</strong> padeda nustatyti gerinimo prioritetus.Organizacijoms, siekiančioms pagerinti savo programų kūrimo procesą, siūloma naudotiproceso gerinimo programą, sudarytą iš 8 pagrindinių žingsnių:Nagrinėti organizacijosverslo tikslusInicijuotiprocesogerinimąAtliktiprocesovertinimąStebėtiprocesovykdymąSudarytiveiksmųplanąPaskleistiprocesopakeitimusPatv<strong>ir</strong>tintiprocesopakeitimusĮgyvendintigerinimoveiksmus6.2 pav. Programų kūrimo proceso gerinimo schemaToks ciklas yra sk<strong>ir</strong>tas planingam, nuosekliam <strong>ir</strong> valdomam organizacijos procesogerinimui (pavienis proceso pakeitimas gali būti atliktas paprasčiau). Apibrėžti žingsniai yraMokymo medžiaga 66
Programų sistemų inžinerija6. Projektas PKP Brandaesminiai sėkmingam proceso gerinimui, bet taikant mažose organizacijose kai kurie žingsniaigali būti apjungti.Nagrinėti organizacijos verslo tikslusProgramų kūrimo proceso gerinimas turi remtis organizacijos verslo tikslais <strong>ir</strong> padėti juospasiekti, todėl prieš pradėdama proceso gerinimą, organizacija turi išanalizuoti savo poreikius <strong>ir</strong>nustatyti verslo tikslus, jei tai nebuvo padaryta. Ši analizė padeda identifikuoti proceso gerinimoporeikį <strong>ir</strong> ko bus siekiama.Labai svarbu turėti gerinimo „sponsorių“ organizacijos vadovybėje, kad užtikrinti finansinį<strong>ir</strong> motyvuojantį palaikymą, todėl organizacijos verslo tikslų nustatymą tikslinga pradėtisusitikimu su vadovybe.Organizacijos verslo tikslai tradiciškai yra susiję su užsakovų pasitenkinimo siekimu,organizacijos konkurencingumo <strong>ir</strong> verslo vertės didinimu. Šie verslo tikslai gali būti pasiekiami:didinant produktų <strong>ir</strong> paslaugų kokybę, mažinant kūrimo <strong>ir</strong> palaikymo sąnaudas, pagreitinantprojektų atlikimą, gerinant proceso valdymą, mažinant sk<strong>ir</strong>tumus tarp vykdomų projektų.Proceso gerinimo inicijavimo veiksniais gali būti: užsakovų nepasitenkinimas dėl vėluojančiųprojektų <strong>ir</strong> klaidų pateiktuose produktuose, per dideli projektų kaštai, noras pagerinti turimųresursų panaudojimą <strong>ir</strong> organizacijos veiklos efektyvumą.Reikia susieti aukšto lygio verslo tikslus su proceso tikslais <strong>ir</strong> jo gerinimo poreikiais,nustatyti, kurios proceso problemos (kuriamų produktų kokybės, projektų kainos ar vėlavimo)organizacijai opiausios.Prieš pradedant gerinimą, reikia susipažinti su programų kūrimo proceso modeliu, kuriuobus remiamasi (rekomenduojamas modelis PKP Branda).Vadovybės palaikymas yra būtina, bet nepakankama sąlyga sėkmingam proceso gerinimui.Būtina rasti proceso gerinimo lyderius – žmones, kurie nori <strong>ir</strong> įsipareigoja diegti procesopakeitimus. Reikia įvertinti, ar organizacijoje nusistovėjusi pripažinimo <strong>ir</strong> skatinimo sistemapalaikys gerinime dalyvaujančius darbuotojus, ar organizacinė kultūra palanki procesogerinimui.Jei organizacija yra nepas<strong>ir</strong>uošusi proceso gerinimui, geriau jį atidėti.Labai svarbu, kad tiek organizacijos vadovybė, tiek darbuotojai nedėtų nepagrįstų vilčių,visi jie turi suprasti, kad proceso gerinimas negali duoti efekto tuoj pat, kad tai ilgalaikis <strong>ir</strong>reikalaujantis investicijų procesas, kad diegiant proceso pakeitimus teks įveikti organizacines,kultūrines <strong>ir</strong>, galbūt, technologines kliūtis. Proceso gerinimui pristatyti reikia organizuotisusitikimus su vadovybe <strong>ir</strong> dalyvausiančiais darbuotojais.Mokymo medžiaga 67
Programų sistemų inžinerija6. Projektas PKP BrandaOrganizacijos verslo tikslai yra pakankamai pastovūs <strong>ir</strong> kiekvienoje gerinimo cikloiteracijoje nebūtina juos iš naujo nagrinėti, tačiau laikas nuo laiko jie turėtų būti peržiūrimi <strong>ir</strong>pr<strong>ir</strong>eikus atnaujinami.Šio žingsnio rezultatai yra:- identifikuoti organizacijos aukščiausio lygio verslo tikslai;- verslo tikslai susieti su proceso tikslais <strong>ir</strong> jo gerinimo poreikiais;- įvertintas organizacijos pas<strong>ir</strong>engimas proceso gerinimui (užsitikrinta vadovybės parama,nustatyti proceso gerinimo lyderiai, darbuotojai supažindinti su proceso gerinimu).Inicijuoti proceso gerinimąProceso gerinimas turi būti atliekamas kaip projektas su nustatytais tikslais, prisk<strong>ir</strong>taisresursais, projekto planu <strong>ir</strong> valdymu, kontroliniais taškais. Svarbu, kad šiam projektuiorganizacijoje būtų suteiktas pakankamai aukštas prioritetas, nes kitu atveju einamieji programųsistemų kūrimo projektai neleis jo sėkmingai įgyvendinti.Projekto planas turi apimti visus kitus gerinimo ciklo žingsnius. Turi būti sudarytasproceso gerinimo projekto Priežiūros komitetas, kuris seka projekto eigą <strong>ir</strong> užtikrina resursus.Priežiūros komitetas sudaromas iš vadovybės atstovo (gerinimo „sponsoriaus“), procesogerinimo projekto vadovo <strong>ir</strong> atsakingų už resursų skyrimą. Mažose organizacijose priežiūroskomitetas gali būti <strong>ir</strong> iš 2 žmonių.Priežiūros komitetas suformuoja proceso gerinimo projekto komandą. Būtų tikslinga įkomandą įtraukti kuo daugiau žmonių, bet reikia įvertinti teigiamą didesnio skaičiaus žmoniųįtraukimo poveikį <strong>ir</strong> išaugančias sąnaudas. Be to, didelei komandai bus sudėtinga reguliariaisus<strong>ir</strong>inkti. Todėl netgi didelėse organizacijose komanda neturėtų būti sudaryta iš daugiau kaip 8žmonių, o labai mažose organizacijose ji netgi gali būti sudaryta iš tų pačių 2 žmonių kaip <strong>ir</strong>Priežiūros komitetas.Atliekant proceso gerinimą p<strong>ir</strong>mą kartą, kad geriau susivokti esamoje situacijoje, sudarytisąlygas vertinimui <strong>ir</strong> tolimesniems proceso pakeitimams, reikia:- apibūdinti organizacijoje vykdomą programų kūrimo veiklą;- sudaryti einamąjį organizacijos veiklos modelį;- atvaizduoti organizacijos veiklos modelį į PKP Branda modelį.Einamojo organizacijos veiklos modelio apibrėžimas turėtų susidėti iš tipinių organizacijosprojektų gyvavimo ciklo modelio aprašymo:produktus;- nurodant vykdomus procesus, jų bazines praktikas, naudojamus <strong>ir</strong> sukuriamus darbo- pateikiant naudojamų <strong>ir</strong> sukuriamų darbo produktų charakteristikas (aprašymus).Mokymo medžiaga 68
Programų sistemų inžinerija6. Projektas PKP BrandaRealios organizacijos veiklos atvaizdavimas į PKP Branda modelį padeda suderintisąvokas (rasti atitikmenis tarp organizacijoje naudojamų <strong>ir</strong> modelio sąvokų), labiau struktūrizuoti<strong>ir</strong> detalizuoti organizacijos veiklos apibrėžimą (kai kurie organizacijos veiklos aspektai yra tarsisavaime suprantami <strong>ir</strong> todėl gali likti neįtraukti į veiklos modelį). Net jei organizacijos <strong>ir</strong>vertinimo modelio procesų apibrėžimai panašūs, pravartu turėti išreikštinai dokumentuotą jųatitikimą. Jeigu organizacijos procesai bei naudojama terminologija smarkiai sk<strong>ir</strong>iasi nuomodelio, tai parengti detalų organizacijos veiklos atvaizdavimą į modelio procesus yra tiesiogbūtina, kadangi vertinimas atliekamas pagal modelio procesų apibrėžimus <strong>ir</strong> reikia aiškiai žinoti,kurios organizacijos veiklos atitinka modelyje apibrėžtų procesų veiklas. Organizacijos veiklosatvaizdavimas į PKP Branda modelį parengiamas procesų darbo produktų lygmenyje.Rekomenduojama organizacijos veiklos konkretizavimą <strong>ir</strong> atvaizdavimą į PKP Brandamodelį daryti iteratyviai.Atlikti proceso vertinimąProceso vertinimo metu nustatomas organizacijos procesų gebėjimo profilis <strong>ir</strong> kartusurenkama procesų būklės medžiaga, kurios pagrindu galima nustatyti gerinimo veiksmus <strong>ir</strong>prioritetus.Prieš pradedant proceso vertinimą, nustatoma vertinimo apimtis: kokie procesai <strong>ir</strong> iki kuriogebėjimo lygio bus vertinami. Vertinimo apimtį gali tekti nustatyti tiek organizacijosnaudojamais procesų terminais, tiek PKP Branda modelio procesų terminais (organizacijos –tam, kad būtų natūraliai suprantama organizacijos atstovams, modelio terminais – vertinimotikslais). Vertinimo apimties apibrėžime fiksuojama vertinimo apimtis PKP Branda modelioterminais.Lietuvoje yra aktualu visų p<strong>ir</strong>ma gerinti programinės įrangos gyvavimo ciklo pagrindinius(inžinerinius) procesus, apimančius programinės įrangos kūrimą (ENG.1, ENG.4, ENG.5,ENG.6, ENG.7, ENG.8, ENG.11) <strong>ir</strong> priežiūrą (ENG.12). Tam, kad programinės įrangos kūrimoinžineriniai procesai galėtų pasiekti antrą gebėjimo lygį, yra būtina, kad jų atlikimą <strong>ir</strong> valdymąparemtų organizacinių procesų <strong>ir</strong> pagalbinių procesų kategorijų procesai.Minimalų būtiną tokių procesų rinkinį sudaro Projektų valdymo procesas (MAN.3) <strong>ir</strong>pagalbiniai procesai: Konfigūracijos valdymas (SUP.8), Kokybės užtikrinimas (SUP.1) <strong>ir</strong>Problemų sprendimo valdymas (SUP.9). Daugumos Lietuvos IT įmonių tikslinis procesųgebėjimo profilis artimiausių 2-3 metų laikotarpiui yra parodytas lentelėje:ProcesasSiekiamas lygisENG.1 Reikalavimų išsiaiškinimas 2ENG.4 Programinės įrangos reikalavimų analizė 2Mokymo medžiaga 69
Programų sistemų inžinerija6. Projektas PKP BrandaENG.5 Programinės įrangos projektavimas 2ENG.6 Programinės įrangos projekto realizavimas 2ENG.7 Programinės įrangos integravimas 2ENG.8 Programinės įrangos testavimas 2ENG.11 Programinės įrangos instaliavimas 2ENG.12 Programinės įrangos <strong>ir</strong> sistemos priežiūra 2MAN.3 Projekto valdymas 1SUP.1 Kokybės užtikrinimas 1SUP.8 Konfigūracijos valdymas 1SUP.9 Problemų sprendimo valdymas 1Jei organizacija turi tikslą sertifikuoti savo programų kūrimo procesą antram CMMIpakopinės architektūros lygiui, į vertinimą galėtų būti įtraukti visi procesai, susiję su antro lygioCMMI proceso sritimis. Toks procesų sąrašas buvo nustatytas pakopinės <strong>ir</strong> tolydinėsarchitektūros modelių sąryšio tyrimais.Pas<strong>ir</strong>inkus vertinamų procesų rinkinį, kiekvieno proceso vertinimas techniškai yra panašus– kiekvienam procesui, pagal siekiamą nustatyti gebėjimą, tikrinama kokiais proceso atributaisjis pasižymi.Vertinimo modelis reikalauja, kad, norint nustatyti (arba įrodyti), jog vertinamas procesasyra p<strong>ir</strong>mojo arba antrojo gebėjimo lygio, reikalinga pagrįsti, kad to proceso kontekste p<strong>ir</strong>mojo <strong>ir</strong>antrojo gebėjimo lygio proceso atributai yra įgyvendinti su tokiais įverčiais:Proceso atributasVertinant 1-ajam lygiui Vertinant 2-ajam lygiuiPA 1.1 Proceso atlikimas Dažnai arba visada VisadaPA 2.1 Vykdymo valdymas - Dažnai arba visadaPA 2.2 Darbo produktų valdymas - Dažnai arba visadaTai yra, norint įvertinti, ar proceso gebėjimas pasiekia p<strong>ir</strong>mąjį gebėjimo lygį, reikiapagrįsti, kad to proceso kontekste PA 1.1 reikalavimai įgyvendinami dažnai. Norint įvertinti, arpasiekia antrąjį lygį, reikia pagrįsti, kad procesas PA 1.1 reikalavimus įgyvendina visada beidažnai įgyvendina PA 2.1 <strong>ir</strong> PA 2.2 reikalavimus.Norint pagrįsti proceso atributo įgyvendinimą, tikrinama, ar procesas pasiekia vertinimomodelyje apibrėžtus to atributo pasiekimus (proceso gebėjimo tikslus). Gebėjimo pasiekimusorganizacijai leidžia pasiekti modelyje aprašytos bendrosios praktikos, todėl praktiškaipasiekimų patikrinimas susiveda į bendrųjų praktikų įgyvendinimo patikrinimą, pagal praktikųpaplitimą išvedant proceso atributo įgyvendinimo lygį (dažnai ar visada). Kiekvieno atributoMokymo medžiaga 70
Programų sistemų inžinerija6. Projektas PKP Brandanustatyti įgyvendinimo lygiai <strong>ir</strong> aukščiau pateikta lentelė leidžia išvesti vertinamo procesogebėjimo lygį.Tokiu būdu organizacijos proceso vertinimo rezultatas (vertinimo apimtyje) yra vertintųorganizacijos procesų gebėjimų profilis, kuriame nurodomas kiekvieno vertinto proceso atributoįgyvendinimo lygmuo bei pasiekiamas gebėjimo lygis.Proceso vertinimo rezultatai dokumentavimui patogu naudoti instrumentines priemones.Vertinimo ataskaitoje pateikiamas ne tik nustatytas procesų gebėjimo profilis, bet <strong>ir</strong> procesoatributų pasiekimo įrodymai arba, priešingai, proceso trūkumai, neleidžiantys pasiekti procesogebėjimo. Vertinimo metu užfiksuoti trūkumai tampa įeities duomenimis rengiant procesogerinimo veiksmų planą.Sudaryti veiksmų planąRemiantis vertinimo rezultatais (faktiniu procesų gebėjimo profiliu, vertinimo metunustatytomis problemomis) <strong>ir</strong> organizacijos verslo tikslais, nustatomas tikslinis (siekiamas)procesų gebėjimo profilis, nurodant reikiamus procesus <strong>ir</strong> jų gebėjimo atributų reikiamasreikšmes, <strong>ir</strong> sudaromas veiksmų planas.Netikslinga siekiamą procesų profilį iš karto apibrėžti kaip „idealų“ (visi procesai 4-5lygio). Tikslinis procesų profilis turėtų atspindėti einamuosius verslo tikslus: jei kažkurieprocesai, būdami antro ar net p<strong>ir</strong>mo lygio, atitinka einamuosius verslo tikslus, reikėtų investuoti įkitų procesų gerinimą. Paprastai sakant, tikslinis procesų profilis turėtų atspindėti verslo tikslus,o ne atv<strong>ir</strong>kščiai. Tam tikrą išimtį iš šios taisyklės sudaro atvejis, kai organizacija yra nusistačiusitikslą gauti, pavyzdžiui, 2-ą lygį pagal CMMI. Tokio įvertinimo turėjimas gali sudarytigalimybes gauti naujus užsakymus iš užsienio. Šiuo atveju tikslinį procesų profilį nusako CMMI2-o lygio reikalavimai.Proceso gerinimą reikėtų daryti evoliuciniu būdu, nes per daug radikalūs procesopakeitimai gali įnešti sumaištį į organizacijos veiklą, sulaukti darbuotojų pasipriešinimo <strong>ir</strong> tokiubūdu sužlugdyti visą proceso gerinimo iniciatyvą, gali būti tikslinga sudaryti tarpinį procesųprofilį, kurio bus siekiama einamojoje proceso gerinimo iteracijoje (toks atvejis yra pateikiamas1 priedo pavyzdyje).Remiantis procesų gebėjimo tiksliniu (tarpiniu) profiliu, sudaromas veiksmų planas. Jeiorganizacija siekia pas<strong>ir</strong>inkto gerinimui vardinio proceso p<strong>ir</strong>mo gebėjimo lygio, tai nustatant,kokios šio vardinio proceso veiklos turi būti atnaujintos ar įdiegtos <strong>ir</strong> kokie darbo produktaiturėtų būti sukuriami, reikia remtis programų kūrimo proceso modelyje šiam procesuiapibrėžtomis bazinėmis praktikomis <strong>ir</strong> jų darbo produktais. Nebūtina, kad įmonės realiameprocese vykdomos veiklos <strong>ir</strong> kuriami darbo produktai „vienas prie vieno“ sutaptų su modelyjeMokymo medžiaga 71
Programų sistemų inžinerija6. Projektas PKP Brandaapibrėžtais, ypatingai nedideliuose <strong>ir</strong> mažuose projektuose: kelios modelio bazinės praktikos ardarbo produktai gali būti apjungiami į vieną.Siekiant antro (ar aukštesnio) lygio atributų įgyvendinimo pas<strong>ir</strong>inktame gerinimuivardiniame procese, reikia remtis programų kūrimo proceso modelyje apibrėžtomisbendrosiomis praktikomis. Kadangi jos apibrėžiamos visiems vardiniams procesams, procesogerinimo komanda turi pritaikyti bendrosios praktikos apibrėžimą pas<strong>ir</strong>inktam procesui.Bendrųjų praktikų įgyvendinimą užtikrina kitų procesų iš valdymo <strong>ir</strong> pagalbinių kategorijųvykdymas. Paprastai sakant, kad inžinerinis procesas pasiektų antrą gebėjimo lygį, turi būtiįgyvendinti jį palaikantys valdymo <strong>ir</strong> pagalbinių kategorijų procesai.Nustačius reikalingus procesų pakeitimus, einamojo organizacijos veiklos modelio(apibrėžto inicijavimo žingsnyje) pagrindu sudaromas pagerintas veiklos modelis, įgyvendinantisprocesų gebėjimo tikslinį (tarpinį) profilį.Veiksmų plane turi būti nurodomi gerinimo veiksmai, jų įgyvendinimo seka <strong>ir</strong> tvarkaraštis,atsakingi asmenys, būdai proceso gerinimo tikslų pasiekimui nustatyti. Veiksmų plano detalumasturi būti pakankamas jo įgyvendinimui, nebūtinas didelis <strong>ir</strong> išsamus dokumentas (turėtų pakaktivieno-dviejų puslapių).komitetas.Prieš įgyvendinant veiksmų planą, jį turi patv<strong>ir</strong>tinti proceso gerinimo projekto PriežiūrosĮgyvendinti gerinimo veiksmusGerinimo veiksmus reikėtų išbandyti pas<strong>ir</strong>inktame, jokiu būdu ne kritiniame organizacijaiprojekte. Įgyvendinimo metu reikia atkreipti dėmesį į žmogiškąjį faktorių, organizacinę kultūrą,papildomų mokymų poreikį. Darbuotojai, kuriuos betarpiškai paliečia proceso pakeitimai, turibūti supažindinti su proceso gerinimo tikslais, jie turi jaustis ne „bandomaisiais triušiais“, oprogresyvių pakeitimų diegėjais. To siekiant yra labai svarbus vadovybės palaikymas <strong>ir</strong>domėjimasis proceso gerinimo eiga.Šiame etape ypač svarbu identifikuoti iškylančias problemas <strong>ir</strong> kuo greičiau bandyti jasišspręsti: darbuotojai turėtų būti skatinami išsakyti savo nuomonę <strong>ir</strong> siūlyti galimus sprendimus,tokiu būdu jie tampa naujo proceso „savininkais“ <strong>ir</strong> gynėjais.Įgyvendinus proceso gerinimo veiksmus, reikia stebėti jų poveikį programų kūrimoproceso efektyvumui, ar nustatyti gerinimo tikslai buvo pasiekti.Patv<strong>ir</strong>tinti proceso pakeitimusKai veiksmų plano įgyvendinimas pas<strong>ir</strong>inktame bandomajame projekte baigtas, procesogerinimo projekto Priežiūros komitetas turi priimti sprendimą, ar numatyti proceso gerinimotikslai buvo pasiekti <strong>ir</strong> gauta nauda, kurios buvo tikėtasi, įvertinti pakeisto proceso paskleidimoMokymo medžiaga 72
Programų sistemų inžinerija6. Projektas PKP Brandaorganizacijoje riziką. Turėtų būti išklausyti darbuotojų, kuriuos betarpiškai palietė procesopakeitimai, atsiliepimai.Jei pakeisto proceso bandymai buvo nesėkmingi - gerinimo tikslai nebuvo pasiekti, turibūti išanalizuotos nesėkmės priežastys <strong>ir</strong> grįžtama prie 3-io ciklo žingsnio: nustatomi nauji, galbūt mažesni (ne tokie ambicingi) gerinimo tikslai, sudaromas naujas veiksmų planas, tiemstikslams pasiekti.Jei gerinimo veiksmai buvo sėkmingai įdiegti <strong>ir</strong> nustatyti gerinimo tikslai pasiekti,priimamas sprendimas dėl pakeisto proceso paskleidimo. Reikėtų, kad visi įmonės darbuotojaisužinotų apie sėkmingą gerinimo projektą <strong>ir</strong> jį vykdžiusius žmones, tai motyvuoja juos <strong>ir</strong> kitusdarbuotojus aktyviau įsijungti į proceso gerinimo veiklą.Paskleisti proceso pakeitimusKai proceso gerinimo veiksmai patv<strong>ir</strong>tinami, turi būti sudarytas proceso pakeitimųpaskleidimo organizacijoje planas: kokiuose projektuose (jei ne visuose) bus taikomas pakeistasprocesas, kaip jis bus diegiamas, kokių papildomų mokymų įmonės darbuotojams reikia, kaipbus užtikrinama, kad pasiektas proceso gebėjimas nebus prarastas <strong>ir</strong> gerinimo veiksmai „prigis“organizacijoje (pavyzdžiui, peržiūros, auditas, gebėjimo vertinimas).Pakeisto proceso diegimo planą organizacijoje turi patv<strong>ir</strong>tinti Priežiūros komitetas.Stebėti proceso vykdymąProceso gerinimo projekto komanda turi stebėti organizacijos procesą <strong>ir</strong> jo efektyvumą.Būdai pas<strong>ir</strong>enkami pagal organizacijos poreikius <strong>ir</strong> verslo tikslus. Komanda turėtų apibendrintiproceso gerinimo pat<strong>ir</strong>tį <strong>ir</strong> darbuotojų atsiliepimus. Turėtų būti įsitikinta, kad proceso pakeitimaibuvo įdiegti organizacijoje pagal planą. Informacija apie proceso būseną turėtų būti skleidžiamaorganizacijoje.Situacija turėtų būti reguliariai peržiūrima Priežiūros komitete. Įvertinęs, kad pakeistasprocesas jau pakankamai įdiegtas organizacijoje, Priežiūros komitetas priima sprendimą dėlnaujo proceso gerinimo ciklo inicijavimo.Programų kūrimo proceso instrumentinės priemonėsŠiame skyriuje aptariamos PKP Branda projekto metu sukurtos programų kūrimo procesovertinimo <strong>ir</strong> gerinimo palaikymo instrumentinės priemonės. Jas galima išbandyti internete(http://proin.ktu.lt/pkp/pkbm/).Programų kūrimo proceso instrumentinės priemonės turi palengvinti brandaus procesodiegimą, palaikymą <strong>ir</strong> gerinimą, o taip pat padėti atlikti proceso vertinimą. Jos turi apimti:- Modelio medžiagos pateikimo priemones;- Organizacijos proceso apibrėžimo <strong>ir</strong> pavaizdavimo priemones;Mokymo medžiaga 73
Programų sistemų inžinerija6. Projektas PKP Branda- Proceso nuolatinio matavimo duomenų surinkimo priemones;- Proceso vertinimo priemones;- Apsikeitimo proceso vertinimo duomenimis priemones;- Apmokymo priemones.Svečiui prieinamainformacijaProjekto informacijaKalbos pas<strong>ir</strong>inkimasAtverti prisijungimopuslapį6.3 pav. Pradinis sistemos puslapisModelio medžiagos pateikimo priemonės turi būti su užpildytu turiniu. Kartu su modeliuturi būti pateikiamas programų kūrimo proceso terminų žodynas, pasižymintis hipertekstosavybėmis.Organizacijos proceso apibrėžimo <strong>ir</strong> pavaizdavimo priemonės turi suteikti galimybesmodifikuoti pateikiamą brandaus proceso modelio turinį, priderinant jį pagal konkrečiosorganizacijos atliekamą veiklą <strong>ir</strong> specifiką.Modelio medžiaga <strong>ir</strong> organizacijos proceso apibrėžimas turi būti pateikiami per vieningąnaršyklę, išnaudojant hiperteksto sistemų savybes. Naršyklė turi pateikti galimybę gauti bet kuriolygio modelio informaciją, atspindint jos vietą bendroje struktūroje, t.y. turi būti užtikrintosgalimybės nuo bet kurio pas<strong>ir</strong>inkto modelio elemento pereiti prie konkretaus jo apibrėžimoMokymo medžiaga 74
Programų sistemų inžinerija6. Projektas PKP Brandaorganizacijoje. Ir atv<strong>ir</strong>kščiai, pas<strong>ir</strong>inkus organizacijoje apibrėžtą veiklos procedūrą ar dokumentošabloną, turi būti galimybė pereiti prie jo atitikmens modelyje.Proceso nuolatinio matavimo duomenų surinkimo priemonės turi padėti rinkti modelyje <strong>ir</strong>diegimo metodikoje apibrėžtus duomenis apie proceso vykdymą. Duomenų surinkimas turi būti,kiek įmanoma, automatizuotas: darbuotojams atliekant procese numatytus veiksmus, sistemojeturi būti kaupiami duomenų įrašai. Instrumentinės priemonės turi sudaryti duomenų analizėsgalimybes: gauti iš anksto apibrėžtas ataskaitas, formuluoti interaktyvias užklausas, rezultataituri būti pateikiami vartotojo pas<strong>ir</strong>inkta forma (lentelėmis ar pas<strong>ir</strong>inkto tipo diagramomis) sugalimybe juos eksportuoti tolimesniam apdorojimui ar publikavimui.6.4 pav. Sistemos architektūraProceso vertinimo priemonės turi padėti atlikti proceso vienkartinį arba pakartotinį, išsamųarba greitąjį vertinimą. Turi būti galimybės adaptuoti vertinimo metodiką. Vertinimui turi būtipanaudojami proceso nuolatinio matavimo duomenys. Sistema turi identifikuoti trūkstamusduomenis <strong>ir</strong> sudaryti galimybes juos įvesti interaktyviai arba importuoti. Turi būti galimybėsanalizuoti vertinimo rezultatus įva<strong>ir</strong>iais pjūviais, palyginti su ankstesnių vertinimų rezultatais,sekti pasikeitimus, eksportuoti vertinimo rezultatus.Mokymo medžiaga 75
Programų sistemų inžinerija6. Projektas PKP BrandaApsikeitimo proceso vertinimo duomenimis priemonės turi padėti keistis vertinimoduomenimis tarp sk<strong>ir</strong>tingų organizacijų, užtikrinant reikiamą anonimiškumą, jautrių duomenųapsaugą <strong>ir</strong> suteikiant analizės priemones.Apmokymo priemonės turi apimti darbo su sistema apmokymus, apimančius visassistemos funkcijas, naudojamo programų kūrimo proceso modelio apmokymus, modeliopritaikymo organizacijos reikmėms apmokymus.6.5 pav. Puslapio modelio medis iliustracijaVisos instrumentinės priemonės turi būti nepriklausomos nuo specifinių brandausprogramų kūrimo proceso adaptacijų ar taikymų.Sistemos architektūra turi užtikrinti pask<strong>ir</strong>stytą duomenų įvedimą, kad instrumentinėmispriemonėmis galėtų naudotis visi organizacijos darbuotojai. Sistema turi būti diegiama <strong>ir</strong>prižiūrima su nedideliais kaštais, užtikrinti normalų darbą vartotojams su vidutinių pajėgumųMokymo medžiaga 76
Programų sistemų inžinerija6. Projektas PKP Brandakompiuteriais. Realizacijai turi būti naudojamos technologijos, užtikrinančios sistemospernešamumą į programų kūrimo įmonių dažniausiai naudojamas operacines sistemas.Turi būti užtikrintas duomenų saugumas, galimybės nustatyti teises vartotojams <strong>ir</strong> jųgrupėms naudotis posistemėmis bei duomenimis, apsauga turi būti organizuota tiek programų,tiek duomenų lygiuose, duomenų bazė turi būti apsaugota patikimomis priemonėmis ne tik nuonesankcionuoto prisijungimo, bet <strong>ir</strong> nuo duomenų kopijavimo.Turi būti specializuotos administravimo priemonės, palengvinančios administravimą.Instrumentinėse priemonėse turi būti numatyta galimybė integruoti jas su įrankiais,padedančiais automatizuoti įva<strong>ir</strong>ius specifinius proceso aspektus, pavyzdžiui, projektųplanavimą.Trečias žingsnis: atliekamasgreitasis vertinimas įrašantreikšmes procesų atributamsPaspaudus mygtuką Atnaujintiišsaugomi daryti keitimai6.6 pav. Puslapio vertinimas iliustracijaProjektuojant sistemą buvo remiamasi analogiškų programinių produktų analizėsrezultatais. Papildomai išnagrinėjus esamas instrumentines priemones, buvo priimta nuostata,kad sistema turėtų užtikrinti efektyvų panaudojimą <strong>ir</strong> tuo pačiu skatinti domėjimąsi pačiubrandaus programų kūrimo procesu. Programų kūrimo proceso modelis yra sudėtingas <strong>ir</strong>, norintjuo pasinaudoti, tenka analizuoti sudėtingais sąryšiais susijusius informacinius elementus.Nenaudojant arba naudojant tik elementarias priemones vartotojas instinktyviai stengiasi išvengtiMokymo medžiaga 77
Programų sistemų inžinerija6. Projektas PKP Brandasudėtingų klausimų sprendimo. Tik patogių priemonių naudojimas leidžia operatyviai spręstiiškilusius klausimus.Buvo išnagrinėti tiek komerciniai įrankiai, tiek atv<strong>ir</strong>ojo kodo instrumentinės priemonės.Pastebėti komercinių produktų trūkumai: dažniausiai neegzistuoja administravimo posistemis,nėra pask<strong>ir</strong>styto duomenų įvedimo galimybės, duomenys dažnai saugomi naudojant nuosavąformatą (tai padidina sistemos pernešamumo kaštus), o taip pat didelė kaina.Projektuojant sistemą atsižvelgta <strong>ir</strong> į tai, kad praktiškai reikalingos <strong>ir</strong> instrumentinėspriemonės sistemoje naudojamam programų kūrimo proceso modeliui vystyti: tikslinti, papildyti,pritaikyti organizacijos poreikiams. Vystymo aplinkos įtraukimas leidžia užtikrinti projektotęstinumą.Vystymo posistemiui buvo iškelti tokie reikalavimai:- Vystymo medžiaga (turinys) turi būti kaip galima labiau atsk<strong>ir</strong>ta nuo jos pavaizdavimobūdo , kad ją būtų galima pateikti įva<strong>ir</strong>iose aplinkose;- Medžiagos aprašymas (žymėjimas) turi būti kuo paprastesnis, kad įsisavinimo laikas būtųkuo trumpesnis;- Medžiagos aprašymas turi atitikti „greitojo žymėjimo“ (arba wiki) ideologiją, kadnaudojimas būtų našesnis, o aprašymas būtų lengviau skaitoma;- Siekiant lankstumo, turi būti galimybės medžiagos žymėjimą panaudoti kartu su HTMLžymėjimu;- Vystymo posistemyje turi būti priemonės efektyviam grupiniam darbui palaikyti(pakeitimų sekimo <strong>ir</strong> kontrolės įrankiai);- Sistema turi įtraukti <strong>ir</strong> programavimo galimybę, kad būtų užtikrinta galimybė realizuotiveiksmus, kuriems nepakanka esamo žymėjimo.Vystymo medžiagos formatavimui buvo pas<strong>ir</strong>inktas MediaWiki žymių poaibis. KadangiWiki formatavimo žymės sk<strong>ir</strong>tos tik teksto formatavimui, todėl modeliui <strong>ir</strong> modelio elementamsaprašyti suprojektuotas atsk<strong>ir</strong>as žymių poaibis.Literatūra papildomam skaitymui[VU05][ISO98]Vilniaus universitetas. Brandaus programų kūrimo proceso įdiegimo metodikos <strong>ir</strong>instrumentinių priemonių sukūrimas (PKP Branda), 2005(http://www.mif.vu.lt/se/Branda/)ISO/IEC 15504: Information technology – Software process assessment, (parts1-9). International Organization for Standardization and the InternationalElectrotechnical Commission, 1998Mokymo medžiaga 78
Programų sistemų inžinerija6. Projektas PKP Branda[Loo04a] H.V. Loon, Process Assessment and Improvement. A practical guide for managers,quality professionals and assessors. Springer, 2004.[IDE96]IDEAL: A User’s Guide for Software Improvement, CMU/SEI-96-HB-001,Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996.Mokymo medžiaga 79
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas7. Asmeninis programų kūrimo procesasVienas iš nedaugelio modelių, orientuotų į asmens disciplinos formavimą, kuriantprogramų sistemas, yra Watts Humphrey pristatytas asmeninis programų kūrimo procesas PSP(angl. Personal Software Process). PSP yra asmeninės veiklos, susijusios su programų kūrimu,kokybės gerinimo procesas, akcentuojantis tris svarbiausius disciplinos aspektus: kokybėssiekimą, tvarkaraščio/planų laikymąsi <strong>ir</strong> pastovų tobulėjimą. Pagal PSP metodiką, asmuo kuriaprogramas, naudodamasis griežtai apibrėžtais <strong>ir</strong> struktūrizuotais metodais, leidžiančiais kurtiaukštos kokybės produktus suplanuotais terminais. Savo darbe įtraukdamas vis daugiau procesoapibrėžtų veiklų, asmuo kelia savo darbo kokybę bei palaipsniui “kyla” PSP proceso lygmenųlaipteliais, atspindinčiais jo asmeninio proceso lygį.Asmeninio programų kūrimo proceso pask<strong>ir</strong>tis – padėti inžinieriui atlikti savo darbusdisciplinuotai, t.y. siekiant aukštos kokybės, tikslaus planų laikymosi bei pastovaus tobulėjimo.Tai PSP procesas užtikrina nurodydamas, kaip geriau projektuoti, koduoti, testuoti bei planuotisavo darbą, o tai, savo ruožtu, lemia darbo kokybę, produktyvumą <strong>ir</strong> tobulėjimo galimybę.PSP ats<strong>ir</strong>adimasŠis modelis buvo sukurtas Watts Humphrey kaip tęsinys jo ankstesnių darbų, kurių metubuvo kuriamas organizacijos lygio programų kūrimo proceso modelis CMM. Gaudamasatsiliepimus, jog CMM modelis nėra tinkamas mažoms organizacijoms, autorius sukūrėprogramų sistemų kūrimo proceso modelį, tinkamą pačiai mažiausiai “organizacijai” – vienamasmeniui. PSP procesas buvo kuriamas taip, kad atitiktų optimizuojantį CMM proceso lygį(CMM 5 lygis), t.y. šio proceso metu yra vykdomos visos CMM veiklos, kurios tinkamosasmeniniam procesui. Šis naujasis modelis buvo pavadintas PSP (angl. Personal SoftwareProcess) <strong>ir</strong> p<strong>ir</strong>mą kartą pristatytas knygoje „A Discipline for Software Engineering” [Hum95].PSP modelisProcesą galima apibrėžti kaip seką žingsnių, kuriuos įvykdžius pasiekiamas norimastikslas. Tikslas, šiuo atveju, yra asmens pas<strong>ir</strong>uošimas pastoviai kurti aukštos kokybėsprograminius produktus per nustatytus terminus. PSP procesą sudaro septyni hierarchiniai lygiai.Kiekvienas aukštesnis lygis apima visų žemesnių lygių veiklas bei prideda naujų veiklų. 7.1 pav.pavaizduotas proceso modelis, kuris buvo pateiktas 1994 metais, knygoje “A Discipline forSoftware Engineering” [Hum95]. Ši knyga buvo orientuota į magistro studijas.Sk<strong>ir</strong>tingai nei CMM atveju apibrėžti PSP proceso lygiai nereiškia, kad tai vienintelis kelias(veiklų eiliškumas), kuriuo jis turėtų būti diegiamas. Pavyzdžiui, 1996 metais išleistoje knygojeMokymo medžiaga 80
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas„Introduction to the Personal Software Process SM ”, sk<strong>ir</strong>toje bakalauro studijoms modelis iš visonepateikiamas <strong>ir</strong> siūloma diegti veiklas kiek kitokiu eiliškumu.CiklinisprocesasPSP3Ciklinis kūrimasKokybėsvaldymoprocesasPSP2Projekto peržiūraKodo peržiūraPSP2.1Projektavimo šablonaiPlanavimoprocesasPSP1Dydžio prognozavimas (PROBE)Testavimo ataskaitaPSP1.1Laiko prognozavimas (PROBE)Užduočių planavimasDarbo grafiko planavimasBazinisprocesasPSP0Dabartinis procesasLaiko fiksavimasDefektų fiksavimasDefektų tipų standartasPSP0.1Dydžio fiksavimasKodavimo standartasDydžio standartas (LOC)Proceso gerinimo pasiūlymai7.1 pav. PSP modelis (1994 metai)Dar viena modelio „revizija“ buvo atlikta, peržiūrint jį <strong>ir</strong> pritaikant taikymams gamyboje[Hum05] – paskutinė paskelbta modelio versija pateikiama 7.2 pav.Kad būtų lengviau vykdyti procesą bei jo aprašytas veiklas, PSP pateikia specialiaiparuoštas instrukcijas, scenarijus, formas, standartus, kuriuose nurodoma, ko reikia veiklaiįvykdyti, kokia informacija turi būti surinkta <strong>ir</strong> kaip pateikta bei kokių rezultatų tikimasi.PSP apimtisPaprasčiausias PSP proceso apibūdinimas būtų toks: tai procesas, kuris pateikianurodymus, kaip reikia kurti programinius produktus. Šis procesas sk<strong>ir</strong>tas vienam asmeniui – nekomandai <strong>ir</strong> ne organizacijai. Proceso metu kalbama apie programinių produktų kūrimą – ne apieataskaitų rašymą, programų diegimo darbus ar kokią kitą veiklą. Procesas apima programųsistemų kūrimo fazes nuo paruoštos reikalavimų specifikacijos gavimo iki modulių testųužbaigimo, t.y. didelė dalis programų sistemos gyvavimo ciklo į originalų PSP procesą neįeina,tačiau tie patys principai gali būti pritaikyti <strong>ir</strong> kitoms programų sistemų kūrimo veikloms. Beabejo, procesas neapima komandinio darbo organizavimo.Mokymo medžiaga 81
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasKomandinisprocesasTSPKomandos formavimasRizikos valdymasProjekto planavimas <strong>ir</strong> stebėjimasKokybėsvaldymas <strong>ir</strong>projektavimasPSP2Kodo peržiūraProjekto peržiūraPSP2.1Projektavimo šablonaiVertinimas<strong>ir</strong>planavimasPSP1Dydžio prognozavimasTestavimo ataskaitaPSP1.1Užduočių planavimasDarbo grafiko planavimasProcesodisciplina <strong>ir</strong>matavimasPSP0Dabartinis procesasBazinės metrikosPSP0.1Kodavimo standartasProceso gerinimo pasiūlymaiDydžio fiksavimas7.2 pav. PSP modelis (2005 metai)PSP struktūraPSP procesas apima tris stambias programų sistemų kūrimo fazes: užduočių planavimą,kūrimą <strong>ir</strong> proceso peržiūrą. Jas galima skaidyti į tokias mažesnes: asmeninių užduočiųplanavimo, eskizinio projekto peržiūros, detaliojo projekto kūrimo, detaliojo projekto peržiūros,kodavimo, kodo peržiūros, kompiliavimo, testavimo <strong>ir</strong> proceso peržiūros. Planavimo fazės metuparuošiamas planas, įtraukiantis prognozuojamą kuriamo produkto dydį bei jo sukūrimu<strong>ir</strong>eikalingą laiką. Kūrimo fazė apima visą „gamybinį“ procesą. Proceso gerinimo fazės metuperžiūrimi surinkti duomenys <strong>ir</strong> siūlomi patobulinimai.PSP metrikosPSP procesas naudoja pagrindines metrikas:• laikas,• defektai,• dydis.Iš šių bazinių metrikų išvedamos visos kitos PSP metrikos. Metrikos, kurios paremtosbazine laiko metrika, būtinos sudarant grafiką <strong>ir</strong> užduočių planus, matuojant produktyvumą <strong>ir</strong> t.t.Metrikos, paremtos bazine defektų metrika, būtinos produkto kokybei matuoti, prognozuoti <strong>ir</strong>Mokymo medžiaga 82
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasvaldyti, taip užtikrinant kokybiško produkto kūrimą. Metrikos, paremtos bazine dydžio metrika,būtinos dydžio matavimui bei prognozavimui, taip pat, kaip sudėtinis dėmuo, naudojamas klaidų“tankiui” bei produktyvumui matuoti.PSP kokybės modelisPSP procesas produkto kokybę užtikrina trimis pagrindiniais būdais:• kiekvienam produktui yra atliekama peržiūra (eskizinio projekto peržiūra, detaliojoprojekto peržiūra, kodo peržiūra), didžiausią dėmesį sk<strong>ir</strong>iant defektams, užfiksuotiemsdažniausiai asmens paliekamų defektų sąraše;• projektavimas atliekamas pagal projektavimo procedūrą, apimančią projektavimošablonų naudojimą bei projekto patikrinimą (design verification);• produkto kokybė stebima <strong>ir</strong> vertinama, naudojantis proceso metu surinktaisduomenimis.PSP prognozavimo modelisPSP proceso metu prognozavimas vykdomas remiantis prielaida, jog ateityje procesasvyks taip, kaip vyko praeityje, t.y. ateities prognozėms naudojami istoriniai duomenys. PSPprocesas pristato prognozavimo metodą PROBE (angl. Proxy Based Estimating). Šis metodasnaudojamas laiko <strong>ir</strong> dydžio prognozavimui. Jis įgalina pakankamai tiksliai prognozuoti, nesremiasi istoriniais duomenimis, kuriuos kiekvienas pagal PSP procesą d<strong>ir</strong>bantis asmuo renkaprojektų metu. Duomenys kategorizuojami, atsižvelgiant į objekto tipą (pvz., duomenų įvedimąužtikrinantis objektas). Turint keletą tai pačiai kategorijai priklausančių objektų bei kiekvieno išjų kūrimui sugaišto laiko įverčius <strong>ir</strong> dydžius, galima apskaičiuoti, kiek laiko užtruktų tokioskategorijos objekto kūrimas <strong>ir</strong> kokio dydžio jis būtų (skaičiuojamas aritmetinis vidurkis arbanaudojamasi sudėtingesniais statistiniais metodais).PSP tobulinimo modelisAsmeninio proceso evoliucionavimas yra vienas iš svarbiausių PSP proceso aspektų. PSPprocesas tobulinamas, remiantis pasiūlymais, pateiktais proceso peržiūros fazės metu. Tamtikslui yra paruošta proceso gerinimo pasiūlymų forma, kurioje fiksuojami visi galimi procesotobulinimo būdai bei siūlomi pakeitimai. Patobulinimai pateikiami su metrikomis, kad būtųgalima išmatuoti pakeitimo naudą.Pagrindiniai principai• Programų sistemų kūrėjai d<strong>ir</strong>bs efektyviai jei naudos apibrėžtą <strong>ir</strong> matuojamą procesą(apibrėžtas, matuojamas).Mokymo medžiaga 83
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas• Kad procesas geriausiai atitiktų individualius poreikius <strong>ir</strong> asmens sugebėjimus, jis turibūti pritaikytas (pritaikytas).• Suteikti galimybę programų kūrėjams d<strong>ir</strong>bti taip, kaip jie įpratę, tačiau prisilaikantnustatytų nurodymų, procedūrų bei atsižvelgiant į jų pačių surinktus duomenis <strong>ir</strong> kolegųpat<strong>ir</strong>tį (efektyvus).• Norint pastoviai gerinti savo veiklą reikia nuolat tobulinti procesą, atsižvelgiant įproceso naudojimo metu sukauptus istorinius duomenis <strong>ir</strong> rodiklius (evoliucionuojantis).• Kad gamintum kokybiškus produktus, privalai jaustis atsakingu už jų kokybę.• Surasti <strong>ir</strong> ištaisyti defektus projekto pradžioje kainuoja mažiau nei projekto pabaigoje;daug veiksmingiau užk<strong>ir</strong>sti kelią defektų ats<strong>ir</strong>adimui nei jų vėliau ieškoti <strong>ir</strong> taisyti(orientuotas į kokybę, ankstyvas defektų šalinimas).PSP praktikosPSP procese išsk<strong>ir</strong>iama 11 praktikų, kurių taikymas sąlygoja aukščiau įvardintų procesoprincipų įgyvendinimą:1. Laiko fiksavimas.2. Defektų fiksavimas.3. Dydžio fiksavimas.4. Standartų apibrėžimas.5. Dydžio prognozavimas.6. Laiko prognozavimas.7. Peržiūros.8. Proceso tobulinimas.Duomenų surinkimui PSP pateikia specialiai paruoštas popierines formas (bei elektroninęformų versiją Microsoft Excel formatu). Surinktų duomenų analizei <strong>ir</strong> agregavimui PSPnaudojami pakankamai primityvūs <strong>ir</strong> ne itin patogūs naudoti įrankiai, kurie neįgalina atlikti bentminimalų surenkamų duomenų integralumo patikrinimą.Laiko fiksavimasTikslas: Vartotojui tinkamoje formoje užfiksuoti minimalią aibę duomenų, būtinų būsimailaiko prognozavimo praktikai vykdyti.Veiklos:• Reikalingų duomenų aibės, matavimo tikslumo apibrėžimas.• Duomenų surinkimo <strong>ir</strong> kaupimo formos apibrėžimas.• Duomenų surinkimas.Mokymo medžiaga 84
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasAprašymas. Metrikos, paremtos bazine laiko metrika, būtinos sudarant grafiką <strong>ir</strong> užduočiųplanus, matuojant produktyvumą <strong>ir</strong> t.t. Remiantis surinktais duomenimis, bus nustatoma kieklaiko galėtų užtrukti panašaus dydžio <strong>ir</strong> sudėtingumo objekto projektavimas, sukūrimas,testavimas. Laiko fiksavimo praktika įvedama jau pačiame p<strong>ir</strong>majame PSP proceso lygyje –PSP0, kadangi surinkti duomenys taps pagrindu planavimo procesui. Laiko sąnaudų užduotimsįgyvendinti fiksavimas leidžia tiksliau prognozuoti produkto kūrimui reikalingo laiko sąnaudasbei nustatyti, kiek trunka “trukdžiai”.Surenkamų duomenų aibė. Fiksuojama, kiek laiko truko tam tikros užduoties ar jos daliesįgyvendinimas, fiksuojamos visos pertraukėlės (pietų pertrauka <strong>ir</strong> pan.). Kadangi PSP procesometu renkami duomenys ne tik apie užduotims įgyvendinti sugaištą laiką, bet <strong>ir</strong> fiksuojamakiekvienos nedarbo pertraukėlės (“trukdžių”) trukmė, tai įgalina nustatyti tokių “trukdžių” kainą<strong>ir</strong> jų santykį su užduotims įgyvendinti sugaištu laiku. Prieš pradedant rinkti duomenis priimamasstandartas, kuris nusako, kaip turi būti fiksuojamas laikas bei kokios paklaidos gali būtiužfiksuotuose duomenyse.Defektų fiksavimasTikslas. Vartotojui tinkamoje formoje užfiksuoti aibę reikalingų duomenų, būtinųidentifikuoti pasitaikančius defektus bei užtikrinti jų prevencijos <strong>ir</strong> ats<strong>ir</strong>adimo priežasčiųeliminavimo veiklas, vertinti būsimo produkto kokybę.Veiklos:• Reikalingų duomenų aibės, matavimo tikslumo apibrėžimas (remiantis apibrėžtudefektų tipų standartu).• Duomenų surinkimo <strong>ir</strong> kaupimo formos apibrėžimas.• Duomenų surinkimas.Aprašymas. Metrikos, paremtos bazine defektų metrika, būtinos produkto kokybeimatuoti, prognozuoti <strong>ir</strong> valdyti, taip užtikrinant kokybiško produkto gamybą. Defektų fiksavimopraktika įvedama jau pačiame p<strong>ir</strong>majame PSP proceso lygyje – PSP0, kadangi surinktiduomenys taps pagrindu planavimo procesui <strong>ir</strong> leis prognozuoti kuriamo produkto kokybę beiparuošti defektų prevencijos procedūras. PSP siūlomas defektų fiksavimas <strong>ir</strong> kategorizavimas beipastovus klaidų kontrolinių sąrašų atnaujinimas leidžia susidaryti gana tikslų vaizdą apiedažniausiai sutinkamas klaidas <strong>ir</strong> netgi iš anksto numatyti <strong>ir</strong> paruošti tam tikrus nurodymus, kaiptokių klaidų išvengti. Asmens lygmenyje klaidų sąrašai įgalina žinoti savo dažniausiai įveliamasklaidas <strong>ir</strong> geriau atlikti projektavimo bei kodavimo darbus.Surenkamų duomenų aibė. Fiksuojami visi defektai, kurių tipus apibrėžia defektų tipųstandartas. Defektų tipų standartas atnaujinamas viso proceso eigoje. Kaip pradinis defektų tipųstandarto variantas naudojamas PSP apibrėžtas standartas. Taip pat sudaromi <strong>ir</strong> pastoviaiMokymo medžiaga 85
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasatnaujinami defektų kontroliniai sąrašai, pateikiantys tikrintinas situacijas, kuriose dažniausiaibūna defektų.Dydžio fiksavimasTikslas. Vartotojui tinkamoje formoje užfiksuoti minimalią aibę duomenų, būtinų būsimaiobjektų/komponentų dydžio prognozavimo veiklai vykdyti.Veiklos:• Reikalingų duomenų aibės, matavimo tikslumo apibrėžimas.• Duomenų surinkimo <strong>ir</strong> kaupimo formos apibrėžimas.• Duomenų surinkimas.Aprašymas. Metrikos, paremtos bazine dydžio metrika, būtinos dydžio matavimui beiprognozavimui, taip pat, kaip sudėtinis dėmuo, naudojamos klaidų “tankiui” bei produktyvumuimatuoti. Objektų/komponentų kategorizavimas bei istorinių duomenų apie kiekvienos rūšiesobjektus/komponentus rinkimas leidžia tiksliau prognozuoti būsimo produkto dydį. Dydžiofiksavimo praktika įvedama jau pačiame p<strong>ir</strong>majame PSP proceso lygyje – PSP0.1, kadangisurinkti duomenys taps pagrindu planavimo procesui <strong>ir</strong> leis tiksliau prognozuoti būsimoprodukto dydį.Surenkamų duomenų aibė. Fiksuojami objektų/komponentų dydžiai remiantis dydžiostandartu. Prieš pradedant rinkti duomenis priimamas dydžio standartas, kuris apibrėžia kaipmatuojamas dydis. Turint keleto tai pačiai kategorijai priklausančių objektų dydžius, galimaapskaičiuoti, koks prognozuojamas tokios kategorijos objekto dydis (skaičiuojamas aritmetinisvidurkis arba naudojamasi sudėtingesniais statistiniais metodais).Standartų apibrėžimasTikslas. Vartotojui tinkamoje formoje pateikti nurodymų rinkinį, kurių laikantis turi būtiatliekama arba pagal kuriuos matuojama atlikta veikla.Veiklos:• Defektų tipų standarto paruošimas.• Kodavimo standarto paruošimas.• Dydžio standarto paruošimas.Aprašymas1. Defektų tipų standartas: įveda sistemą, nurodančią kaip klasifikuoti projekto meturastus defektus. Šioje sistemoje kiekvienas defekto tipas turi jį identifikuojantį numerį <strong>ir</strong> nurodo,kokio tipo defektus jis apima.2. Kodavimo standartas. Kiekvienas programų sistemų kūrėjas, priklausomai nuo turimųžinių kiekio bei praktinių įgūdžių, naudoja sk<strong>ir</strong>tingą programų kūrimo metodiką, t.y. turi savoMokymo medžiaga 86
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesassavitą programavimo “stilių”. Norint PSP proceso metu pasinaudoti kitų programų sistemųkūrėjų surinktais duomenimis <strong>ir</strong> taip patobulinti savo naudojamą procesą, būtina, jog kodavimosritis būtų standartizuota, t.y. visi naudotų vienodus kodavimo standartus. Tai leis panaudoti kitųprogramų sistemų kūrėjų duomenis savo prognozėms atlikti.3. Dydžio standartas: apibrėžia, kaip turi būti matuojamas kodo dydis. Šis standartasglaudžiai susijęs su kodavimo standartu, kadangi dydžio matavimo procesas <strong>ir</strong> tikslumaspriklausys nuo to, kaip apibrėžtas kodavimo standartas.Dydžio prognozavimasTikslas. Naudojantis turimais istoriniais duomenimis <strong>ir</strong> apibrėžtais standartais prognozuotibūsimų projekto produktų (pvz., objektų/komponentų) dydžius.Veiklos:• Prognozavimo metodikos pas<strong>ir</strong>inkimas <strong>ir</strong> procedūrų apibrėžimas.• Projekto produktų (pvz., objektų/komponentų) dydžio prognozavimas.• Dydžio prognozavimo tikslumo didinimas (duomenų, rodiklių koregavimas), lyginantprognozes su realiais projekto produktų (pvz., objektų/komponentų) dydžiais.Aprašymas. Turint keleto tai pačiai kategorijai priklausančių objektų dydžius, galimaapskaičiuoti, koks prognozuojamas tokios kategorijos objekto dydis (skaičiuojamas aritmetinisvidurkis arba naudojamasi sudėtingesniais statistiniais metodais). Dydžio prognozavimo praktikaįvedama PSP proceso planavimo lygmenyje PSP1. Šios praktikos išeities duomenys busnaudojami planavimo praktikos metu.Prognozavimo metodikos pas<strong>ir</strong>inkimas <strong>ir</strong> procedūrų apibrėžimas. PSP procesas dydžiuimatuoti siūlo naudoti kodo eilučių skaičiavimo metodą (LOC), tačiau šis metodas dažnaipraktikoje nepateisina lūkesčių, nes metodas sunkiai panaudojamas, jei nėra griežtai apibrėžtaskodavimo standartas, projektas realizuojamas sk<strong>ir</strong>tingomis programavimo kalbomis. Dydžioprognozavimui naudojamas metodas PROBE, kuris apibrėžiamas PSP1 lygio (planavimo)procese, įgalina pakankamai tiksliai nusakyti, kiek laiko užtruks užduoties vykdymas, nes jisremiasi istoriniais duomenimis, surinktais dydžio fiksavimo praktikos metu.Dydžio prognozavimo tikslumo didinimas. Turint istorinius duomenis <strong>ir</strong> prognozuotuskomponentų/objektų dydžius, tikslinamas/keičiamas prognozavimo metodas, pas<strong>ir</strong>enkami labiautinkantys metodai.Laiko prognozavimasTikslas. Naudojantis surinktais istoriniais duomenimis <strong>ir</strong> pas<strong>ir</strong>inkta metodika, kiek galimatiksliau prognozuoti produkto/komponento/objekto sukūrimui reikalingą laiką.Mokymo medžiaga 87
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasVeiklos:• Prognozavimo metodikos pas<strong>ir</strong>inkimas <strong>ir</strong> procedūrų apibrėžimas.• Projekto produktų sukūrimui (pvz., objektų/komponentų) reikalingo laikoprognozavimas.• Laiko prognozavimo tikslumo didinimas (duomenų, rodiklių koregavimas), lyginantprognozes su realiais projekto produktų sukūrimo laikais.Aprašymas. “Istorinių duomenų” naudojimas, vertinant būsimas laiko sąnaudas yra priimtapraktika programų sistemų kūrimo industrijoje. Tačiau vertinti individualaus asmens laikosąnaudas vis dar yra pakankamai sudėtinga. PSP proceso metu asmuo įgyja teorinių <strong>ir</strong> praktiniųžinių, kaip šią veiklą atlikti kiek įmanoma tiksliau <strong>ir</strong> kokybiškiau. Turint keleto tai pačiaikategorijai priklausančių objektų, galima apskaičiuoti, koks prognozuojamas tokios kategorijosobjekto sukūrimo laikas (skaičiuojamas aritmetinis vidurkis arba naudojamasi sudėtingesniaisstatistiniais metodais). Laiko prognozavimo praktika įvedama PSP proceso planavimo lygmenyjePSP1.1. Šios praktikos išeities duomenys bus naudojami planavimo praktikos metu.Prognozavimo metodikos pas<strong>ir</strong>inkimas <strong>ir</strong> procedūrų apibrėžimas. Laiko prognozavimuinaudojamas metodas PROBE, kuris apibrėžiamas PSP1 lygio (planavimo) procese, įgalinapakankamai tiksliai nusakyti, kiek laiko užtruks užduoties vykdymas, nes jis remiasi istoriniaisduomenimis, surinktais laiko fiksavimo praktikos metu. Duomenys kategorizuojami atsižvelgiantį objekto tipą (pvz., duomenų įvedimą užtikrinantis objektas). Turint keletą tai pačiai kategorijaipriklausančių objektų bei kiekvieno iš jų kūrimui sugaišto laiko įverčius, galima apskaičiuoti,kiek laiko užtruktų tokios kategorijos objekto kūrimas (skaičiuojamas laikų aritmetinis vidurkisarba naudojamasi sudėtingesniais statistiniais metodais).Laiko prognozavimo tikslumo didinimas. Turint istorinius duomenis <strong>ir</strong> prognozuotuskomponentų/objektų sukūrimui reikalingus laiko įverčius, tikslinamas/keičiamas prognozavimometodas, pas<strong>ir</strong>enkami labiau tinkantys įrankiai.PeržiūrosTikslas. Naudojantis apibrėžtais metodais, patikrinti objekto kokybę.Aprašymas. Projekto <strong>ir</strong> kodo peržiūrų veiklos bei kontrolinių sąrašų (angl. checklists)naudojimas pripažinti vienomis iš svarbiausių <strong>ir</strong> didžiausią įtaką kuriamo produkto kokybeiturinčių veiklų. Jų įdiegimo nauda akivaizdi: pastoviai atnaujinami kontroliniai sąrašai įgalinaatsekti dažniausiai pasitaikančias klaidas, jų rūšis <strong>ir</strong> tendencijas, padeda užtikrinti projekto <strong>ir</strong>kodo išbaigtumą <strong>ir</strong> darbo kokybę, tuo pačiu šios veiklos neužima daug laiko <strong>ir</strong> nereikalaujadidelių pradinių investicijų.Realizacija. Projekto metu kiekvienas programų sistemų kūrėjas atlieka kodo peržiūras.Peržiūroms naudojami kontroliniai sąrašai, kuriuose pateikiama informacija apie dažniausiaiMokymo medžiaga 88
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasprogramų sistemų kūrėjo pasitaikančius defektus. Peržiūrų metų ypatingas dėmesys kaip tik <strong>ir</strong>kreipiamas dažniausiai pasitaikančių defektų paieškai. Atliekant peržiūras visi defektaifiksuojami <strong>ir</strong> kontroliniai sąrašai atnaujinami.Proceso tobulinimasTikslas. Pastoviai tobulinti procesą, atsižvelgiant į proceso metu sukauptus istoriniusduomenis <strong>ir</strong> rodiklius.Aprašymas. Šios veiklos metu atliekama ciklo metu surinktų duomenų peržiūra. Peržiūrostikslai - surinkti proceso duomenis bei rodiklius <strong>ir</strong> juos išanalizuoti, identifikuoti, kada procesasveikė sklandžiai, o kada kilo problemų.Analizės metu nustatoma, ar pasiteisino prieš ciklą pasiūlyti proceso <strong>ir</strong> veiklųpakeitimai/patobulinimai. Jeigu peržiūros metu paaiškėja, jog naudinga keisti procesą ar kuriasnors iš veiklų, pakeitimai pateikiami tam tikslui paruoštoje proceso gerinimo pasiūlymų formoje(angl. Process Improvement Proposal).Proceso gerinimo pasiūlymų veikla įtraukiama PSP0.1 lygio procese, taigi, procesogerinimo veiklos ats<strong>ir</strong>anda jau pradiniame procese.PSP principų <strong>ir</strong> praktikų sąryšiaiŽemiau pateikiama PSP procesų principų <strong>ir</strong> praktikų sąryšių lentelė, t.y. kokius PSPprincipus kokios praktikos įgyvendina.PrincipasProgramų sistemų kūrėjaid<strong>ir</strong>bs efektyviai jei naudosapibrėžtą <strong>ir</strong> matuojamąprocesą (apibrėžtas,matuojamas)ĮgyvendinančiosLaikopraktikosfiksavimasDefektųfiksavimasDydžiofiksavimasPraktikos veiklosReikalingų duomenų aibės, matavimotikslumo apibrėžimasDuomenų surinkimo <strong>ir</strong> kaupimo formosapibrėžimasDuomenų surinkimasReikalingų duomenų aibės, matavimotikslumo apibrėžimasDuomenų surinkimo <strong>ir</strong> kaupimo formosapibrėžimasDuomenų surinkimasReikalingų duomenų aibės, matavimotikslumo apibrėžimasDuomenų surinkimo <strong>ir</strong> kaupimo formosapibrėžimasMokymo medžiaga 89
Programų sistemų inžinerijaPrincipasKad procesas geriausiaiatitiktų individualiusporeikius <strong>ir</strong> asmenssugebėjimus, jis turi būtipritaikytas (pritaikytas)Suteikti galimybę programųkūrėjams d<strong>ir</strong>bti taip, kaip jieįpratę, tačiau prisilaikantnustatytų nurodymų,procedūrų bei atsižvelgiant įjų pačių surinktus duomenis<strong>ir</strong> kolegų pat<strong>ir</strong>tį (efektyvus).Norint pastoviai gerinti savoveiklą reikia nuolat tobulintiprocesą, atsižvelgiant įproceso naudojimo metusukauptus istoriniusduomenis <strong>ir</strong> rodiklius(evoliucionuojantis).7. Asmeninis programų kūrimo procesasĮgyvendinančiosPraktikos veiklospraktikosDuomenų surinkimasStandartų Defektų tipų standarto paruošimasapibrėžimas Kodavimo standarto paruošimasDydžio standarto paruošimasVisos praktikos turi būti pritaikytos asmeniniam naudojimuiDydžio Prognozavimo metodikos pas<strong>ir</strong>inkimas <strong>ir</strong>prognozavimas procedūrų apibrėžimasProjekto produktų (pvz.objektų/komponentų) dydžio prognozavimasDydžio prognozavimo tikslumo didinimas(duomenų, rodiklių koregavimas), lyginantprognozes su realiais projekto produktų(pvz. objektų/komponentų) dydžiaisLaiko Prognozavimo metodikos pas<strong>ir</strong>inkimas <strong>ir</strong>prognozavimas procedūrų apibrėžimasProjekto produktų sukūrimui (pvz.objektų/komponentų) reikalingo laikoprognozavimasLaiko prognozavimo tikslumo didinimas(duomenų, rodiklių koregavimas), lyginantprognozes su realiais projekto produktųsukūrimo laiko įverčiais.Proceso Tobulinimo pasiūlymų surinkimas <strong>ir</strong> bendrųtobulinimas tobulinimo žingsnių numatymas.Mokymo medžiaga 90
Programų sistemų inžinerijaPrincipasKad gamintum kokybiškusproduktus, privalai jaustisatsakingu už jų kokybę.Surasti <strong>ir</strong> ištaisyti defektusprojekto pradžioje kainuojamažiau nei projektopabaigoje; daugveiksmingiau užk<strong>ir</strong>sti keliądefektų ats<strong>ir</strong>adimui nei jųvėliau ieškoti <strong>ir</strong> taisyti(orientuotas į kokybę,ankstyvas defektų šalinimas).ĮgyvendinančiospraktikosPeržiūrosPeržiūros atlikimas.7. Asmeninis programų kūrimo procesasPraktikos veiklosPSP mokymų įtakos asmeniniam procesui tyrimaiBuvo atlikti bandymai statistiniais metodais nustatyti, kokią įtaką atsk<strong>ir</strong>o inžinieriausasmeniniam procesui turi PSP proceso metu gautos žinios <strong>ir</strong> kaip tai atsispindi surinktuoseduomenyse. W.Hayes <strong>ir</strong> J.W.Over atliktuose tyrimuose dalyvavo 298 inžinieriai, kurie visi kartupraleido daugiau nei 15.000 valandų rašydami daugiau nei 300.000 eilučių kodo. Į 23 grupessusk<strong>ir</strong>styti inžinieriai buvo apmokomi tiek akademinėje, tiek <strong>ir</strong> realioje darbinėje aplinkoje. PSPproceso metu surinkti duomenys buvo naudojami paties PSP proceso vertinimui atlikti, norintparodyti, jog įsisavinus PSP procesą geriau atliekamos laiko bei dydžio vertinimo veiklos,sumažėjo klaidų kiekiai <strong>ir</strong> tai visiškai nepaveikė produktyvumo.Duomenų imtis <strong>ir</strong> statistinis modelisKiekvienos užduoties atlikimo metu inžinieriai surinko iki 70 rodiklių, kurie naudojamiasmeninio programų kūrimo proceso analizei bei jo tobulinimui. Taip pat PSP mokymų metubuvo apibrėžtos surinktų duomenų analizės veiklos, kurių rezultatai buvo pateikiami kartu suproceso duomenimis užpildytomis formomis <strong>ir</strong> ataskaitomis. Visi duomenys buvo pateikiamipopierinių formų pavidalu, o instruktoriai šiuos duomenis suvesdavo į PSP proceso duomenųanalizei paruoštas lenteles. Surinkti duomenys išanalizuojami, o bendri grupės rezultataipateikiami kiekvienam inžinieriui, kad galėtų savo rezultatus palyginti su grupės rezultatais.Autoriai teigia, jog kursų metu nekilo jokių abejonių dėl inžinierių surenkamų <strong>ir</strong> analizeipateikiamų duomenų kokybės. Surinktų duomenų analizei <strong>ir</strong> agregavimui autoriai nenaudojojokių automatinių įrankių (tik tam sk<strong>ir</strong>tas popierines formas), taip pat nebuvo atliekamasMokymo medžiaga 91
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasnepriklausomas surinktų duomenų patikrinimas ar jų kokybės vertinimas. Nepaisant to, autoriaiteigia, jog surinkti duomenys buvo “išsk<strong>ir</strong>tinės kokybės”.Visų mokymo kursų eigoje tyrimo autoriai analizavo pasikeitimus kiekvieno iš inžinieriųpateikiamuose duomenyse. Buvo stebimi ne tik grupės duomenų vidurkių pasikeitimai, betkiekvieno iš inžinierių surinktų <strong>ir</strong> apdorotų rodiklių pokyčiai. Statistinei analizei naudotaspasikartojančių matavimų sk<strong>ir</strong>tumų analizės metodas (ANOVA). Šis metodas naudingas tada,kai reikia pamatuoti to paties individo progresą, atliekant eilę bandymų. Ankstesni bandymailaikomi pagrindu <strong>ir</strong> analizuojami tik sk<strong>ir</strong>tumai tarp bandymų metu surinktų duomenų. Šismetodas buvo naudojamas visų kursų metu surinktų svarbiausių rodiklių statistinei analizei.Dydžio vertinimasSugebėjimas tiksliai vertinti būsimo produkto ar komponento dydį yra vienas išsvarbiausių dalykų norint paruošti tikslų projekto planą. Tyrimo metu autoriai įsitikino, jogįsisavinę PSP procesą, inžinieriai sugeba žymiai tiksliau numatyti būsimo produkto dydį <strong>ir</strong> tuopačiu geriau suplanuoti savo laiką jo kūrimui. Vidutiniškai inžinieriai 2,5 karto tiksliau vertinobūsimo produkto dydį pasiekę PSP 2-ąjį lygį, lyginant su PSP 0 lygiu. Tai pavyko pasiektidaugiau nei 50% tyrime dalyvavusių inžinierių. Skelbdami tokius įspūdingus tyrimo rezultatus,autoriai nepateikia duomenų, kaip buvo vertinama surinktų duomenų kokybė <strong>ir</strong> matavimųtikslumas bei kokios priemonės naudotos PSP duomenų kaupimui, analizavimui <strong>ir</strong> apdorojimui.Pastangų <strong>ir</strong> laiko vertinimas“Istorinių duomenų” naudojimas, vertinant būsimas laiko sąnaudas, yra priimta praktikaprogramų sistemų kūrimo industrijoje. Tačiau vertinti individualaus asmens laiko sąnaudas visdar yra pakankamai sudėtinga. PSP proceso metu asmuo įgyja teorinių <strong>ir</strong> praktinių žinių kaip šiąveiklą atlikti kiek įmanoma tiksliau <strong>ir</strong> kokybiškiau. Vidutiniškai inžinieriai 1,75 karto tiksliauvertino būsimam produktui sukurti reikalingą laiką pasiekę PSP 2-ąjį lygį lyginant su PSP 0lygiu. Tai pavyko pasiekti daugiau nei 50% tyrime dalyvavusių inžinierių. Skelbdami tokiusįspūdingus tyrimo rezultatus, autoriai nepateikia duomenų, kaip buvo vertinama surinktųduomenų kokybė <strong>ir</strong> matavimų tikslumas bei kokios priemonės naudotos PSP duomenų kaupimui,analizavimui <strong>ir</strong> apdorojimui.Klaidų kiekisKlaidų kiekio mažinimas tiesiogiai susijęs su laiko sąnaudų sumažėjimu, reikalingu tomsklaidoms ištaisyti. Tuo pačiu, PSP procesas įgalina klaidas ištaisyti ankstyvoje produkto kūrimostadijoje, o tai sumažina klaidų taisymo išlaidas. Vidutiniškai inžinieriai 1,5 karto sumažinopaliekamų klaidų kiekį savo programose pasiekę PSP 2-ąjį lygį lyginant su PSP 0 lygiu.Skelbdami tokius įspūdingus tyrimo rezultatus, autoriai nepateikia duomenų, kaip buvoMokymo medžiaga 92
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasvertinama surinktų duomenų kokybė <strong>ir</strong> matavimų tikslumas bei kokios priemonės naudotos PSPduomenų kaupimui, analizavimui <strong>ir</strong> apdorojimui.ProduktyvumasKadangi naudojamas statistinis metodas (ANOVA) įgalina stebėti pokyčius vieno asmenslygyje, tai padeda išryškinti tam tikras tendencijas bei asmens produktyvumo pokyčius. Tyrimoautoriai pastebi, jog nors <strong>ir</strong> pastebimi tam tikri produktyvumo svyravimai, jie yra pakankamainežymūs. Tai leidžia teigti, jog PSP proceso naudojimas produktyvumo nesumažina.IšvadosŠį tyrimą galima prisk<strong>ir</strong>ti tokių tyrimų, kurių rezultatai gali nevisiškai atitikti realiąsituaciją dėl nekontroliuojamos tyrimo metu surinktų duomenų kokybės <strong>ir</strong> nepriklausomomatavimų tikslumo vertinimo nebuvimo. Tyrimo autoriai teigia, jog kursų metu nekilo jokiųabejonių dėl inžinierių surenkamų <strong>ir</strong> analizei pateikiamų duomenų kokybės. Surinktų duomenųanalizei <strong>ir</strong> agregavimui autoriai nenaudojo jokių automatinių įrankių (tik tam sk<strong>ir</strong>tas popierinesformas), taip pat nebuvo atliekamas nepriklausomas surinktų duomenų patikrinimas ar jųkokybės vertinimas. Nepaisant to, autoriai teigia, jog surinkti duomenys buvo “išsk<strong>ir</strong>tinėskokybės”. Tuo pačiu, nėra apibrėžiama kokios PSP priemonės buvo naudotos atliekant laiko,dydžio vertinimus <strong>ir</strong> kaip jos buvo standartizuotos. Be to, autoriai atmeta prielaidą, jog duomenųaibėse galimos tam tikros paklaidos. Tokia prielaida nėra teisinga, ypač žinant, jog duomenyssurenkami popierinėse formose, o apdorojimui nenaudojami automatiniai įrankiai. Žinant, jogpagal PSP proceso metu surinktus duomenis yra vertinamas pats procesas <strong>ir</strong> siūlomi jokeitimai/tobulinimai, netikslūs duomenys gali neigiamai įtakoti asmens procesą <strong>ir</strong> jo tobulinimokelią.PSP proceso taikymo pramonėje pavyzdžiaiNepaisant didelio susidomėjimo PSP procesu, literatūros, aprašančios šio proceso taikymuspramonėje, yra labai mažai. Didžioji dauguma darbų aprašo bandymus <strong>ir</strong> jų metu pasiektusįspūdingus rezultatus izoliuotoje mokymų klasės aplinkoje, todėl tai neleidžia spręsti apie PSPproceso tinkamumą realioje – pramoninėje aplinkoje. Vieni iš nedaugelio darbų, aprašančių PSPproceso diegimo pramonėje rezultatus yra M.Stavros, M.Morisio <strong>ir</strong> E.George paskelbti darbai.Šių darbų autoriai tiesiogiai dalyvavo PSP diegimo procesuose kaip vykdytojai arba konsultantai<strong>ir</strong> identifikavo su PSP proceso diegimu susijusias problemas bei paties proceso privalumus <strong>ir</strong>trūkumus. Diegimai buvo vykdomi kompanijose, turinčiose pakankamai dideles programuotojųkomandas (40-50 programuotojų) <strong>ir</strong> jau nusistovėjusius programinių produktų kūrimo procesus.PSP proceso diegimo rezultatai pakankamai panašūs: nemodifikavus PSP proceso, nepritaikiusprie organizacinių procesų <strong>ir</strong> neautomatizavus duomenų surinkimo <strong>ir</strong> apdorojimo, jopanaudojimas pramonėje yra pakankamai komplikuotas <strong>ir</strong> ribotas.Mokymo medžiaga 93
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasPSP apmokymaiAbiejose kompanijose buvo pas<strong>ir</strong>inkti panašūs PSP proceso apmokymo keliai – pas<strong>ir</strong>inktanuotolinio PSP mokymo programa, specialiai paruošta įmonėms, norinčios įsidiegti PSP procesą,bet negalinčioms viso darbuotojų laiko sk<strong>ir</strong>ti vien tik mokymams. Pas<strong>ir</strong>inktos panašios savostruktūra <strong>ir</strong> pritaikymu, tačiau sk<strong>ir</strong>tingos trukmės PSP apmokymų programos:• 8 savaičių trukmės programa, viso mokymų periodo metu organizacija turėjo galimybębendrauti su savo mokytojais <strong>ir</strong> jiems pateikinėjo savo atliktas užduotis bei surinktus duomenis;• intensyvesnė 3 savaičių trukmės programa, suskaidyta į 3 dviejų dienų seminarus; tokssprendimas buvo priimtas, atsižvelgiant į resursų, galinčių pakeisti/pavaduoti pilną darbo dienąmokymams sk<strong>ir</strong>iančius darbuotojus, trūkumą.Kitas sprendimas, kurį turėjo priimti kiekviena iš aprašomų organizacijų – parinktidarbuotojus, kurie bus apmokomi PSP mokymo programoje. Abiem atvejais buvo pas<strong>ir</strong>inktiaukštesnes pareigas užimantys darbuotojai (vyresnieji programuotojai), turintys daugiau nei 5metų programavimo darbų pat<strong>ir</strong>tį, laiku įvykdantys jiems pask<strong>ir</strong>tas užduotis, dalyvavęprojektuojant aukštos kokybės produktus bei gerai susipažinę su organizacijų programų kūrimoprocesais. Pas<strong>ir</strong>inkti darbuotojai taip pat dalyvavo ankstesniuose programų kūrimo procesųtobulinimo darbuose: CMM proceso gerinimo projekte bei ISO 9000-1 sertifikavimo procese.Kadangi nė vienos iš organizacijų darbuotojai negalėjo PSP mokymams sk<strong>ir</strong>ti viso savolaiko, buvo pas<strong>ir</strong>inkti sk<strong>ir</strong>tingi šios problemos sprendimo būdai.P<strong>ir</strong>mu atveju organizacija stengėsi kuo mažiau nukrypti nuo mokymo programoje siūlomųterminų. Atsižvelgiant į programoje dalyvaujančių darbuotojų kompetenciją, buvo pas<strong>ir</strong>inkta 20valandų per savaitę sk<strong>ir</strong>ti mokymams, o likusias 20 – tiesioginėms darbuotojų užduotims atlikti.Tokios proporcijos buvo išlaikytos praktiškai viso mokymo kurso metu. Toks laiko sk<strong>ir</strong>stymaspas<strong>ir</strong>inktas neatsitiktinai – tai leido mokymų metu įgytas žinias iš karto taikyti praktikoje.Kadangi šie darbuotojai turėjo būti instruktoriai, apmokysiantys visus programinius produktuskuriančius organizacijos darbuotojus, buvo suformuota antra darbuotojų grupė, kuriuos <strong>ir</strong> turėjoapmokyti PSP mokymo kursą baigę p<strong>ir</strong>mosios grupės darbuotojai. Ši komanda buvo sudaryta išjauniausių <strong>ir</strong> mažiausią pat<strong>ir</strong>tį turinčių bei su organizacijos procesu nesusipažinusių darbuotojų.Priežastys, dėl kurių buvo nuspręsta formuoti antrąją grupę yra tokios:• Nustatyti p<strong>ir</strong>mosios komandos narių galimybes <strong>ir</strong> jiems kylančius sunkumus, apmokantlikusius programinius produktus kuriančius organizacijos darbuotojus.• Identifikuoti problemas <strong>ir</strong> kylančius sunkumus, mažiausią pat<strong>ir</strong>tį turintiems komandosnariams naudojant PSP procesą kasdienėje veikloje. Perprasti, kaip mažiausią pat<strong>ir</strong>tį turintyskomandos nariai supranta <strong>ir</strong> sprendžia problemas, kurdami programinius produktus.Mokymo medžiaga 94
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas• Įtraukti mažiausią pat<strong>ir</strong>tį turinčius komandos narius į organizacijos programiniųproduktų kūrimo procesą, laikantis apibrėžtų disciplinos normų asmeniniame lygmenyje.• Sukurti komandą, galinčią dalintis idėjomis, susijusiomis su asmeninio programųkūrimo proceso tobulinimu, laikantis PSP <strong>ir</strong> organizacinio proceso.Antru atveju organizacijos darbuotojai kartu su instruktoriais nusprendė visą 3 savaičiųtrukmės programą suskaidyti į 3 dviejų dienų seminarus (kiekvienas iš seminarų buvo sk<strong>ir</strong>taspristatyti vieną iš PSP lygmenų), su kelių mėnesių pertrauka tarp jų, sk<strong>ir</strong>ta eksperimentavimui -gautų teorinių žinių pritaikymui darbinėje aplinkoje. Tuo pačiu buvo atsisakyta kai kuriųpraktinių užduočių, kadangi jos pas<strong>ir</strong>odė pernelyg paprastos <strong>ir</strong> teikiančios mažai naudos.Abiem atvejais buvo atkreiptas dėmesys į PSP mokymams parinktas praktines užduotis:jos pas<strong>ir</strong>odė pernelyg paprastos <strong>ir</strong> nerealistiškos, t.y. pritaikytos tik akademiniams užsiėmimams.Taip pat buvo prieita išvados, jog darbuotojai rodo didesnį aktyvumą mokymųsi metu, kai juosapmoko kviestiniai instruktoriai/konsultantai, o ne tos pačios organizacijos žmonės.Kadangi abi organizacijos mokymams skyrė nevienodai laiko, tai gauti gana sk<strong>ir</strong>ting<strong>ir</strong>ezultatai. P<strong>ir</strong>mu atveju organizacija mokymams skyrė itin didelį dėmesį, todėl didžioji dalisp<strong>ir</strong>mosios grupės narių sėkmingai įsisavino PSP procesą. Tačiau priešingai nei p<strong>ir</strong>mosioskomandos atveju, tik nedidelė dalis antrosios komandos narių sėkmingai baigė PSP mokymokursą. Tai lėmė kelios priežastys: nepakankamas instruktorių (p<strong>ir</strong>mosios komandos narių)dėmesys besimokantiems bei motyvacijos trūkumas.Antru atveju organizacijos darbuotojai patiems mokymams skyrė gana nedaug laiko, tačiaudaug laiko skyrė eksperimentavimams. Toks laiko pask<strong>ir</strong>stymas taip pat turėjo neigiamos įtakos<strong>ir</strong> tik dalis PSP kursą baigusių narių procesą tinkamai naudojo eksperimentavimo laikotarpiu.PSP adaptavimasNė viename iš nagrinėjamų atvejų PSP procesas nebuvo panaudotas toks, koks jis pateiktasWatts Humphrey. To priežastys aiškios - kiekviena iš organizacijų turi jau nusistovėjusįprogramų sistemų kūrimo procesą, todėl PSP procesas turi būti adaptuotas taip, kad jį papildytų,o ne iš esmės keistų. PSP proceso adaptacijos metu buvo išryškintos stipriosios <strong>ir</strong> silpnosios PSPproceso pusės, į kurias taip pat turėjo būti atsižvelgta. PSP proceso analizės metu buvo išryškintitokie proceso trūkumai <strong>ir</strong> privalumai.Trūkumai:• Programų sistemų kūrimo proceso metu programuotojas koduoja, renka <strong>ir</strong> analizuojadidelius kiekius duomenų, todėl PSP proceso duomenų rinkimas <strong>ir</strong> analizė ne tik reikalaujapapildomo laiko, bet <strong>ir</strong> atitraukia nuo tiesioginių užduočių vykdymo. Programuotojo atliekamoskasdienės užduotys ženkliai sk<strong>ir</strong>iasi nuo PSP proceso mokymams pateikiamų užduočių. Topasekoje programuotojui sunku taikyti PSP įrankius, atliekant kasdienes užduotis <strong>ir</strong> užduotisMokymo medžiaga 95
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasatlikti per nustatytus terminus. Tai bene svarbiausia priežastis, verčianti programuotojusatsisakyti PSP proceso.• Pateikiamų įrankių neužtenka tam, kad būtų automatizuotas PSP duomenų surinkimas <strong>ir</strong>apdorojimas, ypač kodo dydžio vertinimo atveju (LOC matavimas).• PSP numato, kad jau egzistuoja tinkamai apibrėžtas <strong>ir</strong> išanalizuotas bei dokumentuotassistemos projektas, prieš pradedant įgyvendinimo (kodavimo) darbus. Tai skelbiama kaip būtinasąlyga, tačiau bendru atveju ši sąlyga yra retai patenkinama gamybos aplinkoje, kai reikiaypatingai greitai reaguoti į pasikeitusius kliento poreikius. PSP aprašomas modelis daugiautinkamas programų sistemų kūrimo projektams, kuriuose įgyvendinimo fazės kaštai yra labaidideli, lyginant su projektavimo fazės kaštais.• PSP proceso duomenims analizuoti reikalingi įrankiai, kurie būtų integruoti suorganizacijos naudojamais įrankiais, o tai dar labiau padidina tokių įrankių įsigijimo kaštus.Išeitis - patiems kurti organizacijai <strong>ir</strong> konkrečiam procesui pritaikytus automatinius įrankius.• Bene sudėtingiausia PSP proceso taikymo dalis yra kodo eilučių skaičiavimo (LOC)standartizavimas <strong>ir</strong> jo taikymas: pridėtų, pakeistų, pašalintų kodo eilučių skaičiavimas. Šiosrūšies duomenų rinkimas užima daug laiko netgi naudojant automatinius įrankius. Buvonuspręsta komponentų <strong>ir</strong> objektų vertinimui naudoti ne kodo eilučių skaičiavimo metodą, betvertinant atsižvelgti į objekto tipą <strong>ir</strong> jam prisk<strong>ir</strong>tą atitinkamą kategoriją bei jo sukūrimu<strong>ir</strong>eikalingą laiką.• PSP procese ypatingas dėmesys kreipiamas į turimų komponentų pakartotinįpanaudojamumą kodavimo metu. Tuo tarpu organizacijoje komponentų pakartotinispanaudojamumas apsprendžiamas jau analizės <strong>ir</strong> projektavimo fazių metu.Privalumai:• Projekto <strong>ir</strong> kodo peržiūrų veiklos bei kontrolinių sąrašų (checklists) naudojimaspripažinti vienos iš svarbiausių <strong>ir</strong> didžiausią įtaką kuriamo produkto kokybei turinčių veiklų. Jųįdiegimo nauda akivaizdi: pastoviai atnaujinami kontroliniai sąrašai įgalina atsekti dažniausiaspasitaikančias klaidas, jų rūšis <strong>ir</strong> tendencijas, padeda užtikrinti projekto <strong>ir</strong> kodo išbaigtumą <strong>ir</strong>darbo kokybę, tuo pačiu šios veiklos neužima daug laiko <strong>ir</strong> nereikalauja didelių pradiniųinvesticijų.• Laiko sąnaudų užduotims įgyvendinti fiksavimas leidžia tiksliau prognozuoti produktokūrimui reikalingo laiko sąnaudas bei nuspėti, kiek vidutiniškai laiko trunka “trukdžiai”.• PSP siūlomas klaidų fiksavimas <strong>ir</strong> kategorizavimas bei pastovus klaidų kontroliniųsąrašų atnaujinimas leidžia susidaryti gana tikslų vaizdą apie dažniausiai sutinkamas klaidas <strong>ir</strong>netgi iš anksto numatyti <strong>ir</strong> paruošti tam tikrus nurodymus, kaip tokių klaidų išvengti. AsmensMokymo medžiaga 96
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesaslygmenyje klaidų sąrašai įgalina žinoti savo dažniausiai įveliamas klaidas <strong>ir</strong> geriau atliktiprojektavimo bei kodavimo darbus.• Komponentų/objektų kategorizavimas bei istorinių duomenų apie kiekvienos rūšieskomponentus/objektus rinkimas leidžia tiksliau prognozuoti būsimo produkto dydį bei josukūrimui reikalingą laiką. Tačiau dydžiui matuoti naudojamas ne PSP siūlomas kodo eilučiųskaičiavimo metodas, bet objekto atitikimas pagal jo tipą tam tikro sudėtingumo kategorijai.• Formaliai bei išsamiai apibrėžtos testavimų metu naudojamos formos <strong>ir</strong> testų scenarijai.• PSP suteikia galimybę programų kūrėjams d<strong>ir</strong>bti taip, kaip jie įpratę, tačiau prisilaikantnustatytų nurodymų, procedūrų bei atsižvelgiant į jų pačių surinktus duomenis <strong>ir</strong> kolegų pat<strong>ir</strong>tį.AdaptacijaAtsižvelgiant į aukščiau įvardintus PSP proceso privalumus <strong>ir</strong> trūkumus bei organizacijosįsisavintą programinių produktų kūrimo metodologiją <strong>ir</strong> įrankius, buvo adaptuotas PSP procesas.Adaptuotas procesas turėjo atitikti tokius reikalavimus:• Palikti tik reikalingiausias veiklas <strong>ir</strong> įnešti kuo mažiau painiavos.• Ypatingą dėmesį kreipti būsimų produktų laiko <strong>ir</strong> dydžio prognozuojamumo gerinimui.• Sumažinti klaidų kiekį klientams pateikiamuose produktuose.• Sekti <strong>ir</strong> fiksuoti kiekvieno iš vykdomų projektų duomenis vėlesnei analizei.• Pritaikyti projekto <strong>ir</strong> kodo peržiūrų bei kontrolinių sąrašų dokumentus.• Sumažinti projektams įgyvendinti sugaištamo laiko kiekį.• Proceso gerinimo veiklą įtv<strong>ir</strong>tinti kaip besitęsiantį procesą, kuris teikia naudos tiekprogramų sistemų kūrėjui, tiek <strong>ir</strong> organizacijai.Adaptuojant procesą didžioji dauguma scenarijų <strong>ir</strong> formų buvo įtraukti be pakeitimų.Daugiausia pakeitimų buvo atlikta komponentų/objektų dydžio vertinimo veiklose <strong>ir</strong>atitinkamose formose.Antru atveju PSP proceso adaptacijos metu buvo atlikti tokie svarbiausi pakeitimai:• PSP buvo modifikuotas taip, kad atsižvelgtų į sk<strong>ir</strong>tingus projektus (naujų funkcijųdiegimo projektai, klaidų taisymai) bei suteiktų galimybę dalintis užduotimis tarp komandosnarių <strong>ir</strong> vienu metu vykdyti kelis projektus.• PSP procesas modifikuotas atsisakant asmeninės projekto peržiūros veiklos, kadangiįmonėje už projekto peržiūrą atsakinga komanda.• Kadangi PSP procesas neapima projekto (produkto) palaikymo veiklų <strong>ir</strong> neįvertinadefektų atrastų jau naudojant produktą, PSP procesas papildytas šiomis veiklomis <strong>ir</strong> kokybėsvertinimo metu atsižvelgta į tokius defektus.Mokymo medžiaga 97
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas• Įvesti du proceso vertinimo lygiai – asmeninis <strong>ir</strong> komandinis. Asmeniniam procesuivertinti naudojamos PSP proceso metu surinkti rodikliai, o komandiniam – agreguoti visųkomandos narių rodikliai: bendro komandos laiko matavimas, komandos laiko matavimaskiekvienam ciklui, taisymų <strong>ir</strong> tobulinimų vertinimas <strong>ir</strong> pan.• Sukurtas įmonės darbuotojams pritaikytas įrankis, automatizuojantis formų pildymą <strong>ir</strong>rodiklių skaičiavimą.• Užtikrintas surinktų duomenų <strong>ir</strong> rodiklių privatumas.Adaptuoto PSP proceso taikymasSekantis žingsnis, adaptavus PSP procesą, buvo visų programinius produktus kuriančiųdarbuotojų apmokymas. Pagrindinė problema, su kuria susidurta apmokymų metu - darbuotojųnenoras priimti naują procesą <strong>ir</strong> visus su jo diegimu <strong>ir</strong> naudojimu susijusias sunkumus.Darbuotojų nuomone PSP buvo vertinamas kaip vadovybės noras nurodinėti kaip reikia d<strong>ir</strong>bti, one noras padėti jiems tobulėti. Pabrėžiama, jog ši problema buvo išspręsta specialiai tam sk<strong>ir</strong>tųseminarų metu, kuriuose įspūdžiais <strong>ir</strong> patarimais dalinosi p<strong>ir</strong>mosios grupės nariai, p<strong>ir</strong>miejiišbandę <strong>ir</strong> adaptavę PSP procesą, todėl geriausiai žinantys jo privalumus <strong>ir</strong> trūkumus.PSP diegimo rezultataiPSP procesas buvo taikomas daugiau nei 4 mėnesius, per kuriuos išryškėjo tam tikriadaptuoto proceso privalumai <strong>ir</strong> trūkumai. Išanalizavus per šį laikotarpį surinktus duomenis buvoparuošta eksperimentinio PSP diegimo projekto ataskaita.Apibendrinimas• Testų metu randamų klaidų skaičius sumažėjo 15%.• Laiko sąnaudos <strong>ir</strong> produkto dydis prognozuojami su 10% paklaida, lyginant su 20%paklaida prieš PSP proceso diegimą.• Nepastebėta jokių esminių produktyvumo pokyčių naudojant PSP procesą, tačiausumažėjo laiko, sk<strong>ir</strong>iamo produkto kompiliavimui sąnaudos.• PSP proceso taikymas padidina laiko sąnaudas 15%, tačiau ilgainiui jos turėtų sumažėtiiki 5%, kadangi PSP proceso veiklų taikymas turi tapti įpročiu.• Reikalinga jau egzistuojanti proceso infrastruktūra, kuri būtų tarpinis žingsnis diegiantPSP procesą. Konkrečiu atveju CMM 2 lygio organizacijos procesas žymiai pagreitino PSPproceso panaudojimo galimybes.• Ženkliai padidėjo darbuotojų motyvacija kurti kokybiškus produktus.• Pagerėjo kuriamų produktų kokybė.• Padidėjo darbuotojų pasitenkinimas jų atliekamu darbu, o tai suteikia galimybę toliauoptimizuoti PSP procesą bei pritaikyti jį kitose srityse.Mokymo medžiaga 98
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasVeiklos rezultataiVadovybė, analizuodama organizacijos veiklos rezultatus, įsitikino, jog įdėtas pastangas,diegiant PSP procesą organizacijoje, atperka pagerėjusi kuriamų produktų kokybė, o ilgainiui - <strong>ir</strong>išaugsiantis produktyvumas. Įdėtas investicijas <strong>ir</strong> su PSP diegimu susijusius sunkumus atsverspagerėjęs laiko sąnaudų <strong>ir</strong> pastangų, reikalingų produktui sukurti, vertinimas. Tai svarbūsfaktoriai, norint išlikti konkurencingais rinkoje. Tuo pačiu, patraukliai atrodo <strong>ir</strong> galimybė PSPprocesą pritaikyti kitose, su kodavimu nesusijusiose srityse. P<strong>ir</strong>masis bandymas pritaikytiatitinkamai modifikuotą PSP procesą ataskaitų kūrimo veiklai pavyko, todėl neatmetamagalimybė jį adaptuoti <strong>ir</strong> produkto palaikymo veikloms. Žvelgiant dar toliau, PSP procesoįdiegimas organizacijoje galėtų jai padėti pasiekti <strong>ir</strong> aukštesnį CMM proceso lygį.OrganizacijaDidžiausią sus<strong>ir</strong>ūpinimą organizacijos vadovams kėlė galimas darbuotojų nenoras priimtisu PSP proceso diegimu susijusius pasikeitimus jų kasdieninėje veikloje, kadangi šiepasikeitimai būtų priimti kaip vadovų noras kontroliuoti kiekvieną iš darbuotojų. Tačiaupas<strong>ir</strong>odė, jog PSP procesas leidžia darbuotojams d<strong>ir</strong>bti taip, kaip jie yra įpratę, tačiau laikantistam tikrų procedūrų, leidžiančių kiekvienam iš jų kiekybiškai <strong>ir</strong> kokybiškai įvertinti savo veikląbei palyginti savo rezultatus su kolegų pasiekimais. Todėl adaptuojant PSP procesą buvostengiamasi minimizuoti pokyčius esamo proceso infrastruktūroje. Dėl šios priežasties nebuvokuriamos nei naujos procedūros, nei diegiami nauji įrankiai - jau egzistuojančios procedūros <strong>ir</strong>įrankiai buvo modifikuoti taip, kad atitiktų PSP reikalavimus. Tai buvo bene pagrindinėpriežastis leidusi sulaukti minimalaus pasipriešinimo iš darbuotojų pusės.ĮgūdžiaiPSP proceso diegimo metu paaiškėjo, jog PSP mokymų metu gautų įgūdžių nepakankanorint sėkmingai įdiegti procesą. P<strong>ir</strong>mu atveju šį trūkumą organizacija kompensavoorganizuodama specialius seminarus, kurių metu buvo analizuojamas PSP procesas <strong>ir</strong> numatomakaip jis galėtų būti diegiamas gamybinėje aplinkoje. Taip pat paaiškėjo, jog darbuotojai labiaustengiasi <strong>ir</strong> jų motyvacija ženkliai didesnė, kai juos apmoko konsultantai, o ne apmokyti pačiosorganizacijos darbuotojai. Teigiamai motyvaciją veikia <strong>ir</strong> galimybė gauti sertifikatą, kuris yrakaip atlygis už mokymams sugaištą laiką.Antru atveju buvo gauti kitokie PSP proceso diegimo rezultatai <strong>ir</strong> išvados. Organizacijainepavyko sėkmingai įdiegti PSP proceso veiklų, dėl šių priežasčių:• Nesugebėjimo PSP mokymų metu gautų įgūdžių pritaikyti komandinėje aplinkoje.• Chaotiškai sk<strong>ir</strong>stomų užduočių prioritetų, kas neleidžia pakankamai tiksliai įvertint<strong>ir</strong>eikalingų laiko sąnaudų <strong>ir</strong> sudaryti tikslių planų.• Netiesioginių veiklų vykdymo (pvz.: pagalba marketingo žmonėms).Mokymo medžiaga 99
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas• Nesugebėjimo panaudoti produkto dydžio vertinimui kodo eilučių skaičiaus matavimovienetą (LOC).Atmestino proceso duomenų rinkimo.Nepakankamo vadovybės palaikymo.Pagrindinės išvados:• PSP įvestos klaidų klasifikavimo <strong>ir</strong> analizės veiklos užtikrino geresnę galutinioprodukto kokybę.• Nepastebėta jokių esminių pokyčių klaidų rūšims.• PSP požiūriu projektas patyrė nesėkmę, tačiau komandos darbo požiūriu PSP diegimasįnešė teigiamų pokyčių komandos darbui.• PSP naudingesnis kaip modelis, insp<strong>ir</strong>uojantis esančio proceso kaitą nei kaipmodifikacijų nereikalaujantis <strong>ir</strong> pilnai paruoštas naudojimui proceso modelis.• Norint tikėtis teigiamų rezultatų diegiant PSP procesą (komandos kontekste), būtinaPSP proceso adaptacija konkrečiam atvejui, automatinių įrankių sukūrimas <strong>ir</strong> visapusiškasvadovų palaikymas.PSP proceso duomenų kokybės problemaPSP yra asmeninės veiklos, susijusios su programų kūrimu, kokybės gerinimo procesas,akcentuojantis tris svarbiausius disciplinos aspektus: kokybės siekimą, tvarkaraščio/planųlaikymąsi <strong>ir</strong> pastovų tobulėjimą. Pagal PSP metodiką, asmuo kuria programas, naudodamasisgriežtai apibrėžtais <strong>ir</strong> struktūrizuotais metodais, leidžiančiais kurti aukštos kokybės produktussuplanuotais terminais. Nors PSP proceso naudojimas suteikia galimybę programų sistemųkūrėjui d<strong>ir</strong>bti disciplinuotai, tačiau dideli surenkamų duomenų kiekiai (daugiau kaip 500sk<strong>ir</strong>tingų rodiklių reikšmių vieno projekto metu) bei jų pateikimas popieriniu pavidalu (PSP2proceso lygyje reikia pildyti 12 sk<strong>ir</strong>tingų formų) verčia abejoti, ar galima pasitikėti surinktųduomenų kokybe bei jais remtis, priimant tam tikrus sprendimus. Norint atsakyti į šį klausimą,A.M.Disney <strong>ir</strong> P.M.Johnson atlikto specialų tyrimą.Prieš atliekant tyrimą, buvo iškelta hipotezė, jog klaidos PSP proceso surenkamuoseduomenyse gali ženkliai pakeisti kai kurių rodiklių, naudojamų pačiam procesui vertinti, vertes.Apskaičiuotos <strong>ir</strong> tikrosios rodiklių vertės gali sk<strong>ir</strong>tis tiek, kad to užtektų programuotojui priimtiklaidingus sprendimus, lemiančius jo asmeninio proceso tobulinimo eigą. Šiai hipotezeipatikrinti buvo atitinkamai paruoštas PSP procesas (užtikrinta geresnė proceso surenkamųduomenų kokybė) <strong>ir</strong> pristatytas 10 studentų grupei, kuri jį naudojo viso tyrimo metu. Vėlesnėsurinktų duomenų analizė patv<strong>ir</strong>tino tyrimo autorių hipotezę: buvo nustatyta v<strong>ir</strong>š 1500 klaidųpateikiamuose PSP proceso duomenyse, tiek pakeitusių kai kurių rodiklių vertes, jog buvopas<strong>ir</strong>inkti klaidingi proceso tobulinimo keliai.Mokymo medžiaga 100
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesasAnalizės rezultataiAutorių atlikta surinktų duomenų analizė parodė, jog t<strong>ir</strong>iamųjų pateiktuose duomenysebuvo daugiau nei 1500 klaidų. Analizės metu klaidos buvo kategorizuotos pagal jų:• tipą,• svarbą• “amžių” (kurio duomenų surinkimo ar apdorojimo etapo metu klaida buvo įvelta).Klaidoms ištaisyti <strong>ir</strong> duomenims atstatyti buvo apibrėžtas taisyklių rinkinys, kuriuonaudojantis pavyko atstatyti didžiąją daugumą klaidingai pateiktų rodiklių verčių. Palyginuspateiktus <strong>ir</strong> ištaisytus duomenis, buvo nustatyta, jog didžiausią įtaką klaidos turėjo klaidų tankiobei kainos-efektyvumo rodiklių vertėms. Tam tikrais atvejais sk<strong>ir</strong>tumas buvo pakankamaididelis, kad būtų pas<strong>ir</strong>inktas klaidingas išanalizuotų duomenų interpretavimas <strong>ir</strong> tuo pačiuneteisingas proceso tobulinimo kelias.Išvados <strong>ir</strong> rekomendacijos• Mokymų metu naudoti įrankius, leidžiančius automatizuoti PSP proceso surenkamųduomenų agregavimą <strong>ir</strong> analizę. Šie įrankiai turi būti pilnai integruoti, t.y. programuotojaspateikia tik pradinius proceso duomenis, o visos apskaičiuotų rodiklių reikšmės automatiškaipernešamos į kitas formas be programuotojo įsikišimo. Tai yra viena iš pagrindinių sąlygų,norint sėkmingai naudoti PSP procesą <strong>ir</strong> būti užtikrintiems gautų duomenų kokybe.• PSP proceso vertinimui nenaudoti PSP metrikų. Didžioji dalis skelbiamų PSP procesostudijų procesą vertina naudojant paties PSP proceso metrikas, t.y. lyginami PSP procesoduomenys surinkti mokymų pradžioje su duomenimis surinktais mokymo kursų pabaigoje. Taivadinama “vidinių matavimų vertinimu”, kadangi PSP procesas vertinamas paties proceso metusurinktų duomenų pagalba. Norint tinkamai įvertinti PSP proceso naudą reiktų naudoti “išoriniųmatavimų vertinimą”, kai PSP proceso efektyvumui vertinti lyginama programų sistemų kūrėjodarbo kokybė nenaudojant PSP proceso <strong>ir</strong> naudojant PSP procesą.• Nors automatiniai įrankiai užtikrina surinktų duomenų analizės kokybę, tačiau užtikrintisurenkamų duomenų kokybę beveik neįmanoma. Tai priklauso nuo kiekvieno PSP procesąvykdančio asmens noro <strong>ir</strong> motyvacijos pateikti pilnus <strong>ir</strong> korektiškus duomenis.• Aiškiai apibrėžti kokiu tikslu renkami duomenys, taip bus išvengta tyčinio duomenųklastojimo.Literatūra papildomam skaitymui[BOK05] The Personal Software Process SM (PSP SM ) Body of Knowledge, Version 1.0CMU/SEI-2005-SR-003Mokymo medžiaga 101
Programų sistemų inžinerija7. Asmeninis programų kūrimo procesas[DJ99]Anne M. Disney, Philip M. Johnson. A Critical Analysis of PSP Data Quality:Results from a Case Study, Dept. of Information and Computer Sciences,University of Hawaii, 1999.[Hum95] Watts S. Humphrey. A Discipline for Software Engineering. Addison-Wesley,1995.[Hum96] Watts S. Humphrey. Introduction to the Personal Software Process SM . Addison-Wesley, 1996.[Hum98] Watts S. Humphrey. Three Dimensions of Process Improvement Part II: ThePersonal Process. http://www.stsc.hill.af.mil/crosstalk/1998/mar/dimensions.html,1998.[Hum00] Watts S. Humphrey. The Personal Software Process (PSP), Technical Report,CMU/SEI-2000-TR-022, ESC-TR-2000-022, 2000.[Hum05] Watts S. Humphrey. PSP SM : A Self-Improvement Process for Software Engineers.Addison-Wesley Professional, 2005.[Mor00][Sta98]Maurizio Morisio. Applying the PSP in Industry, IEEE SoftwareNovember/December 2000, 0740-7459/00, 2000.Menegos Stavros. PERsonal Software Process Improvement PERSPI, Processimprovement experiment final report, ESSI project number: 24158, 1998.Mokymo medžiaga 102
Programų sistemų inžinerija8. Komandinis programų kūrimo procesas8. Komandinis programų kūrimo procesasTurint apmokytus disciplinuotai d<strong>ir</strong>bti inžinierius, iškyla klausimas, kaip reikia suburtikomandą <strong>ir</strong> organizuoti komandinį darbą, kad kiekvienas galėtų efektyviai taikyti disciplinuotodarbo įgūdžius. Be atitinkamų nurodymų <strong>ir</strong> paramos, komanda bus priversta bandymų <strong>ir</strong> klaidųkeliu išradinėti tai, kas jau pakankamai gerai žinoma <strong>ir</strong> sėkmingai naudojama. Tai verčia ieškotimetodų, remiančių komandos formavimą <strong>ir</strong> komandinio darbo palaikymą programų sistemųkūrimo kontekste. Komandos formavimo veiklos yra tokios, kurios formuoja vieningą supratimąapie komandai keliamus tikslus bei ugdo tarpusavio pasitikėjimą komandos nariais. Komandospalaikymo veiklos yra tokios, kurios palaiko pas<strong>ir</strong>inktą komandos taktiką <strong>ir</strong> kryptį, siekiantiškeltų tikslų, bei didina komandos vertę. Vienas iš modelių, pateikiančių atsakymus į iškeltusklausimus yra komandinio programų kūrimo proceso modelis TSP (angl. Team SoftwareProcess), kurio mokymui sk<strong>ir</strong>ta versija buvo pristatyta Watts S.Humphrey knygoje “Introductionto the Team Software Process” [Hum99], o pilnos TSP versijos apžvalgos pristatytosmoksliniuose darbuose [Hum98, Hum00] 4 .TSP procesas pakankamai smulkiai apibrėžia projektuose dalyvaujančių asmenų roles <strong>ir</strong>kiekvienos iš jų atsakomybes bei joms keliamus tikslus. Visas procesas išskaidomas loginiaisžingsniais, kuriuose aprašoma, kaip turi būti elgiamasi kiekvieno projekto etapo metu, kas turėtųbūti akcentuojama, o ko geriau vengti, kad projekto įgyvendinimas vyktų sklandžiai <strong>ir</strong> betrukdžių. Ypatingai daug dėmesio sk<strong>ir</strong>iama tiksliam viso proceso žingsnių dokumentavimui <strong>ir</strong>nuosekliam jų vykdymui. Tai turi padėti pereiti nuo bandymų <strong>ir</strong> ieškojimų kelio, prie konkrečiai<strong>ir</strong> labai tiksliai apibrėžto proceso metodų įsisavinimo <strong>ir</strong> jų įgyvendinimo. Susipažinus su šiamedžiaga turi sumažėti klausimų “kaip daryti”, “ką daryti” <strong>ir</strong> “kada daryti”, nes jie dažniausiaisutinkami esant neaiškumams projekto organizavime <strong>ir</strong> valdyme, o ši medžiaga kaip tik <strong>ir</strong>padeda, sekant nurodytu procesu, pereiti nuo organizavimo <strong>ir</strong> valdymo problemų sprendimo, prieprodukto kūrimo.TSP projektiniai sprendimaiYra daug būdų suprojektuoti procesą. TSP atveju buvo įgyvendinti septyni pagrindiniaiprojektiniai sprendimaiProcesas turi remtis PSPTSP turi daug formų <strong>ir</strong> scenarijų, bet daug iš jų sutampa su PSP. Žinant PSP, nesunku busišmokti atlikti naujus TSP darbus, nes jie remiasi panašiais principais. Nežinant PSP, greičiausiaiTSP procesai gali pas<strong>ir</strong>odyti sunkiai įveikiami.4 Reikia pažymėti, kad galima rasti tik apžvalgas, o pilnas TSP aprašymas yra viešai neprieinamas.Mokymo medžiaga 103
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasKurti produktus keliais ciklaisSiūloma produktą kurti keliais ciklais, kurių kiekvienas apima reikalavimų apibrėžimo,projektavimo, įgyvendinimo <strong>ir</strong> testavimo procesus. P<strong>ir</strong>mo ciklo eigoje kuriama produkto dalis suminimaliomis funkcijomis. Kitų ciklų metu produktas plečiamas, be to, pr<strong>ir</strong>eikus gali būtipakoreguotas pats procesas.Pasiūlyti standartinius kokybės <strong>ir</strong> progreso vertinimo būdusVertinimas yra esminė kokybiško darbo prielaida. TSP siūlomi vertinimai remiasinaudotais PSP.Pateikti komandų <strong>ir</strong> narių vertinimo būdusPagrindinis vertinimo tikslas yra padėti kuo geriau atlikti darbą, vertinimas taip pat parododarbo eigą komandos nariams. Esminė komandinio darbo savybė: visi žino, ką kiekvienas daro.Naudoti rolių vertinimąTSP siūlo naudoti rolių vertinimą. Idėja yra vertinti, kaip kiekviena rolė buvo atlikta, o nekaip kiekvienas žmogus d<strong>ir</strong>bo. Net jei rolės vertinimas gali būti suprastas kaip vertinimas, kaipd<strong>ir</strong>bo tas žmogus, kuris atliko tą rolę, bet TSP svarbiausia, kaip veikia procesas, o ne kaippas<strong>ir</strong>odė žmogus.Reikalauti iš inžinierių proceso disciplinosProgramų sistemų kūrėjams sunku nuosekliai <strong>ir</strong> drausmingai atlikti savo darbą. Yra tryspriežastys kodėl:1. Programinės įrangos kūrimas neturi tradicijų disciplinuotam asmeniniam darbui.2. Programinės įrangos kūrimo procesas nepateikia disciplinos reikalavimų inžinieriams.3. Drausmingas darbas reikalauja labai aukštų standartųPateikti komandinio darbo problemų sprendimo ga<strong>ir</strong>esNetgi gerai vykstantis projektas gali turėti komandinio darbo problemų. Kiekvienaskomandos narys vykdo sk<strong>ir</strong>tingas roles <strong>ir</strong> kiekviena iš jų turi savo tikslus. Kai tikslai susikerta,ats<strong>ir</strong>anda prieštaravimų tarp komandos narių. Geriausia komandos nesutarimus spręsti pasitelkusvisą komandą. Dauguma žmonių yra sus<strong>ir</strong>ūpinę savo kaip komandos nario įvaizdžiu, siekiapripažinimo komandoje norėdami pritapti prie komandos. Jei komandos nariai negali d<strong>ir</strong>bti kartuefektyviai, reikia kreiptis į vadovybę. Jei nepavyksta išspręsti komandos problemų, gali tektipašalinti kažkuri narį iš komandos.TSP struktūra <strong>ir</strong> eigaTSP siūlo galutinį produktą kurti ciklais:1. Kiekvienas ciklas turi kurti testuojamą versiją, kuri yra galutinio produkto dalis.2. Kiekvieno ciklo produktas turi būti pakankamai mažas, kad būtų lengvai kuriamas <strong>ir</strong>testuojamas.Mokymo medžiaga 104
Programų sistemų inžinerija8. Komandinis programų kūrimo procesas3. Sujungus dalis turi gautis galutinis norimas produktas.TSP kūrimo ciklų struktūra pateikiama paveikslėlyje:Startavimas1Strategija 1Planavimas 1Reikalavimai 1Projektavimas 1Įgyvendinimas 1Testavimas1Aptarimas 1Startavimas 2Strategija 2Planavimas 2Reikalavimai 2Projektavimas 2Įgyvendinimas 2Testavimas 2Aptarimas 2Startavimas 3Strategija 3Planavimas 3Reikalavimai 3Projektavimas 3Įgyvendinimas 3Testavimas 3Aptarimas 3Galutinis produktas8.1 pav. TSP kūrimo ciklų struktūraStartavimasProjekto startavimo tikslai: suformuoti komandą, pasisk<strong>ir</strong>styti rolėmis, nusistatyti projektesiekiamus tikslus.TSP siūlomos rolės: komandos lyderis; kūrimo vadovas; planavimo vadovas;kokybės/proceso vadovas; palaikymo vadovas.TSP nurodymai tikslams nusistatyti:1. Tikslų nustatymas turi būti orientuotas į klientą bei pagrindinius rezultatus.2. Nustatyti matavimus, kurie įgalintų įvertinti, ar tikslas pasiektas.3. Remiantis sukaupta pat<strong>ir</strong>timi gerinti (tikslinti) bei išsk<strong>ir</strong>ti naujus tikslus.Siūlomi standartiniai komandos tikslai: kurti kokybiška produktą; gerai valdyti projektą <strong>ir</strong>jį produktyviai vykdyti; baigti laiku.Siūlomi standartiniai komandos narių tikslai: būti efektyviu bei bendradarbiaujančiukomandos nariu; d<strong>ir</strong>bti tvarkingai (drausmingai metodiškai); planuotis <strong>ir</strong> sekti savo asmeninįdarbą; kurti kokybišką produktąTSP taip pat siūlo standartinius tikslus kiekvienai rolei.StrategijaPagal TSP reikia planuoti prieš atliekant pilną reikalavimų analizę. Tam yra tryspagrindinės priežastys: (1) planuojant komanda susipažįsta su projektu; (2) planas padedaįvertinti darbo dydį, prognozuoti, ar darbas bus padarytas per numatytą laiko tarpą, taip patMokymo medžiaga 105
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasnumatyti kitus rizikos faktorius; (3) jei nėra plano, komanda yra priversta pas<strong>ir</strong>ašyti sutartį pagalvadovo nustatytas datas, nors jie nežino, ar spės laiku atlikti darbą.Strategija turi apibrėžti keliais ciklais bus kuriama sistema, kokios sistemos dalys busįgyvendinamos kiekviename cikle.Siūloma pradėti nuo koncepcinio projektavimo, kuris sudaro pagrindą projekto planui.Tam netinka poreikių specifikacija, nes ji atspindi kliento požiūrį į sistemą, bet neduoda jokiųga<strong>ir</strong>ių, kaip sistema bus realizuota.Pagrindinis tikslas kuriant strategiją - minimizuoti riziką. Strategijos kūrimo žingsnyjeidentifikuojamos rizikos, prognozuojamas produkto dydis <strong>ir</strong> laikas, reikalingas jam sukurti,sudaromas konfigūracijos valdymo planas.PlanavimasKam reikalingi planai:1. Efektyvesnis darbas. Turint detalų planą galima efektyviau d<strong>ir</strong>bti. Be plano žmonėspaprastai atlieka darbus tokia tvarka kaip išeina o ne kaip greičiau, švaisto laiką perplanuodamikiekviename žingsnyje, arba praleidžia ką nors svarbaus.2. Įsipareigojimų vykdymas. Komandinio darbo pagrindas yra bendradarbiavimas, oįsipareigojimų komandos draugams vykdymas - svarbi jo dalis. Turėdamas gerą planą, visadažinai, ką turi padaryti, <strong>ir</strong> kada baigsi. Tokie įsipareigojimai bus realistiški <strong>ir</strong> kiti komandos nariaigalės jais pasitikėti.3. Kokybiškesnis darbas. Spaudžiant terminams kai kurie darbai būna atliekamipaskubomis, dėl ko kenčia produkto kokybė. Turint realistišką planą to neatsitiks.Subalansuoti planai. Viena iš pagrindinių planavimo problemų yra nesubalansuotas darbokrūvis. Tie inžinieriai, kurie turi daugiau darbo, dažniausiai užlaiko visą komandą. Subalansuotuvadinamas toks planas, pagal kurį visi baigia darbus maždaug tuo pačiu metu <strong>ir</strong> niekam nereikianieko laukti.Kaip sekti progresą pagal planą. Kadangi kai kurios užduotys baigiamos ne ta tvarka,kokia planuota, reikia būdo kaip nustatyti, ar atsiliekama nuo tvarkaraščio, ar ne. TSPpagrindiniai progreso sekimo matai yra suplanuota vertė (angl. planed value - PV) <strong>ir</strong> užd<strong>ir</strong>btavertė (angl. earned value - EV). Šie matai padeda nustatyti, kiek kiekviena užduotis įtakojatvarkaraštį. PV nurodo, kiek procentų viso nuplanuoto laiko užima užduotis. Kai užduotis baigta,PV tampa EV. Įpusėtos užduotys jokio EV neduoda.Planavimo detalumas. Jei buvo nuspręsta, kad darbas prie projekto truks 250 valandų, betdetaliau nesuplanuota. Kaip po 150 valandų pasakyti, ar atsiliekama nuo tvarkaraščio, ar darbasbus baigtas laiku? Štai kam reikalingi detalūs planai. TSP reikalauja planuoti 10 valandų arbamažesniais „gabaliukais“, tokiu būdų netikrumas dėl progreso bus daugiausia 10 valandų. ToksMokymo medžiaga 106
Programų sistemų inžinerija8. Komandinis programų kūrimo procesastikslumas reikalingas tik žmogaus lygyje, t.y. jei užduočiai sk<strong>ir</strong>ta daugiau negu 10 valandų, bet jąatlieka keli žmonės, užduotį skaidyti nebūtina.Neplanuotos užduotys. Visada ats<strong>ir</strong>anda užduočių, kurios nebuvo numatytos. Dėl to galitekti planuoti iš naujo. Tačiau turint apibrėžtą procesą tokios užduotys nebūtų labai didelės <strong>ir</strong>perplanavimas užimtų daugiau laiko negu tų užduočių vykdymas (reikėtų perskaičiuoti PV, išnaujo balansuoti planą, pasislinktų kitų užduočių terminai). Iš kitos pusės, neplanuotos užduotysneduotų EV. Siūloma p<strong>ir</strong>muosiuose cikluose kiekvieną savaitę palikti joms šiek tiek laiko (5-10% viso projekto laiko), pvz., įtraukiant 2 valandų trukmės „neplanines“ užduotėles.Kokybės planas turi tokius punktus: santraukų rodikliai (angl. Summary Rates); procentasbe defektų (angl. Percent Defect-Free); defektai puslapyje (angl. Defects Per Page); defektai /KLOC (angl. Defects / KLOC); defektų santykiai (angl. Defect Ratios); projekto vykdymo laikosantykiai (angl. Development Time Ratios); A / FR; peržiūrų <strong>ir</strong> inspekcijų greičiai (angl. Reviewand Inspection Rates); defektų darymo greičiai (angl. Defect-Injection Rates); defektų šalinimogreičiai (angl. Defect-Removal Rates); defektų šalinimas etapuose (angl. Phase Yield); defektųšalinimas procese (angl. Process Yield).ReikalavimaiProceso reikalavimų fazėje komanda formuluoja <strong>ir</strong> dokumentuoja projekto reikalavimus.Jie apibrėžia tikimąsi galutinį projekto rezultatą: produkto funkcionalumą, kokybę,dokumentaciją bei kitus svarbius aspektus.Reikalavimai turi būti aiškūs <strong>ir</strong> prasmingi. Nuo reikalavimų kokybės tiesiogiai priklausoviso projekto sėkmė. Dviprasmiškumai ar reikalavimai, kurie priklauso nuo „sveiko proto“sąvokos, yra pavojingi – jų reikėtų vengti.Reikalavimai yra formuluojami remiantis poreikių specifikacija. Deja, poreikiųspecifikacijos dažnai yra pernelyg abstrakčios – jas reikia patikslinti, užduodant papildomusklausimus projekto užsakovui (instruktoriui). Šioje vietoje dar kartą yra pasitikrinama, ar geraibuvo suprasti pradiniai kliento norai.Reikalavimų dokumentavimas: Sistemos Reikalavimų Specifikacija (SRS). Suformuluot<strong>ir</strong>eikalavimai turi būti užrašomi į Sistemos Reikalavimų Specifikaciją. Šis dokumentas yra derybųobjektas tarp projekto užsakovo <strong>ir</strong> jo vykdytojo.Kodėl reikalavimai yra svarbūs?Svarbiausia yra reikalavimų apibrėžimo procesas. Šis procesas yra labai svarbus, nesleidžia inžinieriams „įsijausti“ į projektą. P<strong>ir</strong>mą kartą visi projekte dalyvaujantys žmonės (tiekužsakovas, tiek vykdytojai) aiškiai suvokia darbo tikslą <strong>ir</strong> viziją. Dėl šios priežasties reikalavimųformulavime turi dalyvauti visi komandos nariai. Jų pat<strong>ir</strong>tis šiame etape yra vertingesnė net užpatį SRS dokumentą.Mokymo medžiaga 107
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasReikalavimų formulavimo rezultatas yra bendras susitarimas. Projektas bus sėkmingas tiktada, jei komanda šiame etape vieningai sutars dėl projekto detalių tiek tarpusavyje, tiek suužsakovu. Kartu tai yra <strong>ir</strong> įsipareigojimas (tarp kliento <strong>ir</strong> vykdytojo) dėl projekto rezultatų.Nepatyrę inžinieriai kartais į tai kreipia nepakankamai dėmesio – <strong>ir</strong> tai yra dažniausiaipasitaikanti projektų žlugimo priežastis.Reikalavimų pasikeitimai <strong>ir</strong> jų valdymas. Reikalavimų pasikeitimai yra potencialusprojekto problemų šaltinis. Netinkamai juos valdant, projektas gali užsitęsti, kainuoti daugiau neibuvo numatyta ar iš viso nepavykti. Todėl yra būtina kiek galima anksčiau <strong>ir</strong> tiksliau juosapibrėžti.Dažniausiai reikalavimų pasikeitimus inicijuoja užsakovas. Viena svarbiausių <strong>ir</strong>dažniausiai pasitaikančių problemų, trukdanti tinkamai apibrėžti reikalavimus yra užsakovoneapsisprendimas. Kartais gali net susidaryti įspūdis, kad klientas nežino ko nori – tai nutinkadėl tokių priežasčių: užsakovas neturi pat<strong>ir</strong>ties IT srityje <strong>ir</strong> tiesiog nežino, kokius sprendimus jigali pateikti; užsakovams sunku tiksliai įsivaizduoti naujos sistemos galutinį variantą, jei jiemstenka pereiti nuo kažkokios kitos egzistuojančios sistemos; dažniausiai tik pabandę galutinįproduktą ar bent jo prototipą, užsakovai gali tiksliai pasakyti, ar šis jiems tinka.Visi reikalavimų pakeitimai kainuoja. Net iš p<strong>ir</strong>mo žvilgsnio nežymūs pakeitima<strong>ir</strong>eikalauja papildomo laiko ar išlaidų. Kuo vėliau projekte šie pakeitimai yra inicijuojami, tuodaugiau jie kainuoja. Svarbu yra tiksliai numatyti, kokią įtaką projektui turės reikalavimųpasikeitimas – <strong>ir</strong> suderinti tai su komanda bei užsakovu. Taip pat svarbu yra atsk<strong>ir</strong>ti reikalavimųpasikeitimą nuo reikalavimų pridėjimo – tai padaryti padės tik tiksliai parengta SRS. Vieninteliskomandos ginklas prieš nevaldomus reikalavimų pakeitimus yra patv<strong>ir</strong>tinta SistemosReikalavimų Specifikacija.Reikalavimų formulavimas, kai poreikių specifikacija yra nepilna ar neaiški. Dažnaiprojekto vykdytojams tenka patiems aiškintis užsakovo poreikius – jei nėra užsakovo poreikiųspecifikacijos, arba ji nepilna. Tada yra atliekami interviu su užsakovu, būsimais sistemosnaudotojais - yra t<strong>ir</strong>iamas procesas, jo aplinka bei kiti veiksniai, kurie gali įtakoti projekto baigtį.ProjektavimasProjektavimo fazės tikslas yra sistemos bendra struktūra. Šitoje fazėje sudaromaprogramos projekto specifikacija (angl. Software Design Specification - SDS), kuriojedokumentuojamas aukšto lygio projektas. Kitas projektavimo lygis – detalusis projektavimas –atliekamas įgyvendinimo fazėje.Projektavimo principai. Projektavimo fazės metu turi būti sukurtos ne tik bendros idėjos –reikia sukurti tikslią <strong>ir</strong> pilną specifikaciją, kaip turi būti sukonstruotas objektas. Pilnasprojektavimas apibrėžia produkto pagrindines dalis, jų sąveiką <strong>ir</strong> jų derinimo būdą. PoMokymo medžiaga 108
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasreikalavimų apibrėžimo visas procesas apjungia įva<strong>ir</strong>ių lygių projektavimą. Aukšto lygioprojektavimas sk<strong>ir</strong>iasi nuo detaliojo projektavimo tik mastu <strong>ir</strong> detalėmis. Todėl aukšto lygioprojektavimo metu reikia sukurti tokią specifikaciją, kurią keli inžinieriai galėtų naudotinepriklausomai kurdami dalis. Kai aukšto lygio projektas yra pilnas <strong>ir</strong> tikslus, inžinierius galigreitai atlikti komponentų detalųjį projektavimą. Tam jiems reikia žinoti pilnas funkcinesspecifikacijas kiekvienam komponentui, jo interfeisus <strong>ir</strong> būsenas.Projektavimas komandose. Kai vienas žmogus kuria projektą, jam rūpi tiktai, kaip jįsukurti <strong>ir</strong> kokia tvarka kurti sk<strong>ir</strong>tingas projekto dalis. Kai kuriama komandoje, iškyla dar tryssvarbūs klausimai: kas kokią dalį turi kurti, kokia tvarka jie turi atlikti darbą <strong>ir</strong> kaip suderinti tasdalis.Paprastai kuriant programų sistemą reikia apibrėžti bendrą sistemos struktūrą prieš darantką nors kitą. Iki to sunku pask<strong>ir</strong>ti darbus. Vienas iš būdų išspręsti šią problemą – priversti visąkomandą užsiimti projektavimu. Gali atrodyti, kad jeigu visą komanda užsiima projektavimu, taiyra gerai, bet iš tikrųjų tai tik laiko gaišimas. Nes kai kuriama didelė sistema, tik keli žmonėsproduktyviai d<strong>ir</strong>ba, o kiti tik užduoda klausimus <strong>ir</strong> siūlo idėjas. O tai tik trukdo projektuotojamsd<strong>ir</strong>bti. Paprastai reikia tik vieno ar dviejų žmonių aukščiausio lygio projektui sudokumentuoti,interfeisams apibrėžti, sistemos funkcijoms pask<strong>ir</strong>styti tarp komponentų <strong>ir</strong> bendroms programosstruktūrai <strong>ir</strong> logikai apibrėžti.Kol sistemos projektuotojai kuria išorines komponentų specifikacijas, kiti inžinieriai galiapmąstyti alternatyvius būdus komponentams sukurti. Jie netgi gal kurti prototipus. Vartotojointerfeisas –viena iš funkcijų, kuriai gali reikėti sukurti prototipą. Vienas ar du inžinieriai galisukurti primityvų vartotojo interfeisą <strong>ir</strong> netgi išbandyti jį su paprastais vartotojais.Kuriant produktą, reikia efektyviausiai panaudoti visų komandos narių idėjas. Viena išpagrindinių problemų yra paskatinti narius d<strong>ir</strong>bti kartu. Nes žmonės labai nenoriai reiškia savomintis <strong>ir</strong> pasiūlymus. Visi komandos nariai turi suprasti, kad komandoje sus<strong>ir</strong>inko žmonės suįva<strong>ir</strong>iomis žiniomis <strong>ir</strong> pat<strong>ir</strong>timi. Ir kiekvienas iš jų turi prisidėti prie komandos darbo nežiūrint įtai, ką kiekvienas iš jų mano apie savo sugebėjimus. Komandos vadovas visada turi pasidomėti,ar kas turi kokių nors idėjų <strong>ir</strong> minčių, gal kas turi pat<strong>ir</strong>ties aptariamoje temoje, o paskui taipritaikyti. Komandos, kurios tą daro, paprastai d<strong>ir</strong>ba žymiai efektyviau.Projektavimo standartai: vardų standartas; interfeisų formatai; defektų standartas; kodoeilučių skaičiavimo standartas; projekto apiforminimo standartas.Projektavimas pakartotiniam naudojimui. Vienas iš būdų produktyviai panaudotikomandos narių laisvą laiką aukšto lygio projektavimo metu yra apibrėžti komandos pakartotinionaudojimo standartus. Tai gali reikšti galimų bendrų funkcijų identifikavimą <strong>ir</strong> pradiniopakartotinio naudojimo dalių rinkinio pasiūlymą. Paprastai komanda pasiekia geresnių rezultatų,Mokymo medžiaga 109
Programų sistemų inžinerija8. Komandinis programų kūrimo procesaskai kažkas sukuria pradinį pakartotinio naudojimo standartą <strong>ir</strong> apibrėžia pakartotinių daliųrinkinį.Pakartotinis naudojimas – potencialiai galingas būdas padidinti komandos produktyvumą.Nustačius pakartotinio naudojimo programą visada galima sutaupyti konstravimo laiką p<strong>ir</strong>mamekūrimo cikle <strong>ir</strong> dar daugiau laiko vėlesniuose cikluose. Paprastai pakartotinis naudojimasnagrinėjamas projekto pradžioje: mažuose projektuose projektavimo fazėje, dideliuoseprojektuose apie tai galima pradėti galvoti jau reikalavimų <strong>ir</strong> strategijos metu.Projektavimas naudojimo patogumui. Vienas iš būdų užtikrinti produktų naudojimopatogumą yra sukurti scenarijus visoms pagrindinėms funkcijoms, išanalizuoti tuos scenarijus <strong>ir</strong>patikrinti, ar jie atitinka sistemą, kurios projektuotojų manymu reikia užsakovams. Jeiguabejojama, kaip kokia nors funkcija turi veikti, reikia arba peržiūrėti atitinkamus scenarijus suprogramos ekspertu, arba sukonstruoti paprastą prototipą. Paprastai patartina konstruoti <strong>ir</strong>demonstruoti visus vartotojų interfeisų prototipus.Projektavimas testavimui. Kelių ciklų projektui yra svarbus pilnas testavimas. Tačiaureikia papildomo programavimo tam, kad programa palaikytų šiuos testus. Taip pat reikia geraisuplanuoti testavimą. Kai komanda gerai suplanuoja integravimą <strong>ir</strong> sistemos testus, jie paprastaisuranda daugiau defektų per testų planavimą, negu per tikrąjį testavimą.Yra dvi testavimo rūšys: juodosios dėžės <strong>ir</strong> baltosios dėžės testavimai. Juodosios dėžėstestavimas nagrinėja programos išorines specifikacijas <strong>ir</strong> nesigilina į programos vidinę struktūrą.Baltosios dėžės testavimas, atv<strong>ir</strong>kščiai, nagrinėja programos logiką <strong>ir</strong> struktūrą. Labai svarbuatlikti abu šiuos testavimus.Projekto peržiūra <strong>ir</strong> inspektavimas. Projekto peržiūra <strong>ir</strong> inspektavimas gali padėti padidintiprodukto kokybę. P<strong>ir</strong>miausia reikia gerai sudokumentuoti projektą. Paskui, kai ruošiamasiprojektavimo inspektavimui, reikia atlikti pilną projekto peržiūrą. Reikia patikrinti kiekvienąprojekto elementą, norint užtikrinti tų elementų tvarkingą veikimą. Geras inspektavimas,atliekamas visos komandos, dažnai atskleidžia problemas, kurių nepamatė autorius. Bet iš kitospusės kuo daugiau žmonių atlieka inspektavimą, tuo daugiau laiko tai užima. Jei laiko yra daug,geriau turėti daugiau inspektuotojų.ĮgyvendinimasPrieš imantis realizacijos, svarbu įsitikinti, kad tikrai pabaigtas aukšto lygio projektavimas.Didesnėms sistemoms aukšto lygio projektavimas dažnai turi būti atliekamas keliais etapais.P<strong>ir</strong>mame lygmenyje sistema dalinama į posistemes, komponentus ar modulius, <strong>ir</strong> apibrėžiamosjų išorinės specifikacijos bei suprojektuojama aukščiausio lygio logika. Tuomet pereinama įantrą <strong>ir</strong> tolimesnius lygmenis, <strong>ir</strong> juose veiksmai kartojami smulkesnėms sistemos dalims. Tai turibūti pakartota tiek kartų, kiek yra reikalinga gauti atominiams sistemos elementams, kuriuosMokymo medžiaga 110
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasgalima nesudėtingai realizuoti (siūlomas atominių elementų sudėtingumas – ne daugiau kaip 150kodo eilučių).Realizacijos standartai. Prieš pradedant produktų realizavimą, kaip <strong>ir</strong> prieš bet kurį kitąproceso etapą, komanda turėtų sk<strong>ir</strong>ti laiko standartų apsibrėžimui. Tam neturėtų būti gaištamadaug laiko, užteks paprašyti kelių komandos narių paruošti standartų juodraščius, pas<strong>ir</strong>inktitinkamiausią <strong>ir</strong> eigoje jį papildyti ar patobulinti. Už komandos darbą su standartais atsakingaskokybės/procesų vadovas.Standartų peržiūra. Peržiūrint <strong>ir</strong> priimant standartus, reikia būti pragmatiškais – galima begalo ilgai ginčytis, kas geriau tinka komandai, kiekvienas narys turės savo nuomonę <strong>ir</strong> galiniekada nesutarti. Kaip minėta, reikia nebijoti pas<strong>ir</strong>inkti iš pažiūros tinkantį standartą <strong>ir</strong> eigoje jįpritaikyti savo reikmėms.Reikia peržiūrėti vardų, interfeisų, pranešimų standartus sukurtus projektavimo stadijoje,kad įsitikinti, jog jie <strong>ir</strong> toliau tinka naudojimui, taip pat pasitikrinti ar visi komandos nariai turipilną pakartotinai panaudotinų funkcijų sąrašą <strong>ir</strong> juo naudojasi. Peržiūrėti terminų žodyną,įsitikinti ar viskam yra neprieštaringi pavadinimai <strong>ir</strong> ar jie nenaudojami sk<strong>ir</strong>tingai.Kodavimo standartai. Su kodavimo standartais komanda turėtų būti susipažinusi asmeninioproceso (PSP) metu, <strong>ir</strong> šie standartai turėtų būti taikomi. Kai visa komanda naudoja tuos pačiuskodavimo standartus, visas rašomas kodas yra panašus, tai labai palengvina kodo peržiūras,padaro jas greitesnėmis <strong>ir</strong> efektyvesnėmis.Geras kodavimo standartas apibrėžia <strong>ir</strong> komentavimą, taip pat palengvinantį peržiūras.Naudojant kodavimo standartus, skatinamas <strong>ir</strong> pakartotinis kodo panaudojamumas - kai„gabalas“ programos kodo atrodo panašus į tokį, kokį pats parašytumėte, labiau tikėtina, kadpaimsite jį <strong>ir</strong> panaudosite, vietoj to, kad rašytumėte pats.Dydžių standartai. Reikia nepam<strong>ir</strong>šti <strong>ir</strong> matavimo standartų. Procesai sukuria įva<strong>ir</strong>ių,daugelio tipo produktų, kurių apimtį reikia matuoti:• Reikalavimų specifikacija – teksto eilutės, pastraipos.• Aukšto lygio projektavimas – puslapiai, eilutės, panaudojimo scenarijai (use-cases).• Detalus projektavimas – pseudokodo eilutės.• Kodavimas – kodo eilutės.Kitiems produktams (duomenų bazių projektams, vartotojui pateikiamiems ekranams, etc.)matuoti kartais tenka susigalvoti savo matavimo vienetus, kurie sietųsi su laiku, sugaištu prieatitinkamo dydžio produktų: kuo produktas didesnis, tuo didesniu dydžiu jis turėtų būtiįvertinamas. Tuomet kaupiant to tipo produktų kūrimo statistiką, ilgainiui galima bus pasakyti,kokio dydžio produktui sukurti kiek reikės projekto laiko.Mokymo medžiaga 111
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasDefektų standartai. Standartinių PSP defektų tipų turėtų būti gana, kad identifikuotisavuosius defektus. Kartais gali tekti pridėti vieną kitą savo sugalvotą tipą, tačiau reikėtųnepersistengti juos kuriant, nepatartina perdaug smulkiai sudalinti defektus į tipus, susikurtigremėzdiško defektų standarto, kuriame įvyks klaidos bandant prisk<strong>ir</strong>ti defektą kažkuriam tipui,nes jų bus paprasčiausiai perdaug. Taip pat reikia stengtis nemaišyti defekto tipo su defektopriežastimi (pvz., nepilni reikalavimai, nepakankamos žinios – tai defektų priežastys, bet netipai. Dauguma defektų, kylančių dėl nepilnų reikalavimų, turėtų būti prisk<strong>ir</strong>ti funkciniųreikalavimų tipui). Dažniausi defektų tipai – duomenų, funkciniai <strong>ir</strong> sisteminiai.Realizacijos strategija. Realizacijos strategija susijusi su peržiūromis, pakartotiniupanaudojimu bei testavimu. Kodo peržiūras lengviausia vykdyti iš apačios į v<strong>ir</strong>šų, t.y. pradėtinuo smulkiausių, atominių kodo dalių, <strong>ir</strong> kilti į v<strong>ir</strong>šų. Peržiūrint kodą aukštesniuose lygiuose,galima pasitikėti atominių objektų veikimu juose, nes jie jau bus peržiūrėti. Toks požiūrissuformuoja <strong>ir</strong> realizacijos strategiją – pradėti realizuoti reikia nuo smulkiausių, atominių dalių, <strong>ir</strong>jungiant jas tarpusavyje kilti į aukštesnius lygmenis.Kadangi žemiausio lygmens atominius objektus lengviausia pakartotinai panaudoti,strategija „iš apačios į v<strong>ir</strong>šų“ tokį panaudojimą skatina. Kad pakartotinis panaudojimas būtųdidesnis, kiekvienas išeities tekstas turėtų turėti antraštę, pasakančią viską apie galima jopanaudojimą. Taip pat kasdieniuose komandos susitikimuose turėtų būti dalinamasi informacijaapie galimas pakartotinai panaudojamas dalis.Kitas svarbus strategijos rūpestis – atitikti testavimo planą. Realizavimas turi vykti tokiatvarka, kuri neprieštarautų iš anksto sudarytiems testavimo planams.Peržiūros <strong>ir</strong> inspekcijos. Labai svarbu pabrėžti, kad peržiūros <strong>ir</strong> inspekcijos yrareikalingos. Kode stebėtinai didelis procentas visų padaromų klaidų yra atsitiktinės klaidos,neturinčios jokios logikos, bet leidžiančios kodui kompiliuotis ar net veikti. Tų klaidųalogiškumas lemia tai, kad jas labai sunku rasti testuojant. Peržiūros yra žymiai efektyvesnėpriemonė tokioms klaidoms rasti.TestavimasPagrindinės TSP testavimo veiklos:1. Surinkti sistemą, naudojant sukurtus <strong>ir</strong> jau ištestuotus atsk<strong>ir</strong>us modulius.2. Atlikti integracijos testus: patikrinti, ar sistema “teisingai” surinkta, ar yra visikomponentai <strong>ir</strong> kaip jie kartu funkcionuoja.3. Atlikti sistemos testus: patikrinti, ar produktas atlieka tai, kas apibrėžta sistemosreikalavimuose.Tuo pat metu atliekamos <strong>ir</strong> šios veiklos:Mokymo medžiaga 112
Programų sistemų inžinerija8. Komandinis programų kūrimo procesas- Identifikuoti prastos kokybės modulius <strong>ir</strong> sugrąžinti juos kokybės/proceso vadovui,kuris turi juos įvertinti bei atiduoti ištaisyti.- Identifikuoti modulius, kurie yra vis dar prastos kokybės net <strong>ir</strong> po pataisymų bei grąžintijuos kokybės/proceso vadovui, kuris turi juos atiduoti perd<strong>ir</strong>bti arba pakeisti.Testų planavimas. Iš pradžių ruošiamas konceptualus testavimo planas, kuriame pateikiamišie įverčiai: testų medžiagos dydis bei laikas, reikalingas testams sukurti <strong>ir</strong> atlikti. Taip patreikalingi planai surinkimo, integracijos testavimo bei sistemos testavimo veikloms.Galutinis testavimo planas turi parodyti, kaip bus testuojamas kiekvienas reikalavimas <strong>ir</strong>kaip testai tikrins tam tikras reikalavimų sritis. Galutinis testavimo planas turi aprašytinumatomus vykdyti testus, jų vykdymo tvarką <strong>ir</strong> testo medžiagą, reikalingą kiekvienam testui.Be to, jis turi apibrėžti testavimo tikslus <strong>ir</strong> užduotis.Galutiniame testavimo plane turi būti:• Testo atliekami žingsniai;• Medžiaga (programos/skriptai <strong>ir</strong> duomenys) kiekvienam testui;• Kokius rezultatus testas turi gauti;• Įverčiai: testo vykdymo bedefektis laiko tarpas, galimų defektų skaičius, bendras laikaskiekvienam testui atlikti.• Visos testavimo medžiagos sąrašas;• Kiekvieno testo tikslai;• Testavimo medžiagos dydis;• Kas <strong>ir</strong> kada sukurs testavimo medžiagą <strong>ir</strong> kiek laiko tai užtruks.Testų rezultatų sekimas <strong>ir</strong> matavimas. Planuojant atlikti daug testų, svarbu matuoti testųefektyvumą – rastų defektų <strong>ir</strong> testo vykdymo laiko santykį. Vertinat atliktus testus, patogu vestitestavimo protokolą (test-log), kurio struktūra yra tokia: Testavimo data; Asmuo, atlikęs testus;Kokie testai buvo atliekami (jų pavadinimai/numeriai); Testuotas produktas <strong>ir</strong> jo konfigūracija;Kiekvieno testo pradžia (laikas); Kiekvieno testo pabaiga (laikas); Aptiktų defektų skaičius,nuorodos į LOGD formas; Testavimo rezultatai.Efektyvūs testai būtų įtraukiami į regresijos testų paketą. Į paketą būtinai turi įeiti: visitestai, kurie anksčiau yra aptikę defektų, visi testai, kurie tikrino tas sistemos sritis, kurios buvomodifikuotos vėlesniuose cikluose.Dokumentavimas. Kol viena komandos dalis planuoja, kuria <strong>ir</strong> vykdo testus, likusi dalisrašo vartotojo dokumentaciją. Siūloma pradiniuose kūrimo cikluose daugiau žmonių sk<strong>ir</strong>titestavimui, o galutiniuose – dokumentavimui. Didesnėse sistemose dokumentavimas turėtųprasidėti daug anksčiau už testų rengimą.Mokymo medžiaga 113
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasDokumentavimas yra labai svarbi kiekvieno programinio produkto dalis – galbūt netsvarbesnė už programos kodą. Ir geriausia dokumentuoti kažkurią sistemos funkciją tuoj pat pojos suprojektavimo. Jei dokumentacija bus paruošta anksčiau nei užbaigta sistemos projektinėspecifikacija – reikės atlikti daug dokumentacijos pakeitimų, jei dokumentavimo darbai bus perilgai atidėliojami – tada tai užims daugiau laiko, nes reikės prisiminti projektavimo metupriimtus sprendimus.Kokia turi būti gera vartotojo dokumentacija (“vartotojo vadovas”):• P<strong>ir</strong>miausia, reikia rašyti ne tai, kokia sistema buvo sukurta, o tai, ko labiausiai reikiavartotojui, d<strong>ir</strong>bančiam su sistema: kaip vartotojui pradėti naudotis produktu, ką vartotojas galidaryti su produktu, kaip jam surasti reikiamą informaciją;• Siūloma naudoti: Terminų žodyną; Klaidų pranešimų skyrių <strong>ir</strong> pan.; Esminių skyriųrodyklę; Detalų turinį;• Kitos rekomendacijos: Rašyti trumpus sakinius; Naudoti paprastus žodžius <strong>ir</strong> frazes;Naudoti sąrašus bei struktūrizuoti informaciją;• Dokumentas turi būti gerai skaitomas <strong>ir</strong> suprantamas.Iš pradžių parengiamas dokumentacijos eskizas, vėliau jis konkretizuojamas. Vartotojodokumentacija turi būti peržiūrima vieno ar kelių komandos narių. Peržiūrint, turi būti paliesti šieaspektai:• Dokumento struktūra: ar dokumente išdėstytas produkto turinys, ar tai, ką vartotojas galidaryti su šiuo produktu?• Dokumento terminologija: ar vartotojas turi turėti specialių žinių, kad galėtų efektyviainaudotis dokumentu?• Dokumento turinys: ar dokumentas apima visą produktą?• Kruopštumas: ar metodai <strong>ir</strong> procedūros veikia taip, kaip apibrėžta dokumente?• Skaitomumas: ar dokumentas lengvai skaitomas?• Suprantamumas: ar gali asmenys neprofesionalai suprasti tai, kas parašyta dokumente?Gera praktika laikoma, kai vartotojo dokumentacijos dokumentas duodamas peržiūrėtivartotojams, anksčiau nesinaudojusiems šia sistema <strong>ir</strong> jų prašoma atlikti veiksmus su sistema,aprašytus vartotojo dokumentacijoje.AptarimasAptarimas yra galutinis žingsnis TSP procese. Jame peržiūrimas visas padarytas darbastam, kad įsitikinti, jog mes užbaigėme visus uždavinius <strong>ir</strong> užrašėme visą reikalingą informaciją(užpildėme visas formas). Analizuojama, kas buvo padaryta ciklo eigoje su tikslu išt<strong>ir</strong>ti, kassekėsi, o kas – nelabai, <strong>ir</strong> padaryti išvadas, kaip kitą kartą atlikti darbą geriau.Mokymo medžiaga 114
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasŠis procesas labai reikalingas, nes jeigu mes nepakeisime savo darbo pobūdžio, tai <strong>ir</strong> toliaud<strong>ir</strong>bsime taip, kaip anksčiau (t.y., galbūt blogai). Aptarimas - tvarkingas būdas nustatyti sritis,kurios reikalauja tobulinimo, <strong>ir</strong> padaryti reikiamus pakeitimus.Kodėl reikalingas aptarimas? Pastovus tobulinimasis yra ypač svarbus programųkūrėjams. Programinė įranga dabar yra beveik visų industrijos atšakų pagrindas. Tipinėse kūrimogrupėse daugiau nei pusė inžinierių užsiėmę programinės įrangos kūrimu. Todėl žinojimas, kaipją kurti, yra lemiamas kiekvienam inžinieriui.Kaip aptarimas gali padėti? Kiekvienas ciklas baigiasi aptarimu, kuris suteikiastruktūriškai apibrėžtą būdą mokytis <strong>ir</strong> tobulėti. Aptarimo metu nagrinėjama tai, kas buvopadaryta palyginus su tuo, ką buvo suplanuota padaryti. Ieškoma tobulinimosi galimybių <strong>ir</strong>sprendžiama, kaip pakeisti darbo pobūdį kitame cikle arba kitame projekte. Galima keisti darboprocesą, arba atrasti, kaip geriau sekti turimu procesu. Aptarimo procesas leidžia pamatytipokyčius, pereinant nuo vieno ciklo prie kito. P<strong>ir</strong>mas ciklas duoda pagrindą. Analizuojama, kaspadaryta, kiek tam buvo sk<strong>ir</strong>ta jėgų, kokiais žingsniais viskas vyko. Nustatomas plano tikslumas<strong>ir</strong> kaip tiksliai buvo laikomasi plano <strong>ir</strong> ar buvo proceso planas tinkamas. Identifikuojamosproblemos <strong>ir</strong> nustatomos jų priežastys, o taip pat klaidų išvengimo priemonės. Aptarimo fazė yrapatogus laikas nustatyti tobulinimosi galimybes <strong>ir</strong> nuspręsti, kur <strong>ir</strong> kaip padaryti pakeitimusasmeniniuose <strong>ir</strong> komandiniuose procesuose.Proceso pagerinimo pasiūlymai. Raktas sėkmingo tobulinimosi link yrasusikoncentravimas ties nedideliu pakeitimu. Šansai dideliems pokyčiams <strong>ir</strong>gi ats<strong>ir</strong>anda, betnedažnai. D<strong>ir</strong>bant projekte galima pastebėti, kad yra daug nežymių dalykų, kuriuos galimapakeisti. Kiekvienas nepastebimas tobulinimasis tik truputį padeda, bet laikui bėgant iš jųsusidaro pastebimi žymūs pakeitimai. O svarbiausia, išmokstama, kaip pastoviai tobulinti savoveiklą <strong>ir</strong> darbo pobūdį.Su nedideliais pakeitimais yra susijusi viena problema – juos lengva užm<strong>ir</strong>šti. Todėl <strong>ir</strong>PSP <strong>ir</strong> TSP naudojami proceso pagerinimo pasiūlymai. Vienas jų – turėti tuščią PIP (angl.Process Improvement Proposal) formą po ranka, į kurią būtų galima įrašinėti visas tobulinimosiidėjas, kurios ats<strong>ir</strong>anda. Idėjos galėtų būti: kaip geriau pasipraktikuoti kažkurioje srityje, išmoktinaudoti naujus įrankius, kaip pakeisti procesą <strong>ir</strong> panašiai. Kai ateina laikas aptarimui, labaipatogu turėti visus įrašus po ranka, atkurti visas savo idėjas <strong>ir</strong> tvarkingai jas nagrinėti.Pagrindiniai TSP principai• Programų sistemų kūrėjai d<strong>ir</strong>bs efektyviai, jei naudos apibrėžtą <strong>ir</strong> matuojamą procesą(efektyvus, apibrėžtas, matuojamas).Mokymo medžiaga 115
Programų sistemų inžinerija8. Komandinis programų kūrimo procesas• Komanda bus motyvuota, jei d<strong>ir</strong>bs turėdama bendrą viziją <strong>ir</strong> žinodama jai keliamustikslus (užtikrinantis efektyvios komandos sukūrimą).• Procesas geriausiai atitiks komandos poreikius, jei bus jai pritaikytas (pritaikytas).• Komandos nariai žinos už ką jie atsakingi <strong>ir</strong> kam turi atsiskaityti, jei komandoje busįtv<strong>ir</strong>tintos aiškios atsakomybės <strong>ir</strong> atskaitomybė (įtv<strong>ir</strong>tinantis atsakomybes, atskaitomybę)• Programų sistemų kūrėjai aktyviai keisis informacija <strong>ir</strong> žiniomis, jei komandoje busskatinamas nuolatinis bendravimas (užtikrinantis informacijos mainus).• Suteikti galimybę programų sistemų kūrėjams d<strong>ir</strong>bti taip, kaip jie įpratę, tačiauprisilaikant nustatyto komandos proceso <strong>ir</strong> atsižvelgiant į jų pačių surinktus duomenis <strong>ir</strong> kolegųpat<strong>ir</strong>tį (disciplinuojantis).• Norint pastoviai gerinti savo veiklą, reikia nuolat tobulinti procesą, atsižvelgiant įproceso metu sukauptus istorinius duomenis <strong>ir</strong> rodiklius (evoliucionuojantis).• Skatinti būsimų produktų kokybės užtikrinimą <strong>ir</strong> galimų rizikų įvertinimą bei valdymą(užtikrinantis kokybės valdymą).TSP praktikosTSP procese išsk<strong>ir</strong>iama 11 praktikų, kurių taikymas sąlygoja aukščiau įvardintų procesoprincipų įgyvendinimą:1. Komandos tikslų suformulavimas <strong>ir</strong> dokumentavimas.2. Rolių <strong>ir</strong> jų atsakomybių apibrėžimas bei priskyrimas.3. Komunikavimo procedūrų apibrėžimas.4. Projekto progreso sekimas.5. Komandos proceso evoliucionavimo/pritaikymo plano paruošimas <strong>ir</strong> jo įgyvendinimas.6. Produkto kūrimo strategijos ruošimas.7. Produkto kūrimo plano <strong>ir</strong> tvarkaraščio ruošimas.8. Reikalavimų specifikacijos ruošimas.9. Projektavimas.10. Rizikų įvertinimas <strong>ir</strong> valdymas.11. Kokybės planavimas <strong>ir</strong> valdymas.Komandos tikslų suformulavimas <strong>ir</strong> dokumentavimasTikslas. Suformuluoti komandai <strong>ir</strong> kiekvienam jos nariui keliamus tikslus, kurių bussiekiama projekto metu.Veiklos:• Komandai keliamų tikslų suformulavimas <strong>ir</strong> dokumentavimas.• Komandos nariams keliamų tikslų suformulavimas <strong>ir</strong> dokumentavimas.Mokymo medžiaga 116
Programų sistemų inžinerija8. Komandinis programų kūrimo procesas• Kriterijų, kuriais remiantis bus vertinamas produkto <strong>ir</strong> komandos atitikimasiškeltiems tikslams, apibrėžimas.Aprašymas. Tikslų komandai <strong>ir</strong> jos nariams iškėlimas užtikrina, jog visi komandos nariaižino, kokie uždaviniai jiems keliami projekto metu <strong>ir</strong> ko iš kiekvieno jų tikimąsi. Tuo pačiu,bendrai iškelti <strong>ir</strong> patv<strong>ir</strong>tinti tikslai apjungia komandos narius <strong>ir</strong> veikia motyvuojančiai, kadangiformuluojant tikslus dalyvauja visi komandos nariai. Ši veikla ypač svarbi buriant naujaskomandas. Labai svarbu komandai iškelti tokius tikslus, kurie būtų realiai įgyvendinami, tiktuomet tikslų iškėlimas turės realią vertę <strong>ir</strong> prasmę.Komandai keliamų tikslų suformulavimas <strong>ir</strong> dokumentavimas. Tipiniai komandoms keliamitikslai orientuoti į tokius aspektus: pagaminti kokybišką produktą (pvz.: sistemos integravimofazėje neužfiksuoti nė vienos klaidos); d<strong>ir</strong>bti produktyviai <strong>ir</strong> efektyviai valdyti projektą; projektąbaigti laiku (pvz.: laiko prognozavimo paklaida mažesnė nei 5 procentai). Be abejo, komandagali papildyti ar pakeisti siūlomus tikslus kitais, tobulinti jų metrikas, tačiau nurodytieji yrapritaikomi daugumai komandų.Komandos nariams keliamų tikslų suformulavimas <strong>ir</strong> dokumentavimas. Komandos nariamsgali būti keliami sk<strong>ir</strong>tingi tikslai projekto metu, atsižvelgiant į kiekvieno iš jų pat<strong>ir</strong>tį <strong>ir</strong> įgūdžius.Be to, komandos nariams keliami tikslai neturi prieštarauti komandai keliamiems tikslams.Komandos nariams keliamų tikslų pavyzdžiai: efektyviai bendradarbiauti komandoje, d<strong>ir</strong>btidisciplinuotai, planuoti <strong>ir</strong> matuoti/vertinti visas savo užduotis, gaminti kokybiškus produktus. Jeinurodytieji tikslai neatitinka komandos narių poreikių, komanda gali juos papildyti/pakeistisavais.Kriterijų, kuriais remiantis bus vertinamas produkto <strong>ir</strong> komandos atitikimas iškeltiemstikslams, apibrėžimas. Komanda apibrėžia kriterijus, kuriais remiantis bus vertinama ar iškeltastikslas buvo įgyvendintas. Tai užtikrina, jog iškeliami tikslai bus išmatuojami <strong>ir</strong> realiaipasiekiami. Priklausomai nuo iškeltų tikslų, kriterijai gali būti laikas, kokybė <strong>ir</strong> pan.Rolių <strong>ir</strong> jų atsakomybių apibrėžimas bei priskyrimasTikslas. Apibrėžti rolių atsakomybes <strong>ir</strong> įsipareigojimus bei jas prisk<strong>ir</strong>ti komandos nariams.Veiklos:• Apibrėžti kiekvienos rolės atsakomybes <strong>ir</strong> įsipareigojimus.• Roles pask<strong>ir</strong>styti komandos nariams.Mokymo medžiaga 117
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasAprašymas. Praktika savo pobūdžiu primena veiklą „Komandos narių tikslų iškėlimas”,nes <strong>ir</strong> ją vykdant komandos nariams prisk<strong>ir</strong>iame tam tikrus įsipareigojimus. Tačiau čia komandosnariams yra prisk<strong>ir</strong>iamos rolės, t.y. jie tampa atsakingi už pask<strong>ir</strong>tą sritį. Kiekvienos rolės atstovuiapibrėžiamos atsakomybės <strong>ir</strong> įsipareigojimai, kuriuos jis turi vykdyti projekto metu kuruodamassavo sritį.Apibrėžti kiekvienos rolės atsakomybes <strong>ir</strong> įsipareigojimus. Komanda apibrėžia kiekvienosrolės atsakomybes <strong>ir</strong> įsipareigojimus. Taip pat apibrėžiama kaip bus vertinamas roliųįgyvendinimas. Reikalavimai dokumentuojami specialiose formose.Roles pask<strong>ir</strong>styti komandos nariams. Atsižvelgiant į kiekvieno komandos nario įgūdžius,sugebėjimus, pat<strong>ir</strong>tį bei jam keliamus tikslus projekte, pask<strong>ir</strong>iama viena iš penkių projekto rolių.Komunikavimo procedūrų apibrėžimasTikslas. Apibrėžti, kaip bus vykdomi informacijos mainai projekto metu.Veiklos:• Nurodyti pateikiamos informacijos rūšis <strong>ir</strong> atsakingus asmenis.• Paruošti komandos sus<strong>ir</strong>inkimų grafiką.Aprašymas. Informacijos mainai užtikrinami įtv<strong>ir</strong>tinant kassavaitinius komandos nariųsus<strong>ir</strong>inkimus. TSP modelyje bendriems visų komandos narių sus<strong>ir</strong>inkimams sk<strong>ir</strong>iamas ypatingasdėmesys, kadangi tai yra svarbiausias visų komandos narių bendravimo užtikrinimo būdų.Komandos sus<strong>ir</strong>inkimų metu įvertinamas komandos progresas, planuojami darbai beianalizuojamos einamosios problemos. Sus<strong>ir</strong>inkimuose dalyvauja visi komandos nariai, kadangikiekvienas privalo žinoti situaciją <strong>ir</strong> dalyvauti priimant sprendimus. TSP proceso aprašomaskassavaitinis komandos sus<strong>ir</strong>inkimas užima pakankamai nedaug projekto laiko, kadangivykdomas pagal iš anksto žinomą scenarijų.Nurodyti pateikiamos informacijos rūšis <strong>ir</strong> atsakingus asmenis. Apibrėžiamos pateikiamosinformacijos rūšys, kokią informaciją turi pateikti kiekvienos rolės atstovas bei kas atsakingas užpateiktos informacijos peržiūrą <strong>ir</strong> analizę.Paruošti komandos sus<strong>ir</strong>inkimų grafiką. Vienas svarbiausių efektyvios komandosformavimo principų – informacijos mainų komandoje užtikrinimas. TSP procese tai sprendžiamaįtv<strong>ir</strong>tinant kassavaitinius komandos sus<strong>ir</strong>inkimus, kurių metu keičiamasi informacija <strong>ir</strong>pristatomos problemos. Paruoštą komandos sus<strong>ir</strong>inkimų grafiką tv<strong>ir</strong>tina komandos vadovas.Patv<strong>ir</strong>tintas grafikas dokumentuojamas specialioje formoje.Projekto progreso sekimasTikslas. Užtikrinti visapusišką vykdomo projekto kontrolę.Mokymo medžiaga 118
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasVeiklos:• Apibrėžti pateikiamos informacijos rūšis, kas jas bei kam ją pateikia.• Apibrėžti informacijos pateikimo formą.Aprašymas. Šios praktikos tikslas – nurodyti, kokius duomenis komandos nariai turi rinktibei kokių ataskaitų pavidalu jie turi būti pateikiami kiekvieną savaitę. Iš visų komandos nariųpateiktų ataskaitų suformuojama viena bendra, kuri naudojama komandos narių sus<strong>ir</strong>inkimųmetu. Surinkti duomenys naudojami projekto progreso sekimui <strong>ir</strong> galimų problemųidentifikavimui bei jų išankstinei prevencijai. Kad duomenys būtų pateikiami vieningu formatu,TSP nurodo specialią formą, kurią pildo visi komandos nariai.Apibrėžti pateikiamos informacijos rūšis.Kiekvienas komandos narys kas savaitę pateikiatokio tipo informaciją:• planuotų <strong>ir</strong> d<strong>ir</strong>btų valandų skaičius,• kiekvienai iš užduočių planuoto <strong>ir</strong> realiai sugaišto laiko įverčius,• kitos savaitės užduotis <strong>ir</strong> planuojamą laiką joms įvykdyti,• identifikuotas problemas.Apibrėžti informacijos pateikimo formą. Informacija pateikiama ataskaitų pavidaluspecialiai pritaikytose formose.Pastabos. Šios praktikos tikslas – sekti projekto progresą, todėl duomenys turi būti tikslūs<strong>ir</strong> pilni. Tam užtikrinti turi būti naudojami automatiniai įrankiai, kurių viena funkcijų būtųprojekto progreso ataskaitų sugeneravimas, remiantis užfiksuotais duomenimis.Komandos proceso evoliucionavimo plano paruošimas <strong>ir</strong> jo įgyvendinimasTikslas. Užtikrinti nuolatinį proceso evoliucionavimą, keičiant, eliminuojant ar pridedantatitinkamas praktikų veiklas, o esant reikalui <strong>ir</strong> pačias praktikas.Veiklos:• Išanalizuoti proceso duomenis.• Įvertinti rolių įgyvendinimą.• Paruošti projekto (ciklo) ataskaitą <strong>ir</strong> tobulinimo pasiūlymus.Mokymo medžiaga 119
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasAprašymas. Proceso peržiūra yra paskutinė TSP proceso fazė. Jos metu yra peržiūrimikomandos atlikti darbai <strong>ir</strong> analizuojama tai, kas buvo atlikta, lyginant su tuo, ką buvo planuotaatlikti. Šios fazės metu ieškoma galimų proceso tobulinimų <strong>ir</strong> sprendžiama, kurias veiklas būtųgalima keisti/tobulinti <strong>ir</strong> kokiomis priemonėmis tai padaryti. Taip pat analizuojami kiekvieno iškomandos narių veiklos rodikliai, norint išsiaiškinti, kaip būtų galima pagerinti kiekvieno iškomandos narių efektyvumą.Išanalizuoti proceso duomenis.Šios veiklos metu atliekama ciklo metu surinktų duomenųperžiūra. Peržiūros tikslai yra:• surinkti duomenis apie komandos <strong>ir</strong> kiekvieno jos nario veiklas <strong>ir</strong> juos išanalizuoti,• identifikuoti, kada procesas veikė sklandžiai, o kada kilo problemų.Analizės metu nustatoma, ar pasiteisino prieš ciklą pasiūlyti proceso <strong>ir</strong> veiklųpakeitimai/patobulinimai. Jeigu peržiūros metu paaiškėja, jog naudinga keisti procesą ar kuriasnors iš veiklų, pakeitimai pateikiami tam tikslui paruoštoje proceso gerinimo pasiūlymų formoje(process improvement proposal).Įvertinti rolių įgyvendinimą.Šios veiklos metu yra vertinama, kaip buvo įgyvendintakiekviena iš rolių. Vertinant roles, keliami tokie klausimai: Kas buvo atlikta gerai? Kur iškiloproblemų? Ką būtų galima tobulinti? Kokius tikslus būtų galima iškelti sekančiam ciklui arprojektui?Vertinimo rezultatai pateikiami tam tikslui paruoštoje formoje, kurią pildo kiekvienaskomandos narys.Paruošti projekto (ciklo) ataskaitą <strong>ir</strong> tobulinimo pasiūlymus. Ši veikla aprašo cikloataskaitos ruošimą. Projekto (ciklo) ataskaitoje pateikiama tokio pobūdžio informacija: kąkomanda gamino, kokį procesą naudojo, ką pavyko įvykdyti, ko nepavyko įvykdyti, ką <strong>ir</strong> kaipbūtų galima atlikti geriau.Kiekvienoje ataskaitoje projekto (ciklo) rezultatai lyginami su ankstesnių projektų (ciklų)rezultatais, taip bandant nustatyti tam tikras tendencijas. Ruošiant ataskaitą išvados grindžiamosrealiais pavyzdžiais-įrodymais (pvz., veiklos rodikliais).Pastabos. Proceso vertinimui negalima naudoti paties proceso metrikų. Tam tikslui turibūti naudojami “išoriniai” proceso vertinimo metodai: vertinamos programų sistemų kūrėjoįgytos žinios (kiek programų sistemų kūrėjas praktiškai panaudojo pristatytus metodus) beivertinami programų sistemų kūrėjo rezultatai (kaip jie keitėsi, naudojant TSP procesą). Tai leisnustatyti, kur procesą (praktikas) reikia tobulinti ar keisti.Produkto kūrimo strategijos ruošimasTikslas. Parinkti, apibrėžti <strong>ir</strong> dokumentuoti produkto kūrimo strategiją.Mokymo medžiaga 120
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasVeiklos:• Nustatyti strategijos kriterijus.• Paruošti koncepcinį projektą.• Pas<strong>ir</strong>inkti kūrimo strategiją.• Nustatyti preliminarius įverčius.• Dokumentuoti kūrimo strategiją.Aprašymas. Pas<strong>ir</strong>enkant produkto kūrimo strategiją, sprendžiamas itin svarbus klausimas –kaip bus atliekama atsk<strong>ir</strong>ų produkto dalių integracija į vieningą sistemą. Sekant TSP procesu,visas darbas <strong>ir</strong> laikas, reikalingi produktui sukurti, suskaidomi į kelis ciklus. Kaip <strong>ir</strong> į kelisciklus bus padalintas visas produkto kūrimas - sprendžia visa komanda. Šis sprendimas tiesiogiaiveiks tolimesnę darbų seką: reikės nuspręsti, kokias funkcijas įgyvendinti <strong>ir</strong> prognozuoti kieklaiko sk<strong>ir</strong>ti kiekvienam iš ciklų, apytikriai nustatyti darbų kiekį bei numatyti metodus kaipištestuoti kiekvieną iš sistemos modulių. Komandai, atsižvelgiant į būsimo produkto struktūrą <strong>ir</strong>jo ciklinį kūrimą, reikės nuspręsti <strong>ir</strong> kurią iš cikliniam produkto kūrimui pritaikytų strategijų jiepas<strong>ir</strong>inks.Nustatyti strategijos kriterijus. Vykdant šią veiklą komanda aptaria <strong>ir</strong> suformuluojakriterijus, kuriuos turi tenkinti produkto kūrimo strategija. Atsižvelgiant į šiuos kriterijuskomanda peržiūrės <strong>ir</strong> vertins visus galimus produkto kūrimo strategijų variantus. Tinkamaisuformuluoti kriterijai padeda greitai <strong>ir</strong> svarbiausia objektyviai palyginti <strong>ir</strong> įvertinti alternatyviasstrategijas. TSP procesas akcentuoja vieną iš svarbiausių strategijos tikslų – užtikrinimą, jogproduktas bus pagamintas laiku. Taigi nustatyti strategijos kriterijai turi padėti parinkti tokiąprodukto kūrimo strategiją, kuri sumažina riziką, jog produkto kūrimas užims daugiau laiko neiplanuota.Paruošti koncepcinį projektą. Šio žingsnio metu komanda sukuria viso produktokoncepcinį projektą bei nurodo funkcijas, kurias produktas turės realizuoti.Pas<strong>ir</strong>inkti kūrimo strategiją. Ši TSP veikla susideda iš tokių žingsnių:• alternatyvių kūrimo strategijų peržiūros <strong>ir</strong> įvertinimo,• produkto funkcijų pask<strong>ir</strong>stymo kiekvienam kūrimo ciklui,• numatymo, kaip produktas bus integruojamas.TSP siūloma strategija įgalina produkto funkcionalumą didinti laipsniškai, t.y. kiekvienociklo metu produktas papildomas naujomis funkcijomis. Kurią iš cikliniam kūrimui pritaikytųstrategijų pas<strong>ir</strong>inkti, sprendžia komanda, atsižvelgdama į būsimo produkto struktūrą bei galimusrizikos faktorius.Nustatyti preliminarius įverčius. Vienas iš strategijos kūrimo uždavinių yra numatyti, kiekgali užtrukti produkto kūrimas <strong>ir</strong> kokio dydžio produktas bus. TSP procese produkto dydisMokymo medžiaga 121
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasmatuojamas kodo eilučių skaičiumi, o laikas – valandų įverčiu, kuris gaunamas imantprognozuojamą produkto dydžio įverčio sandaugą su programuotojo efektyvumo įverčiu (kiekkodo eilučių programuotojas gali parašyti per valandą). Matuojant produkto dydį imamakiekviena iš koncepciniame projekte aprašytų produkto funkcijų <strong>ir</strong> prognozuojamas jos dydis.Įvertinus visų produkto funkcijų dydį <strong>ir</strong> sudėtingumą, paprasčiau planuoti, kurios funkcijos buskuriamos kiekvienos iš iteracijų metu. Taip apsidraudžiama, kad užteks laiko įgyvendinti visasiteracijai numatytas funkcijas. Kadangi <strong>ir</strong> PSP, <strong>ir</strong> TSP modeliuose produkto dydis vertinamas jįsudarančių eilučių skaičiumi, tai dydžiui prognozuoti efektyviausia naudotis PSP modelyjepateikta PROBE metodika, nes TSP nepateikia konkrečių prognozavimo metodų.Dokumentuoti kūrimo strategiją. Produkto kūrimo strategija dokumentuojama tam tiksluisk<strong>ir</strong>tose formose.Rizikų įvertinimas <strong>ir</strong> valdymasTikslas. Identifikuoti projekto rizikas <strong>ir</strong> paruošti jų valdymo bei stebėjimo planus.Veiklos:• Rizikų identifikavimas.• Detali kiekvienos įvardintos rizikos analizė.• Planų, rizikų valdymui, paruošimas.• Pastovus identifikuotų rizikų stebėjimas.Aprašymas. Rizikos įvertinimas <strong>ir</strong> valdymas svarbus faktorius vykdant projektą. Naudingaapibrėžti keletą įvykių, kuriuos būtų galima įtraukti į rizikingų grupę <strong>ir</strong> iš anksto apgalvotibūdus, kaip jų išvengti ar bent sumažinti jų įtaką projekto baigčiai. Įvykius verta kategorizuotipagal jų įvykimo tikimybę <strong>ir</strong> jų padarinius. TSP procesas apibrėžia keletą dažniausiaipasitaikančių, riziką projektui keliančių įvykių, bei nurodo jų valdymo metodus.Galimų rizikų identifikavimas. Numatomi įvykiai, kuriuos būtų galima įtraukti į rizikingųgrupę bei kurie gali įtakoti projektą.Detali kiekvienos įvardintos rizikos analizė. Išanalizuojamas <strong>ir</strong> nustatomas kiekvienosrizikos laipsnis.Planų, rizikų valdymui, paruošimas. Aukščiausią laipsnio rizikoms valdyti paruošiamiplanai.Pastovus identifikuotų rizikų stebėjimas. Komandos sus<strong>ir</strong>inkimų metu aptariamospotencialios rizikos <strong>ir</strong> kaip jas valdyti.Kokybės planavimas <strong>ir</strong> valdymasTikslas. Apibrėžti <strong>ir</strong> dokumentuoti kokybės kriterijus bei paruošti kokybės valdymo planą.Mokymo medžiaga 122
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasVeiklos:• Apibrėžti kokybės kriterijus.• Paruošti kokybės valdymo planą.Aprašymas. Praktikos metu komanda įvardina kokybei keliamus tikslus <strong>ir</strong> kokiomismetrikomis remiantis ji bus vertinama. Veiklos rezultatas yra kokybės valdymo planas,pateikiantis informaciją apie:• klaidų kiekius programų išeities tekstuose bei projekto dokumentuose <strong>ir</strong> šių kiekiųkitimą kiekvienos iš iteracijų metu;• nurodo klaidų radimui, projekto dokumentų peržiūrai <strong>ir</strong> pačių komponentų kūrimuisugaištą laiką;• suformuoja kokybės kriterijus, kuriuos tenkinantis produktas laikomas kokybišku.Apibrėžti kokybės kriterijus. Kokybei vertinti naudojama daugelis PSP proceso metrikų,pavyzdžiui: defektų kiekis randamas kiekvienos iš fazių metu (angl. yeld by phase), peržiūrųefektyvumas (angl. review rates), vidutinis defektų kiekis kiekvienos iš fazių metu (angl. defectdensity by phase).Paruošti kokybės valdymo planą. Paruošiamas kokybės valdymo planas, kuriamedokumentuojami apibrėžti kokybės kriterijai. Projekto metu kokybės valdymo plane pateikiamiklaidų kiekiai <strong>ir</strong> jų kitimas kiekvienos iš produkto kūrimo iteracijų metu.Pastabos. Praktika turi būti diegiama kartu su automatiniais įrankiais, padedančiaisautomatizuoti duomenų surinkimą bei projekto ataskaitų, reikalingų kokybės valdymo planoparuošimui (defektų kiekio, peržiūrų efektyvumo, vidutinio defektų kiekio metrikos),generavimą.Produkto kūrimo plano <strong>ir</strong> tvarkaraščio ruošimasTikslas. Numatyti užduočių įgyvendinimui sk<strong>ir</strong>iamus terminus, užduočių įgyvendinimotvarką bei kiekvienam iš komandos narių užduotims įvykdyti planuojamą laiką.Veiklos:• Įvardinamos ciklo metu kuriamos sistemos dalys <strong>ir</strong> įvertinami bei dokumentuojami jųdydžiai.• Paruošiamas ciklo užduočių planas.• Paruošiamas ciklo tvarkaraštis.• Subalansuojamas komandos narių apkrovimas.Aprašymas. Vykdant šį žingsnį įvardinamos ciklo metu kuriamos produkto dalys <strong>ir</strong>numatomi apytikriai jų dydžiai. Taip pat įvardinami kiti ciklo metu kuriami produktai beiįvardinami jų dydžiai: numatoma, kiek laiko užtruks produktui keliamų reikalavimųMokymo medžiaga 123
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasspecifikavimas, eskizinio projekto paruošimas, vartotojo dokumentacijos paruošimas, testų planųsukūrimas <strong>ir</strong> kitų ciklo metu atliekamų užduočių įvykdymas. Kuriamų sistemos dalių dydžiuimatuoti naudojama kodo eilučių skaičiavimo metodika bei vertinamas detaliojo projektodokumento eilučių skaičius. Tuo tarpu reikalavimų specifikacijos dydis vertinamas tekstopuslapių skaičiumi, eskizinio projekto dydis – eskizinio projekto puslapių skaičiumi. Kadangistrategijos kūrimo fazėje sistemos dalių dydis jau buvo įvertintas, tai naudojamasi jau turimaisįverčiais.Įvardinamos ciklo metu kuriamos sistemos dalys <strong>ir</strong> įvertinami bei dokumentuojami jųdydžiai. Vykdant šį žingsnį įvardinamos ciklo metu kuriamos produkto dalys <strong>ir</strong> dokumentuojamijų dydžiai, remiantis strategijos kūrimo fazėje surinktais duomenimis.Paruošiamas užduočių planas. Šio žingsnio metu suformuojamas komandos atliekamųužduočių sąrašas. Antrasis darbas, kurį atlieka komanda, tai įvertina, kiek reikia laiko atliktikiekvienai iš sąraše įvardintų užduočių. Kadangi kiekviena iš užduočių yra atliekama bent vienosrolės atstovo, tai prie užduoties konkrečiai nurodomas jos vykdytojas (vykdytojai) <strong>ir</strong>prognozuojamas užduoties įvykdymo laikas. Laiko prognozavimui gali būti naudojamas PROBEmetodas, kuris naudojamas PSP planavimo procese. PROBE metodas naudos PSP proceso metusurinktus duomenis to komandos nario, kuriam prisk<strong>ir</strong>tas užduoties įvykdymas.Paruošiamas tvarkaraštis. Pagal ankstesniame žingsnyje paruoštą užduočių planąpaskaičiuojama, kiek laiko (valandomis) kiekvienas komandos narys praleis d<strong>ir</strong>bdamas projekte.Jeigu užduočių plane randamos klaidos, laiko prognozavimo darbai gali būti atliekamipakartotinai. Naudojantis užduočių planu, komanda paruošia tvarkaraščio projektą.Subalansuojamas komandos narių apkrovimas. Šios TSP veiklos tikslas - identifikuotilabiausiai apkrautus komandos narius <strong>ir</strong> perkelti kai kurias jų užduotis kitiems komandosnariams, taip subalansuojant visų komandos narių apkrovimą.Pastabos. Užduočių plano <strong>ir</strong> tvarkaraščio paruošimą labai palengvintų specialiaiplanavimui paruoštų įrankių naudojimas. Idealiausia, jei planavimo įrankiui būtų prieinamikomandos narių surinkti asmeniniai rodikliai, kadangi tai užtikrintų ne tik kokybiškesnį, bet <strong>ir</strong>operatyvesnį planavimo procesą.Reikalavimų specifikacijos ruošimasTikslas. Paruošti vartotojo poreikius atitinkančią reikalavimų specifikaciją.Veiklos:• Poreikių išsiaiškinimas <strong>ir</strong> specifikavimas.• Reikalavimų specifikavimas.Mokymo medžiaga 124
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasAprašymas. Vykdydamas šią praktiką kiekvienas komandos narys specifikuojareikalavimus tos produkto dalies, kuri jam buvo pask<strong>ir</strong>ta ankstesnio žingsnio metu, t.y.įvardinant reikalavimų specifikacijos ruošimo užduotis.Poreikių išsiaiškinimas <strong>ir</strong> specifikavimas. Vykdant šį žingsnį, išsiaiškinami <strong>ir</strong>dokumentuojami vartotojo poreikiai. Specifikavus vartotojo poreikius, atliekama jų peržiūra.Peržiūra yra sk<strong>ir</strong>ta tam, kad komandos nariai identifikuotų specifikavimo metu padarytas klaidas(neatsižvelgta į tam tikrus poreikius, neteisingai suprasti poreikiai <strong>ir</strong> pan.), o peržiūros pabaigojeturėtų vienodą supratimą apie poreikius būsimam produktui. Šios peržiūros metu komandakoncentruojasi ties tomis funkcijomis, kurios bus kuriamos sekančio ciklo metu. Nors ikiprojektavimo fazės pabaigos visos šios funkcijos <strong>ir</strong> nėra tiksliai žinomos, tačiau preliminariąkuriamų funkcijų aibę komanda gali įvardinti.Reikalavimų specifikavimas. Vykdydamas šią veiklą, kiekvienas komandos narysspecifikuoja reikalavimus tos produkto dalies, kuri jam buvo pask<strong>ir</strong>ta ankstesnio žingsnio metu,t.y. įvardinant reikalavimų specifikacijos ruošimo užduotis. TSP pateikia nurodymų <strong>ir</strong>rekomendacijų, kaip specifikuoti reikalavimus, kad projektuojant jie būtų vienodai suprasti visųprojektuotojų. Klaidingai specifikuotiems reikalavimams ištaisyti reikės laiko, todėl komandanegalės laiku įvykdyti visų užduočių, o tai tiesiogiai veiks planavimo <strong>ir</strong> paties produkto kokybęProjektavimasTikslas. Paruošti projektą, kuriame būtų nurodyta, kaip bus kuriamas produktas, kokiatvarka projektuojamos įva<strong>ir</strong>ios produkto dalys, kas projektuos kiekvieną iš dalių <strong>ir</strong> kaip visosdalys d<strong>ir</strong>bs kartu.Veiklos:• Bendros kuriamo produkto struktūros numatymas <strong>ir</strong> aptarimas.• Produkto funkcijų pask<strong>ir</strong>stymas jį sudarantiems komponentams.• Kiekvieno iš komponentų aprašų sudarymas.• Projektavimo užduočių, kurias reikia atlikti norint paruošti projektą, įvardinimas.Aprašymas. Praktikos metu labai tiksliai <strong>ir</strong> aiškiai nurodomos produktą sudarysiančiosdalys, apibrėžiama, kaip jos sąveikauja tarpusavyje bei nurodomi būdai, kaip <strong>ir</strong> kokia tvarka jasapjungti į vientisą produktą.Bendros kuriamo produkto struktūros numatymas <strong>ir</strong> aptarimas. Šios veiklos metukomanda tiksliai apibrėžia komponentus, kurie bus sukurti kiekvieno iš ciklų metu beinusprendžia, kokie tarpusavio ryšiai juos sies.Produkto funkcijų pask<strong>ir</strong>stymas jį sudarantiems komponentams. Šios veiklos vykdymometu yra prisk<strong>ir</strong>iamos ciklo metu kuriamo produkto funkcijos jį sudarantiems komponentams.Taip pat numatoma, kurių ciklų metu komponentai bus papildomi naujomis funkcijomis.Mokymo medžiaga 125
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasaprašai.Kiekvieno iš komponentų aprašų sudarymas. Paruošiami visų komponentų interfeisųProjektavimo užduočių, kurias reikia atlikti norint paruošti projektą, įvardinimas. Šioveiklos metu paruošiama projekto dokumento struktūra <strong>ir</strong> įvardinamos projektavimo užduotys,kurias reikia atlikti, norint paruošti dokumentą. Suformuluotos užduotys padalinamos komandosnariams, nurodant kiekvienos iš jų įvykdymo terminus. Užduotys padalinamos atsižvelgiant įkomandos narių žinias, įgūdžius bei projektavimo praktiką.TSP principų <strong>ir</strong> praktikų sąryšiaiŽemiau pateikiama TSP procesų principų <strong>ir</strong> praktikų sąryšių lentelė, t.y. kokius TSPprincipus kokios praktikos įgyvendina.PrincipasProgramų sistemų kūrėjaid<strong>ir</strong>bs efektyviai, jei naudosapibrėžtą <strong>ir</strong> matuojamąprocesą.Komanda bus motyvuota, jeid<strong>ir</strong>bs turėdama bendrą viziją<strong>ir</strong> žinodama jai keliamustikslus.Procesas geriausiai atitikskomandos poreikius, jei busjai pritaikytas.Komandos nariai žinos už kąjie atsakingi <strong>ir</strong> kam turiatsiskaityti, jei komandojebus įtv<strong>ir</strong>tintos aiškiosatsakomybės <strong>ir</strong> atskaitomybėĮgyvendinančiospraktikosProjekto progresosekimas (PSPpraktikos laiko,defektų, dydžiomatavimui)Komandos tikslųsuformulavimas <strong>ir</strong>dokumentavimasPraktikos veiklosApibrėžti pateikiamos informacijosrūšis, kas jas turi pateikti bei kam jospateikiamos.Apibrėžti informacijos pateikimo formąKomandai keliamų tikslųsuformulavimas <strong>ir</strong> dokumentavimasKomandos nariams keliamų tikslųsuformulavimas <strong>ir</strong> dokumentavimasKriterijų, kuriais remiantis busvertinamas produkto <strong>ir</strong> komandosatitikimas iškeltiems tikslams,apibrėžimasPritaikytos visos TSP <strong>ir</strong> PSP praktikosRolių <strong>ir</strong> jųatsakomybiųapibrėžimas beipriskyrimasApibrėžti kiekvienos rolės atsakomybes<strong>ir</strong> įsipareigojimus.Roles pask<strong>ir</strong>styti komandos nariamsProgramų sistemų kūrėjai Komunikavimo Nurodyti pateikiamos informacijos rūšisMokymo medžiaga 126
Programų sistemų inžinerijaPrincipasaktyviai keisis informacija <strong>ir</strong>žiniomis, jei komandoje busskatinamas nuolatinisbendravimas.Suteikti galimybę programųsistemų kūrėjams d<strong>ir</strong>bti taip,kaip jie įpratę, tačiauprisilaikant nustatytokomandos proceso <strong>ir</strong>atsižvelgiant į jų pačiųsurinktus duomenis <strong>ir</strong> kolegųpat<strong>ir</strong>tį.Norint pastoviai gerinti savoveiklą, reikia nuolat tobulintiprocesą, atsižvelgiant įproceso metu sukauptusistorinius duomenis <strong>ir</strong>rodiklius.Skatinti būsimų produktųkokybės užtikrinimą <strong>ir</strong>galimų rizikų įvertinimą beivaldymą.ĮgyvendinančiospraktikosprocedūrųapibrėžimasProdukto kūrimostrategijos ruošimasProdukto kūrimoplano <strong>ir</strong> tvarkaraščioruošimasReikalavimųspecifikacijosruošimasProjektavimasKomandos procesoevoliucionavimo/pritaikymo planoparuošimas <strong>ir</strong> joįgyvendinimasRizikų įvertinimas <strong>ir</strong>valdymas8. Komandinis programų kūrimo procesasPraktikos veiklos<strong>ir</strong> atsakingus asmenisParuošti komandos sus<strong>ir</strong>inkimų grafikąVisos nurodytus etapus atitinkančiosgyvavimo ciklo veiklosIšanalizuoti proceso duomenis.Įvertinti rolių įgyvendinimą.Paruošti projekto (ciklo) ataskaitą <strong>ir</strong>tobulinimo pasiūlymusRizikų identifikavimas.Detali kiekvienos įvardintos rizikosanalizė.Planų, rizikų valdymui, paruošimas.Pastovus identifikuotų rizikų stebėjimasKokybėsplanavimas <strong>ir</strong>valdymasApibrėžti kokybės kriterijus.Paruošti kokybės valdymo planąTSP taikymų praktikoje rezultatų analizėNors komandinis programų sistemų kūrimo procesas (TSP) buvo pristatytas dar 1999metais, tačiau paskelbta itin mažai darbų, aprašančių šio proceso taikymą praktikoje. Vienas išMokymo medžiaga 127
Programų sistemų inžinerija8. Komandinis programų kūrimo procesastokių darbų pavyzdžių yra Carnegie Mellon universiteto darbuotojų paskelbtas darbas, aprašantis4 organizacijų (nuo CMM 1 iki CMM 5 lygio) TSP proceso taikymo rezultatus. Šis darbas yrastatistinės analizės ataskaita, kurioje naudojant statistinius metodus bandoma įrodyti TSPproceso taikymo naudą. Darbo autorių teigimu, taikydamos TSP procesą, komandos galitinkamai paruošti projekto planus <strong>ir</strong> laiku įgyvendinti pask<strong>ir</strong>tas užduotis. Ir kas svarbiausia,naudojant TSP, sukuriami itin aukštos kokybės produktai, pasižymintys minimaliu klaidųskaičiumi. Mažas klaidų skaičius sąlygoja trumpesnę testavimo fazę bei trumpesnį produktokūrimo ciklą, o tai leidžia klientui produktą pateikti per maksimaliai trumpus terminus.Statistinei analizei naudotas pasikartojančių matavimų sk<strong>ir</strong>tumų analizės metodas(ANOVA). Šis metodas naudingas tada, kai reikia pamatuoti progresą atliekant eilę bandymų.Ankstesni bandymai laikomi pagrindu <strong>ir</strong> analizuojami tik sk<strong>ir</strong>tumai tarp bandymų metu surinktųduomenų. Šis metodas buvo naudojamas visų svarbiausių rodiklių statistinei analizei.Surinktų duomenų p<strong>ir</strong>minė analizė. Kadangi tyrime dalyvaujančių 4 organizacijų pateiktiduomenys yra nepilni, tai negalima atlikti išsamios analizės, tačiau tai įgalina nustatyti tam tikrastendencijas. Atliekant duomenų analizę buvo laikomasi tokių prielaidų: pateikti duomenųrinkiniai nėra homogeniški; duomenys nėra pasisk<strong>ir</strong>stę pagal normalinį sk<strong>ir</strong>stinį; duomenų aibėsyra pakankamai mažos.Pastangų <strong>ir</strong> laiko vertinimo tikslumas. Projekto kaštų apskaičiavimo <strong>ir</strong> planų sudarymoproblemos iškyla tada, kai programų sistemų kūrėjai įsipareigoja įgyvendinti projektą,remdamiesi klaidingais produkto dydžio bei reikalingų laiko sąnaudų vertinimais. Šiemsvertinimams atlikti TSP naudoja PSP procese aprašytus vertinimo metodus. Vertinant metunaudojami istoriniai duomenys, surinkti PSP proceso metu. Organizacijų pateiktų duomenųstatistinė analizė parodė, jog komandos sugebėjo gana tiksliai suplanuoti produkto kūrimą bei suminimalia paklaida pateikė produkto kūrimo kaštus. Prieš įdiegiant TSP procesą laiko planavimoprognozavimo vidutinis nuokrypis buvo 35%, o TSP proceso naudojimo metu vidutinėnuokrypis buvo sumažintas iki 12%.Klaidų kiekis. Taikant TSP procesą, kiekvienas iš komandos narių yra atsakingas už jokuriamo komponento ar komponento dalies kokybę. Norint išvengti klaidų galutiniame produkte,kiekvienas komandos narys atlieka savo kuriamo komponento peržiūrą. Sėkmingai įvykdžiuskomponento peržiūrą, kodas yra sukompiliuojamas <strong>ir</strong> kartu su jo dokumentacija patikrinamaskitų komandos narių, naudojant apibrėžtus metodus. Tai užtikrina, jog sukurti produktai turėsminimalų defektų skaičių. Duomenų analizė parodė, jog viso komandos, netgi CMM 5 lygįturinčios organizacijos komanda, sugebėjo pagerinti savo kuriamo produkto kokybę.Produktyvumas. Jei komandos nariai laikosi TSP proceso, tai kurdami kokybišką produktągali pagerinti savo komandos produktyvumą, sumažindami produkto testavimui reikalingą laiką.Mokymo medžiaga 128
Programų sistemų inžinerija8. Komandinis programų kūrimo procesasNaudodamos TSP procesą komandos daugiau laiko praleidžia reikalavimų specifikavimo,projektavimo bei projekto peržiūros fazių metu, tačiau sutaupo laiko testavimo fazės metu. Norsprodukto kūrimo (kodavimo) laiko sąnaudos gali būti tos pačios kaip <strong>ir</strong> nenaudojant TSPproceso, tačiau sutrumpėjusi sistemos testavimo fazė leidžia sutaupyti gana daug laiko. Norstyrime dalyvaujančios organizacijos nepateikė duomenų apie komandų produktyvumopadidėjimą ar sumažėjimą, tačiau iš pateiktų duomenų matosi, jog sutrumpėjo produktotestavimo fazės.Išvados. Šį tyrimą galima prisk<strong>ir</strong>ti tokių tyrimų kategorijai, kurių rezultatai gali nevisiškaiatitikti realią situaciją dėl nepakankamos duomenų imties. Tuo pačiu, nėra griežtai apibrėžiama,kokios TSP priemonės buvo naudotos atliekant laiko, dydžio vertinimus <strong>ir</strong> kaip jos buvostandartizuotos kiekvienoje iš organizacijų. Autoriai atmeta prielaidą, jog duomenų aibėsegalimos tam tikros paklaidos. Taip pat tyrimo autoriai nepateikia jokių duomenų apie tyrimedalyvavusius inžinierius: jų išsilavinimą, darbo pat<strong>ir</strong>tį <strong>ir</strong> t.t.PSP <strong>ir</strong> TSP taikymų pat<strong>ir</strong>ties analizės išvadosNors asmeninis programų kūrimo procesas (PSP) <strong>ir</strong> komandos programų kūrimo procesas(TSP) literatūroje pristatyti jau pakankamai seniai, tačiau vis dar trūksta medžiagos, aprašančiosjų pritaikymą pramonėje. Didžioji dalis esamos literatūros aprašo procesų taikymo pavyzdžiusizoliuotoje akademinėje aplinkoje, nenukrypstant nuo pateiktos procesų mokymo programos,todėl jų darbuose neįvardinamos su procesų diegimu susijusios problemos bei galimi šiųproblemų sprendimo būdai, neaptarti pas<strong>ir</strong>inkti procesų adaptacijos <strong>ir</strong> tobulinimo keliai. Be to,paskelbtų darbų autoriai labai mažai dėmesio kreipia į surenkamų duomenų kokybę, nors procesąvertina remdamiesi kaip tik šiais duomenimis.Išanalizavus keletą paskelbtų darbų, kuriuose procesai t<strong>ir</strong>iami <strong>ir</strong> diegiami ne izoliuotojeaplinkoje, o realiose pramonės įmonėse, galima suformuluoti tokias išvadas:• Įdiegus procesus, nepastebėta jokių esminių produktyvumo pokyčių, tačiau sumažėjolaiko sk<strong>ir</strong>iamo produkto kompiliavimui <strong>ir</strong> testavimui sąnaudos.• Procesų taikymas padidina laiko sąnaudas,kadangi proceso veiklų taikymas turi tapti įpročiu.tačiau ilgainiui jos turėtų sumažėti,• Ženkliai padidėjo darbuotojų motyvacija kurti kokybiškus produktus.• Pagerėjo kuriamų produktų kokybė.• Padidėjo darbuotojų pasitenkinimas jų atliekamu darbu, o tai suteikia galimybę toliauoptimizuoti procesus bei juos pritaikyti kitose srityse.• Būtina naudoti įrankius, leidžiančius automatizuoti procesų metu surenkamų duomenųagregavimą <strong>ir</strong> analizę. Šie įrankiai turi būti pilnai integruoti, t.y. komandos narys pateikia tikMokymo medžiaga 129
Programų sistemų inžinerija8. Komandinis programų kūrimo procesaspradinius proceso duomenis, o visos apskaičiuotų rodiklių reikšmės automatiškai pernešamos įkitas formas be programuotojo įsikišimo. Tai yra viena iš pagrindinių sąlygų, norint sėkmingainaudoti įdiegtus procesus <strong>ir</strong> būti užtikrintiems gautų duomenų kokybe.• Proceso vertinimui nenaudoti paties proceso metrikų. Tam tikslui turi būti naudojami“išoriniai” proceso vertinimo metodai.• Nors automatiniai įrankiai užtikrina surinktų duomenų analizės kokybę, tačiauužtikrinti surenkamų duomenų kokybę beveik neįmanoma. Tai priklauso nuo kiekvieno procesąvykdančio asmens noro <strong>ir</strong> motyvacijos pateikti pilnus <strong>ir</strong> korektiškus duomenis.• Aiškiai apibrėžti, kokiu tikslu renkami duomenys, kad būtų išvengta tyčinio duomenųklastojimo.Literatūra papildomam skaitymui[Hum98] Watts S. Humphrey. Three Dimensions of Process Improvement Part III: TheTeam Process. http://www.stsc.hill.af.mil/crosstalk/1998/apr/dimensions.html,1998.[Hum99] Watts S. Humphrey. Introduction to the Team Software Process. Addison-Wesley,463 pages, 1999[Hum00] Watts S. Humphrey. The Team Software Process (TSP), Technical Report,CMU/SEI-2000-TR-023, ESC-TR-2000-023, 2000.[McA00] Donald R. McAndrews. The Team Software Process (TSP): An Overview andPreliminary Results of Using Disciplined Practices, Technical Report, CMU/SEI-2000-TR-015, ESC-TR-2000-015, 2000.Mokymo medžiaga 130
Programų sistemų inžinerija9. Testavimo brandos modelis9. Testavimo brandos modelisTestavimo brandos modelis TMM buvo sukurtas 1996 m. Ilene Burnstein vadovaujamosgrupės Ilinojaus technologijos institute.9.1 pav. Ilene Burnstein (http://www.cs.iit.edu/faculty/burnstein.html)Pagrindinis TMM tikslas yra testavimo proceso vertinimas <strong>ir</strong> gerinimas. Jis parodopakopinį testavimo proceso gerinimo kelią, todėl, autorių nuomone, jis gali būti naudojamas <strong>ir</strong>mokymui, kad palaipsniui supažindinti su testavimo sąvokomis, principais <strong>ir</strong> geriausiomispraktikomis.TMM orientuojasi į procesą, konkrečiai į testavimo procesą. Testavimas suprantamasplačiąja prasme, kaip visos veiklos, susijusios su programų kokybe.Apibrėžimas. Testavimas: (1) Grupė procedūrų, atliekamų programinės įrangos 5 dalieskokybės įvertinimui. (2) Procesas, naudojamas radimui programinės įrangos defektų <strong>ir</strong>nustatymui, kad programinė įranga atitinka apibrėžtą kokybės lygį pagal pas<strong>ir</strong>inktus atributus.TMM modelį gali naudoti (kas <strong>ir</strong> kokiam tikslui):- vidinė organizacijos vertinimo komanda einamojo proceso brandos nustatymui;- organizacijos vadovybė testavimo proceso gerinimo inicijavimui;- kokybės užtikrinimo specialistai testavimo gerinimo planų sukūrimui <strong>ir</strong> diegimui;- kūrimo/testavimo komandos testavimo efektyvumo gerinimui;- naudotojai/užsakovai savo rolės testavimo procese apibrėžimui.Reikėjo specifinio modelio, nes bendrieji programų kūrimo proceso modeliai, tokie kaipCMM, CMMI, SPICE, ISO/IEC 15504, Bootstrap, nepakankamai dėmesio sk<strong>ir</strong>ia testavimui.TMM pagrindiniai komponentai:1. Testavimo brandos lygiai.2. Brandos tikslai <strong>ir</strong> potiksliai kiekvienam brandos lygiui, išskyrus 1-ą lygį3. Vertinimo modelis, sudarytas iš:5 TMM nepateikia programinės įrangos apibrėžimo, bet reikia manyti, kad naudojama ISO/IEC 12207 samprata:„Programinė įranga yra aibė kompiuterio programų, procedūrų <strong>ir</strong>, galbūt, susijusios dokumentacijos bei duomenų.“Mokymo medžiaga 131
Programų sistemų inžinerija9. Testavimo brandos modelisa. Su brandos tikslais susijusių klausimų, sk<strong>ir</strong>tų testavimo proceso einamajai būsenainustatyti.b. Nurodymų vertinimo komandos parinkimui <strong>ir</strong> parengimui.c. Vertinimo procedūros, apibrėžiančios testavimo proceso vertinimo <strong>ir</strong> gerinimožingsnius.Reikalavimai, kuriuos turėjo patenkinti TMM:- Modelis turi būti priimtinas programinę įrangą kuriančioms įmonėms <strong>ir</strong> remtispripažintais programų sistemų inžinerijos principais <strong>ir</strong> praktikomis. Aukštesni brandos lygiai turibūti pakankamai lankstūs, kad galėtų būti taikomos naujai ats<strong>ir</strong>adusios geriausios praktikos.- Modelis turi leisti testavimo proceso brandos vystymą fazėmis, atitinkančiomis natūraliąproceso evoliuciją.- Turi būti pateikiamas testavimo proceso vertinimo <strong>ir</strong> gerinimo būdas.TMM buvo kuriamas, remiantis tokiais šaltiniais: SW-CMM, evoliuciniu testavimomodeliu [GH88], esama testavimo praktika [Dur93] <strong>ir</strong> testuotojo mentalinio modelio vystymosifazėmis [Bei90].EvoliucinistestavimomodelisGebėjimobrandosmodelisLygis 5Lygis 4Lygis 3Lygis 2Lygis 1Testavimo brandos modelisEsamatestavimopraktikaTestuotojomentaliniomodeliovystymosi fazės9.2 pav. PagrindiniaiTMM šaltiniaiMokymo medžiaga 132
Programų sistemų inžinerija9. Testavimo brandos modelisTMM savo struktūra <strong>ir</strong> principais panašus į CMM. TMM gali būti naudojamas kartu suCMM, nes testavimo proceso branda yra susijusi su viso organizacijos proceso branda,investicijos vertinimui gali būti optimizuojamos.Testavimo modelio evoliucija [GH88] apima laikotarpį nuo 1950 metų. Pradžiojetestavimas buvo neatsk<strong>ir</strong>iamas nuo derinimo (angl. debugging), jis buvo atliekamas kartu suderinimu, kai pr<strong>ir</strong>eikdavo rasti <strong>ir</strong> pašalinti defektus. Nuo to laiko testavimas praėjo keletą fazių,kol tapo prevencine veikla, atitinkančia 5-ą CMM <strong>ir</strong> TMM lygį.Lygis 5. 5. Optimizavimo, defektų prevencijos <strong>ir</strong>kokybės kontrolėsTestavimo proceso optimizavimasKokybės kontrolėProceso duomenų taikymas defektų prevencijaiLygis 4. Valdymo <strong>ir</strong> matavimoKokybės įvertinimasMatavimų programos įdiegimasPeržiūrų programos įdiegimas visoje organizacijojeLygis 3. IntegravimoTestavimo proceso stebėjimas <strong>ir</strong> valdymasTestavimo integrvaimas į gyvavimo cikląTechninių apmokymų programos įdiegimasTestavimo organizacijos įkūrimasLygis 2. Fazės apibrėžimoBazinių testavimo būdų <strong>ir</strong> metodų institucionalizavimasTestavimo proceso incijavimasTestavimo <strong>ir</strong> derinimo tikslų apibrėžimasLygis 1. Pradinis9.3 pav. 5 lygių TMM struktūraMokymo medžiaga 133
Programų sistemų inžinerija9. Testavimo brandos modelisEsamos testavimo praktikos tyrimas [Dur93] parodė tiek geriausias, tiek blogiausiastestavimo aplinkas, kurių pagrindu buvo pasiūlyti atitinkantys realybę testavimo procesovertinimo <strong>ir</strong> gerinimo rodikliai.Atsk<strong>ir</strong>o testuotojo mentalinio modelio vystymosi [Bei90] idėjos buvo panaudotos TMM:brandi testavimo organizacija remiasi įgūdžiais, galimybėmis <strong>ir</strong> nuostatomis (požiūriu) jojed<strong>ir</strong>bančių individųTMM struktūraTMM yra pakopinės architektūros proceso modelis. Jame yra apibrėžti 5 testavimo procesobrandos lygiai (angl. Maturity Levels):Goals).1. Pradinis (angl. Initial)2. Fazės apibrėžimo (angl. Phase Definition)3. Integravimo (angl. Integration)4. Valdymo <strong>ir</strong> matavimo (angl. Management and Measurement)5. Optimizavimo, defektų prevencijos <strong>ir</strong> kokybės kontrolės (angl. Optimization, DefectPrevention and Quality Control)Kiekvienam brandos lygiui, išskyrus 1-ą lygį, apibrėžiami brandos tikslai (angl. MaturityDetalesnė (vidinė) modelio struktūra pateikta 9.4 pav. Kiekvienas brandos lygis parodoatitinkamą testavimo proceso gebėjimą (angl. Testing Capability). Brandos tikslai (angl.Maturity Goals) tikslus, kurie turi būti pasiekti proceso gerinimo eigoje, arba, kitaip sakant,proceso sritis, kurios turi būti įgyvendintos. Brandos tikslai detalizuojami į brandos potikslius(angl. Maturity Subgoals), nusakančius mažiau abstrakčius tikslus, jų įgyvendinimo apimtį <strong>ir</strong>rezultatus. Tikslų yra siekiama atliekant veiklas, užduotis <strong>ir</strong> apibrėžiant atsakomybes (angl.Activities/Tasks/Responsibilities). Veiklos <strong>ir</strong> užduotys apibrėžia, kas turi būti daroma testavimoproceso pagerinimui atitinkamame lygyje; jos turi būti pritaikomos organizacijai <strong>ir</strong>įgyvendinamos (angl. Implementation and organizational adaptation). Veikloms yraprisk<strong>ir</strong>iamos atsakomybės <strong>ir</strong> užduotys yra grupuojamos į 3 grupes, atitinkančias esminiustestavimo proceso dalyvius – vadovus, kūrėjus/testuotojus <strong>ir</strong> naudotojus/užsakovus. Modelyje josvadinamos kritiniais požiūriais (angl. Critical views).Vadovų (angl. Manager) požiūris apima įsipareigojimą <strong>ir</strong> gebėjimą atlikti veiklas <strong>ir</strong>užduotis, susijusias sutestavimo proceso gerinimu. Vadovų TMM kontekste pavyzdžiai: projektovadovas, testavimo grupės vadovas, kokybės užtikrinimo vadovas, o taip pat <strong>ir</strong> aukštesnio lygiovadovai – skyriaus ar padalinio vadovas.Mokymo medžiaga 134
Programų sistemų inžinerija9. Testavimo brandos modelisKūrėjų/testuotojų (angl. Developer/tester) požiūris apima technines veiklas <strong>ir</strong> užduotis,įgyvendinančias testavimą. Kūrėjai <strong>ir</strong> testuotojai tai žmonės specifikuojantys, projektuojantys,koduojantys <strong>ir</strong> testuojantys programinę įrangą.Naudotojų/užsakovų (angl. User/client) požiūris apibrėžtas kaip bendradarbiaujantis arpalaikantis. Jis orientuojasi į pastangas gauti naudotojų/užsakovų palaikymą, konsensusopasiekimą <strong>ir</strong> įtraukimą į reikalavimų analizę, naudojamumo testavimą, sistemos veikimoaplinkos apibrėžimą <strong>ir</strong> priėmimo testų (angl. acceptance testing) planavimą.LygisnurodoapibrėžiaTestavimogebėjimasBrandos tikslaiBrandospotiksliaipalaikopasiekiami perVeiklos, užduotys, atsakomybėssk<strong>ir</strong>tiDiegimas <strong>ir</strong>pritaikymasorganizacijojeKritiniaipožiūriaisugrupuoti pagalVadovųKūrėjų/testuotojųNaudotojų/užsakovų9.4 pav. Vidinė TMM brandos lygio struktūraTMM vertinimo modelisVertinimo modelis turi pateikti žingsnius, veiklas, užduotis <strong>ir</strong> formas proceso vertinimuipagal formalų proceso modelį. Jis taip pat turėtų padėti, atlikus vertinimą, gerinti procesą.TMM vertinimo modelis tenkina šiuos reikalavimus: naudoja TMM proceso modelį <strong>ir</strong>vertina, kaip (kiek) organizacija pasiekia TMM brandos tikslus.Vertinimo modelį sudaro 3 pagrindinės komponentės:1) vertinimo komandos parinkimas <strong>ir</strong> apmokymas;2) vertinimo procedūra;Mokymo medžiaga 135
Programų sistemų inžinerija9. Testavimo brandos modelis3) vertinimo instrumentas (klausimynas).Vertinimo modelio schema pateikta 9.5 pav.PradiniaiduomenysInterviu duomenysKlausimynų duomenysVertinimo planasSusiję dokumentaiTestavimo brandosmodelisTMM apmokymai <strong>ir</strong>komandosparinkimo kriterijaiTMM vertinimoprocesasTMM vertinimoprocedūraTMM vertinimoklausimynas9.5 pav. TMM vertinimo modelio struktūraRezultataiTMM lygisTestavimo proceso profilisStipriosios/silpnosios pusėsVeiksmų planaiVertinimo įrašaiVertinimo komandos parinkimas <strong>ir</strong> apmokymasKomandos nariai turi būti kvalifikuoti <strong>ir</strong> motyvuoti: kandidatai į vertinimo komandą turiišmanyti TMM vertinimą, būti gerbiami organizacijoje, suinteresuoti pagerinti testavimoprocesą, turėti galimybę įgyvendinti pakeitimus <strong>ir</strong> turėti kūrimo/testavimo/vadovavimo pat<strong>ir</strong>ties(rekomenduojama vidutinė 7 metų pat<strong>ir</strong>tis). Komandai būtinas lyderis, kuriam būtinos aukštolygio kūrimo <strong>ir</strong> vadovavimo žinios bei pat<strong>ir</strong>tis. Siūloma vertinimo komandą sudaryti iš 4-8 narių.Komandos pas<strong>ir</strong>engimui turi vadovauti komandos lyderis. Apmokymo programa turėtųapimti tokias temas:- įvadas į proceso gerinimo modelius;- TMM apžvalga;- informacijos surinkimo metodai;- vertinimo planavimas;- duomenų analizė;- ataskaitos parengimas.Vertinimo procedūraTMM vertinimo procedūra apibrėžia tokius žingsnius (reikia pastebėti, kad iš esmės tai yraproceso gerinimo procedūra):- Pas<strong>ir</strong>engimas- TMM vertinimo atlikimas- Vertinimo rezultatų ataskaita- Vertinimo rezultatų analizėMokymo medžiaga 136
Programų sistemų inžinerija9. Testavimo brandos modelis- Gerinimo veiksmų planavimas- Gerinimo įgyvendinimas.Vertinimo klausimynasVertinimo klausimynas yra tokios struktūros lentelė (toliau vardinami jos stulpeliai):- Klausimas. Pavyzdžiui, Ar testavimo <strong>ir</strong> derinimo komitetas buvo įkurtas?- Taip - atsakoma tuo atveju, kai praktika yra įgyvendinta <strong>ir</strong> tinkamai atliekama.- Ne - atsakoma tuo atveju, kai praktika nėra įgyvendinta arba netinkamai atliekama.- Netaikoma - atsakoma tuo atveju, kai turima pakankamai žinių apie projektą arorganizaciją <strong>ir</strong> manoma, kad šis klausimas neturi būti projektui ar organizacijai.- Nežinoma - atsakoma tuo atveju, kai nežinoma, kaip atsakyti, arba neturimapakankamai informacijos ar pat<strong>ir</strong>ties.- Pastabos.Kiekvienas respondentas prieš atsakinėdamas turi pateikti:1) informaciją apie save (vardas, pareigos, projektas, kontaktinė informacija), savopareigų kategoriją, už ką jis atsakingas, ar buvo apmokytas TMM, pat<strong>ir</strong>tį organizacijoje<strong>ir</strong> iš viso, ar anksčiau dalyvavo vertinimuose;2) informaciją apie organizaciją: kokio tipo programinę įrangą kuria, vidiniam ar išoriniamnaudojimui, kiek žmonių d<strong>ir</strong>ba organizacijoje, kiek dalyvauja testavime, ar procesogerinime dalyvaujantys žmonės yra gerbiami organizacijoje, ar testavimo procesogerinimo atsakomybės aiškiai apibrėžtos, kaip organizuota testavimo grupė, kaip galimaapibūdinti testavimo procesą (nuo chaotiško iki labai struktūrizuoto), kaip dažnaikeičiasi užsakovų reikalavimai.Klausimyne kiekvienam brandos lygiui pateikiami:- jo tikslai, pvz.:TMM 2 lygis: Fazės apibrėžimasBrandos tikslas 2.1: Apibrėžti testavimo <strong>ir</strong> derinimo tikslus <strong>ir</strong> politikąŠis tikslas turi aiškiai atsk<strong>ir</strong>ti testavimo <strong>ir</strong> derinimo procesus. Kiekvienam iš jų turi būtiidentifikuoti tikslai, veiklos, užduotys <strong>ir</strong> įrankiai bei prisk<strong>ir</strong>tos atsakomybės. Vadovybėturi nustatyti politiką abiejų procesų pritaikymui <strong>ir</strong> įdiegimui.- potiksliai, pvz.:2.1.1. Organizacijos lygmens testavimo <strong>ir</strong> derinimo komitetas ar grupė yra suformuota<strong>ir</strong> aprūpinta finansavimu bei palaikymu. Tikslai, politikos <strong>ir</strong> procedūros patv<strong>ir</strong>tintos <strong>ir</strong>periodiškai peržiūrimos.2.1.2. Testavimo <strong>ir</strong> derinimo politikos/tikslai atspindimi projekto/testavimo planuose.2.1.3. Apibrėžta bazinė defektų klasifikacija <strong>ir</strong> įdiegta defektų saugykla.Mokymo medžiaga 137
Programų sistemų inžinerija9. Testavimo brandos modelis2.1.4. Esminiai testavimo <strong>ir</strong> derinimo matavimai apibrėžti <strong>ir</strong> renkami.- klausimai (į kuriuos reikia atsakyti Taip/Ne/Netaikoma/Nežinoma <strong>ir</strong> galima pateiktikomentarus), pvz.:1. Ar testavimo <strong>ir</strong> derinimo komitetas buvo įkurtas?2. Ar testavimo proceso politika, tikslai, veiklos <strong>ir</strong> įrankiai identifikuoti,dokumentuoti <strong>ir</strong> patv<strong>ir</strong>tinti?3. Ar derinimo proceso politika, tikslai, veiklos <strong>ir</strong> įrankiai identifikuoti, dokumentuoti<strong>ir</strong> patv<strong>ir</strong>tinti?4. Ar testavimo procesas apibrėžtas?5. Ar derinimo procesas apibrėžtas?6. Ar testavimo politikos dokumentai paskleisti projekto vadovams <strong>ir</strong> kūrėjams(testuotojams)?7. Ar derinimo politikos dokumentai paskleisti projekto vadovams <strong>ir</strong> kūrėjams(testuotojams)?8. Ar planuodami testavimą kūrėjai (testuotojai) vadovaujasi rašytine organizacijospolitika?9. Ar derindami kūrėjai vadovaujasi rašytine organizacijos politika?10. Ar testavimo tikslų pasiekimo įvertinimui naudojami matavimai?11. Ar derinimo tikslų pasiekimo įvertinimui naudojami matavimai?12. Ar kuriant testavimo politiką <strong>ir</strong> tikslus buvo atsižvelgta į klientų/vartotojų grupėsatsiliepimus <strong>ir</strong> poreikius?13. Ar kuriant derinimo politiką <strong>ir</strong> tikslus buvo atsižvelgta į klientų/vartotojų grupėsatsiliepimus <strong>ir</strong> poreikius?14. Ar apibrėžta bazinė defektų klasifikacija?15. Ar įdiegta defektų saugykla?16. Ar kūrėjai/testuotojai reguliariai registruoja defektus saugykloje?17. Ar testavimo/derinimo politikos <strong>ir</strong> tikslai reguliariai peržiūrimi?IšvadosTMM yra pavyzdys modelio, paruošto praktiniam taikymui, t.y. tokie modeliai kaipCMMI, ISO 15504 yra per daug bendri <strong>ir</strong> „nutolę“ nuo praktikos, kad juos taikyti reikia juos„nuleisti“ iki praktinio taikymo (pvz., norint atlikti vertinimą) <strong>ir</strong> iki konkrečios organizacijos(pvz., susieti organizacijoje naudojamus terminus su modelio terminais), todėl kad organizacijapradėtų taikyti modelį ji turi samdytis konsultantus arba/<strong>ir</strong> pati nueiti ilgą mokymosi kelią.TMM atveju modelis yra maksimaliai sukonkretizuotas, kad būtų galima bandyti jį taikytiorganizacijoje - pateikiama visa būtina taikymui medžiaga (visa medžiaga yra knygoje [Bur03],Mokymo medžiaga 138
Programų sistemų inžinerija9. Testavimo brandos modeliskurią galima rasti internete <strong>ir</strong> atsisiųsti, o šiame dokumente yra pateikiama tik apžvalga, kuriosžinoma, nepakanka praktiniam taikymui).Literatūra papildomam skaitymui[Bur03][GH88][Dur93][Bei90]I. Burnstein, Practical software testing: a process-oriented approach. Springer-Verlag, 2003, ISBN 0-387-95131-8.D. Helperin, B. Hetzel, The growth of software testing. Communications of ACM,Vol. 31, No. 6, 1988, pp. 687-695.J. Durant, Software testing practices survey report. Technical Report, TR5-93,Software Practices Research Center, 1993.B. Beizer, Software Testing Techniques, 2 nd edition, Van Nostrand Reinhold, NewYork, 1990.Mokymo medžiaga 139
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikos10. Judriosios programų kūrimo metodikosJudriosios (angl. agile) programų kūrimo metodikos – jauniausia programų sistemųinžinerijos atšaka. Ats<strong>ir</strong>adusios 90-ųjų metų pabaigoje, jos greitai išpopuliarėjo <strong>ir</strong> sprendžiantpagal skelbiamą statistiką šiandien yra plačiai naudojamos programinės įrangos kūrimo srityje.Visame pasaulyje diskutuojamos judriųjų metodikų paplitimo priežastys <strong>ir</strong> jų taikymo galimybės.Nesėkmingi projektai yra didelė problema ne tik juos vykdančių organizacijų, bet <strong>ir</strong>pasaulinės ekonomikos mastu. JAV Nacionalinio standartų <strong>ir</strong> technologijos instituto duomenimisnekokybiškos programinės įrangos produktai vien JAV nacionalinei ekonomikai padaro 59,5milijardo dolerių per metus žalos.Standish Group atliktuose tyrimuose kaip pagrindiniai nesėkmės veiksniai buvo įvardinti:naudotojo neįtraukimas į kūrimo procesą; nepilni <strong>ir</strong> /arba besikeičiantys reikalavimai; nerealūsplanai <strong>ir</strong> terminai; netinkamas vadovavimas; neaiškūs tikslai; nepakankamos naudojamųtechnologijų žinios.Tradicinės metodikos nuolat apibūdinamos kaip lėtos, pernelyg formalios <strong>ir</strong> nelanksčios,todėl sunkiai išsprendžiančios išvardintas problemas. Tai paskatino naujų programų kūrimometodų paiešką <strong>ir</strong> ko pasėkoje imta siūlyti naujas metodikas (XP, DSDM, Scrum), sk<strong>ir</strong>tasdaugiausiai mažoms komandoms nedideliems projektams su besikeičiančiais reikalavimaisvykdyti. 90-ųjų pabaigoje jos pradėtos vadinti lengvosiomis (angl. lightweight) arba judriosiomis(angl. agile) programų kūrimo metodikomis.Judriųjų programų kūrimo metodikų manifestas2001 metais grupė programinės įrangos praktikų <strong>ir</strong> konsultantų paskelbė judriųjų programųsistemų kūrimo metodikų manifestą (angl. Agile Software Development Manifesto), kuriameformuluojami tokie principai:• Individai <strong>ir</strong> jų bendradarbiavimas yra svarbesni už procesus <strong>ir</strong> įrankius. Judriosiosmetodikos teigia, kad programų kūrimo procese ypač svarbūs individualūs žmoniųsugebėjimai <strong>ir</strong> dalyvaujančių žmonių sugebėjimas d<strong>ir</strong>bti komandoje.• Veikianti programinė įranga yra svarbesnė už išsamią jos dokumentaciją. Judriosiosmetodikos teigia, kad kur kas svarbiau sukurti veikiančią <strong>ir</strong> atitinkančią klientoporeikius programų sistemą, negu parengti dokumentaciją, nes priešingu atveju sistemanebus diegiama. Šiuo teiginiu yra akcentuojama <strong>ir</strong> testavimo svarba.• Bendradarbiavimas su užsakovu svarbesnis už kontrakto derybas. Pabrėžiamaužsakovo galimybė įtakoti projekto eigą. Skatinami dažni produkto pristatymaiMokymo medžiaga 140
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosužsakovui, pvz., prototipų demonstravimas, tuo būdu mažinant riziką sukurti produktą,netenkinantį užsakovo poreikių.• Galimybė reaguoti į pakeitimus svarbesnė už plano vykdymą. Užsakovui artimiaususipažinus su sistema, o inžinieriams su verslo modeliu, kyla nauji reikalavimai.Projekto dalyviai turi būti pas<strong>ir</strong>uošę daryti pakeitimus <strong>ir</strong> sutartyje turi būti numatytospriemonės tai atlikti.Judriųjų programų kūrimo metodikų manifestas suformuluotas taip, kad kiekviena šiųmetodikų iškeliama vertė priešpastatoma tradicines metodikas charakterizuojančioms savybėms.Tokiu būdu siekiama pabrėžti, kad tradicinės metodikos pasenusios <strong>ir</strong> nepakankamai efektyviosdabartiniams projektams, pasižymintiems didele reikalavimų, resursų, terminų kaita, vykdyti.Sanjay Murthi pateikia tokį palyginimą, kuriame nurodoma kokiems veiksniams esantpatartina naudoti judriąsias programų kūrimo metodikas:Veiksnys Tradicinės metodikos Judriosios metodikosApimtis (reikalavimai) Tiksliai žinoma;Dydis gerai suvokiamas;Nesikeičianti.Neaiški (ar reikalavimaiteisingi?);Nežinoma (Kas yra apimtis?)Besikeičianti.Resursai (pinigai,infrastruktūra, žmonės)Patv<strong>ir</strong>tinti <strong>ir</strong> prieinami;Nustatyti iš anksto;Biudžetas pakankamas <strong>ir</strong>finansuojamas;Žmonės susipažinę suužduotimis <strong>ir</strong> įrankiaisNepilnai patv<strong>ir</strong>tinti arbaprieinami;Patikrinimo poreikis;Pinigų nepakanka;Biudžetas neapibrėžtas;Naujų įgūdžių poreikis.LaikasAiškiai nustatytas;Aiškūs etapai.Netiksliai nustatytas, atv<strong>ir</strong>as;Neaiškūs etapai;Linkęs keistis.RizikosGerai suprantamos;Nedidelė įtaka.Naujos technologijos;Nežinomos rizikos;Didelė įtaka.Nepaisant to, kad judriosios programų kūrimo metodikos buvo kuriamos daugiausiaimažoms komandoms nedideliems projektams vykdyti, pastaraisiais metais bandoma taikyti <strong>ir</strong>nuolat pranešama apie įva<strong>ir</strong>ius sėkmingus taikymus sk<strong>ir</strong>tinguose tiek dydžiu, tiek apimtimi, tiektaikymo sritimi projektuose.Mokymo medžiaga 141
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosPopuliariausia judrioji metodika yra ekstremalaus programavimo (XP), kuri pagal 2001metais surinktus statistinius duomenis buvo naudojama 38% judriąsias metodikas taikiusiuoseprojektuose, be to, ji <strong>ir</strong> toliau tobulinama.Pagal to paties tyrimo rezultatus DSDM metodiką taikė 19% apklaustų respondentų. Jiįdomi <strong>ir</strong> tuo, kad yra pakankamai formali <strong>ir</strong> tarp judriųjų metodikų yra viena iš labiausiai artimųtradiciniams metodams.Ekstremalus programavimasEkstremalus programavimas (angl. eXtreme Programming, XP) – metodika, kuriospagrindinės idėjos pradėjo formuotis 1990-ųjų viduryje <strong>ir</strong> kurios autoriais laikomi Kent Beck,Ron Jeffrees <strong>ir</strong> Ward Cunninghan.XP metodika sk<strong>ir</strong>ta daugiausia mažoms <strong>ir</strong> vidutinėms komandoms, kurios vykdo projektą,pasižymintį reikalavimų neapibrėžtumu arba kitimu.XP procesasXP metodika yra gana plačiai aprašyta, tačiau vis dėlto nepakankamai formali, todėl nėraformaliai aprašytas <strong>ir</strong> XP kūrimo procesas.Tyrimas Planavimas Iteracijos iki versijos išleidimo Gamyba Priežiūra "M<strong>ir</strong>tis"Pasakojimaikitai PasakojimaiiteracijaiPastoviosperžiūrosReguliarūsatnaujinimaiProgramavimas poromisPasakojimaiPasakojimaiPrioritetaiApimtiesvertinimasAnalizėGrįžtamasisryšysTestaiProjektavimasTestųplanavimasBendrakodo bazėTestavimasPastovusintegravimasMažoslaidosUžsakovopatv<strong>ir</strong>tinimasPapildytosversijosGalutinėversija10.1 pav. XP proceso struktūraXP gyvavimo ciklą sudaro 6 fazės:- tyrimas (angl. Exploration);- planavimas (angl. Planning);- iteracijos iki versijos išleidimo (angl. Iteration to release);- gamyba (angl. Productionizing);- priežiūra (angl. Maintenance);Mokymo medžiaga 142
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikos- m<strong>ir</strong>tis (angl. Death).Tyrimo fazės metu užsakovas rašo vadinamuosius pasakojimus (angl. story), kuriuosenurodomi reikalavimai, kuriuos reikia įgyvendinti p<strong>ir</strong>mai sistemos versijai. Kiekvienaspasakojimas atitinka vieną savybę, kuri turi būti realizuota programų sistemoje. Taip pat šiameetape projekto komanda susipažįsta su įrankiais, technologijomis, metodais, kurie bus naudojamiprojekto įgyvendinimui.Po tyrimo fazės vykdoma planavimo fazė, kurios metu kūrimo komanda turi nuspręsti, kasbus įtraukiama į p<strong>ir</strong>mąją naujos iteracijos sistemos versiją. Programuotojai nustato kiek laikoreikės įgyvendinti kiekvienam pasakojimui, užsakovas pasakojimams prisk<strong>ir</strong>ia prioritetus <strong>ir</strong>kūrimo komanda sudaro projekto tvarkaraštį.Iteracijų iki versijos išleidimo fazę sudaro keletas iteracijų, kol yra išleidžiama p<strong>ir</strong>mojisistemos versija. Planavimo fazėje sudarytas tvarkaraštis suskaidomas į iteracijas, kurios trunkanuo vienos iki keturių savaičių. Jau p<strong>ir</strong>mojoje iteracijoje sukuriama sistema, kurios architektūraatitinka pilnos sistemos architektūrą. Kurie pasakojimai kokioje iteracijoje įgyvendinami,nusprendžia užsakovas. Kiekvienos iteracijos pabaigoje atliekami užsakovo parengti funkciniaitestai. Paskutinės iteracijos pabaigoje sukurta sistema jau yra parengta naudojimui.Sėkmingai atlikus testus pereinama į gamybos fazę, kurioje atliekamas papildomastestavimas <strong>ir</strong> prieš sistemą pristatant užsakovui tikrinamas sistemos efektyvumas. Šioje fazėjesistema gali būti dar keičiama <strong>ir</strong> reikalingi pakeitimai įtraukiami į einamąją versiją.Jei gamybos fazėje sukurta sistemos versija tenkina užsakovą, pereinama į priežiūros fazę.Šioje fazėje sukurta sistema naudojama, todėl po p<strong>ir</strong>mosios sistemos versijos XP projektokomanda privalo prižiūrėti veikiančią sistemą <strong>ir</strong> tęsti programų sistemos kūrimą, vykdant kitasiteracijas. Priežiūros fazė gali pareikalauti įtraukti į projekto komandą naujų žmonių <strong>ir</strong> pakeistikomandos struktūrą.Po to, kai užsakovas nebepateikia jokių pasakojimų, kuriuos reikėtų įgyvendinti, XPprojektas laikomas baigtu – m<strong>ir</strong>ties fazė. Šitoje fazėje realizuojami ne tik užsakovo poreikiai, betkartu <strong>ir</strong> kiti reikalavimai, pvz., efektyvumo, patikimumo.Pagrindinės XP vertybėsXP išsk<strong>ir</strong>ia keturias pagrindines vertybes:- bendravimas (angl. communication);- paprastumas (angl. simplicity);- grįžtamasis ryšys (angl. feedback);- drąsa (angl. courage).Mokymo medžiaga 143
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosXP metodika teigia, kad norint pasiekti tinkamą rezultatą reikia mažiau dėmesio sk<strong>ir</strong>tidokumentacijos rašymui, o daugiau bendrauti „akis į akį“. XP taisyklės apibrėžtos taip, kad būtųkuo daugiau bendraujama: kūrėjas su kūrėju, kūrėjas su užsakovu.Paprastumas reiškia tai, kad XP komanda turi stengtis sukurti kiek įmanoma paprastesnęsistemą, kadangi tokios sistemos keitimo kaina yra žymiai mažesnė. XP atsisako realizuoti tamtikrą funkcionalumą, jei šiuo metu klientas jo nereikalauja, kadangi jeigu tam tikra sistemosfunkcija nereikalinga dabar, galbūt jos nereikės <strong>ir</strong> vėliau.Grįžtamasis ryšys išreiškia tai, kad siekiant sukurti sistemą reikia kuo dažniau gautiatsiliepimus iš užsakovo apie sistemą. Grįžtamasis ryšys XP metodikoje yra daug svarbesnisnegu sistemos pristatymas užsakovui (angl. feedforward).Kai visos trys vertybės įgyvendintos ats<strong>ir</strong>anda drąsa. Drąsa yra reikalinga tada, kai reikiakeisti architektūrą, atsisakyti jau atlikto darbo, kai pasikeičia užsakovo reikalavimai.XP praktikosXP vertybėms įgyvendinti yra suformuluotos 12 praktikų:Planavimo žaidimas. XP planavimą sudaro verslo <strong>ir</strong> techninių prioritetų nustatymas <strong>ir</strong>pasakojimų priskyrimas iteracijoms.Mažos laidos. Kiekviena sistemos laida turi būti kiek įmanoma mažesnė, realizuojantisvarbiausius verslo reikalavimus. Taip siekiama kuo greičiau pateikti sistemą naudojimui.Metafora. Metafora reiškia tai, kad sistemos kūrimas turi būti paprastas <strong>ir</strong> suprantamastiek kūrėjams, tiek klientams.Paprastas projektas. Paprastas projektas nusako du dalykus: sistemoje neturi būt<strong>ir</strong>ealizuotas nereikalingas funkcionalumas, bet reikia sukurti geriausią projektą, kad būtųrealizuotas reikalingas funkcionalumas.Pertvarkymas. XP reikalauja nuolatinio sistemos projektavimo. Sistema nuolatpertvarkoma, kad būtų pašalinamas nereikalingas funkcionalumas <strong>ir</strong> būtų išlaikytas paprastasprojektas.Testavimas. Testavimas padeda užtikrinti sistemos kokybę. Programuotojai rašo moduliųtestus prieš kodavimą, o iš užsakovo pasakojimų kuriami funkciniai testai.Programavimas poromis. Ši taisyklė sako, kad visas kodas yra rašomas dviejųprogramuotojų prie vieno kompiuterio.Bendra kodo nuosavybė. Bendra kodo nuosavybė reiškia, kad kiekvienas projektedalyvaujantis asmuo gali keisti bet kurią kodo dalį.Mokymo medžiaga 144
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosNuolatinis integravimas. Sistema integruojama kelis kartus per dieną kas keletą valandų.XP grįžtamasis ciklas yra trumpas: parašyti testus, sukoduoti, integruoti, ištestuoti. Vienu metuintegruoti kodą leidžiama tik vienai programuotojų porai.40-ies darbo valandų savaitė. Ši taisyklė sako tai, kad darbuotojai neturi d<strong>ir</strong>bti pavargę.Aktyvus užsakovas. Ši praktika atitinka naudotojo įtraukimą į programos kūrimo procesą.Užsakovas turi būti pasiekimas visą darbo laiką, kad galėtų nuolat atsakinėti į klausimus apiesistemą.Kodavimo standartai. Visos šios praktikos susijusios viena su kita. Jeigu programuojamaporomis <strong>ir</strong> leidžiama keisti svetimą kodą, kodas turi būti rašomas pagal taisykles, kad būtųvisiems suprantamas.DSDMDSDM (angl. Dynamic Systems Development Method) – dinaminis programų kūrimometodas, sukurtas 1994 metais <strong>ir</strong> prižiūrimas DSDM konsorciumo, priklauso judriųjų programųkūrimo metodikų grupei.Pagrindinė DSDM idėja – kurti programų sistemą, atsižvelgiant į kintančius reikalavimus,siekiant, kad kuriama sistema atitiktų verslo poreikius. Toks principas priešingas tradicinėmsmetodikoms, tai grafiškai pavaizduota paveikslėlyje:FunkcionalumasTradicinėsFiksuotaResursaiDSDMLaikasLaikasResursaiKintamasFunkcionalumas10.2 pav. DSDM <strong>ir</strong> tradicinės metodikosDSDM vadove teigiama, kad tradicinėse metodikose reikalavimai apibrėžiami iš anksto <strong>ir</strong>fiksuoti visą sistemos kūrimo laiką, taigi siekiama sukurti programinę įrangą, kuri tenkintų visusnumatytus reikalavimus, o laikas <strong>ir</strong> resursai sk<strong>ir</strong>iami pagal tai, kiek bus reikalinga apibrėžtamfunkcionalumui pasiekti. DSDM priešingai nustato fiskuotą projekto laiką <strong>ir</strong> stengiasi kiekįmanoma fiksuoti resursus, tačiau reikalavimai gali būti keičiami pagal verslo poreikius.Mokymo medžiaga 145
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosDSDM procesasDSDM naudoja iteratyvų <strong>ir</strong> ciklinį gyvavimo ciklą, kas reiškia, kad sistema sukuriama neper vieną ciklą, bet per ciklų seriją, kai kiekvienam cikle tobulinamas jau pasiektas rezultatas.DSDM reikėtų laikyti daugiau konstrukcija negu metodu. Jis nenusako detalių, kaip turėtųbūti atliekami veiksmai, tačiau apibrėžia proceso apmatus <strong>ir</strong> produktus.Taikymotyrimas1Verslo analizė5Funkcinio modelioiteracija6Realizavimas2473Projektavimo <strong>ir</strong>konstravimo iteracija10.3 pav. DSDM proceso struktūraKūrimo procesą sudaro 5 fazės:- DSDM taikymo galimybių tyrimas (angl. feasibility);- verslo analizė (angl. business study);- funkcinio modelio iteracija (angl. functional model iteration);- projektavimo <strong>ir</strong> konstravimo iteracija (angl. design and build iteration);- realizavimas (angl. implementation).DSDM taikymo galimybių tyrimas <strong>ir</strong> verslo analizė atliekami nuosekliai. Šiose fazėsenustatomos pagrindinės taisyklės likusioms kūrimo fazėms, kurie atliekami iteratyviai <strong>ir</strong>cikliškai. Po verslo analizės kūrimo procese seka funkcinio modelio iteracija (1 rodyklė).Perėjimai tarp kitų fazių aprašyti žemiau.Toliau trumpai apibūdinama kiekviena fazė.DSDM taikymo galimybių tyrimas sk<strong>ir</strong>tas patikrinti, ar DSDM metodika priimtinaprojektui vykdyti. Kartu šioje fazėje nustatoma, kiek laiko reikės įvykdyti projektą, nustatomisistemos kaštai <strong>ir</strong> ar įmanoma techniškai išspręsti keliamą verslo problemą.Verslo analizėje pagrindinis dėmesys sk<strong>ir</strong>iamas verslo procesams <strong>ir</strong> jų informaciniamsporeikiams nustatyti. Apibrėžiami <strong>ir</strong> prioritetizuojami reikalavimai, apibrėžiama sistemosarchitektūra <strong>ir</strong> parengiamas prototipų planas.Mokymo medžiaga 146
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosFunkcinio modelio iteracija susidaro iš analizės, kurios metu peržiūrimi <strong>ir</strong> koreguojamiverslo analizės fazėje apibrėžti reikalavimai, identifikuojami nefunkciniai reikalavimai, <strong>ir</strong>prototipų, kurie sk<strong>ir</strong>ti pagrindiniam funkcionalumui pavaizduoti, kūrimo. Į šią fazę įtrauktas <strong>ir</strong>funkcinių reikalavimų testavimas.Projektavimo <strong>ir</strong> konstravimo iteracijoje sukuriama sistema, kuri nebūtinai atitinka visus jaikeliamus reikalavimus, tačiau tenkina visus ciklui sutartus reikalavimus. Sukurtą produktą –vadinamą testuota sistema (angl. Tested System) – testuoja sistemos naudotojai. Šiame etaperealizuojami <strong>ir</strong> testuojami nefunkciniai reikalavimai. Netenkinant pastarųjų grįžtama į funkciniomodelio iteracijos fazę (4 rodyklė).Realizavimo fazėje sukuriama visus ciklui iškeltus reikalavimus tenkinanti sistema, kurigali būti pateikiama naudojimui (angl. Delivered System), apmokomi naudotojai, kurienedalyvavo kūrimo procese. Yra galimi 4 perėjimai iš šios fazės:sritis:- Jei visi sistemai keliami reikalavimai tenkinami, projektas baigiamas.- Jei nustatoma, kad buvo neteisingai apibrėžtas pagrindinis funkcionalumas, grįžtama įverslo analizės fazę (5 rodyklė).- Jei mažiau svarbus funkcionalumas buvo praleistas dėl trumpo laiko, bet projektoterminas dar nesibaigė, grįžtama į funkcinio modelio iteracijos fazę tam, kadreikalingas funkcionalumas būtų realizuotas (6 rodyklė).- Jei dėl laiko spaudimo mažiau svarbūs techniniai aspektai buvo praleisti, bet projektoterminas nesibaigė, grįžtama į projektavimo <strong>ir</strong> konstravimo iteraciją (7 rodyklė).Pagrindiniai DSDM principaiDSDM metodikoje išsk<strong>ir</strong>iami 9 principai, kurių kiekvienas apibūdina sk<strong>ir</strong>tingas metodikosPrincipas1. Būtinas aktyvus naudotojoįtraukimas2. DSDM komandai privalo būtisuteikta sprendimo teisėKomentaraiDSDM yra į naudotojus orientuotas metodas. Į kūrimoprocesą įtraukiama tam tikra nedidelė grupė naudotojų, kuriepateikia atsiliepimus apie sistemą.DSDM komandą sudaro kūrėjai <strong>ir</strong> naudotojai. Pastariesiemsturi būti suteikta spręsti, kokius reikalavimus sistema privalotenkinti, kurie iš jų turėtų būti peržiūrėti arba pakeistiišvengiant dažno vadovybės dalyvavimo.Mokymo medžiaga 147
Programų sistemų inžinerijaPrincipas3. Reikalingas dažnas produktopristatymas užsakovui.4. Esminis produkto priėmimokriterijus – tinkamumas verslopask<strong>ir</strong>čiai5. Siekiant rasti verslui tinkamąsprendimą naudojamas cikliškaskūrimo procesas.6. Kūrimo metu visi keitimaigali būti atšaukiami.7. Reikalavimai projektuojamiabstrakčiu lygiu.8. Testavimas integruojamas įgyvavimo ciklą.9. Labai svarbusbendradarbiavimas tarp visųsuinteresuotų asmenų (angl.stakeholders).10. Judriosios programų kūrimo metodikosKomentaraiDSDM komandos darbas orientuotas į produktus, kurie galibūti sukurti per sutartą laiko tarpą. Pagal tai, kiek laiko yrask<strong>ir</strong>ta užduočiai komanda pas<strong>ir</strong>enka užduoties įgyvendinimobūdą. Iteracijas siekiama daryti kuo trumpesnes, todėl galimaanksti sulaukti užsakovo vertinimo.DSDM kelia tikslą realizuoti reikalingą funkcionalumą perpageidaujamą laiko tarpą. Atitikimas pagrindiniams versloporeikiams, atsižvelgiant, kad jie gali keistis, yra svarbesnisuž sistemos techninį tobulumą.Dėl cikliško kūrimo proceso anksti sulaukiama naudotojovertinimų, todėl ankstyvose fazėse ištaisomos klaidos.DSDM palaiko grįžimo metodą (angl. backtracking).Priėmus neteisingą sprendimą, grįžtama į ankstesnę kūrimofazę, tokiu būdu neteisingas kūrimo kelias gali būtiištaisomas. Pakeitimų atsisakymas apribojamas kūrimociklais.Apibrėžiami tik pagrindiniai reikalavimai, kurie turėtųapibūdinti sistemos apimtį. Reikalavimai detalizuojamivėlesnėse kūrimo fazėse <strong>ir</strong> gali būti keičiami esant poreikiui.Testavimas nėra laikomas atsk<strong>ir</strong>a veikla. Sistema testuojamatiek kūrėjų, tiek naudotojų. Ankstyvose fazėseorientuojamasi atitikimą verslo poreikiams, vėliautestuojama, ar sistema veikia efektyviai.Reikalavimai detalizuojami projekto vykdymo metu <strong>ir</strong> norintišlaikyti trumpus terminus, reikia priimti sprendimusatsisakant varžančių pakeitimų kontrolės procedūrų, todėlreikalinga įtraukti visus suinteresuotus asmenis ne tik išverslo pusės, tačiau <strong>ir</strong> atstovus iš paslaugų teikimo,logistikos srities.Pagrindiniai DSDM metodaiPagrindiniai DSDM metodai yra laiko skaidymas intervalais (angl. timeboxing),reikalavimų prioritetizavimas (angl. prioritization) <strong>ir</strong> prototipavimas (angl. prototyping).Mokymo medžiaga 148
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosLaiko skaidymas intervalaisKiekvienas DSDM projektas turi fiksuotą pabaigos datą – šitas laikotarpis nurodo sistemosrealizavimo terminą, kuris savo ruožtu sk<strong>ir</strong>stomas į 2-6 savaičių trukmės intervalus. Kiekvienaslaiko intervalas turi galutinį terminą <strong>ir</strong> prisk<strong>ir</strong>tą reikalavimų, susk<strong>ir</strong>stytų pagal prioritetus, rinkinį.Kiekvieno intervalo tikslus nustato kūrėjai <strong>ir</strong> naudotojai. P<strong>ir</strong>mieji nustato reikalingą laikąreikalavimams įgyvendinti. Atėjus galutiniam terminui, naudotojai įvertina pasiektus rezultatus.Svarbus laiko skaidymo intervalais aspektas – kontrolė nėra paremta konkrečių užduočiųvisapusišku įgyvendinimu, t.y., keliamas tikslas kažką padaryti: jei kažkuriame laiko intervalenebuvo pasiekti tam tikri rezultatai, apimtis peržiūrima – reikalavimai gali būti nukeliami, tačiauterminas – ne. Naudotojai tokiu atveju nusprendžia, kurie reikalavimai bus įtraukiami į sekantįlaikotarpį ar nukeliami vėliau. Šio metodo tikslas – kontroliuoti projekto eigą, bet kartu gali būtinaudojamas reikalingų resursų, sukurti veikiančią sistemą, kiekiui įvertinti. Toks kontroliavimobūdas žymiai intensyvina valdymą.Reikalavimų prioritetizavimasReikalavimams susk<strong>ir</strong>styti pagal prioritetus DSDM naudojamos vadinamosios MoSCoWtaisyklės. Pagal jas reikalavimai susk<strong>ir</strong>stomi į 4 grupes:• Privalomieji (angl. Must have). Esminiai sistemos reikalavimai, kurių nerealizavussistema neveiktų. Privalomieji reikalavimai apibūdina minimalų tinkamos naudotisistemos reikalavimų poaibį. DSDM projektas privalo tenkinti visus šio poaibioreikalavimus.• Reikalingi (angl. Should have). Svarbūs reikalavimai, kurie būtų klasifikuoti kaipprivalomi mažiau į laiką orientuotose metodikose, tačiau net jų nerealizavus sistemabūtų tinkama naudoti.• Galimi (angl. Could have). Reikalavimai, kurių galima lengvai atsisakyti.• Vertingi, tačiau gali būti atidėti (angl. Want to have but Won’t have this time round).Reikalavimai, kurie gali būti atidėti vėlesniam kūrimo etapui <strong>ir</strong> reikšmingi tik tam tikrainaudotojų grupei.Visi šitie reikalavimai sudaro pilną sistemą, tačiau paprastai ne visi reikalavimai išpildomivieno laiko intervalo metu arba jų naudotojas gali atsisakyti dėl įgautų naujų žinių apie techninesgalimybes, arba dėl darbo aplinkos pokyčių. Reikalavimų, kurie nepriklauso privalomųjų grupeigali būti atsisakyta, kadangi reikalavimai gali būti keičiami, tačiau pabaigos terminas – ne.PrototipavimasDSDM kūrimo pradžioje reikalauja suformuluoti tik pagrindinius reikalavimus, kurieapibūdina sistemos apimtį <strong>ir</strong> kūrimo eigoje yra konkretizuojami. Detalizuoti reikalavimaiMokymo medžiaga 149
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosužsakovui demonstruojami prototipais. Prototipų demonstravimas išplečia naudotojo supratimąapie sistemos galimybes <strong>ir</strong> yra tinkamas sužinoti, kaip naudotojai vertina sistemos korektiškumą,tinkamumą naudoti, <strong>ir</strong> nustatyti užsakovo poreikiams. Prototipuose paprastai nėra realizuojamivisi iškelti funkciniai <strong>ir</strong> nefunkciniai reikalavimai, bet DSDM kelia reikalavimą, kad prototipaibūtų pakankamai kokybiški, nes yra įtraukiami į galutinę sistemą.DSDM metodika rekomenduoja 4 tipų prototipus:1. Verslo, sk<strong>ir</strong>ti automatizuojamų verslo aspektų demonstravimui.2. Tinkamumo naudoti – naudotojo interfeiso demonstravimui.3. Efektyvumo/sugebėjimų – sistemos sugebėjimo sėkmingai atlikti numatytą darbą. Šisprototipas sk<strong>ir</strong>tas kūrėjams, kadangi susijęs su nefunkciniais reikalavimais.4. Gebėjimų/metodų – koncepcijos tikrinimui <strong>ir</strong> projektavimo bandymams.ScrumPavadinimas „pasiskolintas“ iš regbio žaidimo, kai komanda bendromis pastangomisneleidžia kamuoliui nukristi ant žemės.Ši judrioji programų kūrimo metodika buvo sukurta 90-aisiais metais grupės, kuriaivadovavo Jeff Sutherland. Paskutiniu metu ji vystoma K.Schwaber <strong>ir</strong> M.Beedle darbuose.Scrum principai atitinka judriųjų metodikų manifestą:- Mažos komandos turi maksimizuoti bendravimą, neformalų keitimąsi informacija <strong>ir</strong>žiniomis bei minimizuoti papildomas valdymo sąnaudas.- Procesas turi būti pritaikomas prie techninių <strong>ir</strong> verslo sąlygų pasikeitimų, kad užtikrintųgeriausio įmanomo produkto sukūrimą.- Procesas orientuotas į dažnas programos laidas (versijas).- Darbai <strong>ir</strong> juos atliekantys žmonės dalinami į aiškias <strong>ir</strong> mažai susijusias grupes.- Kuriamas produktas būtinai testuojamas <strong>ir</strong> dokumentuojamas.- Scrum procesas sudaro galimybę paskelbti produktą „sukurtu“, kada tik to reikia.Esminės Scrum proceso veiklos yra reikalavimai (angl. requ<strong>ir</strong>ements), analizė (angl.analysis), projektavimas (angl. design), įgyvendinimas (angl. evolution) <strong>ir</strong> pateikimas (angl.delivery). Produktas kuriamas iteracijomis, kurios vadinamos sprintais (angl. sprints). Bendraproceso schema pateikta 10.4 pav.Mokymo medžiaga 150
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikos24 valandosScrumsus<strong>ir</strong>inkimas30 dienųSprinto užsakymų krepšelis:sprintui prisk<strong>ir</strong>tos produktosavybėsKomandospatikslintiužsakymaiNaujasfunkcionalumasProdukto užsakymų krepšelis:prioritetizuotos užsakovo pageidaujamos produkto savybės10.4 pav. Scrum proceso struktūraUžsakymų krepšelis (angl. backlog) – prioritetizuotas sąrašas svarbių užsakovo verslu<strong>ir</strong>eikalavimų ar sistemos savybių. Šis sąrašas gali būti papildomas/patikslinamas bet kuriuo metu.Kai pr<strong>ir</strong>eikia, produkto vadovas (angl. product manager) įvertina užsakymus <strong>ir</strong> patikslinaprioritetus.Sprintas (angl. sprint) – darbai, kurie turi būti atlikti pas<strong>ir</strong>inktų užsakymų iš krepšelio(angl. backlog) įgyvendinimui per nustatytą laiko intervalą (angl. time-box), kuris tradiciškai yra30 dienų. Sprinto metu jame įgyvendinami užsakymai yra „užšaldomi“ (t.y. jokie reikalavimųpakeitimai nedaromi). Tokiu būdu komandai sudaromos sąlygos sprinto metu d<strong>ir</strong>bti stabiliojeaplinkoje.Scrum sus<strong>ir</strong>inkimai (angl. Scrum meetings) – trumpi (tradiciškai 15 minučių) kasdieniniaiScrum komandos sus<strong>ir</strong>inkimai, kurių metu kiekvienas komandos narys atsako į 3 klausimus:- Ką padarė nuo paskutinio komandos susitikimo?- Su kokiomis kliūtimis, problemomis susidūrė?- Ką planuoja padaryti iki kito komandos susitikimo?Susitikimui vadovauja <strong>ir</strong> komandos narių atsakymus vertina komandos lyderis, vadinamasScrum meistru (angl. Scrum master). Sus<strong>ir</strong>inkimai padeda komandai identifikuoti galimasMokymo medžiaga 151
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosproblemas, kiek įmanoma, anksčiau. Be to, šie sus<strong>ir</strong>inkimai veda prie „žinių suvisuomeninimo“(visi žino tikslią projekto būseną) <strong>ir</strong> skatina saviorganizuojančią komandos struktūrą.Demo (angl. demos) – programos laidos pateikiamos užsakovams tam, kad įgyvendintasfunkcionalumas galėtų būti išbandytas <strong>ir</strong> įvertintas. Svarbu pastebėti, kad demo gali neturėti visoplanuoto funkcionalumo, iš esmės jame yra funkcijos, kurios galėjo būti įgyvendintos pernustatytą laiko intervalą (angl. time-box), t.y. prioritetas teikiamas laikui, o ne planuotamfunkcionalumui.Teigiama, kad Scrum metodika įgalina komandą sėkmingai d<strong>ir</strong>bti aplinkoje, kuriojeneapibrėžtumų išvengti neįmanoma.CrystalCrystal judriųjų metodikų šeimą sukūrė Alista<strong>ir</strong> Cockburn <strong>ir</strong> Jim Highsmith. Pavadinimas„Crystal“ buvo parinktas pagal geologinių kristalų charakteristikas – kiekvienas kristalas yraunikalus, turintis savo spalvą, formą <strong>ir</strong> kietumą. Siekiamas tikslas buvo maksimalusmanevringumas, kuris charakterizuojamas kaip „kolektyvinis kūrimo <strong>ir</strong> bendravimo žaidimas suribotais resursais, siekiant p<strong>ir</strong>miausia patiekti naudingą, veikiančią programų sistemą, o taip patpas<strong>ir</strong>engti sekančiam žaidimui“.Siekdami manevringumo autoriai apibrėžė aibę metodikų, turinčių bendrus esminiuselementus, tačiau unikalius procesus, šablonus, darbo produktus, roles <strong>ir</strong> praktikas. Praktiškai taiaibė judriųjų metodikų, kurios pas<strong>ir</strong>odė efektyvios sk<strong>ir</strong>tingo tipo projektuose. Siekiamas tikslassuteikti „judrioms“ komandoms galimybę pas<strong>ir</strong>inkti iš metodikų šeimos tą, kuri labiausiai tinkajų projektui <strong>ir</strong> aplinkai.Judriųjų <strong>ir</strong> planais paremtų metodų derinimasŠeši esminiai principai:1. Nei judriosios metodikos, nei planais paremti metodai nepateikia sidabrinės kulkos.2. Judriosios metodikos <strong>ir</strong> planais paremti metodai turi taikymo sąlygas, kurioseneabejotinai dominuoja prieš kitus metodus.3. Ateities tendencijos yra link programų sistemų kūrimo, kuriam reikia <strong>ir</strong> judrumo, <strong>ir</strong>disciplinos.4. Ats<strong>ir</strong>anda subalansuoti metodai.5. Geriau konstruoti savo metodą „į v<strong>ir</strong>šų“ nei prisitaikyti jį „žemyn“.6. Metodai yra svarbūs, tačiau labiau tikėtina rasti sidabrinę kulką užsiimant žmonėmis,vertybėmis, komunikavimu <strong>ir</strong> vilčių valdymu.Mokymo medžiaga 152
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosNei judriosios metodikos, nei planais paremti metodai nepateikia sidabrinės kulkosNei judriosios metodikos, nei planais paremti metodai nepateikia sidabrinės kulkos, kuriužmuštų programinės įrangos krizės vaiduoklį. Šio vaiduoklio esmė yra susijusi su esminiaisprogramų sistemų inžinerijos sunkumais kovojant su programų sistemų sudėtingumu,suderinamumu, keičiamumu <strong>ir</strong> nematomumu. Kai kurie metodai pasiekė „švininės kulkos“ lygį,t.y. jie sprendžia dalį programų sistemų inžinerijos problemų. Judriųjų metodikų <strong>ir</strong> planaisparemtų metodų elementai gali būti apibūdinti kaip švininės kulkos.Judriosios metodikos valdo kintamumą <strong>ir</strong> nematomumą, sukurdamos bendrą visiemskomandos nariams projekto tikslų <strong>ir</strong> strategijos viziją. Bet judriosios metodikos žlungasprendžiant sudėtingumo <strong>ir</strong> tam tikru lygiu suderinamumo problemas. Jos „neišplečiamos“dideliems sudėtingiems projektams, be to, jos nesk<strong>ir</strong>ia dėmesio kartais kritiniam suderinamumoreikalavimui, pavyzdžiui, interfeiso specifikacijoms ar produktų linijos architektūrai.Planais paremti metodai valdo suderinamumą <strong>ir</strong> nematomumą, investuodami į išsamiądokumentaciją. Tačiau jie žlunga sprendžiant kintamumo (dokumentacijos perdarymas) <strong>ir</strong>augančio sudėtingumo problemas.Judriųjų metodikų <strong>ir</strong> planais paremtų metodų taikymo sąlygosBe abejonės yra sąlygos tinkamos grynoms judriosioms metodikoms ar gryniems planaisparemtiems metodams, tačiau tokių specifinių atvejų nėra daug. Nustatyti situaciją <strong>ir</strong> įvertintimetodo tinkamumą galima remiantis penkiais esminiais faktoriais:- dydis (darbuotojų skaičius);- kritiškumas (galimi praradimai dėl defektų);- dinamizmas (per mėnesį pasikeičiančių reikalavimų procentas);- kultūra (chaoso procese paplitimo procentas);- darbuotojai (atitinkamo lygio darbuotojų procentas).Ateities programų sistemų kūrimui reikia <strong>ir</strong> judrumo, <strong>ir</strong> disciplinosPraeityje buvo pakankamai daug nedidelių, nekritinių, įgudusių, greitai besivystančiųprojektų, pataikančių į patį centrą sąlygų, tinkamų judriųjų metodikų taikymui. Taip pat buvodaug žmonių, d<strong>ir</strong>bančių dideliuose, kritiniuose, įva<strong>ir</strong>ių įgūdžių, tvarkos reikalaujančiuose,stabiliuose projektuose, kuriems tinka planais paremti metodai. Tačiau situacija keičiasi.Dideliuose projektuose nebegalima tikėtis žemo pasikeitimų procento, todėl jų detalūsproceso <strong>ir</strong> produkto planai reikalauja didelių sąnaudų <strong>ir</strong> stabdo. Judriosios metodikospradedamos taikyti dideliems projektams <strong>ir</strong> neišvengiamai susiduriama su naujomis –sudėtingumo <strong>ir</strong> suderinamumo - problemomis. Todėl didžiausią naudą duos turėjimas metodų,derinančių judrumą <strong>ir</strong> discipliną, priklausomai nuo situacijos.Mokymo medžiaga 153
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosAts<strong>ir</strong>anda subalansuoti metodaiKai kurios judriosios metodikos, pavyzdžiui, Crystal Orange, DSDM, FDD <strong>ir</strong> LeanDevelopment, siūlo būdus pasiekti balansui. Tai būdinga <strong>ir</strong> naujoms, „lengvesnėms RUP(Rational Unified Process) versijoms.Yra pritaikytų metodikų pavyzdžių pateikiančių rizikomis paremtą, sp<strong>ir</strong>alinį gyvavimociklą, derinantį judriuosius <strong>ir</strong> planais paremtus metodus. Šios metodikos dar nėra išbaigtos,tačiau bet kuriuo atveju tai nėra receptūrinis (tinkamas visiems gyvenimo atvejams) būdas <strong>ir</strong>kiekviename projekte jis turi būti taikomas, priklausomai nuo situacijos.Konstruok metodą („į v<strong>ir</strong>šų“) – nesistenk jo prisitaikyti („žemyn“)Tradiciškai planais paremtos metodikos turi visokiausių metodų, kurie gali būti pritaikyti(žemyn) konkrečioms situacijoms. Ekspertai gali tai padaryti, bet ne ekspertai, kad būtų saugiau,linkę naudoti viską, dažnai su žymiomis nereikalingomis papildomomis sąnaudomis. Judrusispožiūris yra geresnis - jis siūlo pradėti nuo minimalaus rinkinio praktikų <strong>ir</strong> papildomas į vesti tiktada, kai aiškus jų poreikis <strong>ir</strong> naudingumas. Kai kuriais atvejais, pavyzdžiui, Crystal, yrask<strong>ir</strong>tingi baziniai rinkiniai, kurie naudojami priklausomai nuo dydžio <strong>ir</strong>/ar kritiškumo. Panašiųtikslų yra siekiama vystant RUP.Mažiau dėmesio metodams - daugiau žmonėms, vertybėms, komunikavimui <strong>ir</strong> vilčiųvaldymuiJudriojo požiūrio šalininkai yra teisus labiau vertindamas individus <strong>ir</strong> bendravimą neiprocesą <strong>ir</strong> įrankius. Jie nebuvo p<strong>ir</strong>mieji, tai pabrėžę, yra ilgas sąrašas giminingo požiūrio darbų:Weinberg kompiuterių programavimo psichologija(1971), skandinavų projektavimas kartudalyvaujant (1990), DeMarco <strong>ir</strong> Lister Peopleware (1987), Curtis žmogiškojo faktoriaus tyrimai(1988), žmonių gebėjimo brandos modelio (People Capability Maturity Model) kūrimas. Yragausybė patv<strong>ir</strong>tinimų, kad žmogiškasis faktorius dominuoja prieš kitus programų sistemų kainos<strong>ir</strong> kokybės faktorius: pavyzdžiui, Grant-Sackman 1986 metų eksperimentai, rodantys žmoniųproduktyvumo varijavimą 26:1; COCOMO <strong>ir</strong> COCOMO II modelių kalibravimas 1981 <strong>ir</strong> 2000metais, parodęs 10:1 efektą priklausomai nuo darbuotojų gebėjimo, pat<strong>ir</strong>ties <strong>ir</strong> tęstinumo.ŽmonėsProgramų sistemų inžinerija susijusi su žmonėmis trimis aspektais:- Žmonės buriasi į komandas, kad sukurti visapusiškai tenkinančias programų sistemas.- Žmonės identifikuoja, kokių programų sistemos galimybių jiems reikia, <strong>ir</strong> kiti žmonėssukuria ją.- Žmonės apmoka sąskaitas už programų sistemų kūrimą <strong>ir</strong> naudoja sukurtus produktus.Mokymo medžiaga 154
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosTačiau programų sistemų inžinerija vis dar „vargsta“ su atsk<strong>ir</strong>tų aspektų palikimu -reikalavimų transformavimas į kodą yra toks sudėtingas, kad jis turi būti atliekamas atsietai nuožmogiškųjų aspektų. Galima pateikti keletą pavyzdžių - anksčiau paplitusių teiginių:- „vartotojo“ sąvoka negali būti tiksliai apibrėžta, todėl jai ne vieta informatikoje <strong>ir</strong>programų sistemų inžinerijoje;- sistemos reikalavimų analizė <strong>ir</strong> pask<strong>ir</strong>stymas nėra programų sistemų inžinerijos grupėsdarbas <strong>ir</strong> turi būti pateiktas jai prieš pradedant darbą;- programų sistemų inžinerija nėra projektų valdymas.Šiandieniniame <strong>ir</strong> ateities pasaulyje toks aspektų atskyrimas tampa vis labiau pavojingas.VertybėsKartu su žmonėmis yra vertybės - įva<strong>ir</strong>ios vertybės. Vienas iš svarbiausių programųsistemų inžinerijos iššūkių, kuriam, deja, neteikiama daug reikšmės, yra suderinti sk<strong>ir</strong>tingusvartotojų, užsakovų, kūrėjų <strong>ir</strong> kitų suinteresuotų asmenų vertybes įžvelgiamas planuojamojeprogramų sistemoje į visus patenkinančios <strong>ir</strong> visiems naudingos sistemos apibrėžimą <strong>ir</strong> galutinįrezultatą. Deja, programų sistemų inžinieriai dažnai dar veikia neutralioje aplinkoje, kurkiekvienas reikalavimas, vartojimo scenarijus, objektas, testas <strong>ir</strong> defektas yra vertinami kaipvienodai svarbūs. Didžioji dalis proceso gerinimo iniciatyvų <strong>ir</strong> debatų būna orientuoti į vidinįproceso efektyvumo gerinimą, o ne į išorinį efektą – suteikti suinteresuotiems asmenims didesnęvertę už kiekvieną įdėtą investiciją. Vėlgi judriosios metodikos prioritetizuodamos reikalavimus<strong>ir</strong> atsižvelgdamos į vartotojo vertybių pasikeitimus veda prie labiau atsiperkančių sprendimų.KomunikavimasNetgi vidiniuose projektuose „aš negaliu išreikšti tiksliai, ko noriu, bet aš žinosiu, kaipamatysiu tai“ (IKIWISI: I can't express exactly what I need, but I'll know it when I see it)sindromas apriboja žmonių galimybes iš anksto suderinti reikalavimus sistemai. Jei sistemosapibrėžimas <strong>ir</strong> kūrimas vyksta keliose organizacijose, reikalingas dar aktyvesnis bendravimas,kad apibrėžti <strong>ir</strong> suderinti bendrą sistemos viziją <strong>ir</strong> jos kūrimo strategiją. Augantis pasikeitimųtempas dar paaštrina problemą <strong>ir</strong> padidina netinkamo komunikavimo pasekmes.Be jau minėtų darbų, orientuotų į žmones, yra labai nedaug šaltinių nagrinėjančių, kokiekomunikavimo būdai geriausiai tinka kokiose situacijose. Iš jų reiktų išsk<strong>ir</strong>ti Cockburn knygą„Agile Software Development“, kurioje ne tik akivaizdžiai parodomas problemos, kylančios dėlnetinkamo komunikavimo, programų sistemų kūrimas apibūdinamas kaip bendras išradimo <strong>ir</strong>komunikavimo žaidimas, bet <strong>ir</strong> pateikiama visa eilė naudingų komunikavimo principų beikonkrečių būdų.Mokymo medžiaga 155
Programų sistemų inžinerija10. Judriosios programų kūrimo metodikosVilčių valdymasViena iš svarbių išvadų, padarytų nagrinėjant JAV Gynybos departamento užsakomusprojektus, yra ta, kad sk<strong>ir</strong>tumas tarp sėkmingų <strong>ir</strong> probleminių projektų dažniausiai yra sk<strong>ir</strong>tumastarp gero <strong>ir</strong> blogo vilčių valdymo.Dauguma programų sistemų kūrėjų nėra nei kvalifikuoti, nei patyrę vilčių valdyme. Jie turididelį norą įtikti <strong>ir</strong> išvengti konfrontacijos <strong>ir</strong> tuo pačiu turi per mažai pasitikėjimo savogalimybėmis numatyti projekto biudžetą <strong>ir</strong> tvarkaraštį. Tai daro juos silpnais priešininkaisagresyvių užsakovų <strong>ir</strong> vadovų, besistengiančių gauti daugiau programų per mažesnį laiką <strong>ir</strong> užmažesnius pinigus. Esminis PSP/TSP <strong>ir</strong> XP komandų bruožas, kad jos turi pakankamai procesožinių, pas<strong>ir</strong>engimo <strong>ir</strong> drąsos, kad gauti savo užsakovų sutikimą sumažinti funkcionalumą arpadidinti laiką tam, kad būtų įgyvendinti nauji aukšto prioriteto pakeitimai. Jie žino, kad gavimasnerealių vilčių nėra užsakovo laimėjimas, todėl jie sugeba įtikinti užsakovą sumažinti savo viltis.Tiek trumpos judriųjų metodikų iteracijos, tiek planais paremtuose metoduose naudojamasproduktyvumo kalibravimas yra keliai į sėkmingą vilčių valdymą.Literatūra papildomam skaitymui[Agi01]Manifesto for Agile Software Development, 2001. http://www.agilemanifesto.org.[ASRW02] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Juhani Warsta. Agile softwaredevelopment methods. VTT, 2002.[Coc02] A. Cockburn. Agile Software Development. Boston: Addison-Wesley, 2002.[Crystal]Crystal methodologies. http://www.crystalmethodologies.org/[DSDM97] DSDM Consortium. DSDM Manual Version 3, 1997.http://htsa.ie.hva.nl/~helpdesk/DSDMManual/frames9.htm[Hig02] J. Highsmith. Agile Software Development Ecosystems. Addison-Wesley, 2002.[SB01]K. Schwaber, M. Beedle. Agile software development with SCRUM. Prentice-Hall, 2001.[SCRUM] SCRUM: It's About Common Sense. Advanced Development Methods, Inc.http://www.controlchaos.com/Mokymo medžiaga 156
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKPMBOK 611. Projekto valdymas pagal PMBOK(angl. Project Management Body Of Knowledge) yra projektų valdymoprofesijos žinių visuma. Pilnas PMBOK suprantamas kaip apimantis tiek pasitv<strong>ir</strong>tinusias <strong>ir</strong>plačiai taikomas projektų valdymo žinias <strong>ir</strong> praktikas, tiek naujai ats<strong>ir</strong>adusias profesinespraktikas, tame tarpe publikuotas <strong>ir</strong> nepublikuotas. Todėl PMBOK pastoviai vystosi.PMBOK ga<strong>ir</strong>ių [PMI04] pagrindinis tikslas identifikuoti poaibį projektų valdymo žiniųbendrai pripažįstamų kaip gera praktika. Pripažinimas gera praktika nereiškia, kad visos šiosžinios yra tinkamos <strong>ir</strong> turi būti taikomos visuose projektuose vienodai - projekto valdymo grupėyra atsakinga už nustatymą, kas tinka konkrečiam projektui. PMBOK neapima visų projektųvaldymo aspektų <strong>ir</strong> tai, kad kažkas nėra įtraukta į PMBOK, nereiškia, jog šis aspektas yranesvarbus. Galimos kelios priežastys, kodėl aspektas nėra įtrauktas į PMBOK: jis aptariamaskituose susijusiuose standartuose; jis yra toks bendras, kad neturi nieko specifinio projektųvaldymui, arba nėra konsensuso šiuo klausimu (t.y. nėra vieningos nuomonės kada, kaip ar kasorganizacijoje turi vykdyti šią projektų valdymo praktiką).Kitas PMBOK tikslas yra pateikti projektų valdymo terminiją, sąvokų sistemą.Kas yra projektas?Projektas yra apribotas laike siekimas sukurti unikalų produktą, paslaugą ar rezultatą.Projekto charakteristikosApribotas laike reiškia, kad kiekvienas projektas turi apibrėžtą pradžią <strong>ir</strong> pabaigą.Projektas baigiamas, kai jo tikslai pasiekiami, arba nutraukiamas, kai tampa aišku, kad projektotikslai negali būti pasiekti ar projektas tampa nebereikalingu. Apribotas laike nebūtinai reiškianeilgas, nes projektas gali tęstis <strong>ir</strong> kelis metus. Tačiau visais atvejais projekto trukmė yraapribota. Projektas nėra nuolatinis darbas.Be to, apribojimas laike netaikomas projekto sukurtam produktui, paslaugai ar rezultatui.Projekto rezultatas gali būti ilgalaikis, pavyzdžiui, paminklo sukūrimo projekto rezultatas turėtųišlikti amžius. Projektai dažnai turi numatomą ar netyčinę socialinę, ekonominę ar aplinkos įtaką,kuri išlieka <strong>ir</strong> projektui pasibaigus.Projektų ribotumas laike susijęs <strong>ir</strong> su kitais aspektais, pavyzdžiui: galimybė ar rinkos„langas“ dažniausiai būna apribotas laike, todėl projektas turi ribotą laiką produktui ar paslaugaisukurti; projekto komanda retai gyvuoja ilgiau nei projektas - komanda suburta projektui atlikti,jam pasibaigus, tradiciškai yra išformuojami <strong>ir</strong> komandos nariai gauna kitus paskyrimus.6 PMBOK sk<strong>ir</strong>tas bet kokių projektų, ne tik programų sistemų kūrimo, valdymui.Mokymo medžiaga 157
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKProjekto rezultatų unikalumas. Projektas gali sukurti:- produktą ar artefaktą, kuris yra kiekybiškai įvertinamas <strong>ir</strong> yra savarankiškas vienetasarba kažko dalis;- galimybes suteikti paslaugas, pavyzdžiui, verslo funkcijas gamybai ar platinimui;- rezultatą, pavyzdžiui, dokumentą ar žinias (mokslo t<strong>ir</strong>iamojo projekto atveju).Projekto rezultatų unikalumas yra svarbi charakteristika. Pavyzdžiui, yra suprojektuotadaugybė namų, bet kiekvienas yra unikalus – sk<strong>ir</strong>tinga išvaizda, vieta, užsakovas <strong>ir</strong> t.t.Pasikartojančių elementų buvimas nepakeičia esminės projekto unikalumo savybės.Laipsniškas plėtojimas yra dar viena projekto charakteristika, susijusi su apribojimu laike<strong>ir</strong> unikalumu. Laipsniškas plėtojimas reiškia kūrimą žingsniais, pavyzdžiui, projekto apimtis išesmės apibrėžiama projekto pradžioje <strong>ir</strong> detalizuojama, kai projekto komanda pilniau išsiaiškinaprojekto tikslus <strong>ir</strong> darbo produktus. Laipsniškas plėtojimas neturėtų būti painiojamas su projektoapimties pasikeitimu. Laipsniškas projekto specifikacijos plėtojimas turi būti atidžiaikoordinuojamas su tinkamu projekto apimties apibrėžimu, ypač jei projektas atliekamas pagalsutartį. Tinkamai apibrėžta projekto apimtis (kas turi būti padaryta) turi būti kontroliuojamaprojektui palaipsniui vystantis.Projektas vs. einamoji veiklaOrganizacijos d<strong>ir</strong>ba siekdamos tikslų. Darbas gali būti arba projektas, arba procesas(einamoji veikla), nors jie kartais persidengia. Abu turi bendrų savybių:- juos atlieka žmonės;- suvaržyti ribotų resursų;- planuojami, vykdomi <strong>ir</strong> kontroliuojami.Esminis sk<strong>ir</strong>tumas tarp jų yra tai, kad procesas (einamoji veikla) yra nuolatinis <strong>ir</strong>pasikartojantis, o projektas yra apribotas laike <strong>ir</strong> unikalus. Be to, jų tikslai yra iš esmės sk<strong>ir</strong>tingi:projekto pask<strong>ir</strong>tis pasiekti tikslus <strong>ir</strong> pasibaigti, o proceso (einamosios veiklos) tikslas yrapalaikyti verslą. Projektas baigiasi, kai pasiekia specifinius jam iškeltus tikslus, o procesas(einamoji veikla) prisitaiko prie naujų tikslų <strong>ir</strong> tęsia darbą.Projektai vykdomi visuose organizaciniuose lygiuose <strong>ir</strong> juose gali dalyvauti nuo vieno ikikelių tūkstančių žmonių. Jų trukmė varijuoja nuo kelių savaičių iki keleto metų. Projektųpavyzdžiai:- naujo produkto ar paslaugos sukūrimas;- organizacijos struktūros, darbuotojų ar darbo stiliaus pakeitimas;- naujos transporto priemonės suprojektavimas;- naujos ar modifikuotos informacinės sistemos sukūrimas ar įsigijimas;- įrenginio sukonstravimas;Mokymo medžiaga 158
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOK- visuomeninės vandentiekio sistemos pastatymas;- politinė kampanija;- naujų veiklos procedūrų ar procesų įdiegimas<strong>ir</strong> t.t.Projektai <strong>ir</strong> strateginis planavimasProjektai yra organizacinės veiklos priemonės, kurios „netelpa“ į normalius proceso(einamosios veiklos) apribojimus. Projektai yra priemonės, naudojamos organizacijos strateginiųplanų įgyvendinimui. Projekto komanda gali būti sudaryta iš organizacijos darbuotojų arbaišorinių paslaugų teikėjų.Projektai tipiškai yra inicijuojami kaip rezultatas vieno ar daugiau tokių strateginiųsumetimų (aplinkybių):- Rinkos poreikis (pvz., naftos perd<strong>ir</strong>bimo kompanija inicijuoja naujos perd<strong>ir</strong>bimoįmonės statybą dėl pastovaus benzino trūkumo);- Organizaciniai poreikiai (pvz., apmokymų centras inicijuoja naujo kurso parengimą,kad padidinti pelną);- Užsakovų pageidavimas (pvz., elektros tinklai inicijuoja naujos pastotės statybą naujopramoninio parko aptarnavimui);- Technologinė pažanga (pvz., programinės įrangos kūrimo įmonė inicijuoja naujoskartos žaidimo kūrimą ats<strong>ir</strong>adus naujiems žaidimų įrenginiams);- Teisiniai reikalavimai (pvz., dažų gamintojai inicijuoja projektą nustatyti naujųnuodingų medžiagų naudojimo rekomendacijas).Kas yra projektų valdymas?Projektų valdymas yra žinių, įgūdžių, įrankių <strong>ir</strong> metodų taikymas projekto veikloms, kadpatenkinti projekto reikalavimus. Projekto valdymas atliekamas taikant projekto valdymoprocesus: inicijavimą, planavimą, vykdymą, stebėjimą <strong>ir</strong> kontrolę, uždarymą. Projekto vadovasyra asmuo, atsakingas už projekto tikslų pasiekimą.Projekto valdymas apima:- reikalavimų identifikavimą;- nustatymą aiškių <strong>ir</strong> pasiekiamų tikslų;- prieštaringų kokybės, apimties, kainos <strong>ir</strong> laiko poreikių balansavimą;- pritaikymą specifikacijų, planų <strong>ir</strong> metodų sk<strong>ir</strong>tingiems įva<strong>ir</strong>ių suinteresuotų asmenųporeikiams <strong>ir</strong> lūkesčiams.Projektų vadovai dažnai kalba apie „trigubą apribojimą“ (projekto apimtis, laikas <strong>ir</strong> kaina)prieštaringų projekto reikalavimų valdymui. Projekto kokybė priklauso nuo šių trijų faktoriųMokymo medžiaga 159
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKsuderinimo. Aukštos kokybės projektai pateikia numatytos apimties rezultatus, laiku <strong>ir</strong> už sutartąkainą. Šie trys faktoriai yra susiję taip, kad jei bet kuris vienas iš jų pasikeičia, tai įtakoja darbent vieną kitą faktorių. Projektų vadovai turi atsižvelgti į neapibrėžtumus. Projekto rizika yratikėtinas įvykis, kuris, jei įvyksta, turi teigiamą ar neigiamą įtaką bent vienam iš projekto tikslų.Projekto valdymo grupė yra profesiniu požiūriu atsakinga prieš suinteresuotus asmenis,įskaitant užsakovus, vykdančią organizaciją <strong>ir</strong> visuomenę. Visi projekto valdymo grupės nariaituri laikytis etikos kodekso (angl. Code of Ethics), o sertifikuoti profesionalai (angl. ProjectManagement Professional certified) turi laikytis profesinės veiklos kodekso (angl. Code ofProfessional Conduct).Svarbu pastebėti, kad daugelis projekto valdymo procesų yra iteratyvūs dėl laipsniškoprojekto plėtojimo poreikio jo gyvavimo ciklo eigoje, t.y. kai projekto eigoje yra sužinoma apieprojektą daugiau (detaliau), jis gali būti tiksliau valdomas.Daug projektų valdymo žinių, įrankių <strong>ir</strong> metodų yra specifiniai projektų valdymui (pvz.,darbų skleistinė, kritinio kelio analizė ar užd<strong>ir</strong>btos vertės valdymas). Tačiau pripažintų žinių,įgūdžių, įrankių <strong>ir</strong> metodų taikymo nepakanka efektyviam projekto valdymui, tam būtina, kadprojekto valdymo grupė žinotų <strong>ir</strong> taikytų žinias <strong>ir</strong> įgūdžius bent jau iš penkių sričių:- projektų valdymo žinios (PMBOK);- taikomosios srities žinios, standartai, įstatymai <strong>ir</strong> taisyklės;- projekto aplinkos supratimas;- bendrosios valdymo žinios <strong>ir</strong> įgūdžiai;- tarpasmeniniai (darbo grupėje) įgūdžiai.Šios penkios sritys persidengia. Nebūtina (<strong>ir</strong> mažai tikėtina), kad kiekvienas komandosnarys bus visų penkių sričių ekspertas, bet efektyviam darbui reikia, kad projekto valdymo grupėturėtų pakankamai žinių <strong>ir</strong> įgūdžių visose penkiose srityse.Projektų valdymo žinių sritysPMBOK išsk<strong>ir</strong>ia tokias projektų valdymo žinių sritis:- integravimo valdymas (angl. Project Integration Management);- apimties valdymas (angl. Project Scope Management);- laiko valdymas (angl. Project Time Management);- kainos valdymas (angl. Project Cost Management);- kokybės valdymas (angl. Project Quality Management);- žmogiškųjų resursų valdymas (angl. Project Human Resource Management);- komunikavimo valdymas (angl. Project Communications Management);- rizikos valdymas (angl. Project Risk Management);- įsigijimo valdymas (angl. Project Procurement Management).Mokymo medžiaga 160
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKProjekto gyvavimo ciklasProjekto vadovai ar organizacija gali susk<strong>ir</strong>styti projektus į fazes, kad užtikrinti geresnįvaldymą <strong>ir</strong> kontrolę. Šios fazės kartu yra vadinamos projekto gyvavimo ciklu. Daugelisorganizacijų apibrėžia specifinius gyvavimo ciklus saviems projektams.Projekto gyvavimo ciklas apibrėžia fazes, apimančias projektą nuo pradžios iki pabaigos.Pavyzdžiui, kai organizacija identifikuoja progą, kuria norėtų pasinaudoti, ji dažnai inicijuojagalimybių studiją (angl. feasibility study), kad nuspręsti, ar pradėti projektą. Gyvavimo cikloapibrėžimas nusako, ar galimybių studija yra laikoma p<strong>ir</strong>ma projekto faze, ar atsk<strong>ir</strong>u,nepriklausomu projektu. Kai šios preliminarios veiklos rezultatai nėra aiškūs, geriau ją traktuotikaip atsk<strong>ir</strong>ą projektą. Projekto gyvavimo ciklo fazės yra ne tas pats, kas projekto valdymoprocesų grupės.Nėra idealaus gyvavimo ciklo tinkamo visiems projektams. Kai kurios organizacijosapibrėžia vieningą gyvavimo ciklą, kuris taikomas visiems jų projektams, kitos organizacijosleidžia projektų vadovams parinkti projektui tinkamiausią gyvavimo ciklą.Projekto gyvavimo ciklas apibrėžia:- koks techninis darbas atliekamas kiekvienoje fazėje;- kokie darbo produktai yra sukuriami kiekvienoje fazėje <strong>ir</strong> kaip jie yra peržiūrimi,verifikuojami <strong>ir</strong> validuojami;- kas dalyvauja kiekvienoje fazėje;- kaip valdoma <strong>ir</strong> patv<strong>ir</strong>tinama kiekviena fazė.Projekto gyvavimo ciklas apibrėžimai gali būti labai bendri <strong>ir</strong> labai detalūs (sukonkrečiomis formomis, schemomis, kontroliniais sąrašais <strong>ir</strong> pan.) Dauguma projekto gyvavimociklo apibrėžimų pasižymi tokiomis savybėmis:- fazės yra iš esmės nuoseklios <strong>ir</strong> dažniausiai apibrėžiamos techninės informacijos arproduktų perdavimu;- finansavimo <strong>ir</strong> personalo resursų poreikis yra nedidelis pradžioje, maksimaliai išaugavidurinėse fazėse <strong>ir</strong> staigiai mažėja projektui artėjant prie pabaigos;- projekto pradžioje neapibrėžtumo lygis yra aukščiausias <strong>ir</strong> rizika nepasiekti tikslų yradidžiausia (projekto eigoje jie mažėja);- suinteresuotų asmenų galimybės įtakoti projekto rezultatų galutines charakteristikas <strong>ir</strong>projekto kainą yra didžiausia projekto pradžioje.Projektu suinteresuoti asmenysSuinteresuoti asmenys (angl. stakeholders) yra asmenys <strong>ir</strong> organizacijos, kurie aktyviaidalyvauja projekte arba kurių interesus gali įtakoti projekto vykdymas ar įgyvendinimas(projekto tikslai <strong>ir</strong> rezultatai). Projekto valdymo grupė turi identifikuoti suinteresuotus asmenis,Mokymo medžiaga 161
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKišsiaiškinti jų reikalavimus <strong>ir</strong> lūkesčius bei pagal galimybes valdyti jų reikalavimus, kadprojektas būtų sėkmingas.Suinteresuoti asmenys turi projekte sk<strong>ir</strong>tingo lygio atsakomybes <strong>ir</strong> įgaliojimus, kurie galikeistis projekto eigoje. Suinteresuoti asmenys gali įtakoti projektą tiek teigiamai (tie, kurie gausnaudos iš sėkmingo projekto rezultatų), tiek neigiamai (tie, kurie mato neigiamas projektopasekmes).Kiekvieno projekto suinteresuoti asmenys apima:- Projekto vadovas: asmuo atsakingas už projekto valdymą.- Užsakovas/naudotojas: asmuo ar organizacija, kuri naudos projekto produktą. Galimikelių lygių užsakovai, pavyzdžiui, naujų vaistų atveju tai <strong>ir</strong> gydytojai, <strong>ir</strong> ligoniai, <strong>ir</strong>ligonių kasos. Kai kuriose taikymo srityse užsakovas <strong>ir</strong> naudotojas yra sinonimai,kitose – užsakovas yra esybė, įsigyjanti projekto produktą, o naudotojas yra tas, kurisbetarpiškai naudos tą produktą.- Vykdanti organizacija: įmonė, kurios darbuotojai yra labiausiai tiesiogiai įtraukti įprojekto vykdymą.- Projekto komanda: grupė, kuri atlieka projekto darbus.- Projekto valdymo grupė: projekto komandos nariai, kurie betarpiškai dalyvaujaprojekto valdyme.- Sponsorius: asmuo ar grupė, suteikianti projektui finansinius resursus.- Įtakojantys: asmenys ar grupės, tiesiogiai nesusiję projekto produkto įsigijimu arnaudojimu, bet dėl savo individualios pozicijos užsakovo ar vykdančioje organizacijojegalintys teigiamai ar neigiamai įtakoti projekto eigą.- Projektų valdymo skyrius (angl. PMO – Project Management Office): jei toks yravykdančioje organizacijoje, gali būti suinteresuotas asmuo, jei tiesiogiai ar netiesiogiaiatsakingas už projekto rezultatus.Be išvardintų gali būti daugybė kitų projektu suinteresuotų asmenų, pavyzdžiui: savininkai<strong>ir</strong> investuotojai, pardavėjai <strong>ir</strong> kontraktoriai, komandos nariai <strong>ir</strong> jų šeimos, valstybinėsorganizacijos, atsk<strong>ir</strong>i gyventojai <strong>ir</strong> visa visuomenė.Projekto vadovas turi valdyti suinteresuotų asmenų lūkesčius, kas nėra paprasta, nessuinteresuoti asmenys dažnai turi sk<strong>ir</strong>tingus <strong>ir</strong> konfliktuojančius tikslus.Projekto valdymo procesaiProjekto valdymo procesai apibrėžti kaip diskretūs elementai su savo interfeisais, tačiaupraktikoje jie persidengia. Labiausiai patyrę praktikai pripažįsta, kad yra ne vienas būdas valdytiprojektą. Projekto specifiką sudaro tikslai, kuriuos reikia pasiekti atsižvelgiant į sudėtingumą,riziką, dydį, laiką, projekto komandos pat<strong>ir</strong>tį, prieinamus resursus, turimą istorinę informaciją,Mokymo medžiaga 162
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKorganizacijos projektų valdymo brandumą <strong>ir</strong> taikomąją sritį. Projekto valdymo procesai taikomiprojekte iteratyviai <strong>ir</strong> daug procesų projekto eigoje yra kartojama ar peržiūrima. Projektovadovas <strong>ir</strong> komanda yra atsakingi už nustatymą, kas kuriuos procesus <strong>ir</strong> kaip reglamentuotai turitaikyti, kad būtų pasiekti projekto tikslai.Projekto valdymo procesai sąveikauja pagal principą planuok-daryk-tikrink-veik (angl.plan-do-check-act).Projekto valdymo procesų grupėsPMBOK apibrėžia 5 projekto valdymo procesų grupes:- Inicijavimo procesų grupė (angl. Initiating Process Group): apibrėžia <strong>ir</strong> inicijuojaprojektą ar projekto fazę.- Planavimo procesų grupė (angl. Planning Process Group): apibrėžia <strong>ir</strong> detalizuojatikslus <strong>ir</strong> planuoja veiklas projekto tikslų <strong>ir</strong> apimties pasiekimui.- Vykdymo procesų grupė (angl. Executing Process Group): apjungia žmones <strong>ir</strong> kitusresursus projekto valdymo plano įgyvendinimui.- Stebėjimo <strong>ir</strong> kontroliavimo procesų grupė (angl. Monitoring and Controlling ProcessGroup): reguliariai matuoja <strong>ir</strong> stebi projekto progresą, kad identifikuoti nukrypimusnuo projekto plano taip, kad būtų galima imtis korekcinių veiksmų, reikalingų projektotikslams pasiekti.- Uždarymo procesų grupė (angl. Closing Process Group): formalizuoja produkto,paslaugos ar rezultatų priėmimą <strong>ir</strong> tvarkingai užbaigia projektą ar projekto fazę.Projekto integravimo valdymasProjekto integravimo valdymo žinių sritis apima procesus <strong>ir</strong> veiklas, reikalingasidentifikavimui, apibrėžimui, kombinavimui, unifikavimui <strong>ir</strong> koordinavimui sk<strong>ir</strong>tingų procesų <strong>ir</strong>veiklų projekto valdymo procesų grupėse (jų viduje). Projekto valdymo kontekste integravimasyra priėmimas sprendimų, kur kiekvienu momentu koncentruoti pastangas <strong>ir</strong> resursus, numatantpotencialias problemas, sprendžiant jas prieš tampant kritiškomis <strong>ir</strong> koordinuojant darbus.Integravimas taip pat apima derybas dėl prieštaringų tikslų <strong>ir</strong> alternatyvų.Integravimo poreikis darosi akivaizdus situacijose, kai atsk<strong>ir</strong>i procesai sąveikauja,pavyzdžiui: kainos įvertinimas, reikalingas sudarant atstatymo (contingency) planą, apimaintegravimą planavimo procesų, susijusių su projekto kainos, laiko <strong>ir</strong> rizikos valdymu.Projekto integravimo valdymo procesai:- Sukurti projekto įsakymą (angl. Develop Project Charter): įsakymas formaliaiinicijuoja (sankcionuoja) projektą ar projekto fazę.Mokymo medžiaga 163
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOK- Sukurti preliminarų projekto apimties apibrėžimą (angl. Develop Preliminary ProjectScope Statement): aukštu lygiu aprašo projekto apimtį.- Sukurti projekto valdymo planą (angl. Develop Project Management Plan):dokumentuoti veiksmus, būtinus apibrėžti, paruošti, integruoti <strong>ir</strong> koordinuoti visusdalinius planus į projekto valdymo planą.- Vadovauti <strong>ir</strong> valdyti projekto vykdymą (angl. D<strong>ir</strong>ect and Manage Project Execution):vykdyti projekto valdymo plane numatytas veiklas, kad pasiekti projekto tikslus,apibrėžtus projekto apimties dokumente.- Stebėti <strong>ir</strong> kontroliuoti projekto darbą (angl. Monitor and Control Project Work): stebėti<strong>ir</strong> kontroliuoti procesus, naudojamus projekto inicijavimui, planavimui, vykdymui <strong>ir</strong>uždarymui, kad pasiekti projekto efektyvumo rodiklius, apibrėžtus projekto valdymoplane.- Integruotas pakeitimų valdymas (angl. Integrated Change Control): peržiūrėti visusprašymus pakeitimams, patv<strong>ir</strong>tinti pakeitimus <strong>ir</strong> kontroliuoti pakeitimus.- Uždaryti projektą (angl. Close Project): pabaigti visas veiklas, kad formaliai uždarytiprojektą ar projekto fazę.Projekto apimties valdymasProjekto apimties valdymas apima procesus, reikalingus užtikrinimui, kad projektenumatyti visi tie <strong>ir</strong> tik tie darbai, kurie reikalingi įvykdyti projektą sėkmingai. Projekto apimtiesvaldymas iš esmės yra susijęs su apibrėžimu <strong>ir</strong> kontroliavimu, kas turi <strong>ir</strong> kas neturi būti įtraukta įprojektą.Projekto apimties valdymo procesai:- Apimties planavimas (angl. Scope Planning): sukūrimas projekto apimties plano, kurisdokumentuoja, kaip bus nustatoma, tikrinama, kontroliuojama projekto apimtis <strong>ir</strong> kaipbus sudaroma darbų skleistinė (angl. WBS – Work breakdown Structure).- Apimties apibrėžimas (angl. Scope Definition): sukūrimas detalaus projekto apimtiesapibrėžimo, kuris bus pagrindu tolimesniems projekto sprendimams.- Darbų skleistinės sukūrimas (angl. Create WBS): pagrindinių projekto darbo produktų<strong>ir</strong> darbų suskaidymas į mažesnius <strong>ir</strong> lengviau valdomus komponentus.- Apimties patikrinimas (angl. Scope Verification): baigtų projekto darbo produktųpriėmimo formalizavimas.- Apimties kontroliavimas (angl. Scope Control): projekto apimties pasikeitimųkontroliavimas.Mokymo medžiaga 164
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKProjekto laiko valdymasProjekto laiko valdymas apima procesus, reikalingus laiku užbaigti projektą:- Veiklų apibrėžimas (angl. Activity Definition): identifikavimas specifinių veiklų, kuriosturi būti atliktos, kad būtų sukurti projekto darbo produktai.- Veiklų sekų nustatymas (angl. Activity Sequencing): nustatyti <strong>ir</strong> dokumentuotipriklausomybes tarp veiklų.- Resursų veikloms vertinimas (angl. Activity Resource Estimating): kiekvienai veiklainustatyti pobūdį <strong>ir</strong> apimtis jau vykdyti reikalingų resursų.- Veiklų trukmės vertinimas (angl. Activity Duration Estimating): kiekvienai veiklainustatyti, kiek laiko reikia jos įvykdymui.- Tvarkaraščio sukūrimas (angl. Schedule Development): analizuoti veiklų sekas,trukmes, resursų poreikius <strong>ir</strong> apribojimus tvarkaraščiui <strong>ir</strong> sudaryti projekto tvarkaraštį.- Tvarkaraščio kontroliavimas (angl. Schedule Control): projekto tvarkaraščiopasikeitimų kontroliavimas.Projekto kainos valdymasProjekto kainos valdymas apima procesus, naudojamus kainos planavime, vertinime,biudžetavime <strong>ir</strong> kontroliavime taip, kad projektas būtų įvykdytas su patv<strong>ir</strong>tintu finansavimu:- Kainos vertinimas (angl. Cost Estimating): įvertinimas resursų, reikalingų projektoveikloms atlikti, kainos.- Biudžeto sudarymas (angl. Cost Budgeting): agregavimas atsk<strong>ir</strong>ų veiklų kainų įverčių<strong>ir</strong> sudarymas projekto biudžeto (cost baseline).- Kainos kontroliavimas (angl. Cost Control): įtakojimas faktorių, kurie sąlygojaprojekto kainos nukrypimus, <strong>ir</strong> kontroliavimas projekto biudžeto pasikeitimų.Projekto kokybės valdymasProjekto kokybės valdymas apima visas organizacijas atliekamas veiklas, nustatantkokybės politiką, tikslus <strong>ir</strong> atsakomybes taip, kad projektas patenkintų poreikius, kuriems jisbuvo sk<strong>ir</strong>tas. Tai kokybės valdymo sistemos įgyvendinimas, apibrėžiant politiką, procedūras <strong>ir</strong>procesus kokybės planavimui, kokybės užtikrinimui, kokybės kontroliavimui <strong>ir</strong> nuolatiniamproceso gerinimui.Projekto kokybės valdymo procesai:- Kokybės planavimas (angl. Quality Planning): nustatymas, kokie kokybės standartaiyra susiję su projektu <strong>ir</strong> kaip juos patenkinti.Mokymo medžiaga 165
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOK- Kokybės užtikrinimas (angl. Perform Quality Assurance): taikymas planuotųsistemingų kokybės veiklų, kad projekte vykdomi visi procesai, reikaling<strong>ir</strong>eikalavimams patenkinti.- Kokybės kontroliavimas (angl. Perform Quality Control): stebėjimas specifiniųprojekto rezultatų, kad nustatyti, ar jie atitinka susijusius kokybės standartus, <strong>ir</strong>nustatymas būdų eliminavimui netinkamo vykdymo priežasčių.Projekto žmogiškųjų resursų valdymasProjekto žmogiškųjų resursų valdymas apima projekto komandos organizavimo <strong>ir</strong> valdymoprocesus. Projekto komanda sudaryta iš asmenų, kuriems prisk<strong>ir</strong>tos rolės <strong>ir</strong> atsakomybėsprojekte. Komandos nariai turėtų būti įtraukiami į projekto planavimą <strong>ir</strong> sprendimų priėmimą.Projekto žmogiškųjų resursų valdymo procesai:- Žmogiškųjų resursų planavimas (angl. Human Resource Planning): identifikavimas <strong>ir</strong>dokumentavimas projekto rolių, atsakomybių <strong>ir</strong> atsiskaitomybių bei kadrųkomplektavimo valdymo plano sudarymas.- Projekto komandos surinkimas (angl. Acqu<strong>ir</strong>e Project Team): gavimas žmogiškųjųresursų, reikalingų projektui vykdyti.- Projekto komandos suformavimas (angl. Develop Project Team): pagerinimaskomandos narių kompetencijos <strong>ir</strong> tarpusavio bendravimo, kad padidinti darboefektyvumą.- Projekto komandos valdymas (angl. Manage Project Team): komandos narių darboefektyvumo stebėjimas, grįžtamojo ryšio užtikrinimas, problemų sprendimas <strong>ir</strong>pakeitimų koordinavimas, siekiant padidinti darbo efektyvumą.Projekto komunikavimo valdymasProjekto komunikavimo valdymas apima procesus, užtikrinančius savalaikį <strong>ir</strong> tinkamąprojekto informacijos generavimą, surinkimą, pask<strong>ir</strong>stymą, saugojimą, gavimą <strong>ir</strong> galutinį„atsikratymą“. Šie procesai užtikrina kritinius ryšius tarp žmonių <strong>ir</strong> sėkmingam darbu<strong>ir</strong>eikalingos informacijos. Projekto vadovas gali sugaišti neleistinai daug laiko komunikuodamassu projekto komanda, suinteresuotais asmenimis, užsakovu <strong>ir</strong> sponsorium. Kiekvienas,dalyvaujantis projekte, turi suprasti, kokį poveikį komunikavimas daro visam projektui.Projekto komunikavimo valdymo procesai:- Komunikavimo planavimas (angl. Communication Planning): nustatymassuinteresuotų asmenų poreikių informacijai <strong>ir</strong> komunikavimui.- Informacijos platinimas (angl. Information Distribution): užtikrinti, kad suinteresuotiasmenys galėtų gauti reikalingą informaciją laiku.Mokymo medžiaga 166
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOK- Informavimas apie eigą (angl. Performance Reporting): surinkimas <strong>ir</strong> paskleidimasinformacijos apie eigą (būsenos ataskaitos, progreso matavimas <strong>ir</strong> prognozavimas).- Suinteresuotų asmenų valdymas (angl. Manage Stakeholders): komunikavimovaldymas, siekiant patenkinti suinteresuotų asmenų reikalavimus <strong>ir</strong> išspręsti problemas.Projekto rizikos valdymasProjekto rizikos valdymas apima procesus, susijusius su rizikos valdymo planavimu,identifikavimu, analize, reagavimu, stebėjimu <strong>ir</strong> kontroliavimu. Rizikos valdymo tikslai yrapadidinti teigiamų įvykių tikimybes <strong>ir</strong> poveikį bei sumažinti neigiamų įvykių tikimybes <strong>ir</strong>poveikį.Projekto rizikos valdymo procesai:- Rizikos valdymo planavimas (angl. Risk Management Planning): nuspręsti, kaipplanuoti <strong>ir</strong> vykdyti rizikos valdymą projekte.- Rizikos identifikavimas (angl. Risk Identification): nustatyti, kokios rizikos galipaveikti projektą <strong>ir</strong> dokumentuoti jų charakteristikas.- Kokybinė rizikos analizė (angl. Qualitative Risk Analysis): rizikų prioritetizavimas,nustatant jų įvykimo tikimybes <strong>ir</strong> poveikį.- Kiekybinė rizikos analizė (angl. Quantitative Risk Analysis): identifikuotų rizikųpoveikio viso projekto tikslams skaitinė analizė.- Reagavimo į rizikas planavimas (angl. Risk Response Planning): sukūrimas alternatyvų<strong>ir</strong> veiksmų padidinimui galimybių <strong>ir</strong> sumažinimui grėsmių projekto tikslams pasiekti.- Rizikos stebėjimas <strong>ir</strong> kontroliavimas (angl. Risk Monitoring and Control): sekimasidentifikuotų rizikų, stebėjimas neišaiškintų rizikų, identifikavimas naujų rizikų,vykdymas reagavimo į rizikas planų <strong>ir</strong> vertinimas jų efektyvumo.Projekto įsigijimų valdymasProjekto įsigijimų valdymas apima procesus, sk<strong>ir</strong>tus p<strong>ir</strong>kimui ar įsigijimui iš išorėsproduktų, paslaugų ar rezultatų, reikalingų projekto komandai atlikti darbą. Nagrinėjamos abiperspektyvos: organizacija gali būti arba p<strong>ir</strong>kėjas, arba pardavėjas.Projekto įsigijimų valdymas apima: sutarties valdymo <strong>ir</strong> pakeitimų kontroliavimo procesus,naudojamus administravimui projekto komandos sudarytų sutarčių ar p<strong>ir</strong>kimo dokumentų;administravimą bet kokių išorinių organizacijų (p<strong>ir</strong>kėjų) sudarytų sutarčių su projektą vykdančiaorganizacija (pardavėju) <strong>ir</strong> administravimą sutartinių įsipareigojimų, už kurių įvykdymąatsakinga projekto komanda.Mokymo medžiaga 167
Programų sistemų inžinerija11. Projekto valdymas pagal PMBOKProjekto įsigijimų valdymo procesai:- P<strong>ir</strong>kimų <strong>ir</strong> įsigijimų planavimas (angl. Plan Purchases and Acquisitions): nustatymas,ką p<strong>ir</strong>kti ar įsigyti bei kada <strong>ir</strong> kaip tai padaryti.- Sutarčių planavimas (angl. Plan Contracting): dokumentavimas reikalavimųproduktams, paslaugoms <strong>ir</strong> rezultatams <strong>ir</strong> identifikavimas potencialių pardavėjų.- Informacijos iš pardavėjų gavimas (angl. Request Seller Responses): gavimasinformacijos, kainų, pasiūlymų.- Tiekėjų pas<strong>ir</strong>inkimas (angl. Select Sellers): pasiūlymų peržiūrėjimas, pas<strong>ir</strong>inkimas tarppotencialių pardavėjų, derybos <strong>ir</strong> pas<strong>ir</strong>ašymas sutarčių su tiekėjais.- Sutarties administravimas (angl. Contract Administration): valdymas sutarties <strong>ir</strong>santykių tarp p<strong>ir</strong>kėjo <strong>ir</strong> pardavėjo, peržiūra <strong>ir</strong> dokumentavimas, kaip pardavėjas atliekaar atliko įsipareigojimus, nustatyti pataisas <strong>ir</strong> pagrindus tolimesniam bendravimui supardavėju, valdymas su sutartimi susijusių pakeitimų <strong>ir</strong>, kai aktualu, valdymassutartinių santykių su išoriniu projekto p<strong>ir</strong>kėju.- Sutarties uždarymas angl. (Contract Closure): užbaigimas <strong>ir</strong> sureguliavimas kiekvienossutarties, įskaitant išsprendimą atv<strong>ir</strong>ų problemų, uždarymas visų kontraktų, susijusių suprojektu ar projekto faze.Literatūra papildomam skaitymui[PMI04]A Guide to Project Management Body of Knowledge (PMBOK Guide). ProjectManagement Institue, 2004.(an American National Standard: ANSI/PMI 99-001-2004).Mokymo medžiaga 168
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektams12. Vadovavimas programų sistemų projektamsProgramų sistemų projekto lyderisLyderio tikslaiSvarbiausias techninio lyderio vaidmuo yra nustatyti tikslus <strong>ir</strong> vesti, kad jie būtų pasiekti.Pavyzdys su IMB 370 kompiuterio kūrimu: kaip tik tuo metu ats<strong>ir</strong>ado v<strong>ir</strong>tualios atmintieskoncepcija <strong>ir</strong> būtent lyderiui reikėjo priimti sprendimą, ar reikia ją realizuoti kuriamamekompiuteryje; situacija buvo labai neaiški, nes toks sprendimas atidėtų naujo kompiuteriosukūrimą metams. Paprasčiausia buvo nieko nekeisti, bet buvo priimtas (iš perspektyvos žiūrint,akivaizdžiai teisingas) sprendimas realizuoti v<strong>ir</strong>tualią atmintįLyderio įsitikinimasJei lyderis priėmė sprendimą, jis turi vesti, kad įveikti visas kliūtis, <strong>ir</strong> kai jo žmonės jaupas<strong>ir</strong>uošę pasiduoti, jis turi vėl juos sutelkti dar vienam bandymui.Pavyzdys su spalvotos televizijos standartu. 1950 m. iškilo klausimas, kokiu standartu bustransliuojama spalvota TV JAV. Buvo 2 alternatyvos: jau egzistuojanti CBS mechaninė sistema<strong>ir</strong> dar tik kuriama RCA trijų spalvų tūbos sistema. 1950 m. Valstybinė komisija priėmė nutarimąnerizikuoti <strong>ir</strong> naudoti egzistuojančią CBS sistemą. Visi galvojo, kad trispalvė sistema jau m<strong>ir</strong>usi,bet projekto lyderis tikėjo, kad ši sistema tikrai geresnė, tęsė darbus <strong>ir</strong> 1953 m. podemonstracijos ši sistema buvo patv<strong>ir</strong>tinta.Lyderiai <strong>ir</strong> jų pasekėjaiBe pasekėjų lyderis neturi pakankamai jėgų. Lyderio jėga yra patraukti žmones, o valdymod<strong>ir</strong>ektyvos riboja pas<strong>ir</strong>inkimo laisvę. Galimybė valdyti yra ne tas pats kas galimybė vesti.Lyderis turi rūpintis savo pasekėjais, t.y. galvoti apie žmones, jų poreikius <strong>ir</strong> viltis.Rūpinimasis yra parodomas, pavyzdžiui, kai Napoleonas žinojo savo karių vardus, o TomasVatsonas atsiminė savo fabriko darbininkų žmonas <strong>ir</strong> vaikus. Štai kodėl, pavyzdžiui, didiejigenerolai atsisako leisti savo pajėgas į riziką, su kuria patys jie nesusidurtų. Kai lyderiai taipelgiasi, žmonės jaučia tai <strong>ir</strong> pas<strong>ir</strong>yžę sekti paskui juos bet kur.Transformacinis lyderiavimasVienas iš būdų sužadinti žmonių vaizduotę yra remtis jų svajonėmis <strong>ir</strong> ambicijomis.Dauguma inžinierių <strong>ir</strong> mokslininkų siekia didybės <strong>ir</strong> linkę dalyvauti jaudinančiame nuotykyje.Kai viena iš Data General komandų kūrė naują kompiuterį, lyderis savaites aiškino inžinieriams,kokia tai bus puiki, naujo tipo mašina, kokia jis svarbi kompanijai, kokia stipri konkurencinėkova. Jam pavyko suburti pasišventusių žmonių komandą, kuri neįsivaizduojamai ilgas valandasd<strong>ir</strong>bo, kad sukurtų geriausią kompiuterį, kokį jie galėjo įsivaizduoti.Mokymo medžiaga 169
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamsĮtikindami žmones pasišvęsti jų tikslo pasiekimui, lyderiai naudoja tai, ką Burns vadina"transformaciniu lyderiavimu". Toks lyderiavimas yra naudingas visiems dalyvaujantiems.Inžinieriai <strong>ir</strong> programuotojai gauna didžiulį vidinį pasitenkinimą, o kompanija puikiausiąproduktą. Toks susijaudinimas yra tipiškas tokiems projektams kaip RCA trijų spalvų tūba arIBM 370 kompiuteris. Nevisi projektai turi šią savybę, bet nė vienas projektas negali būti toksvisą laiką. Kiekvienas inžinierius susiduria su mėnesiais rutininio darbo kiekvienai susijaudinimodienai, o tipinis mokslininkas metais ruošiasi kiekvienam atradimui. Henris Kisendžeris yrapasakęs, kad lyderiavimas ats<strong>ir</strong>anda "iš akumuliavimo niuansų, šimtų daiktų padarytų truputėlįgeriau".Pareigybinis lyderiavimasKiekvienas vadovas turi oficialią jėgą, jo užimamų pareigų jėgą. Vadovas turi platų spektrągalimybių sprendžiant, kas dalyvauja kokiame projekte, kas pripažįstamas <strong>ir</strong> kas skatinamas.Darbuotojai žino, kad vadovo nuomonė yra svarbi, <strong>ir</strong> stengiasi būti vadovo mėgstami. Tačiauvadovai retai naudoja šias savo galimybes tiesiogiai, jos glūdi už visko, ką jie daro.Lyderiavimas, pagrįstas oficialia jėga, vadinamas pareigybiniu lyderiavimu. Jis suteikiamotyvaciją veiklai, bet tuo pačiu turi apribojimų. Pavyzdžiui, darbuotojai, bes<strong>ir</strong>ūpindami savoatlyginimu <strong>ir</strong> paskatinimu, gali stengtis daryti tai, ko bosas nori, o ne tai, ko reikia darbui. Be to,jie nelinkę prieštarauti.Kadangi inžinieriai <strong>ir</strong> mokslininkai turi profesinę garbę, dauguma trokšta atlikti darbą gerainet, jei tai nėra vertinama. Pavyzdys kaip produkto vadovas išsaugojo svarbų spausdintuvoprojektą. Inžinieriai pasiūlė naują spausdintuvą, kuris pakeistų senesnį, tačiau senesnispausdintuvai buvo labai pelningi, todėl finansiniai vadovai abejojo dėl pakeitimo projekto.Inžinieriai kovojo su šiais finansiniais aspektais, bet greitai pasidavė <strong>ir</strong> nuėjo pas produktovadovą sutikimo nutraukti projektą. Jų nuostabai vadovas pasakė, kad jų darbas daryti geresniusproduktus <strong>ir</strong>, jei finansininkai nėra patenkinti, reikia juos patenkinti. Jis tikėjo, kad jiemspasiseks. Grįžę inžinieriai sugebėjo parodyti finansininkams, kad jų mašinos techniniaiprivalumai turi prasmę <strong>ir</strong> piniginiu požiūriu. Programa buvo baigta <strong>ir</strong> rezultatas buvo labaisėkmingas produktas.Produkto vadovas pasielgė kaip lyderis, bet jo poelgis buvo netradicinis. Tikriprofesionalai susigėdo, kai tapo aišku, kad jie nepavyko padaryti tai, ką turėjo, <strong>ir</strong> iššūkispabandyti dar kartą buvo didelis stimulas.Kodėl inžinieriai neatliko savo darbo gerai iš p<strong>ir</strong>mo karto? Daugumai žmonių reikiaperiodinio paraginimo d<strong>ir</strong>bti geriausiai. Technologijoje kiekvienai sėkmei tenka daug nesėkmių,todėl lengva nusivilti. P<strong>ir</strong>mas kainos vertinimas visada per didelis, pradinis grafikas netikslus.Kūrėjai, kurie per lengvai pasiduoda, niekada nepabaigs produkto, <strong>ir</strong> jų vadovai turi jausti tai <strong>ir</strong>Mokymo medžiaga 170
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamsraginti stengtis labiau. Vadovai turi vesti, palaikyti, padėti, bet viso šito jie turi neleisti savožmonėms pasiduoti per anksti.Lyderiavimas iš apačiosKiekvienas vadovas turi elgtis kaip lyderis, ar vadovautų didelei korporacijai ar dviemsžmonėms. Ir lyderio vaidmens svarba nepriklauso nuo organizacijos dydžio. Organizacijanegalės sėkmingai funkcionuoti, jei nebus lyderių visuose lygiuose.Iš principo, lyderio vaidmuo nelabai priklauso nuo lygio, bet praktiškai yra vienas didžiulissk<strong>ir</strong>tumas: aukščiausi vadovai tipiškai suvokia poreikį imtis veiksmų, o žemiausi vadovai dažnaipaskęsta biurokratinių <strong>ir</strong> rutininių darbų jūroje. Todėl labai svarbu kūrybiškai žiūrėti į rutininiusdarbus <strong>ir</strong> stengtis patobulinti jų atlikimą. Pavyzdys kaip viena žemiausio lygio vadovė sugebėjoiš esmės pagerinti darbą.Lyderio vizijaMatyt, viena svarbiausių lyderio charakteristikų yra vizija. Tomas Vatsonas jaunesnysis1950-aisiais matė kompiuterių svarbą <strong>ir</strong>, nepaisydamas kliūčių, suorientavo IBM į kompiuteriųsritį. Deja, 1970 nauji vadovai perėmė IBM. Jų vizija iš esmės buvo orientuota į finansinį IBMaugimą. Tai buvo tikrai pajėgūs vadovai, bet jie nepateikė principų, taip reikalingų kompanijai.Šio vizijos trūkumo rezultatas buvo esminės klaidos <strong>ir</strong> praleistos galimybės.Tai buvo tik aukščiausio lygio IBM vadovų problema, techninis personalas turėjo stipriusįsitikinimus, ką kompanija turėtų daryti. Tai rodo jų laiškai vadovams, pavyzdžiui, 1970pabaigoje pabrėžiantis kompiuterių tinklų svarbą. Deja, į juos nebuvo tinkamai atsižvelgta.Techninių profesionalų lyderisLyderiui tenka didžiulė atsakomybė. Keletas patarimų lyderiams, pateiktų Lee Lacocca: jeijūs krizėje, nėra laiko atlikti studijas; sus<strong>ir</strong>ašykite ant popieriaus lapo 10 dalykų, kuriuos jūsbūtinai turite padaryti; visa kitą - pam<strong>ir</strong>škite; m<strong>ir</strong>ties šešėlis verčia skubiai sutelkti dėmesį.Lyderiai taip pat apibrėžia organizacijos tempą: boso greitis yra komandos greitis. Jūsnegalite visiems projektams suteikti nutrūktgalviško greičio, bet jei bosas atsipalaiduoja dienai ardviems, organizacija užmiega. Bosas turi reikalauti susitarimų laikymosi, net jei tai reiškia darbąiki vėlumos ar savaitgaliais.Galiausiai, jokia sėkmė neateina pati <strong>ir</strong> lengvai. Kai žmonės jau pas<strong>ir</strong>engę pasiduoti,dažniausiai dar yra likę neišbandytų kelių. Lyderis turi paklausti: kokios yra nebandytosalternatyvos, ar kas nors buvo susidūręs su čia problema anksčiau, su kuo iš ekspertų buvokontaktuota? Nuostabu, kaip dažnai techniniai žmonės randa kūrybinį sprendimą, kai bosas juosparagina pabandyti dar kartą. Bokso čempionas yra pasakęs: pakovok dar vieną raundą tada, kaiMokymo medžiaga 171
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamsjau atrodo, kad nebeturi jėgų, nebeklauso nei rankos, nei kojos, <strong>ir</strong> atsimink, kad žmogus, kuriskovoja dar vieną raundą yra nesumušamas.Įsipareigojimų etikaHumphrey pateikia pavyzdį, kaip jis p<strong>ir</strong>mą kartą dalyvavo priimant sprendimą pradėtinaujos mašinos gamybą. Viskas buvo paruošta labai kruopščiai <strong>ir</strong> atrodė, kad patv<strong>ir</strong>tinimas turėtųbūti tik formalumas. Bet užv<strong>ir</strong>ė labai aktyvus svarstymas, aibė detaliausių klausimų, kas labainustebino Humphrey. Tada vienas patyręs inžinierius jam paaiškino, kad šie žmonės pas<strong>ir</strong>yžęprisiimti įsipareigojimus, o kai jie tai padarys, "apvers žemę <strong>ir</strong> pragarą", kad šiuos įvykdyti, todėljiems reikia laiko, kad jaustųsi komfortabiliai.Kai grupės žmonių daro bendrą produktą, reikalingas grafikas, paremtas abipusiaissusitarimais ar įsipareigojimais. Deja, žmonės retai daro tikslius vertinimus <strong>ir</strong> visada iškyla kasnors netikėta, kas vėlina pabaigimą. Tada kiekvienas turi kautis, kad sutilpti į grafiką. Bet kodėlkiekvienas kovoja vietoje to, kad susitaikyti su vėlavimu <strong>ir</strong> keikti blogą likimą? Sk<strong>ir</strong>tumas yrapožiūryje į įsipareigojimus.Įsipareigojimų elementaiKai vienas žmogus sudaro paktą su kitu <strong>ir</strong> abu tikisi, kad jo bus laikomasi, tai <strong>ir</strong> vadinamaįsipareigojimu. Beveik viskas, ką daro inžinieriai <strong>ir</strong> mokslininkai, yra kažkuria prasme daromap<strong>ir</strong>mą kartą. Kai žmonės d<strong>ir</strong>ba kartu stebinančioje aplinkoje, jie turi padėti vienas kitam; <strong>ir</strong> šipagalba turi remtis įsipareigojimų disciplina.Motyvacija vykdyti įsipareigojimus yra daugiausia rezultatas būdo, kaip tie įsipareigojimaiprisiimami. P<strong>ir</strong>ma, įsipareigojimas turi būti prisiimamas laisvai. Nors praktikoje įsipareigojimųlankstumo laipsnis dažnai ribotas, žmogus turi jausti, kad turi kažkokį pas<strong>ir</strong>inkimą. Net gavęgalimybę trumpai pasisakyti, paprieštarauti ar pasiūlyti pakeitimus, jie jausis surišti pažado tiktada, kai jausis, kad davė jį savanoriškai.Įsipareigojimo matomumas (viešumas) yra vienodai svarbus. Asmeniškas įsipareigojimasstato ant kortos profesionalo patikimumą, kuris labai svarbus. Patikimumas yra kažkas, kągalima įgyti tik per laiką. Ir tik jei jūs jį užsitarnavote, jūs galite jį naudoti.Pavyzdys, rodantis, kas gali įvykti, kai šios sąlygos nėra patenkintos. Projektas labaiatsiliko nuo grafiko <strong>ir</strong> tapo aišku, kad negalės būti baigtas laiku. Marketingo vadovybė labaipiktinosi <strong>ir</strong> grasino skųstis aukščiausiai kompanijos valdžiai. Suprasdamas, kad turi kažką daryti,projekto vadovas šiaip taip susitarė atidėti dar 3 mėnesiams. Nors tai buvo daugiausia, ką jisgalėjo padaryti be didžiulio kompanijos nagrinėjimo, programuotojai neapsidžiaugė <strong>ir</strong> vienas išjų pasakė: tai jo data, aš jam linkiu sėkmės. Vadovas sąžiningai stengėsi, bet kadangi niekas išprogramuotojų nedalyvavo, sudarant naują grafiką, jie nesijautė asmeniškai įsipareigoję.Mokymo medžiaga 172
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamsAtsakingų įsipareigojimų sudarymasKitas reikalavimas atsakingiems įsipareigojimams yra pas<strong>ir</strong>uošimas. Įsipareigojimas turėtųbūti p<strong>ir</strong>miausia aiškiai apibrėžtas <strong>ir</strong> įvertintas. Jei įtraukta keletas žmonių, jie visi turėtų dalyvauti<strong>ir</strong> jų požiūriai turėtų būti kruopščiai aptarti. Supažindinti kiekvieną su darbu <strong>ir</strong> tuo, ko iš jotikimasi, reikalauja laiko, bet tai vienintelis būdas padėti tv<strong>ir</strong>tus pamatus įsipareigojimui.Po to seka pats susitarimas. Paprasčiausiu atveju dalyvauja 2 žmonės: vienas nori, kaddarbas būtų atliktas, o kitas potencialus atlikėjas. Abu nori paskatinimo <strong>ir</strong> ekonominio efekto, betjų interesai priešingi. Vienas nori agresyvaus įsipareigojimo, kad užtikrinti greičiausią atlikimą,kitas - komfortabilaus buferio nenumatytoms problemoms. Rezultatas yra susitarimas, kai abiejųpusių žinios <strong>ir</strong> reliatyvi jėga apibrėžia rezultatą.Trečias įsipareigojimo žingsnis yra įvykdymas. Kai viskas eina pagal planą, jokiųproblemų, bet taip retai būna. Visada būna siurprizų, <strong>ir</strong> nerašyta technologijos taisyklė sako, kadvisi siurprizai reikalauja daugiau darbo. Patyrę techniniai žmonės mokosi tai numatyti, bet jųplanai negali būti absoliučiai tikslūs. Rezultate didžiulių pastangų visada reikia, kad sutilpti įsutartą grafiką.Kai dūmai prasisklaido, darbas turi būti iš naujo įvertintas, kad suprasti kas buvo blogai <strong>ir</strong>kaip prisiimti geresnius įsipareigojimus kitą kartą. Lygindami realų vykdymą su įvertinimais,profesionalai mokosi daryti geriau vertinti. Štai kodėl žmonės, atliekantys darbus, turėtų darytissavo planus: išmokti kaip prisiimti įsipareigojimus, kuriuos gali įvykdyti.Įsipareigojimai ar kryžiaus žygiai?Nors įsipareigojimų laikymasis yra gyvybiškas, jis gali nuvesti per toli. Pavyzdys su pigiubanko spausdintuvu. Buvo nutarta panaudoti specialų plastikinį spausdinimo rato mechanizmą.Iš pradžių viskas atrodė puiku, bet vis iškildavo įva<strong>ir</strong>ios problemos, kurios reikalavokonstrukcijos patobulinimų, todėl galiausiai vietoj paprasto gavosi labai sudėtingas <strong>ir</strong> brangusspausdintuvas, kuris nebeteko praktinės prasmės.Inžinieriai taip stengėsi spręsti iškilusias problemas, kad pam<strong>ir</strong>šo pradinį tikslą, aklaibandydami įvykdyti duotus įsipareigojimus.Įsipareigojimų hipnozė yra santykinai bendra problema. Žmonės įsitikinę, kad tai, ko jienori, kad įvyktų, turi įvykti. Pamatę, kad jų projektas akivaizdžiai neveikia, inžinieriai dažnaipadvigubina pastangas. Jie atrodo įsitikinę, kad truputį daugiau laiko <strong>ir</strong> dar vienas bandymasišspręs šią paskutinę problemą.Per griežti įsipareigojimaiVienas iš optimisto triukų priversti vadovybę taip įsipareigoti projektui, kad jis negalėtųbūti nutrauktas. Pavyzdžiui, inžinieriai dažnai stengiasi, kad jų produktas būtų anonsuotas,Mokymo medžiaga 173
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamstikėdamiesi, kad tai apsaugos nuo planų pakeitimo. Kraštutinis atvejis buvo lėktuvo Konkordkūrimo pradžioje. Sutartyje tarp Britanijos <strong>ir</strong> Prancūzijos buvo įrašytas punktas, kad jei vienas išpartnerių atsisakytų tęsti darbus, tai turėtų apmokėti abiejų išlaidas tam momentui. Šis punktaspadarė kiekvienos iš pusių pasitraukimą nepraktišku, nežiūrint į tolimesnes problemas, kadangiišlaidos pastoviai augo. Mažai organizacijų gali leisti sau tokius technologinus kryžiaus žygius.Vidiniai įsipareigojimai yra esminiai, bet vadovybė turi įtarti komandą, kuri ragina juos prisiimtineatšaukimus įsipareigojimus. Dažnai inžinieriai jaučia problemą <strong>ir</strong> stengiasi apsaugoti projektąnuo nutraukimo.Paprastai reikia stengtis įveikti visas kliūtis, bet kartais tai tik didina beviltiško nuotykiokainą. Nevisi projektai gali būti sėkmingi, <strong>ir</strong> labiausiai įsitraukę inžinieriai paprastai paskutiniaisuvokia realybę. Dažnai reikalinga nepriklausoma priežiūra entuziazmo subalansavimui, nestechninė komanda pati įstūmusi save į bėdą retai pati be pagalbos išsikapstys.Vadovybės įsipareigojimaiPavyzdys iliustruojantis bendrą įsipareigojimų problemą. 1963 IBM turėjo pateiktipasiūlymą Skrydžių kontrolės kompiuteriui. Atkakliai d<strong>ir</strong>bdami, inžinieriai paruošė puikųtechnologiškai pasiūlymą, bet nekonkurentabilų kainos <strong>ir</strong> laiko požiūriu. Klientas norėjo gautimašiną per 9 mėnesius <strong>ir</strong> buvo konkurentų, sutinkančių tai padaryti už 65 mln. $. Nors <strong>ir</strong> labaistengdamiesi, IBM inžinieriai nesugebėjo kainos sumažinti mažiau nei iki 100 mln. $, ogeriausias grafikas 12 mėnesių <strong>ir</strong> tai su didele rizika.Pardavimų vadovas manė, kad užsakymas bus prarastas, bet inžinieriai tikėjo, kadužsakovas supras techninę pasiūlymo kokybę. Valdžia parėmė inžinierių poziciją <strong>ir</strong> liepė stengtisparduoti pasiūlymą. Visų nuostabai pasiūlymas buvo priimtas.Visada yra baimė, kad konkurentai pasiūlys žemesnę kainą ar geresnė grafiką. Vadovybėstengiasi sumušti konkurento pasiūlymus <strong>ir</strong> spaudžia inžinierius <strong>ir</strong> programuotojus. Grafikasvisada per ilgas, o kaina per aukšta. Kuo svarbesnis užsakymas, tuo didesnis spaudimassumažinti <strong>ir</strong> prisiimti didesnę riziką.Tokiomis sąlygomis vadovams sunku apsispręsti, kaip stipriai spausti savo žmones. Tadaįsipareigojimų disciplina yra lemianti. Atsakingi profesionalai ieškos kiekvienos galimybėspagerinti programą, bet kai jų idėjos išsenka, jie gali įsipareigoti atlikti tik tai, ką jie mano galiatlikti. Jei vadovai nori rizikuoti, profesionalai padarys viską kiek gali geriau, bet jie negaliįsipareigoti. Geriausi vadovai palaiko savo žmones, kai jie pasiekia tokį tašką.Įsipareigojimų keitimasKita monetos pusė yra problema, kada pakeisti planus. Kiekvienas planas yraįsipareigojimas, bet jis taip pat turi būti pagrindu darbų valdymui. Kai planas yra nerealistiškas,Mokymo medžiaga 174
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamstarpusavio koordinavimas yra praktiškai neįmanomas. Žmonės sudės papildomas pastangas, kadįvykdyti planą, kuriuo jie tiki, bet kai grafikas yra absurdiškas, prarandama motyvacija <strong>ir</strong>produktyvumas krenta.Vadovai turi jausti, kada griežti įsipareigojimai nustoja motyvuoti žmones. Akivaizdžiųpožymių nėra, bet paprastai nesunku tai pajausti: aptarimai nervingi, projekto būsena neaiški …Visi žino, kad projektas bėdoje, bet niekas nenori p<strong>ir</strong>mas apie tai prabilti. Štai tada vadovas turiorganizuoti visapusišką peržiūrą, kad išsiaiškinti realią padėtį. Be aiškaus einamosios situacijossupratimo, nėra pagrindo naujo plano darymui.Kruopštus darbo atlikimasJudy teisingai vadovavo, bet projektas susidūrė su nenumatytomis problemomis. Ji aptarėsu žmonėm padėtį <strong>ir</strong> suderino naują planą su betarpiškais vadovais. Po to nuėjo pas laboratorijosd<strong>ir</strong>ektorių, kuris žinoma neapsidžiaugė, bet sutiko, kad nieko geriau neišeina.Po savaitės vienas iš betarpiškų vadovų atėjo susigėdęs pas Judy <strong>ir</strong> pasakė, kad vienakritinė funkcija buvo praleista <strong>ir</strong> pr<strong>ir</strong>eiks daugiau laiko nei pagal naują grafiką. Judy buvošok<strong>ir</strong>uota, bet prieš kažką darydama, sušaukė savo žmones peržiūrėti, ar dar kas nors nebuvopraleista. Buvo rasti dar 2 punktai <strong>ir</strong> atitinkamai pakoreguotas grafikas. Kai ji pateikė taivyresniesiems vadovams, jie labai kritiškai žiūrėjo į šiuos pakeitimus, bet paaiškinus problemą <strong>ir</strong>kas buvo padaryta, sutiko, kad pas<strong>ir</strong>inkti teisingi veiksmai.Įsipareigojimų etikos kūrimasĮsipareigojimas yra bendras susitarimas dviejų ar daugiau žmonių, kurie tiki, kad kiti jolaikysis. IBM projekto vadovas suvokė, kad jo pavaldiniai ned<strong>ir</strong>ba kartu taip efektyviai kaipgalėtų. Problema buvo tarpusavio pasitikėjimas, todėl jis paprašė skyrių vadovus apibrėžti <strong>ir</strong>dokumentuoti jų tarpusavio įsipareigojimus. Tam buvo sk<strong>ir</strong>ti savaitiniai susitikimai <strong>ir</strong> visakomanda sukūrė tikslų jų tarpusavio ryšių supratimą <strong>ir</strong> galėjo lengviau bendrauti. Tai sukūrėpasitikėjimą būtiną efektyviai įsipareigojimų disciplinai.Efektyvi valdymo komanda turi bendrauti atv<strong>ir</strong>ai <strong>ir</strong> laisvai. Šie susitarimai tarp skyriųatvėrė bendravimą <strong>ir</strong>, kai jie pasitarnavo šiam tikslui, formalūs susitarimai tapo nebereikalingi.Įsipareigojimų nuosavybėŽmogus prisiimantis įsipareigojimą turėtų jaustis atsakingu įvykdyti jį. Pavyzdys taiparodo. Grupė buvo atsakinga už kokybės ataskaitų paruošimą. Duomenys buvo išmėtyti podaugelį failų, be to, dažnai buvo atliekami specialūs tyrimai, todėl visa tai tekdavo daryt<strong>ir</strong>ankomis <strong>ir</strong> kas kartą perdaryti. Dėl tokio pakartotinio darbo žmonės buvo nusivylę.Grupės vadovas žinojo, kad kompiuterinė DB būtų efektyviau, todėl pavedė žmonėmsparuošti pasiūlymą. Kadangi atliekamų žmonių nebuvo, tai jie suplanavo sk<strong>ir</strong>ti dalį to patiesMokymo medžiaga 175
Programų sistemų inžinerija12. Vadovavimas programų sistemų projektamslaiko, kurio <strong>ir</strong> taip trūkdavo. Kai jie nunešė planą d<strong>ir</strong>ektoriui, buvo tikimasi, kad darbas užimsmetus. Tačiau d<strong>ir</strong>ektoriui reikėjo naujo operacijų plano kitą vasarą <strong>ir</strong> jis suprato, kad bazė būtųlabai naudinga. Bet iki vasaros buvo 9 mėnesiai <strong>ir</strong> jis buvo nelinkęs įsakyti šiai per daug užimtaigrupei sutrumpinti grafiką. Jis paaiškino, kodėl jam tai svarbu, <strong>ir</strong> paprašė padaryti, ką gali.Visas skyrius įn<strong>ir</strong>tingai d<strong>ir</strong>bo kelis mėnesius <strong>ir</strong> atrado, kaip darbą galima padaryti žymiaigreičiau: jie rado egzistuojančią programą, atliekančią didelę dalį darbo. Jie didžiavosi, kadišpildė d<strong>ir</strong>ektoriaus prašymą.Tai puikus įsipareigojimo pavyzdys. D<strong>ir</strong>ektorius įsitikino, kad žmonės supranta problemą,<strong>ir</strong> prašė padaryti viską, ką gali. Jis nereikalavo, kad darbas būtų atliktas per 9 mėnesius, nes taibūtų jo data, o ne žmonių. Tačiau nurodydamas tikslą <strong>ir</strong> prašydamas pagalbos, jis perdavė jiemsvaldymą. Todėl jie jautėsi asmeniškai įsipareigoję padaryti viską, ką gali.Literatūra papildomam skaitymui[Hum96] Watts S. Humphrey. Managing Technical People: Innovation, Teamwork, and theSoftware Process. Addison-Wesley Professional, 1996.Mokymo medžiaga 176
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektai13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaiProfesija apibrėžiama kaip darbas, reikalaujantis išankstinio paruošimo. Kompiuteriniųinformacinių sistemų vystymas <strong>ir</strong> bet koks darbas susijęs su IT taip pat yra profesijos.Profesionalumas - tai d<strong>ir</strong>bti taip, kad būtų patenkinti aukščiausi šiai profesinei grupei keliam<strong>ir</strong>eikalavimai. Tokie reikalavimai užfiksuoti įva<strong>ir</strong>ių organizacijų profesinės etikos kodeksuose.Informacinių sistemų profesijoms artimiausiai esančios organizacijos yra ACM (angl.Association of Computing Machinery) <strong>ir</strong> DPMA (angl. Data Processing ManagementAssociation). Abi šios organizacijos turi etiško elgesio kodeksus <strong>ir</strong> jie yra gana panašūs.Plačiausiai žinomas yra ACM [ACM92] kodeksas programų sistemų kūrėjams. Programųsistemų kūrėjai turėtų:1) visada elgtis garbingai: nefalsifikuoti faktų apie savo kvalifikaciją; sąmoningai neskelbtineteisingų faktų apie esamą ar tikimąsi sistemos būklę; nepiktnaudžiauti konfidencialia arįmonės informacija; likti dėmesingais potencialiems konfliktams <strong>ir</strong> padėti juos spręsti;2) stengtis pastoviai gerinti savo profesinę kompetenciją: kurti sistemas, kurios vykdytųjoms numatytas funkcijas <strong>ir</strong> patenkintų vartotojų poreikius; padėti savo kolegoms d<strong>ir</strong>btiprofesionaliai;3) prisiimti tik tuos įgaliojimus, kurie priimtinai padeda siekti kuriamos sistemos tikslų;4) panaudoti savo profesines žinias visuomenės individų asmeniniam gyvenimui, sveikatai<strong>ir</strong> bendrai gerovei gerinti: d<strong>ir</strong>bdami su duomenimis, visada skaitytis su asmenų teise į asmeninįgyvenimą; susilaikyti nuo dalyvavimo projekte, jei tai galėtų sukelti neigiamas pasekmesvisuomenei.Atidžiai perskaičius šį kodeksą, galima pastebėti, kad į jį įeina tiek etikos, tiekprofesionalumo temos. Tam, kad atsk<strong>ir</strong>tume, kas yra etiškas elgesys <strong>ir</strong> kas yra profesinis elgesys,p<strong>ir</strong>miausia turime apsibrėžti etikos terminus <strong>ir</strong> juos susieti su informacinių sistemų profesijomis.Viskas, kas yra neetiška, yra <strong>ir</strong> neprofesionalu, bet ne atv<strong>ir</strong>kščiai. Profesionalumas yra platesnėtema negu etiškas elgesys. Anksčiau etikos kodeksai vadinosi profesinio elgesio kodeksai.Temos apie etiką daugiausiai susijusios su vartotojais <strong>ir</strong> labiausiai akivaizdžios duomenųsurinkimo veiklose.Taigi, kas yra etika? Etika - filosofijos šaka, studijuojanti moralinius sprendimus <strong>ir</strong> jųpagrindimus. Dilema - situacija, reikalaujanti rinktis tarp dviejų alternatyvų su galimomisnemaloniomis pasekmėmis. Taigi, etinė dilema yra situacija, kurioje sprendimas reikalaujamoralinio pagrindimo. IT pas<strong>ir</strong>odymas organizacijose pateikia naujas, mažai suprantamasgalimybes neetiškam elgesiui, apie kurias retai diskutuojama.Mokymo medžiaga 177
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaiEtika informacinėse technologijose - problema, kelianti vis didesnį susidomėjimą. ITvartotojai <strong>ir</strong> kūrėjai kartais patenka į ypatingas aplinkybes, sukeliančias dilemas, kurio turi būtigerai apgalvotos pasiekti etišką sprendimą. Viena iš problemų, susijusių su etika, yra ta, kadetika yra suprantama kaip religinis auklėjimas <strong>ir</strong> religinių minčių pritaikymas realiam gyvenimui.Tai nėra tiesa. Etiniai sprendimai <strong>ir</strong> pagrindimai yra paremti teisingumo <strong>ir</strong> naudingumofilosofijomis, tai yra, didžiausiu gėriu didžiausiam skaičiui žmonių. Etika reikalauja alternatyvųįvertinimo tikint žmonių lygybe <strong>ir</strong> kilnumu. Toliau aptarsime etiką, susijusią su duomenųrinkimų <strong>ir</strong> vartotojo sąveiką su programų kūrimu.Pagrindiniai etiniai principaiKonfidencialumas. Bet kokia interviu informacija yra konfidenciali, nebent asmuo, iškurio imamas interviu, yra informuojamas, kad jo kalba yra užrašinėjama(įrašinėjama). Jeiskleisite konfidencialią informaciją (“nešite šiukšles iš namų”), jūs ne tik neetiškai elgsitės,tačiau dėl to gali nukentėti <strong>ir</strong> jūsų karjera. Jei manote, kad privačiai sužinota informacija turėtųbūti paskleista, paklauskite asmens, ar jis sutinka, kad apie tai žinotų <strong>ir</strong> kiti. Jam leidus,konfidencialumo ribos yra pašalinamos, <strong>ir</strong> jūs galite laisvai aptarinėti tą informaciją.Išimtis yra tada, kai jūs sužinote apie neleistinus kieno nors veiksmus. Tada jūs laisvaigalite (<strong>ir</strong> turite) pranešti apie bet kokią nelegalią veiklą vadovams, kompanijos valdžiai ar netpolicijai, jei nesiimama jokių priemonių. Pagal įstatymus, jei jūs apie tai nepranešate, tampatenusikaltimo bendrininku.Slaptumas. Ekspertai turi teisę žinoti apie jų pat<strong>ir</strong>ties <strong>ir</strong> žinių panaudojimą programųkūrime. Pagrindinė taisyklė - elgtis taip, kaip norėtum, kad būtų elgiamasi su tavimi. Arnorėtumėte, kad kompanija stebėtų jūsų kompiuterių vartojimą <strong>ir</strong> kurtų sistemas, paremtas jūsųpat<strong>ir</strong>timi? Ypač daug etikos problemų dėl ekspertizių nuosavybės iškyla, kuriant ekspertinessistemas. Be leidimo negali būti jokių tyrimų <strong>ir</strong> stebėjimų (nei asmeniškai, nei kompiuteriu).Niekas negali būti priverstas bendradarbiauti. Dalyvavimas turi būti savanoriškas.Nuosavybė. Dabar kompiuteriai yra dalis bendro gyvenimo, todėl sunku suprasti, kam ištikrųjų priklauso resursai. Pamastę dauguma žmonių pripažįsta, kad kompanijai, kuriai priklausokompiuteriai, taip pat priklauso <strong>ir</strong> darbo su kompiuteriu laikas. Tačiau dažniausiai žmonės linkęmanyti, kad jei resursas neišnaudotas, jis iššvaistytas veltui, <strong>ir</strong> kad kompiuterių laikas yra kaiporas, tai yra, laisvas resursas, kuris sk<strong>ir</strong>tas tam, kad jį naudotum. Vykdomoji valdžia dažniausiainemano taip pat, nežiūrint ar yra kokia nors kompiuterinių resursų naudojimo politika.Reikėtų sužinoti kompanijos nuostatas apie kompiuterinių resursų naudojimą asmeninėmsreikmėms <strong>ir</strong> vadovautis jomis. Tokie veiksmai kaip programos kūrimas draugui, savo asmeniniųreikalų ruošimas gali būti etiški arba neetiški priklausomai nuo to, ką mano kompanijos vadovaiapie jiems priklausančių kompiuterinių resursų naudojimą.Mokymo medžiaga 178
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaiTuri būti aiškiai išsakyta, kam priklauso susiję su darbu produktai, kad jei jūs manote, kadkažkas teisėtai priklauso jums, taip pat mano <strong>ir</strong> klientas ar kompanija, taigi jūs nepasielgsiteneetiškai tai panaudodami. Painiavos dėl nuosavybės gali kilti dėl tokių dalykų kaip techninė arvartotojo dokumentacija, duomenys, programos išeities tekstai. Jei jūs d<strong>ir</strong>bate kokioje norsf<strong>ir</strong>moje <strong>ir</strong> kuriate programą pagal užsakymą, jūs neturite teisės jos parduoti kokiai nors kitaif<strong>ir</strong>mai. Ši teisė yra svarstytina <strong>ir</strong> priklauso tik klientui, jei nėra pabrėžtinai paminėta kontrakte.Išsiaiškinkite viską <strong>ir</strong> jums neteks būti atleistam iš darbo ar patrauktam į teismą dėl nuosavybėsteisių pažeidinėjimo.Pat<strong>ir</strong>tis, kurią įgaunate d<strong>ir</strong>bdami, yra intelektualinis turtas. Tai yra jūsų, nebent jūspas<strong>ir</strong>ašote tai paneigiantį kontraktą. Tačiau neetiška naudoti specifines jūsų kompanijos žiniasasmeniniams, konkurentiniams ar nekonkurentiniams finansiniams tikslams, jei nesate susitaręsu savo darbdaviu dėl tokio panaudojimo. Paprastai darbdaviai reikalauja neskleisti f<strong>ir</strong>mospatentuotos informacijos, tačiau kiekvienas gali sk<strong>ir</strong>tingai suprasti, kas būtent priklauso tokiaiinformacijai. Taip pat jums gali būti uždrausta naudoti tą informaciją 1-2 metus, jei darbdavysįrodo, kad tai kenkia jo verslui. Geriausia iš pat pradžių atv<strong>ir</strong>ai išsiaiškinti tokias problemas, kadvėliau nekiltų jokių konfliktų.Politika. Pasistenkite niekada neįsivelti į politines kovas. Tai lengviau nei atrodo, ypač jeijūs esate programų sistemų inžinierius ar projekto vadovas. Politika - valdžios mokslas,dažniausiai priklausantis nuo asmeninių motyvų. Organizacijose dauguma žmonių galvoja apief<strong>ir</strong>mos interesus darydami sprendimus, kiekvienas asmuo bent jau apsvarsto savo asmeninęsituaciją. Kai kurie asmenys p<strong>ir</strong>miausia siekia asmeninio pagerėjimo, net jei tai daro žaląkompanijai. Didelis savanaudiškumas nepaisant rezultatų kitiems asmenims ar kompanijai yraneetiška.Politinėse kovose kai kurie asmenys stengiasi manipuliuoti projekto rezultatais, siekdamipagerinti savo padėtį kompanijoje. Politiniai manevrai gali įgyti įva<strong>ir</strong>ias formas: melavimas,d<strong>ir</strong>btiniai reikalavimai, apgaulingas bendradarbiavimas ar sk<strong>ir</strong>tingos viešos <strong>ir</strong> privačios kalbos.PS inžinierius arba projekto vadovas turėtų atidžiai stebėti tokius pas<strong>ir</strong>eiškimus <strong>ir</strong> išmokti juosišsklaidyti.Informavimas apie problemas. Su klientu reikia aptarinėti susijusias su projektovykdymo tvarkaraščiu, biudžetu ar teisingumu bei kitas svarbias problemas, tačiau jo nereikiajaudinti smulkiomis problemomis, kurias galite išspręsti pats. Sprendžiant, kada informuotivartotoją apie problemas, reikėtų vadovautis sveiku protu. Vartotoją apie problemą reikia įspėtipakankamai anksti, kad žinotų, <strong>ir</strong> pakankamai vėlai, kad nebūtų jaudinamasi dėl niekų. Niekadanelaukite paskutinės minutės, kai nebebus nieko galima pataisyti, arba visi projekto dalyviaipraras pasitikėjimą. Visada paprašykite kliento pagalbos problemos sprendime, jei jau juosMokymo medžiaga 179
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaiinformavote. Savaitinių sus<strong>ir</strong>inkimų tikslas yra įvertinti projekto būklę <strong>ir</strong> nustatyti problemas <strong>ir</strong>numatyti jų sprendimus. Jei problema egzistuoja kelis mėnesius be jokio jos sprendimo, ji visadasukels plano <strong>ir</strong> biudžeto problemas. Jei klientas pastoviai informuojamas apie techninesproblemas, jisai taip netiesiogiai paruošiamas potencialiems kainos kilimams <strong>ir</strong> laikoužtęsimams. Apie projekto problemas turi būti informuojami <strong>ir</strong> visi projekto dalyviai.Asmeniniai metodai <strong>ir</strong> atsakomybė. Kai žmonės d<strong>ir</strong>ba bendrame projekte, jie kartaispraranda supratimą apie savo įnašą. Supratimas “laiku, telpant į kainą, teisingai” turi reikšmęprojektui, bet ne kiekvienam individualiam asmeniui, programuojančiam ar testuojančiam kokįnors modulį. Vienas iš PS inžinieriaus <strong>ir</strong> projekto vadovo uždavinių yra kiekvienam projektodalyviui išugdyti atsakomybės jausmą. Kiekvienas asmuo turėtų žinoti savo užduotis, biudžetą,sk<strong>ir</strong>tus resursus <strong>ir</strong> savo laiką. Kiekvienas turėtų būti atsakingas už savo terminus <strong>ir</strong> programas beklaidų. Atskaitomybę bendrame projekte lengva perkelti, <strong>ir</strong> pasidaro neaišku, kas yra atsakingas.Vieni sako, kad visada atsakingas projekto vadovas. Kiti - kad analitikai <strong>ir</strong> PS inžinieriai. Darkiti - kad niekas neatsakingas. Trumpas atsakymas yra toks, kad kiekvienas asmuo yra atsakingasuž nuosavą darbą <strong>ir</strong> jo integravimą į visą projektą.Nekalbėkite su savo vadovu, klientu ar darbuotojais apie darbo problemas nesusijusias suprojekto užbaigimu. Vadovai <strong>ir</strong> klientai nori atsakymų <strong>ir</strong> sprendimų, o ne problemų. Todėl jieturėtų būti informuojami apie projekto būklę <strong>ir</strong> problemas, kurios gali juos paveikti, o kitaisatvejais palikite juos ramybėje. Vadovų nedomina, kaip kokia nors spausdintoja ar dar kas norsžlugdo jūsų darbą. Jūs tai išsiaiškinkite <strong>ir</strong> pam<strong>ir</strong>škite. Jei yra problemų su kieno nors darbokokybe, p<strong>ir</strong>miausia aiškinkitės su tuo žmogumi, <strong>ir</strong> tik tada, jei nepasiseka, kalbėkite su jųvadovu. Kuo mažiau jūs kaltinsite <strong>ir</strong> kuo konkretesnis būsite, tuo mažiau atrodysite kaipverkšlentojas <strong>ir</strong> skundikas. Būkite tikras, kad galite paremti bet kuriuos jūsų pareikštuskaltinimus.Neetiška pasakoti klientui ar vadovui apie savo asmenines problemas, jei jūsų nesiejaasmeniniai ryšiai, nes visa kaltė visada gali būti suversta asmeninėms problemoms (“Nevercomplain, never explain”, Henry Ford). Jūsų pareiga darbe - d<strong>ir</strong>bti, taigi taip <strong>ir</strong> darykite.Neužmegzkite asmeninių ryšių su klientu. Jei pradeda megztis emocinis ryšys, tegu taipalaukia iki projekto pabaigos. Asmeniniai ryšiai lengvai užsimezga, kai esate kartu 10-15valandų per dieną daug mėnesių iš eilės. Jie taip pat lengvai linkę iš<strong>ir</strong>ti, kai tik prasideda naujasprojektas <strong>ir</strong> pradedama su kitais d<strong>ir</strong>bti 10-15 valandų per dieną. Asmeniniai ryšiai temdosprendimus <strong>ir</strong> jiems ne vieta įstaigoje.Niekada sąmoningai neklaidinkite kitų. Niekada nemeluokite. Nesuteikite vartotojuiklaidingų įspūdžių, supratimų ar kokios kitos informacijos, kuri jiems leistų įsivaizduoti geresnę,funkcionalesnę sistemą negu jūs planuojate padaryti. Vartotojai susidaro nuomonę pagal tai, kąMokymo medžiaga 180
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaijūs <strong>ir</strong> vadovai jiems sakote. Nepervertinkite sistemos galimybių. Tačiau, jei sistema kartais yranuvertinama, nepalikite klaidingų vilčių žmonėms, kad jų darbo vietos bus išsaugotos, jei žinote,kad taip nebus. Nekelkite aliarmo, bet <strong>ir</strong> nesuteikite neteisingų vilčių.Etinis sprendimų pagrindimasJei jūs susiduriate su problema, reikalaujančia etinio pagrindimo, reikia nustatyti visassuinteresuotas puses (t.y. asmenis, galinčius turėti arba žalos, arba naudos, priklausomai nuosprendimo), įvertinti visus galimus veiksmus <strong>ir</strong> pagrįsti visas alternatyvas. Čia pateikiamasvienas iš tokių metodų, bandantis atspindėti žmogaus mąstymą, sprendžiant problemas.Suinteresuotų pusių nustatymas. P<strong>ir</strong>miausia reikia nustatyti visus asmenis, galinčiusnukentėti arba pasipelnyti nuo jūsų sprendimo. Tai nelengva užduotis, ypač kai naudojamikompiuteriai, jūs galite nepažinoti visų tokių žmonių asmeniškai. Tai gali būti kompanijosakcininkai, kompanija, jūsų v<strong>ir</strong>šininkas, jūs, vartotojai, visuomenė ar žmonės, turintys kokį norskontaktą su kuriama programa (pvz., ligoninės pacientai, asmenys, gyvenantys šalia gamyklos,kurioje bus pradėta vykdyti programa, ataskaitų vartotojai, el. pašto adresatai, vyriausybė <strong>ir</strong> t.t.).Priimtinų veiksmų kiekvienai suinteresuotai pusei nustatymas. Dabar kiekvienaisuinteresuotai pusei nustatykite veiksmą, kuris jai būtų priimtiniausias. Ši užduotis nusako visusįmanomus veiksmus. Pradėkite nuo savęs. Ką jūs norėtumėte daryti? Koks geriausiassprendimas? Atsakykite į šiuos klausimus nuo kiekvienos suinteresuotų asmenų grupės.Pabandymas įsivaizduoti save kiekvieno iš jų vietoje reikalauja objektyvumo <strong>ir</strong> gebėjimopažiūrėti į problemą iš šalies.Alternatyvų eliminavimas. Nustatykite, ar nėra kokių nors procedūrų, įstatymų ar kitųnuostatų, kurioms prieštarautų kurios nors alternatyvos. Išbraukite tas alternatyvas. Visadaatsižvelkite į šalies, kurioje esate, <strong>ir</strong> šalies, kurią atstovaujate, įstatymus.Kompanijų veiklos procedūros <strong>ir</strong> normos (“procedures and policies”) yra panašūs elgesiokodeksuose, bet gali sk<strong>ir</strong>tis griežtumu, baudžiant už pažeidimus. Už rimtus pažeidimusdažniausiai atleidžiama iš darbo (“policy”). Už kitokius pažeidimus baudžiama ne taip griežtai(“procedures”). Jūs galite gauti oficialų papeikimą, kad nesilaikėte tam tikrų nuostatų.Profesionalumo <strong>ir</strong> etikos kodeksų nuostatos taip pat padeda valdyti savo elgesį darbe. Užetikos kodekso nesilaikymą nėra tiesioginių bausmių. Jūs galite būti atleistas arba paduotas įteismą, bet tai nėra profesinės organizacijos bausmė.Neigiamų rezultatų alternatyvų įvertinimas. Peržiūrėkite alternatyvų sąrašą, pateikdamiklausimus, reiškiančius neigiamus pas<strong>ir</strong>inkimo rezultatus. Jei į bent vieną iš tų klausimųatsakysite “taip” (teigiamai), išbraukite tą alternatyvą iš sąrašo. Pavyzdžiui.: Ar šiuo veiksmupažeidžiamos kieno nors teisės? Apsvarstykite teises į asmeninį gyvenimą, turėjimą informacijosapie kieno nors p<strong>ir</strong>kimo, mokėjimo būdus, pajamas, mokesčius <strong>ir</strong> panašiai. ApsvarstykiteMokymo medžiaga 181
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaikompanijos teises į finansinę, klientų, personalo, medicininę <strong>ir</strong> kitą konfidencialią informaciją.Pasidomėkite, ar dėl apsaugos trūkumo privatūs klientų duomenys, saugomi duomenų bazėje,nebus prieinami atsitiktiniams žmonėms. Tam kelias turi būti užk<strong>ir</strong>stas.Ar šiuo veiksmu nesielgiama neteisingai su asmeniu ar grupe? Tarptautinėse kompanijoseneteisingumas gali būti traktuojamas kaip verslo sprendimas. Nemažai JAV korporacijų įėjo įtarptautinį verslą siųsdamos blogesnės kokybės gaminius į svetimą rinką. Ar tai buvo etiška?Atsakymas priklauso nuo to, kaip tai buvo padaryta. Jai daiktai buvo pardavinėjami kaipprastesnės kokybės, tai problemos nebuvo. Jei buvo teigiama, kad tai aukščiausios kokybėsdaiktai, kompanijos melavo <strong>ir</strong> elgėsi neetiškai.Ar šiuo veiksmu su jokiu žmogumi ar kompanija nepasielgiama finansiškai, fiziškai,teisiškai ar moraliai rizikingai? Nuo ligoninių programų sistemos, kurios prižiūri pacientus,transporto pramonės sistemų, kurios gali paveikti traukinių arba lėktuvų saugumą, priklausožmonių gyvybės. Tokio programų sistemos yra reikalingos, bet jos turi būti aukščiausioskokybės, kad būtų mažiausiai rizikuojama žmonių gyvybėmis. Jei yra nukertami kampaianalizuojant, projektuojant ar testuojant, gali būti prarandami žmonės.Teigiamų rezultatų alternatyvų įvertinimas. Likusioms alternatyvoms pateikiteklausimus apie teigiamus rezultatus <strong>ir</strong> išs<strong>ir</strong>inkite geriausią. Ar šis veiksmas geriausiai veiks visussuinteresuotus asmenis? O kas bus, jei nesiimsite jokių veiksmų? Jei yra alternatyvos tik suneigiamais rezultatais, ar ši alternatyva visiems sukelia mažiausiai žalos? Jei taip, kas nukenčia <strong>ir</strong>kaip? Jei asmuo yra įspėjamas, ar gali problema būti pašalinta?Tinkamiausio veiksmo pas<strong>ir</strong>inkimas. Kai apsvarstyti visi pliusai <strong>ir</strong> minusai, pas<strong>ir</strong>inkitealternatyvą, kuri suteikia naudos daugiausiai žmonių, nepažeidžia niekieno teisių <strong>ir</strong> siūloteisingiausią sprendimą.Teisiniai programų sistemų inžinerijos aspektaiTeisiniai veiksniai turi didelę įtaką <strong>ir</strong> kuriamai programų sistemai, <strong>ir</strong> jos kūrimo projektui.Įstatymai, vyriausybės nutarimai, organizacijų statutai <strong>ir</strong> kiti normatyviniai dokumentai nustatofunkcijas, kurios gali būti kompiuterizuojamos, <strong>ir</strong> duomenis, kurie gali būti renkami beikaupiami, daro poveikį duomenų rinkimo <strong>ir</strong> saugojimo technologijai, duomenų bazių struktūraibei tų bazių valdymo tvarkai, rezultatų pateikimo formai, techninės įrangos parinkimui, sistemosdiegimui <strong>ir</strong> projekto valdymui. Galimos teisinės rizikos veiksniai taip pat yra esminiai.Technologinių procesų valdymo sistemų, bankų kompiuterizavimo sistemų <strong>ir</strong> daugelio kitųsistemų padaryta žala gali būti gana didelė. Be to, ji gali būti siejama su baudžiamąjaatsakomybe. Todėl kuriant svarbias programų sistemas, reikia pasitarti su patyrusiu juristu,nustatyti <strong>ir</strong> išnagrinėti visus teisinės rizikos veiksnius <strong>ir</strong> numatyti atitinkamas apsaugospriemones.Mokymo medžiaga 182
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaiFormuluojant funkcinius programų sistemų reikalavimus, būtina atsižvelgti į konstitucinįįstatymų leidžiamosios, vykdomosios <strong>ir</strong> teisminės valdžių atskyrimo principą. Įstatymai nustatokiekvienos institucijos kompetencijos ribas, t.y. nustato, ką ta institucija gali daryti <strong>ir</strong> ko ne.Valstybinės <strong>ir</strong> savivaldos institucijos turi tik tuos įgaliojimus, kurie joms yra deleguoti. Privačiosinstitucijos negali užsiimti veikla, nenumatyta jų įstatuose. Institucijose naudojamos programųsistemos negali tų apribojimų pažeisti. Tai liečia <strong>ir</strong> renkamus, apdorojamus bei platinamusduomenis, <strong>ir</strong> sistemos vykdomas funkcijas. Teismas, nustatęs, kad institucija, naudodama tamtikrą programų sistemą, v<strong>ir</strong>šija savo įgaliojimus, gali sustabdyti tos institucijos veiklą arbapripažinti tą veiklą nekonstitucine.Formuluojant funkcinius reikalavimus, būtina atsižvelgti <strong>ir</strong> į kitus teisinius apribojimus.Pavyzdžiui, jei kuriama programų sistema bus naudojama pelno nesiekiančioje organizacijoje,tai reikia išanalizuoti, ar ta sistema kaip nors nepažeis tos organizacijos turimo statuso. Kitaspavyzdys - asmens duomenų apsaugos <strong>ir</strong> mokesčių įstatymai. Dėl jų gali tekti skaidyti į daliskuriamas duomenų bazes, kartais net <strong>ir</strong> pačias sistemas. Asmens duomenų apsaugos reikalavima<strong>ir</strong>iboja spausdinamų duomenų apimtį <strong>ir</strong> turinį, reglamentuoja duomenų rinkimo būdus <strong>ir</strong> jųapdorojimo procedūras. Pavyzdžiui, JAV įstatymai nustato, koks turi būti personalo duomenųbazėje saugomo įrašo apie darbuotoją formatas, reglamentuoja įrašų apie profesinius sus<strong>ir</strong>gimus<strong>ir</strong> sužalojimus kompiuterinio apdorojimo būdus.Mokesčių <strong>ir</strong> kiti su jais susiję įstatymai nustato pelno kontrolės procedūras <strong>ir</strong> finansinės beibuhalterinės apskaitos vedimo taisykles. Tos taisyklės yra privalomos <strong>ir</strong> vedant apskaitąkompiuterizuotu būdu. Kai kurių šalių įstatymai reikalauja, kad mokestiniai dokumentai būtųrengiami taip, jog juos galėtų skaityti kompiuteris, reglamentuoja magnetinių laikmenųformatavimo būdus, saugomų duomenų struktūrą <strong>ir</strong> saugojimo formatą. Reikalaujama numatytisistemoje audito trasas, dokumentuoti sistemą tam tikru nurodytu būdu, archyvuoti tam tikrusnurodytus duomenis. Teisiniai reikalavimai turi didelę įtaką <strong>ir</strong> rezultatų pateikimo pavidalui. Kaikurių dokumentų forma yra griežtai nustatyta, į kitus dokumentus reikalaujama rašyti tik tamtikrus duomenis. Pažeidus šiuos reikalavimus, dokumentai praranda savo teisinę galią.Daugelyje šalių teismai pripažįsta kompiuteriniu būdu parengtus dokumentus tik tuomet,kai juos sugeneravusios programos yra dokumentuotos atitinkamu būdu <strong>ir</strong> galima patikrintidokumento parengimo vietą, laiką <strong>ir</strong> jam rengti naudotus šaltinius. Tokio dokumentopatikimumas gali priklausyti nuo programų sistemos apsaugos mechanizmo ypatumų <strong>ir</strong>veiksmingumo.Pažymėsime, kad programų sistemos dokumentacija yra svarbi <strong>ir</strong> baudžiamosiosatsakomybės požiūriu. Jei naudojant programų sistemą padaroma žala, tenka aiškintis, kas yraMokymo medžiaga 183
Programų sistemų inžinerija13. Profesiniai, teisiniai <strong>ir</strong> etiniai aspektaikaltas: programų sistemos kūrėjai ar tos sistemos naudotojai. Jei to patikrinti neįmanoma,dažniausiai yra apkaltinami programų autoriai.Didelę įtaką programų sistemai gali turėti <strong>ir</strong> telekomunikacijų bei ryšių įstatymai.Duomenų perdavimo maršrutai, tarifai <strong>ir</strong> kiti panašaus pobūdžio veiksniai lemia daugelįprogramų sistemos reikalavimų.Reikia atsižvelgti <strong>ir</strong> į tai, kad programų sistema nepažeistų konkurencijos įstatymo. Ypačtai aktualu sistemoms, kurios keičiasi informacija arba ją platina. Projektuojant tokias sistemas,reikia užtikrinti, kad nebūtų atskleistos komercinės paslaptys, informaciją apie vieną varžovąnebūtų prieinama kitam varžovui. Ypač turi būti saugoma informacija apie būsimas kainas arbajų kitimo tendencijas. Niekam negali būti prieinama statistinė ar analitinė informacija, galintipaveikti kainas.Čia aptarėme tik pačius bendriausius teisinius aspektus. Kadangi normatyviniaidokumentai kiekvienai dalykinei sričiai yra kiti, tai teisiniai veiksniai kiekvienai dalykinei sričiaitaip pat sk<strong>ir</strong>iasi.Literatūra papildomam skaitymui[IEEE99] Software Engineering Code of Ethics and Professional Practice as recommendedby the IEEE-CS/ACM Joint Task Force on Software Engineering Ethics andProfessional Practices. http://seeri.etsu.edu/Codes/TheSECode.htm[ACM92]ACM Code of Ethics and Professional Conduct, Adopted by ACM Council10/16/92. http://www.acm.org/about/code-of-ethicsMokymo medžiaga 184
Programų sistemų inžinerijaKontroliniai klausimaiProgramų sistemų inžinerijos kontrolinių klausimų pavyzdžiai1. Ar yra sąlygos, kuriose nuoseklus (waterfall) gyvavimo ciklo modelis tinka geriausiai?Jei NE, argumentuokite kodėl. Jei TAIP, nurodykite tokias sąlygas.2. Palyginkite sistemų inžineriją (system engineering) <strong>ir</strong> programų sistemų inžineriją(software engineering).3. Išvardinkite programinės įrangos gyvavimo ciklo procesų kategorijas, apibrėžtasISO/IEC 122074. Kas yra organizacijos programų kūrimo proceso įvertinimo pagal CMMI pakopinį modelįrezultatas?5. Kas yra organizacijos programų kūrimo proceso įvertinimo pagal ISO/IEC 15504rezultatas?6. Nurodykite pakopinių <strong>ir</strong> tolydinių programų kūrimo procesų modelių pliusus <strong>ir</strong> minusus7. Organizacija įvertinta 5-u lygiu pagal CMMI pakopinį modelį. Koks bus jos įvertinimaspagal CMMI tolydinį modelį <strong>ir</strong> kodėl?8. Kokias pagrindines (bazines) metrikas naudoja PSP?9. Kam TSP naudojamas užd<strong>ir</strong>btos vertės (earned value) metodas? Paaiškinkite jo esmę.10. Pateikite judriųjų programų sistemų kūrimo metodikų manifeste (Agile SoftwareDevelopment Manifesto) suformuluotus principus11. Pateikite XP (eXtreme Programming) praktikas12. Paaiškinkite laiko skaidymo intervalais (time boxing) metodo, naudojamo, pvz., DSDM,esmę.13. Įvardinkite bent vieną moterų indėlį į programų sistemų inžineriją.14. Kam naudojamas bazinių kelių (basis path) metodas? Paaiškinkite jo esmę.15. Koks esminis sk<strong>ir</strong>tumas tarp baltos dėžės (white box) <strong>ir</strong> juodos dėžės (black box)testavimo metodų?16. Kokiais principais remiantis sudaromi testai Cleanroom metodikoje?17. Kas yra COCOMO? Kam jis naudojamas?18. Kas yra TMM? Kam jis naudojamas?19. Kas yra scenarijai (use-case)? Kam jie naudojami? Kaip jie gali būti apibrėžiami (kokiagali būti naudojama notacija)?20. Kokiais kriterijais remiantis prioritetizuojamos rizikos?Mokymo medžiaga 185
Change language