Program ų sistem ų inžinerija - mif.vu.ltragaisis/PSI_mag2007/PSI.pdf · Standartas ISO/IEC 15504 ... Scrum ... t.y. pagal Lietuvoje naudojam ą moksl ų klasifikacij ą ji apima

EUROPOS SĄJUNGA Europos socialinis fondas

KURKIME ATEITĮ DRAUGE!

Saulius Ragaišis

Programų sistemų inžinerija

Mokymo medžiaga

Vilnius 2007

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ų ir inovacijų srityje”, finansuojamą

Europos Sąjungos struktūrinių fondų lėšomis ir Lietuvos Respublikos bendrojo finansavimo

lėšomis.


Mokymo medžiaga 3

Turinys

Pratarmė ..........................................................................................................................................6

1. Programų sistemų inžinerijos samprata.......................................................................................7

2. Programinės įrangos gyvavimo ciklo procesai pagal standartą ISO/IEC 12207 ......................13 Procesų kategorijos ...............................................................................................................15 Procesų apibrėžimai ..............................................................................................................17 Kūrimo proceso apibrėžimas veiklomis ir užduotimis..........................................................17 Kūrimo proceso apibrėžimas tikslais ir rezultatais ...............................................................18 Įsigijimo proceso apibrėžimas...............................................................................................19

3. Programų kūrimo procesas........................................................................................................28 Esminės sąvokos .......................................................................................................................32 Standartas ISO/IEC 15504 ........................................................................................................34

Procesų gebėjimo matavimo karkasas...................................................................................34 Reikalavimai procesų modeliui .............................................................................................38 Reikalavimai vertinimo modeliui..........................................................................................39

4. Integruotas gebėjimo brandos modelis......................................................................................43 CMM atsiradimas......................................................................................................................43 CMMI struktūra.........................................................................................................................44 Pakopinės architektūros CMMI modelis...................................................................................47 Tolydinės architektūros CMMI modelis ...................................................................................49 Bendra proceso sričių struktūra.................................................................................................51 Atitikimas tarp organizacijos brandos lygio ir proceso sričių gebėjimo lygių..........................53 Vertinimas pagal CMMI ...........................................................................................................54

SCAMPI: standartinis vertinimo pagal CMMI proceso gerinimui metodas.........................55

5. Programų kūrimo proceso modelių sąryšis ...............................................................................59

6. Projektas PKP Branda ...............................................................................................................63 Brandaus programų kūrimo proceso modelis............................................................................63 Programų kūrimo proceso gerinimo metodika..........................................................................66

Nagrinėti organizacijos verslo tikslus ...................................................................................67 Inicijuoti proceso gerinimą....................................................................................................68 Atlikti proceso vertinimą.......................................................................................................69 Sudaryti veiksmų planą .........................................................................................................71 Įgyvendinti gerinimo veiksmus.............................................................................................72 Patvirtinti proceso pakeitimus...............................................................................................72 Paskleisti proceso pakeitimus................................................................................................73 Stebėti proceso vykdymą ......................................................................................................73

Programų kūrimo proceso instrumentinės priemonės ...............................................................73

7. Asmeninis programų kūrimo procesas ......................................................................................80 PSP atsiradimas .........................................................................................................................80 PSP modelis...............................................................................................................................80 PSP apimtis ...............................................................................................................................81 PSP struktūra .............................................................................................................................82

PSP metrikos .........................................................................................................................82 PSP kokybės modelis ............................................................................................................83 PSP prognozavimo modelis ..................................................................................................83 PSP tobulinimo modelis ........................................................................................................83 Pagrindiniai principai ............................................................................................................83 PSP praktikos ........................................................................................................................84

PSP principų ir praktikų sąryšiai ...........................................................................................89 PSP mokymų įtakos asmeniniam procesui tyrimai ...................................................................91 PSP proceso taikymo pramonėje pavyzdžiai ............................................................................93 PSP proceso duomenų kokybės problema ..............................................................................100

8. Komandinis programų kūrimo procesas .................................................................................103 TSP projektiniai sprendimai....................................................................................................103 TSP struktūra ir eiga................................................................................................................104 Pagrindiniai TSP principai ......................................................................................................115 TSP praktikos ..........................................................................................................................116 TSP principų ir praktikų sąryšiai.............................................................................................126 TSP taikymų praktikoje rezultatų analizė ...............................................................................127

PSP ir TSP taikymų patirties analizės išvados ....................................................................129

9. Testavimo brandos modelis.....................................................................................................131 TMM struktūra ........................................................................................................................134 TMM vertinimo modelis .........................................................................................................135

Vertinimo komandos parinkimas ir apmokymas ................................................................136 Vertinimo procedūra ...........................................................................................................136 Vertinimo klausimynas .......................................................................................................137

Išvados.....................................................................................................................................138

10. Judriosios programų kūrimo metodikos................................................................................140 Judriųjų programų kūrimo metodikų manifestas ....................................................................140 Ekstremalus programavimas ...................................................................................................142

XP procesas .........................................................................................................................142 Pagrindinės XP vertybės .....................................................................................................143 XP praktikos........................................................................................................................144

DSDM .....................................................................................................................................145 DSDM procesas...................................................................................................................146 Pagrindiniai DSDM principai..............................................................................................147 Pagrindiniai DSDM metodai...............................................................................................148

Scrum ......................................................................................................................................150 Crystal .....................................................................................................................................152 Judriųjų ir planais paremtų metodų derinimas ........................................................................152

11. Projekto valdymas pagal PMBOK ........................................................................................157 Kas yra projektas? ...................................................................................................................157 Kas yra projektų valdymas? ....................................................................................................159 Projektų valdymo žinių sritys..................................................................................................160 Projekto valdymo procesų grupės ...........................................................................................163

Projekto integravimo valdymas...........................................................................................163 Projekto apimties valdymas ................................................................................................164 Projekto laiko valdymas ......................................................................................................165 Projekto kainos valdymas....................................................................................................165 Projekto kokybės valdymas.................................................................................................165 Projekto žmogiškųjų resursų valdymas...............................................................................166 Projekto komunikavimo valdymas......................................................................................166 Projekto rizikos valdymas ...................................................................................................167 Projekto įsigijimų valdymas................................................................................................167

12. Vadovavimas programų sistemų projektams ........................................................................169 Programų sistemų projekto lyderis..........................................................................................169

Lyderio tikslai .....................................................................................................................169 Lyderio įsitikinimas.............................................................................................................169

Lyderiai ir jų pasekėjai ........................................................................................................169 Transformacinis lyderiavimas .............................................................................................169 Pareigybinis lyderiavimas ...................................................................................................170 Lyderiavimas iš apačios ......................................................................................................171 Lyderio vizija ......................................................................................................................171 Techninių profesionalų lyderis............................................................................................171

Įsipareigojimų etika.................................................................................................................172 Įsipareigojimų elementai .....................................................................................................172 Atsakingų įsipareigojimų sudarymas ..................................................................................173 Įsipareigojimai ar kryžiaus žygiai? .....................................................................................173 Per griežti įsipareigojimai ...................................................................................................173 Vadovybės įsipareigojimai..................................................................................................174 Įsipareigojimų keitimas .......................................................................................................174 Kruopštus darbo atlikimas...................................................................................................175 Įsipareigojimų etikos kūrimas .............................................................................................175 Įsipareigojimų nuosavybė ...................................................................................................175

13. Profesiniai, teisiniai ir etiniai aspektai ..................................................................................177 Pagrindiniai etiniai principai ...................................................................................................178 Etinis sprendimų pagrindimas.................................................................................................181 Teisiniai programų sistemų inžinerijos aspektai .....................................................................182

Programų sistemų inžinerijos kontrolinių klausimų pavyzdžiai .................................................185

Programų sistemų inžinerija Pratarmė

Mokymo medžiaga 6

Pratarmė

Šį mokymo medžiaga skirta informatikos krypties magistrantūros gilinamajam programų

sistemų inžinerijos kursui. Daroma prielaida, kad klausytojai jau yra išklausę bakalauro lygmens

programų sistemų inžinerijos pagrindų kursą.

Daugiausiai dėmesio skiriama temoms, susijusioms su programų kūrimo procesu, nes šioje

programų sistemų inžinerijos srityje labiausiai vystomi moksliniai tyrimai VU MIF.

Pirmiausia aptariama programų sistemų inžinerijos samprata, jos vieta tarp kitų disciplinų

ir pagrindinės žinių sritys. Antrame skyriuje pateikiami programinės įrangos gyvavimo ciklo

procesų apibrėžimai standarte ISO/IEC 12207.

Trečiasis skyrius pradeda programų kūrimo proceso nagrinėjimą. Pirmiausia apibrėžiamos

pagrindinės sąvokos, tada pristatomi labiausiai pasaulyje paplitę proceso modeliai ISO/IEC

15504 ir CMM/CMMI bei naujausi jų sąryšių tyrimų rezultatai.

Šeštame skyriuje aptariami pagrindiniai VU, KTU ir pirmaujančių Lietuvos IT įmonių

„Alna“ ir „Sintagma“ atlikto projekto „Brandaus programų kūrimo proceso įdiegimo metodikos

ir instrumentinių priemonių sukūrimas (PKP Branda)“ rezultatai: brandaus programų kūrimo

proceso modelis, proceso gerinimo metodika ir ją palaikančios instrumentinės priemonės.

Septintame ir aštuntame skyriuose nagrinėjami asmeninis ir komandinis programų kūrimo

procesai atitinkamai, o devintame skyriuje pateikiamas specializuoto gebėjimų brandos modelių

pavyzdys, skirtas testavimui.

Paskutinį dešimtmetį pasaulyje labai išpopuliarėjo judriosios programų kūrimų metodikos,

kurių pristatymui skirtas dešimtas skyrius.

Esminis vaidmuo programų sistemų kūrime tenka projektų valdymo veikloms, todėl

pirmiausia išnagrinėjami pagrindiniai bet kokių projektų valdymo procesai, apibrėžti de facto

standartu tapusiame PMBOK, o po to aptariamas vadovavimas programų sistemų projektams.

Paskutinis skyrius skirtas profesiniams, etiniams ir teisiniams programų sistemų inžinerijos

aspektams, kurie tradiciškai ignoruojami Lietuvoje teikiamose studijų programose.

Programų sistemų inžinerija 1. Programų sistemų inžinerijos samprata

Mokymo medžiaga 7

1. Programų sistemų inžinerijos samprata

Pirmiausia apibrėšime, kas yra informatika1 (angl. Computing) ir kokią vietą joje užima

programų 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ą ir kūrimą techninės įrangos

bei įvairios paskirties programų sistemų; apdorojimą, struktūrizavimą ir valdymą įvairių tipų

informacijos; mokslinius tyrimus naudojantis kompiuteriais; kūrimą intelektualių kompiuterinių

sistemų; naudojimą ir kūrimą komunikavimo bei laisvalaikio priemonių; radimą ir surinkimą

kažkuriam tikslui reikalingos informacijos ir taip toliau. Šis sąrašas yra begalinis, o galimybės

neišmatuojamos.“.

Informatikoje išskiriamos 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).

Skirtumai tarp šių disciplinų ir tai, kam kiekvienoje iš jų skiriama daugiausiai dėmesio,

aiškiai matomi iš diagramų, pateiktų 1.1 ir 1.2 paveikslėliuose, bet pradiniam įspūdžiui susidaryti

trumpai apibūdinkime jas visas.

Kompiuterių inžinerija nagrinėja kompiuterių ir jų sistemų projektavimą ir kūrimą,

pagrindinį dėmesį skirdama techninei ir įdėtinei programinei įrangai (angl. Embedded Software).

Kompiuterių mokslas apima plačią sritį nuo teorinių ir algoritminių pagrindų iki įvairiausių

taikymų. Visą veiklą galima būtų suskirstyti į 3 sritis: programinės įrangos projektavimas ir

kūrimas; naujų kompiuterių taikymų paieška (pvz., tokių tyrimų rezultate atsirado WWW);

efektyvių sprendimų paieška (pvz., duomenų bazės efektyviam informacijos saugojimui ir

apdorojimui). Kompiuterių mokslo studijų programose akcentuojamas ne pasiruošimas

konkrečiam darbui, bet pagrindai, įgalinantys pereiti prie naujų technologijų ir idėjų.

Informacinių sistemų pagrindinis sprendžiamas uždavinys yra organizacijos informacinių

poreikių patenkinimas diegiant informacines technologijas į verslo procesus. Ši disciplina

pagrindinį dėmesį skiria informacijai, verslo poreikiams, o technologijas nagrinėja kaip

priemones verslo tikslams pasiekti. Informacinių sistemų specialistams tenka esminis vaidmuo

1 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 tiek informatikos, tiek informatikos inžinerijos mokslų sritis. Lietuvoje informatika dažnai naudojama žymiai siauresne prasme (pavyzdžiui, Informatikos studijų programa), kuri atitinka klasikinį kompiuterių mokslą (angl. Computer

Science).


Mokymo medžiaga 8

apibrėžiant reikalavimus organizacijos informacinei sistemai, jie dalyvauja ir sistemos

specifikavime, projektavime bei kūrime.

Kompiuterių techninėįranga ir architektūra

Sistemų infrastruktūra

Programų kūrimometodai ir technologijos

Taikymų technologijos

Organizaciniai aspektaiir informacinės sistemos

TeorijaPrincipaiInovacijos

TaikymasDiegimas

KonfigūravimasLabiau teorinis Labiau taikomasis

Kūrimas

Kompiuterių inžinerija







TaikymasDiegimas


Kūrimas

Kompiuterių mokslas

Informacinės sistemos







TaikymasDiegimas


Kūrimas

Informacinės technologijos







TaikymasDiegimas


Kūrimas








TaikymasDiegimas


Kūrimas

1.1 pav. Disciplinų nagrinėjamos sritys [CC2005]

Terminas informacinės technologijos (IT) naudojamas dviem prasmėm. Plačiąja prasme jis

apima visą informatikos (angl. Computing) sritį. Siaurąja prasme jis apibrėžia discipliną,

sprendžiančią kompiuterių naudojimo organizacijose problemas. Tikslai yra labai panašūs kaip

informacinių sistemų disciplinos, bet iš esmės skiriasi požiūris - IT atveju pagrindinis dėmesys

yra skiriamas technologijoms, be kurių organizacijų veikla kuo toliau tuo labiau darosi

neįmanoma: reikalingos tinkamos sistemos, jos turi korektiškai veikti, būti saugios, reikia jas

palaikyti, atnaujinti. Kitaip sakant, organizacijoms reikia specialistų, sugebančių spręsti visas

joms iškylančias su kompiuteriais susijusias problemas.


Mokymo medžiaga 9

Kompiuterių inžinerija

Informacija

Valdymas

Programinė įranga

Organizacijos ir verslas

Fizika

30 %

25 %

20 %

15 %

10 %

5 %Matematika

Informatikos teorija

Techninė įranga irarchitektūra

Infrastruktūra

Žmonės

Kompiuterių mokslas

Informacija

Valdymas

Programinė įranga


Fizika

30 %

25 %

20 %

15 %

10 %

5 %Matematika



Infrastruktūra

Žmonės

Informacinės sistemos

Informacija

Valdymas

Programinė įranga


Fizika

30 %

25 %

20 %

15 %

10 %

5 %Matematika



Infrastruktūra

Žmonės

Informacinės technologijos

Informacija

Valdymas

Programinė įranga


Fizika

30 %

25 %

20 %

15 %

10 %

5 %Matematika



Infrastruktūra

Žmonės


Informacija

Valdymas

Programinė įranga


Fizika

30 %

25 %

20 %

15 %

10 %

5 %Matematika



Infrastruktūra

Žmonės

1.2 pav. Disciplinų nagrinėjamos sritys [Kon06]

Programų sistemų inžinerija atsirado kaip kompiuterių mokslo sritis, kai patikimų sistemų,

skirtų sudėtingų uždavinių sprendimui, kūrimas darėsi vis sunkesnis – vienas žmogus nebegalėjo

aprėpti visos programos. Sistemos pradėtos naudoti ir kritinėse veiklose, kuriose netgi vienintelė


Mokymo medžiaga 10

programos klaida gali baigtis žmonių sužalojimu ar mirtimi. Tapo aišku, kad gerų programų

kūrimas yra labai sudėtingas, labai brangus, bet labai reikalingas.

Kiekvienai iš penkių disciplinų ir jos bakalauro lygmens2 studijų programoms apibrėžti yra

skirtos atskiros Computing Curricula 2005 dalys. Programų sistemų inžinerijai skirta 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 ir kiti mokslai) koncentruojasi į naujų žinių kūrimą, o

programų sistemų inžinerija (kaip ir kitos inžinerinės disciplinos) koncentruojasi į apibrėžimą

metodų projektavimui ir kūrimui patikimų „daiktų“, atliekančių tai, kam jie buvo skirti.

Programų sistemų inžinerija yra disciplina, tirianti kūrimą ir priežiūrą programų sistemų,

veikiančių patikimai ir efektyviai bei tenkinančių visus užsakovų joms iškeltus reikalavimus. Ji

iš esmės skiriasi nuo kitų inžinerijos disciplinų tuo, kad kuriami produktai (programų sistemos)

yra nematerialūs (neapčiuopiami), o jų naudojimo sritys begalinės. Ji siekia apjungti

matematikos ir kompiuterių mokslo principus su inžineriniais metodais, skirtais materialių

produktų kūrimui.

Kompiuterių mokslo ir programų sistemų studijų programos turi daug bendrų kursų, bet

programų sistemų inžinerijoje yra labiau akcentuojami sistemų kūrimo ir priežiūros metodai,

užtikrinantys jų naudojamumą ir patikimumą; net rekomenduojama, kad studijų metu būtų

dalyvaujama kūrime realios sistemos, kurią naudos kiti, taip formuojant supratimą ir įgūdžius

suprasti užsakovų poreikius ir sukurti juos tenkinančią sistemą.

Pagrindinis programų sistemų inžinerijos tikslas yra sukurti modelius ir patikimus metodus

kūrimui kokybiškų sistemų laiku ir su numatytu biudžetu, apimant tiek teoriją, tiek jos taikymą

praktikoje.

Projektas SWEBOK

Detalesnę programų sistemų inžinerijos sampratą galima susidaryti iš IEEE Computer

Society iniciatyva yra vykdomos projekto SWEBOK (angl. SoftWare Engineering Body Of

Knowledge) [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 skirtinguose universitetuose rasti vienodas magistro lygmens studijų programas.


Mokymo medžiaga 11

3. Geležies amžiaus žmogaus versija (angl. Iron Man Version) 2004 metais.

SWEBOK išskiriamos pagrindinės žinių sritys ir įvardinamos esminės temos (1 lentelė), nurodoma svarbiausia literatūra ir joje nagrinėjamos temos.

Nr. Žinių sritis ir esminės jos temos 1 Programų sistemų reikalavimai (angl. Software Requirements):

- Reikalavimų pagrindai (angl. Software Requirements Fundamentals) - Reikalavimų procesas (angl. Requirements Process) - Reikalavimų išgavimas (angl. Requirements Elicitation) - Reikalavimų analizė (angl. Requirements Analysis) - Reikalavimų specifikavimas (angl. Requirements Specification) - Reikalavimų validavimas (angl. Requirements 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 ir architektūra (angl. Software Structure and Architecture) - Projekto kokybės analizė ir vertinimas (angl. Software Design Quality Analysis and

Evaluation) - Projektavimo notacijos (angl. Software Design Notations) - Projektavimo strategijos ir 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 ir pateikimas (angl. Software Configuration

Release Management and Delivery) 7 Programų sistemų projektų valdymas (angl. Software Engineering Management):

- Inicijavimas ir apimties apibrėžimas (angl. Initiation and Scope Definition) - Projekto planavimas (angl. Software Project Planning) - Projekto vykdymas (angl. Software Project Enactment) - Peržiūra ir vertinimas (angl. Review and Evaluation) - Uždarymas (angl. Closure) - Programų inžinerijos matavimai (angl. Software Engineering Measurement)


Mokymo medžiaga 12

Nr. Žinių sritis ir esminės jos temos 8 Programų sistemų kūrimo procesas (angl. Software Engineering Process):

- Proceso įgyvendinimas ir keitimas (angl. Process Implementation and Change) - Proceso apibrėžimas (angl. Process Definition) - Proceso vertinimas (angl. Process Assessment) - Proceso ir produkto matavimai (angl. Process and Product Measurement)

9 Programų sistemų metodai ir įrankiai (angl. Software Engineering Tools and Methods): - Reikalavimų įrankiai (angl. Software Requirements 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) - Įvairialypiai į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] Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree

Programs in Software Engineering. A Volume of the Computing Curricula Series.

ACM and IEEE, 2004. http://sites.computer.org/ccse/

[Kon06] Karoly Kondorosi, Towards a Common Frame for European CS/Informatics

Education. euroTICS2006, 17 October 2006.

http://www.informatics-europe.org/talks/Kondorosi_eurotics_2006.pdf

[SWEBOK] Guide to the Software Engineering Body of Knowledge, 2004 Version, SWEBOK®. IEEE, 2004. http://www.swebok.org/.

Programų sistemų inžinerija 2. Programinės įrangos gyvavimo ciklo procesai

Mokymo medžiaga 13

2. Programinės įrangos gyvavimo ciklo procesai pagal standartą ISO/IEC 12207

Viena iš esminių sąvokų programų sistemų inžinerijoje yra programinės įrangos gyvavimo

ciklas. Kaip matėme praeitame skyriuje, didžioji dalis žinių sričių yra siejamos su gyvavimo

ciklo procesais.

Apibrėždami programinės įrangos gyvavimo ciklą, įvairūs autoriai įvardina skirtingus jį

sudarančius procesus. Procesų rinkinys kaip taisyklė priklauso ne tik nuo autoriaus, bet ir nuo

nagrinėjamo gyvavimo ciklo modelio: pavyzdžiui, nuosekliame (angl. waterfall) gyvavimo cikle

išskiriami vienokie procesai, o evoliuciniame (angl. evolutionary) – kitokie. Tačiau bet kuriuo

atveju programinė įrangos sukūrimui reikia atlikti iš esmės tas pačias veiklas, todėl pageidautinas

ir vieningas procesų rinkinys. Pavyzdžiui, R.S.Pressman [Pre05] visų gyvavimo ciklo modelių

apibrėžimuose išskiria tokius procesus:

- Bendravimas (angl. Communication) apima projekto inicijavimą ir reikalavimų

surinkimą;

- Planavimas (angl. Planning) apima vertinimą, plano sudarymą ir stebėjimą;

- Modeliavimas (angl. Modeling) apima reikalavimų analizę ir projektavimą;

- Kūrimas (angl. Construction) apima kodavimą ir testavimą;

- Pateikimas (angl. Deployment) apima įdiegimą, palaikymą ir 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 pamirštant, kad daugeliu atveju

tinkamos programų sistemos sukūrimas beveik neįmanomas be įsigyjančios

organizacijos tinkamo dalyvavimo;

2) nagrinėjimas baigiamas programų sistemos sukūrimu ir įdiegimu, o juk tuo metu

programų sistema, jei ji naudojama, tik pradeda savo „gyvenimą“ ir reikalauja

nuolatinės priežiūros – tiek rastų klaidų taisymo, tiek tobulinimo, pritaikymo

pasikeitusioms veiklos ar techninėms sąlygoms.

Galima papildyti, kad programų sistemų inžinerijos pagrindinis objektas yra kūrėjų

atliekami procesai ir dauguma ne tik vadovėlių, bet ir mokslinių tyrimų nagrinėja tik juos, tačiau

ignoravimas, nežinojimas užsakovams (naudotojams) būtinų procesų tikrai nepadės sėkmingai

įvykdyti projektą, o dažnu atveju gali ir stipriai pakenkti kokybiškos (atitinkančios poreikius)

sistemos sukūrimui. Tiesa, didžioji dalis Lietuvos įmonių ir organizacijų dar nesupranta įsigijimo

proceso svarbos ir mano, kad įsigyti programų sistemą yra beveik taip pat paprasta kaip

nusipirkti sąvaržėlių dėžutę.


Mokymo medžiaga 14

O programų sistemų priežiūros (angl. maintenance) svarbą galima pagrįsti ir tuo, kad pagal

atliktus 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 ir terminologijos nebuvimas trukdo IT pramonės vystymuisi,

todėl natūralu, kad tarptautinė standartų organizacijos (ISO) iniciatyva buvo sukurtas specialus

standartas.

ISO/IEC 12207 - Programinės įrangos gyvavimo ciklo procesų standartas

Pagrindinis šio standarto tikslas yra apibrėžti programinės įrangos gyvavimo ciklo

procesus, suteikti bendrą sampratą ir terminologiją, kas palengvintų, iš vienos pusės,

programinių produktų ar paslaugų įsigijimą, o iš kitos pusės, jų sukūrimą, pateikimą ir priežiūrą.

Šiuo metu galiojanti standarto versija yra sudaryta iš 3 dokumentų:

1. Pagrindinio standarto [ISO95], kuris buvo priimtas 1995 metais ir apibrėžė procesų

kategorijas, pačius procesus, jų veiklas ir užduotis bei pateikė procesų pritaikymo gaires

skirtingoms organizacijoms.

2. 1-o papildymo[ISO02], kuris buvo priimtas 2002 metais ir papildė procesų rinkinį bei

apibrėžė visus procesus, nurodydamas jų tikslus ir rezultatus.

3. 2-o papildymo[ISO04], kuris buvo priimtas 2004 metais ir tik patikslino kai kurių

procesų apibrėžimą.

Kaip ir daugelis standartų, ISO/IEC 12207 sudarytas iš normatyvinių (privalomų

taikantiems standartą) ir informacinių (pateikiančių papildomą informaciją ir 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 ir pačius procesus, nurodydamas jų veiklas ir užduotis.

- Priedas A [ISO95], apibrėžiantis standarto pritaikymo (angl. tailoring) procesą, t.y.

standarto pritaikymo konkrečiam projektui pagrindinius žingsnius: projekto aplinkos

identifikavimas; informacijos surinkimas; procesų, veiklų ir užduočių pasirinkimas;

priimtų sprendimų ir jų pagrindimo dokumentavimas (standarte žingsniai aprašyti labai

lakoniškai – šio priedo apimtis tik1 puslapis).

- Priedas F [ISO02, ISO04], apibrėžiantis programinės įrangos gyvavimo ciklo procesus,

nurodydamas jų tikslus ir rezultatus.

ir 6 informacinės dalys:

- Priedas B [ISO95], pateikiantis gaires standarto pritaikymui (angl. tailoring).

- Priedas C [ISO95], pateikiantis organizacijų ir gyvavimo ciklo procesų sąryšį, kokioms

organizacijoms kurie procesai yra svarbesni.


Mokymo medžiaga 15

- Priedas D [ISO95], pateikiantis nuorodą į vienintelį standartą ISO/IEC 12119, skirtą

programinės įrangos paketų kokybės reikalavimams ir testavimui.

- Priedas E [ISO02, ISO04], pateikiantis sąryšį tarp pagrindiniame standarto tekste

[ISO95] ir priede F pateiktų procesų. Dauguma priede F apibrėžtų procesų sutampa su

jų buvusiais apibrėžimais [ISO95], bet (1) yra įvesta ir visai naujų procesų: pavyzdžiui,

naudojamumo procesas (angl. usability process) ar personalo valdymas (angl. human

resource management), tokie procesai vadinami baziniais); (2) nauji procesai

suformuoti iš buvusių kitų procesų veiklų: pavyzdžiui, pasirengimas įsigijimui (angl.

acquisition preparation) ar proceso vertinimas (angl. process assessment); (3) kai kurie

procesai yra išplėsti: pavyzdžiui, reikalavimų surinkimas (angl. requirements

elicitation) ar produkto įvertinimo procesas (angl. product evaluation process).

- Priedas G [ISO02], pateikiantis priede F pateiktų naujų procesų apibrėžimą jų

veiklomis ir užduotimis, t.y. papildantis pagrindiniame standarto tekste esantį procesų

apibrėžimą.

- Priedas H [ISO02], pateikiantis praplėstą (detalesnį), lyginant su priedu F, programinės

įrangos įsigijimo procesų rinkinį, labiau tinkamą įsigijimo gebėjimo vertinimui.

Reikia pastebėti, kad dabartinė standarto versija nėra visai „tvarkinga“: dalies procesų

apibrėžimas veiklomis ir užduotimis yra normatyvinis (pagrindiniame tekste), o dalies procesų

apibrėžimas – tik informacinis (priede G).

Turėtų kilti natūralus klausimas „O kam iš viso reikalingas dvejopas procesų

apibrėžimas?“ Procesų apibrėžimas veiklomis ir užduotimis yra labiau tinkamas organizacijoms

norinčioms diegti (vykdyti) tą procesą, nes tai atitinka pasaulyje pripažintą geriausią praktiką

(angl. best practice), kaip procesas turėtų (galėtų) būti atliekamas. Procesų apibrėžimas jų

tikslais ir rezultatais yra orientuotas į proceso gebėjimo vertinimą, nes suformuluoti proceso

tikslai ir rezultatai gali būti naudojami kaip rodikliai, parodantys, ar organizacijoje tas procesas

yra vykdomas ir ar vykdomas „gerai“. Apibrėžimas veiklomis ir užduotimis yra mažiau tinkamas

vertinimui dėl galimo alternatyvaus įgyvendinimo: jei procesas pasiekia savo tikslus ir duoda

reikiamus rezultatus, jo gebėjimo įvertinimas turi nepriklausyti nuo to, kokiomis veiklomis jis

yra įgyvendintas organizacijoje – kaip nurodyta standarte ar kitokiomis.

Procesų kategorijos Standartas ISO/IEC 12207 apibrėžia tokias procesų kategorijas:

- Pagrindiniai gyvavimo ciklo procesai (angl. primary life cycle processes)

- Pagalbiniai gyvavimo ciklo procesai (angl. supporting life cycle processes)

- Organizaciniai gyvavimo ciklo procesai (angl. organizational life cycle processes)


Mokymo medžiaga 16

Pagrindinių gyvavimo ciklo procesų kategoriją sudaro esminiai procesai, kuriuos vykdo

organizacijos, inicijuojančios arba atliekančios programinės įrangos kūrimą, naudojimą ir/ar

priežiūrą:

- Įsigijimo procesas (angl. acquisition process) apibrėžia veiklas, kurias vykdo

organizacija, įsigyjanti sistemą, programinį produktą ar paslaugą.

- Tiekimo procesas (angl. supply process) apibrėžia veiklas, kurias vykdo organizacija,

tiekianti sistemą, programinį produktą ar paslaugą.

- Kūrimo procesas (angl. development process) apibrėžia veiklas, kurias vykdo

programinį produktą apibrėžianti ir kurianti organizacija.

- Naudojimo procesas (angl. operation process) apibrėžia veiklas, kurias vykdo

organizacija, kad suteiktų sistemos naudotojams galimybę dirbti sus sistema.

- Priežiūros procesas (angl. maintenance process) apibrėžia veiklas, kurias vykdo

sistemą prižiūrinti organizacija tam, kad sistema atitiktų einamuosius naudojimo

poreikius.

Pagalbinių gyvavimo ciklo procesų kategoriją sudaro procesai, kurie vykdomi kartu su

kitais (juos inicijuojančiais) procesais prisideda prie sėkmingo projekto įvykdymo ir kokybiško

produkto kūrimo:

- Dokumentavimo procesas (angl. documentation process) apibrėžia gyvavimo ciklo

procesų surinktos informacijos užrašymo veiklas.

- Konfigūracijos valdymo procesas (angl. configuration management process) apibrėžia

programinės įrangos3 konfigūracijos valdymo veiklas.

- Kokybės užtikrinimo procesas (angl. quality assurance process) apibrėžia veiklas,

padedančias užtikrinti, kad produktai ir procesai atitiks jiems nustatytus reikalavimus ir

planus. Verifikavimas, validavimas, bendros peržiūros ir auditas gali būti naudojami

kaip kokybės užtikrinimo būdai.

- Verifikavimo procesas (angl. verification process) apibrėžia veiklas, kurias vykdo

programinį produktą įsigyjanti, tiekianti ar nepriklausoma organizacija produkto

patikrinimui (ar jis atitinka apibrėžtus jam reikalavimus).

- Validavimo procesas (angl. validation process) apibrėžia veiklas, kurias vykdo

programinį produktą įsigyjanti, tiekianti ar nepriklausoma organizacija produkto

tinkamumo patvirtinimui (ar jis atitinka poreikius).

- Bendrų peržiūrų procesas (angl. joint review process) apibrėžia veiklas, atliekamas

produkto ar veiklos būsenos įvertinimui.

3 Kaip programinė įranga (angl. software) yra suprantamas rinkinys kompiuterinių programų, procedūrų ir susijusios dokumentacijos bei duomenų.


Mokymo medžiaga 17

- Auditavimo procesas (angl. audit process) apibrėžia veiklas, atliekamas atitikimo

reikalavimams, planams ir sutarčiai įvertinimui.

- Problemų sprendimo procesas (angl. problem resolution process) apibrėžia veiklas,

skirtas bet kokio pobūdžio ir prigimties gyvavimo ciklo metu iškilusių problemų

analizavimui ir šalinimui.

Organizacinių gyvavimo ciklo procesų kategoriją sudaro procesai, kuriuos vykdo

organizacijos, kad užtikrintų kitų gyvavimo ciklo procesų atlikimą ir gerinimą:

- Valdymo procesas (angl. management process) apibrėžia valdymo veiklas, vykdomas

viso gyvavimo ciklo metu.

- Infrastruktūros procesas (angl. infrastructure process) apibrėžia veiklas, skirtas sukurti

sąlygas kitų procesų vykdymui.

- Gerinimo procesas (angl. improvement process) apibrėžia veiklas, kurias organizacija

atlieka procesų apibrėžimui, valdymui ir gerinimui.

- Mokymo procesas (angl. training process) apibrėžia veiklas tinkamai apmokytų

darbuotojų parengimui.

Procesų apibrėžimai Kaip jau buvo minėta, standartas ISO/IEC 12207 pateikia dvejopus procesų apibrėžimus:

1) veiklomis ir užduotimis ir

2) tikslais ir rezultatais.

Detaliau panagrinėkime šiuos skirtingus apibrėžimus kūrimo proceso (angl. development

process) pavyzdžiu.

Kūrimo proceso apibrėžimas veiklomis ir užduotimis Kūrimo procesą sudaro veiklos, kurias vykdo programinį produktą apibrėžianti ir kurianti

organizacija (procesas numato ir sistemos lygio veiklas, kurios atliekamos, jei to reikalauja

sutartis):

- Proceso įgyvendinimas (angl. process implementation);

- Sistemos reikalavimų analizė (angl. system requirements analysis);

- Sistemos architektūros projektavimas (angl. system architectural design);

- Programinės įrangos reikalavimų analizė (angl. software requirements analysis);

- Programinės įrangos architektūros projektavimas (angl. software architectural design);

- Detalus projektavimas (angl. software detailed design);

- Kodavimas ir testavimas (angl. software coding and testing);

- Programinės įrangos integravimas (angl. software integration);

- Programinės įrangos kvalifikacinis testavimas (angl. software qualification testing);


Mokymo medžiaga 18

- Sistemos integravimas (angl. system integration);

- Sistemos kvalifikacinis testavimas (angl. system qualification testing);

- Programinės įrangos instaliavimas (angl. software installation);

- Programinės įrangos priimtinumo palaikymas (angl. software acceptance support).

Kiekvienai iš proceso veiklų yra apibrėžtos užduotys. Pavyzdžiui, sistemos reikalavimų

analizės veikla turi atlikti 2 užduotis:

- Išanalizuoti būsimą sistemos naudojimą ir specifikuoti sistemos reikalavimus,

apimančius funkcijas ir sistemos galimybes; veiklos, organizacinius ir vartotojų

reikalavimus; saugos, saugumo, ergonomiškumo, interfeiso, naudojimo ir priežiūros

reikalavimus; projektavimo apribojimus ir kvalifikavimo reikalavimus. Sistemos

reikalavimų specifikacija turi būti dokumentuota.

- Sistemos reikalavimai turi būti įvertinti pagal tokius kriterijus ir vertinimo rezultatai

turi būti dokumentuoti: reikalavimų atitikimas (angl. traceability) įsigijimo poreikiams;

įsigijimo poreikių suderinamumas; testuojamumas; sistemos architektūros

suprojektavimo galimybės (angl. feasibility); naudojimo ir priežiūros galimybės (angl.

feasibility).

Kūrimo proceso apibrėžimas tikslais ir rezultatais Tikslas. Kūrimo proceso tikslas yra transformuoti reikalavimus į programinį produktą ar

sistemą, atitinkančius užsakovo išreikštus poreikius.

Rezultatai. Sėkmingai įgyvendintas kūrimo procesas turi pasiekti tokius rezultatus:

- reikalavimai programinės įrangos kūrimui surinkti ir patvirtinti;

- programinis produktas ar sistema sukurti;

- tarpiniai darbo produktai yra sukurti ir parodo, kad galutinis produktas sukurtas pagal

reikalavimus;

- proceso produktai yra nuoseklūs ir dera tarpusavyje;

- sistemos kokybės rodikliai (pvz., greitis, kaina, naudojamumas ir kt.) optimizuoti pagal

reikalavimus;

- pateikti įrodymai (pvz., testavimo įrodymai), kad galutinis produktas atitinka

reikalavimus;

- galutinis produktas instaliuotas pagal sutartus reikalavimus.

Kūrimo procesas apima tikslus ir rezultatus tokių detalesnių procesų (angl. sub-processes):

- Reikalavimų surinkimas (angl. requirements elicitation);

- Sistemos reikalavimų analizė (angl. system requirements analysis);

- Sistemos architektūros projektavimas (angl. system architecture design);

- Programinės įrangos reikalavimų analizė (angl. software requirements analysis);


Mokymo medžiaga 19

- 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 atitinka

pirmojo tipo apibrėžimo veiklas. Galima atkreipti dėmesį, kad į atskirą procesą buvo išskirtas

reikalavimų surinkimas, siekiant pabrėžti jo svarbą; aukšto ir detalaus lygio projektavimas

apjungtas į 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 proceso

gebėjimo vertinimui; patikslinti pavadinimai, jie labiau atitinka šiuo metu naudojamus.

Kiekvienam iš detalesnių procesų irgi yra apibrėžti tikslai ir rezultatai. Pavyzdžiui,

sistemos reikalavimų analizės tikslas yra transformuoti suinteresuotų asmenų (angl.

stakeholders) apibrėžtus reikalavimus (poreikius) į techninius reikalavimus, kuriais remiantis bus

projektuojama sistema.

Sėkmingai įgyvendinta sistemos reikalavimų analizė turi pasiekti tokius rezultatus:

- apibrėžti funkciniai ir nefunkciniai reikalavimai sprendžiamam uždaviniui reikalingai

sistemai;

- panaudoti tinkami metodai pageidaujamo projektinio sprendimo optimizavimui;

- išanalizuotas sistemos reikalavimų korektiškumas ir testuojamumas;

- suprasta sistemos reikalavimų įtaka naudojimo aplinkai;

- reikalavimams suteikti prioritetai, jie patvirtinti ir atnaujinti, kai prireikia;

- patikrintas sistemos reikalavimų ir užsakovo reikalavimų (poreikių) bazinio komplekto

(angl. baseline) suderinamumas ir atsekamumas (angl. traceability);

- bazinio komplekto (angl. baseline) pakeitimų įtaka kainai, tvarkaraščiui ir techniniam

įgyvendinimui yra įvertinta;

- sistemos reikalavimai yra pateikti visiems suinteresuotiems asmenims ir įtraukti į

bazinį komplektą.

Įsigijimo proceso apibrėžimas Kadangi programų sistemų inžinerijos literatūroje yra nepakankamai dėmesio skiriama

įsigijimo procesui ir praktikoje (bent jau Lietuvoje) dar nėra susiformavęs šio proceso poreikio

supratimas, panagrinėkime detaliau, kaip įsigijimo procesas yra apibrėžtas standarte

ISO/IEC 12207. Nagrinėsime procesų apibrėžimus tikslais ir rezultatais.


Mokymo medžiaga 20

Kaip buvo minėta, programinės įrangos įsigijimas apibrėžiamas standarto priede F ir

detalizuojamas priede H.

Priede F apibrėžiami tokie programinės įrangos įsigijimo procesai:

- Pasiruoš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 sutarties

sudaryme, nors šis procesas ir priskirtas tiekėjo kategorijai.

Panagrinėkime šiuos procesus detaliau.

F1. Pasiruošimas įsigijimui

Tikslas. Nustatyti įsigijimo poreikius ir 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 ir patikrinti įsigijimo reikalavimai, atitinkantys projekto poreikius;

- apibrėžti ir patikrinti pirkėjo žinomi reikalavimai;

- sukurta įsigijimo strategija;

- apibrėžti tiekėjo parinkimo kriterijai.

F2. Tiekėjo išrinkimas

Tikslas. Išrinkti organizaciją, atsakingą už programinės įrangos tiekimą pagal projekto

reikalavimus.


- tiekėjo išrinkimo kriterijai nustatyti ir naudojami potencialių tiekėjų įvertinimui;

- remiantis tiekėjų pateiktais pasiūlymais, procesų gebėjimu bei kitais faktoriais išrinktas

tiekėjas;

- sudaryta ir suderinta sutartis tarp pirkėjo ir tiekėjo.

F3. Tiekėjo stebėjimas

Tikslas. Stebėti ir vertinti tiekėjo darbą pagal sutartus reikalavimus.


- esant reikalui atliekamos jungtinės pirkėjo ir 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 pirkėjo ir tiekėjo bei dokumentuojami

sutartyje.


Mokymo medžiaga 21

F4. Programinės įrangos priėmimas

Tikslas. Aprobuoti tiekėjo pateiktus darbo produktus, kai patenkinami priėmimo kriterijai.


- pristatytas programinės įrangos produktas ir/arba paslauga įvertinti pagal sutartyje

pateiktus reikalavimus;

- produkto priėmimas yra paremtas sutartais priėmimo kriterijais;

- priimtas programinės įrangos produktas ir/arba paslauga;

F5. Sutarties sudarymas

Tikslas. Suderinti ir patvirtinti sutartį, kuri aiškiai ir vienareikšmiškai nustatytų

programinės įrangos tiekėjo ir užsakovo lūkesčius, įsipareigojimus, darbo produktus bei

atsakomybes.


- suderinta, peržiūrėta, patvirtinta ir pasirašyta sutartis su tiekėju;

- peržiūrėti ir apsvarstyti įtraukimui į sutarties sąlygas tiekėjo(ų) gebėjimo ir darbo

kontrolės bei rizikos švelninimo mechanizmai;

- konkurso dalyviai informuoti apie išrinktą tiekėją;

- pasiektas formalus sutarties patvirtinimas.

Siekiant sudaryti sąlygas tikslesniam proceso gebėjimo vertinimui ir gerinimui standarto

priede H apibrėžiama 17 detalesnių programinės įrangos įsigijimo procesų.

H1. Įsigijimo poreikiai

Tikslas. Nustatyti bendruosius aukšto lygio tikslus, įsigijimo poreikių pagrindą ir metodus,

kurie bus įdiegti įsigijimui valdyti.


- nustatytas poreikis organizacijai įdiegti bendrą įsigijimo politiką;

- nustatytas sisteminis pagrindas arba pageidavimai technologijoms, procesams,

metodams, pardavėjams, standartams bei teisiškai įvykdomiems reikalavimams, kad

būtų optimizuotas įsigijimas;

- nustatytas poreikis užtikrinti pakankamus įsigijimo valdymo resursus, tokius kaip

sutartiniai, techniniai, finansiniai bei projekto valdymo įgūdžiai;

- nustatytas poreikis apibrėžti kokybės standartus tiekėjo pateikiamiems darbo

produktams, kurie priimami pagal užfiksuotus ir numanomus pirkėjo poreikius;

- nustatytas poreikis nustatyti efektyvius ir produktyvius ryšius su tiekėju ir kitomis

susijusiomis grupėmis.


Mokymo medžiaga 22

H2. Įsigijimo strategija

Tikslas. Užtikrinti, kad įsigyti produktai rems verslo misiją ir tikslus bei pateiks pagrindą

visų įsigijimo projekto aspektų planavimui. Šis procesas apima verslo infrastruktūros (biudžeto,

finansinių investicijų), įsigijimo metodų (perkama arba modifikuojama komercinė programinė

įranga, sukuriama sistema) ir bendrų strategijų (įsigijimo strategija, darbo planas) derinį.


- sudarytos gairės įsigijimo valdymo programai, kuri atitiktų įsigijimo politiką bei

naudotojo/pirkėjo verslo poreikius;

- nustatyti skirtingi specifiniai (finansiniai, techniniai, sutartiniai, projektiniai) tikslai

ir/arba alternatyvūs įgyvendinimo sprendimai;

- nustatyti kritiniai įsigijimo sėkmės faktoriai;

- nustatyti įvairūs būdai, kaip sprendimai galėtų atitikti pirkėjo poreikius ir lūkesčius;

- nustatytos įvairios verslo rizikos bei finansiniai, techniniai, resursų veiksniai

alternatyviems įgyvendinimo sprendimams;

- nustatyti reikalavimai produktų atnaujinimui.

H3. Naudos analizė

Tikslas. Nustatyti įsigijimo tinkamumą bei naudą patenkinant užsakovo veiklos poreikius.


- išanalizuotas įsigijimo naudos atitikimas verslo tikslams;

- atlikta įsigijimo naudos atitikimo kainai analizė;

H4. Techniniai reikalavimai

Tikslas. Nustatyti įsigijimo techninius reikalavimus. Tai apima funkcinių ir nefunkcinių

reikalavimų, kurie nagrinėja produktų pateikimo gyvavimo ciklą, išsiaiškinimą, kad būtų

parengta ir patvirtinta techninių reikalavimų specifikacija.


- apibrėžti ir išvystyti naudotojų poreikius bei lūkesčius atitinkantys techniniai

reikalavimai, taip pat, jei tinka, bus įtraukti poveikio aplinkai įvertinimas, saugos ir

saugumo reikalavimai;

- surinkti ir apibrėžti esami įsigijimo poreikiai;

- reikalavimai ir potencialūs sprendimai perduoti visiems suinteresuotiems asmenims;

- nustatytas pakeistų arba naujų reikalavimų įtraukimo į patvirtintą reikalavimų

specifikaciją mechanizmas;

- apibrėžtas kintančių technologijų poveikio techniniams reikalavimams nustatymo ir

valdymo mechanizmas;


Mokymo medžiaga 23

- reikalavimuose užfiksuotas atitinkamų standartų laikymasis, taip pat, jei tinka, bus

įtraukti poveikio aplinkai įvertinimas, saugos ir saugumo standartai.

H5. Teisiniai ir administraciniai reikalavimai

Tikslas. Apibrėžti tiekėjo išrinkimo aspektus – lūkesčius, atsakomybes, teisinius ir kitus

klausimus, kurie atitiktų sutartyje nurodytus nacionalinius ir tarptautinius įstatymus.


- apibrėžtas sutarties traktavimas, atitinkantis svarbius nacionalinius, tarptautinius bei

reguliuojančiuosius įstatymus, patarimus (vadovavimus), politikas (strategijas);

- apibrėžti sutarties terminai ir sąlygos, apibrėžta, kaip tiekėjas patenkins poreikius ir

lūkesčius;

- nustatyti priėmimo kriterijai bei sutarties nesilaikymo valdymo mechanizmai;

- nustatytos gavėjo teisės intelektinės nuosavybės atžvilgiu;

- taikytinoms vietoms pateiktos paslaugų lygio susitarimai ir garantijos;

- tiekėjams nustatytos kitų reikalavimų (pvz., kokybės planai, trečiųjų šalių dalyvavimas

ir t.t.) patenkinimo nuostatos;

- nustatyti kriterijai nuosavybės teisių, kontrolės ir kitų produkto atsakomybių

klausimams.

H6. Finansiniai reikalavimai

Tikslas. Specifikuoti reikalavimus efektyvaus finansinio įsigijimo projekto valdymo

infrastruktūros paruošimui.


- nustatytas finansinis valdymas, rizikos ir kainos gavėjui;

- apibrėžtos ir dokumentuotos įsigijimo išlaidų ir mokėjimų finansinės sąlygos;

- finansiniai sutarties sudarymo proceso aspektai sekami iki projekto įgyvendinimo;

- finansavimo prašymai naudojami projekto veiklų biudžeto paruošimui;

- nustatyti reikalavimai išlaidų ataskaitoms pagal sutartus kainų įvertinimo modelius;

- nustatyti reikalavimai mokėjimams, kad jie būtų valdomi pagal apibrėžtas procedūras,

susijusias su sutarties duomenimis ir projekto vadovybės teikimais;

- reikalavimams suteikti prioritetai, kad būtų užtikrintas įsigijimo gyvavimo ciklo

sprendimo atitikimas reikalavimų svarbai.

H7. Projekto reikalavimai

Tikslas. Specifikuoti reikalavimus, užtikrinančius, kad įsigijimo projektas yra vykdomas su

projekto užduotims ir veikloms įgyvendinti pakankamu planavimu, personalu, vadovavimu,

organizavimu bei kontrole.



Mokymo medžiaga 24

- nustatytas nuoseklumas tarp finansinių, techninių, sutartinių ir projekto reikalavimų;

- apibrėžti reikalavimai projekto valdymui, kontrolei, ataskaitų pateikimui ir

organizaciniams projekto aspektams;

- apibrėžti reikalavimai tinkamam projekto personalui su aiškiom atsakomybėm ir

tikslais;

- nustatyti poreikiai informacijos apsikeitimui tarp į projekto vykdymą įtrauktų šalių;

- nustatyti reikalavimai tarpinių darbo produktų užbaigimui, priėmimui bei

apmokėjimui;

- nustatytos rizikos, susijusios su projekto gyvavimo ciklu ir tiekėjais;

- apibrėžti reikalavimai bendravimo ir ryšių su tiekėjais nuosavybei;

- apibrėžtos naudojimosi produktu bei jo išplatinimo pirkėjo ir tiekėjo teisės;

- nustatyti palaikymo ir priežiūros reikalavimai.

H8. Kvietimas teikti pasiūlymus

Tikslas. Paruošti ir išleisti reikiamus įsigijimo reikalavimus. Dokumentacija turi apimti (bet

ne apsiriboti) sutartinius, projekto, finansinius, techninius reikalavimus, kurie būtų pateikti

kvietime teikti pasiūlymus.


- kvietimui teikti pasiūlymus ir pasiūlymų vertinimui apibrėžti kriterijai, atitinkantys

įsigijimo politiką ir strategiją;

- sudarytas patvirtintas techninių ir netechninių reikalavimų rinkinys ir pridėtas prie

kvietimų teikti pasiūlymus

- kvietime teikti pasiūlymus pateiktos sutarties sąlygos;

- kvietime teikti pasiūlymus apibrėžtos finansinės sąlygos;

- kvietime teikti pasiūlymus apibrėžtos projektinės sąlygos;

- kvietime teikti pasiūlymus apibrėžtos techninės sąlygos;

- paruoštas ir išleistas kvietimas teikti pasiūlymus, atitinkantis įsigijimo politiką bei

atitinkamus nacionalinius, tarptautinius bei reguliuojančius teisės aktus, reikalavimus.

H9. Tiekėjo kvalifikacija

Tikslas. Įvertinti ir nuspręsti, ar potencialūs tiekėjai turi reikiamą kvalifikaciją, kad jų

pasiūlymai būtų perduoti pasiūlymų vertinimo procesui. Tiekėjo kvalifikacijos procese bus

įvertinta techninė kvalifikacija, kokybės sistema, paslaugų teikimo bei naudotojų palaikymo

gebėjimas ir t.t.


- nustatyti tiekėjų kvalifikacijos kriterijai;

- jei būtina, atliktas tiekėjo gebėjimo įvertinimas;


Mokymo medžiaga 25

- reikiamą kvalifikaciją turintys tiekėjai atrinkti pasiūlymų vertinimui;

- nustatyti ir įvertinti bet kokie trūkumai;

- įvertinti ir atlikti reikalaujami koreguojamieji veiksmai.

H10. Pasiūlymų vertinimas

Tikslas. Įvertinti pateiktus pasiūlymus ir/arba asocijuotus parduodamus OTS (angl. Off The

Shelf) produktus, kad būtų galima pradėti sutarties derinimą.


- pateikti pasiūlymai įvertinti pagal kvietime teikti pasiūlymus pateiktus reikalavimus;

- nustatyti OTS produktų vertinimo kriterijai, jei tokie produktai yra pateikiami kaip

pasiūlymas arba pasiūlymo dalis;

- OTS produktai įvertinti pagal apibrėžtą planą, įvertinant jų atitikimo gavėjo poreikiams

ir lūkesčiams laipsnį;

- atrinkto pasiūlymo(ų) tiekėjas(ai) pakviesti pradėti sutarties derybas.

H11. Sutarties parengimas

Tikslas. Suderinti ir patvirtinti sutartį, kuris aiškiai ir vienareikšmiškai specifikuotų tiek

tiekėjo(ų), tiek gavėjo lūkesčius, įsipareigojimus, darbo produktus bei atsakomybes.


- sutartis bus suderinta, peržiūrėta, patvirtinta ir pasirašyta;

- peržiūrėti ir apsvarstyti įtraukimui į sutarties sąlygas tiekėjo(ų) gebėjimo ir darbo

kontrolės bei rizikos švelninimo mechanizmai;

- pasiūlymų teikėjai informuoti apie pasirinktą pasiūlymą.

H12. Tiekėjo stebėjimas

Tikslas. Kontroliuoti ir įgalinti tiekėjo veiklų integraciją į įsigijimo proceso vykdymą,

laikantis susijusių reikalavimų ir valdymo būdų.


- reikiamu metu vykdomos jungtinės tiekėjo ir gavėjo veiklos;

- su tiekėju reguliariai apsikeičiama informacija ir duomenimis apie įsigijimo projekto

pažangą;

- tiekėjo darbas kontroliuojamas pagal sutartus reikalavimus;

- iškilusios problemos užfiksuotos ir sekamos iki išsprendimo.

H13. Priėmimas

Tikslas. Pagal priėmimo kriterijus priimti ir patvirtinti išleistą produktą. Procesas apims

suplanuotus ir integruotus būdus sumažinti gavėjo ir tiekėjo veiklų dubliavimąsi.



Mokymo medžiaga 26

- pagal suplanuotą ir dokumentuotą įsigijimo strategiją atliekamas patikrinimas ir

patvirtinimas;

- priėmimas atliekamas remiantis įsigijimo strategija ir pagal sutartus reikalavimus;

- pristatytas produktas įvertintas pagal sutartus reikalavimus;

- reikiamose vietose patvirtintos garantijos detalės.

H14. Sutarties užbaigimas

Tikslas. Užtikrinti išsamios informacijos, susijusios su projekto vykdymu ir užbaigimu,

surinkimą bei suderinimą tarp dalyvaujančių šalių.


- sutarta dėl apmokėjimų užbaigimo ir tolimesnių apmokėjimų planų;

- patvirtintas tiek tiekėjo, tiek gavėjo pateiktos konfidencialios informacijos

išsaugojimas ir grąžinimas;

- apsikeista (tarp dalyvaujančių šalių) įsigijimo rezultatų informacija;

- pagal iškeltus reikalavimus ir tikslus įvertinti projekto sutartinių, projektinių, techninių

ir finansinių aspektų rezultatai;

- įvertintas visų dalyvaujančių šalių darbas;

- svarbi su projektu susijusi informacija padėta į archyvą ir prieinama ateityje, atliekant

gerinimus ir kitus įsigijimo projektus;

H15. Tiekėjo santykiai

Tikslas. Pagerinti gavėjo-tiekėjo santykius teikiamų paslaugų kokybės bei kainos-kokybės

atžvilgiu, kad būtų pasiektas geresnis abiejų šalių poreikių supratimas.


- nustatyti dabartiniams ir būsimiems poreikiams svarbūs ryšiai su tiekėjais;

- apibrėžta ryšių nuosavybė ir koordinavimas;

- aiškiai suprasti ryšiai, labiausiai įtakojantys verslo tikslų pasiekimą;

- nustatyta potenciali pagerintų ryšių nauda bei atitinkamos pakeitimų neįgyvendinimo

rizikos;

- peržiūrimas ir kontroliuojamas tiekėjo ryšių efektyvumas.

H16. Naudotojo santykiai

Tikslas. Pagerinti gavėjo-naudotojo ryšius teikiamų paslaugų kokybės terminais tam, kad

būtų pasiektas geresnis abiejų šalių poreikių supratimas.


- apibrėžta ryšių nuosavybė ir koordinavimas;

- aiškiai suprasti ryšiai, labiausiai įtakojantys verslo tikslų pasiekimą;


Mokymo medžiaga 27

- nustatyta potenciali pagerintų ryšių nauda bei atitinkamos pakeitimų neįgyvendinimo

rizikos;

- peržiūrimas ir kontroliuojamas tiekėjo ryšių efektyvumas.

H17. Finansų valdymas

Tikslas. Užtikrinti, kad įsigijimo išlaidos ir biudžetas yra nustatyti ir valdomi pagal

suderintus planus ir tikslus.


- nustatyti ir palaikomi finansiniai planai ir tikslai;

- paruoštas ir patvirtintas 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ų ir esamų išlaidų;

- imtasi sprendimų, kad būtų užtikrintas finansinių tikslų pasiekimas.


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

Programų sistemų inžinerija 3. Programų kūrimo procesas

Mokymo medžiaga 28

3. Programų kūrimo procesas

Daugiau kaip prieš dešimtį metų pasauliniu mastu imta vis labiau akcentuoti „programinės

įrangos krizę” ir ieškoti adekvačių priemonių jos įveikimui. Tyrimais nustatyta, kad vos keli

procentai sukurtos programinės įrangos yra naudojama. Be to, daugelio programinės įrangos

projektų faktiniai kaštai ir terminai net kelis kartus viršija planinius. Programinės įrangos kūrimo

problemų (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, ir

nedavė laukiamų rezultatų, todėl vis didesnis dėmesys skiriamas organizacinių ir metodinių

aspektų nagrinėjimui. Buvo suprasta, kad programinės įrangos kokybė tiesiogiai priklauso nuo

jos kūrimo proceso kokybės.

Programinei įrangai bei sistemoms, veikiančioms programinės įrangos pagrindu, visą laiką

keliami vis nauji reikalavimai ir 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. Jei

kolektyviniame darbe nėra apibrėžtų “žaidimo” taisyklių, tuomet kiekvienas narys vadovaujasi

savo įsivaizduojamomis taisyklėmis ir vertybėmis, ko pasekoje kiekvieno darbo sėkmingas

užbaigimas ir atsiskaitymas su užsakovu - tai heroizmo demonstravimas taikos metu. Ne

naujiena, kad naudojant standartinius inžinerinius ir mokslinius principus galima pasiekti sėkmės

profesijoje, tame tarpe ir programinių produktų kūrime. Atskiri profesionalai asmeninės

intuicijos dėka sugebėjo pasiekti aukštų rezultatų profesinėje ir organizacinėje veikloje. Tikslas

yra tokių bendrųjų principų įdiegimą pervesti iš intuicijos lygmens į metodo, procedūros

lygmenį.

Programų kūrimo proceso brandos modeliavimas pripažįstamas kaip viena iš labiausiai

besivystančių ir daugiausia pasiekusių per pastarąjį dešimtmetį programų sistemų inžinerijos

sričių. Pagrindinis uždavinys, kurį turėjo išspręsti programų kūrimo proceso tyrimai, buvo

atsakyti į klausimą, kodėl žlunga programų kūrimo projektai: net ir išvystytų planavimo ir

įgyvendinimo įrankių naudojimas nesumažino projektų, viršijusių suplanuotą biudžetą, terminus,

ar visai nutrauktų, skaičiaus. Programų kūrimo proceso tyrimo ir modeliavimo darbais siekiama

nustatyti proceso charakteristikas, skiriančias gerą ir blogą procesą, „gerumu“ įvardinant proceso

gebėjimą pateikti rezultatą suplanuotais terminais ir neviršijant suplanuoto biudžeto.

Nors programų kūrimo proceso modeliavimo, vertinimo ir gerinimo srityje pasiekta tikrai

nemažai, bet problema ir toliau išlieka labai aktuali.


Mokymo medžiaga 29

16%

27%

26%

28%

31%

40%

28%

23%

53%

33%

46%

49%

1994

1996

1998

2000

Sėkmingi

Žlugę

Pažeisti

3.1 pav. Projektų rezultatų tyrimas [StG01]

Kaip rodo Standish Group atlikto tyrimo CHAOS [StG01] rezultatai, nors sėkmingų

projektų – atliktų laiku ir su planuotu biudžetu bei įgyvendinusių visas numatytas savybes ir

funkcionalumą – dalis ir išaugo, tačiau pažeistų projektų dalis išlieka beveik nepakitusi.

Pažeistiems projektams priskiriami baigti projektai, kuriuose sukurtos programų sistemos yra

naudojamos, bet viršiję planinį biudžetą, tvarkaraštį ir/ar įgyvendinę mažiau savybių ir

funkcionalumo nei buvo numatyta pradžioje. 3.1 pav. pateikia daugiau kaip 30,000 Standish

Group tirtų projektų rezultatus.

Programų kūrimo proceso sąvoka buvo pasiūlyta Carnegie Melon universiteto profesoriaus

W. Humphrey darbuose, atliktuose JAV gynybos departamento finansuojamame Programų

inžinerijos institute (angl. Software Engineering Institute – SEI). Europoje pirmieji analogiški

darbai inicijuoti Europos Bendrijos Komisijos ESPRIT programos rėmuose, žinomi

BOOTSTRAP metodo vardu, ir 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ūrimo

proceso charakteristikas. Keletas iš jų tapo de facto standartais, o kai kurie įteisinti ir kaip

tarptautiniai arba atskirų valstybių standartai.

Vienas iš plačiausiai pripažįstamų ir vertinamų vardų, tame tarpe ir informacinių

technologijų srityje, yra tarptautinis bendrinis kokybės standartas ISO 9000, kuris dažnai tampa

privalomu reikalavimu įmonei, norinčiai atlikti tam tikrą projektą. ISO 9000 standartas nusako

tik 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čiau

bendrinis kokybės standartas negali atsižvelgti į taikymo srities specifiką. Programinės įrangos

kūrimo industrijoje įsitvirtino specializuoti standartai.

Jungtinėse Amerikos Valstijose neabejotinai didžiausią autoritetą šioje srityje turi

Programų sistemų inžinerijos institutas (SEI), pirmasis 1993 metais parengęs išbaigtą programų

kūrimo proceso brandos modelį SW-CMM (angl. Capability Maturity Model for Software). Po


Mokymo medžiaga 30

dviejų metų SEI parengė sistemų kūrimo brandos modelį SE-CMM (angl. Systems Engineering

Capability Maturity Model), o 1999 metais pradėjo integruoto brandos modelio CMMI (angl.

Capability Maturity Model Integration) rengimą, šiuo metu išleistą keturiomis versijomis,

skirtomis 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 ir proceso kūrimui CMMI-SE/SW/IPPD (angl. CMMI for Systems

Engineering/ Software Engineering/ Integrated Product and Process Development) bei sistemų

įsigijimui CMMI-SE/SW/IPPD/SS (angl. CMMI for Systems Engineering/ Software

Engineering/ Integrated Product and Process Development/ Supplier Sourcing). CMMI modelis

laikomas pačiu išsamiausiu programų kūrimo brandos modeliu, tinkamu panaudoti programinių

produktų ir paslaugų kūrimo ir priežiūros gerinimui. Šis modelis apima visas SW-CMM modelio

geriausias praktikas ir daugelį kitų proceso gerinimo modelių žinių, tačiau jis dar nėra taip

plačiai paplitęs kaip jo pirmtakas: SEI pateikiamais duomenimis iki 2003 metų atlikta daugiau

kaip 2600 vertinimų pagal CMM ir tik kiek daugiau nei 70 vertinimų pagal CMMI.

1995 metais lygiagrečiai sukurtas ir publikuotas kitas brandos modelis SPICE (angl.

Software Process Improvement and Capability dEtermination), aprašantis programų kūrimo

proceso vertinimo reikalavimus, nusakydamas proceso sudedamąsias dalis bei kriterijus joms

įvertinti. Modelio SPICE ir jo vėlesnės versijos, tapusios standartu ISO/IEC 15504, paskirtis –

apibrėžti vertinimo kriterijus ir principus, kurių pagrindu būtų galima kurti kitus programų

kūrimo proceso brandos įvertinimo ir gerinimo modelius. Kuriant paskutines CMMI versijas,

buvo siekiama suderinamumo su ISO/IEC 15504 standartu ir jo bus siekiama vėlesnėse

versijose.

Be jau minėto Europos programų inžinerijos instituto tarp didžiausių programų kūrimo

proceso brandos tyrimų centrų yra 1993 metais Europos Komisijos įsteigtas Europos programų

kūrimo proceso gerinimo fondas (angl. ESPI Foundation). Abi šios institucijos užsiima

programų kūrimo proceso standartų propagavimu, konsultavimu bei įmonių vertinimu, o taip pat

kartu su SEI organizuoja kasmetines mokslines-technines konferencijas programų kūrimo

proceso brandos gerinimo klausimais (angl. SEPG Conference).

Tiek CMMI, tiek ISO/IEC 15504 autoriai supranta, kad modeliai negalės išlikti aktualūs

tokie, kokie yra sukurti, todėl yra numatyti modelių tobulinimo tvarkaraščiai, pagal kuriuos

modelis turi būti peržiūrimas ir papildomas kas ketverius metus.

Programų kūrimo proceso brandos modelių atsiradimas davė impulsą specializuotų

brandos modelių tyrimams – smarkai suaktyvėjo ir pradėjo duoti rezultatus tyrimai tokiose

srityse kaip: reikalavimų specifikavimo branda, programų sistemų testavimo branda, programų

sistemų priežiūros branda, informacinių sistemų paslaugų valdymo branda.


Mokymo medžiaga 31

Programų kūrimo įmonės palankiai sutiko sukurtus brandos modelius ir ėmėsi juos taikyti.

SEI pateikiamais duomenimis atliktų vertinimų vien pagal CMM ir ISO/IEC 15504 (SPICE)

modelius skaičius siekia beveik 5000. Nuo pirmųjų modelių ir vertinimo metodikų atsiradimo

daugelis įmonių ėmėsi „kopti“ brandos įvertinimo laipteliais. 2003 metų pradžios duomenimis

aukščiausių brandos lygių pagal CMM organizacijų sąraše yra 72 ketvirto ir 74 penkto lygio

organizacijos. Tokio brandos lygio sertifikatas yra liudijimas, kad organizacija kokybiškai ir

patikimai atlieka savo darbą.

Organizacijos vertinimas atliekamas, turint du pagrindinius tikslus: programų kūrimo

proceso gerinimą ir projekto vykdytojo (sistemos tiekėjo) pasirinkimą. Pavyzdžiui, JAV gynybos

departamentas 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, tiriant programų kūrimo proceso brandą, leido suprasti ir aiškiai

nusakyti programų kūrimo metu atliekamas veiklas, apibrėžti programų kūrimo proceso

valdymą, programinio produkto kokybę išreikšti per kūrimo proceso kokybę bei sukurti darnius

programų kūrimo proceso modelius, padedančius įvertinti ir išmatuoti tiek programų kūrimo

procesą, tiek pačią organizaciją apskritai.

Programų kūrimo proceso vertinimas ir gerinimas yra sudėtinga ir didelių darbo sąnaudų

reikalaujanti veikla. Remiantis pasauline patirtimi, galima teigti, kad pradinis proceso gerinimo

projektas organizacijoje trunka ne mažiau kaip metus ir jo sėkmė be kitų veiksnių nemaža dalimi

priklauso ir nuo tinkamo proceso vertinimo ir palaikymo instrumentinių priemonių pasirinkimo.

Įmonių vadovams kyla natūralus, ar proceso vertinimas yra ekonomiškai naudingas

organizacijai. Žinoma, yra daug kitų svarbių aspektų (sauga, saugumas, sistemos stabilumas ir

kt.), kuriuos padeda užtikrinti brandus programų kūrimo procesas, tačiau netgi apsiribojus tik

finansiniu požiūriu galima drąsiai teigti, jog proceso branda yra vertinga. Tai galima pagrįsti

statistiniais CMM taikymo duomenimis.

Tai, kad aukštesnis brandos lygis sumažina kaštus, sutrumpina sistemos kūrimo laiką,

pagerina kokybę ir prisiimamų įsipareigojimų įvykdymo tikimybę, akivaizdžiai parodo 3.1

lentelėje pateikti 1.300 projektų statistiniai duomenys [Kea02]. Buvo analizuojami dideli

projektai, turintys apie 200.000 kodo eilučių. Kaštai buvo skaičiuojami pagal vieno žmogaus

metinį į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 lygio

organizacijos. Be to, tokios organizacijos sukurtame produkte lieka maždaug 5 kartus mažiau

defektų, kas tiesiogiai įtakoja užsakovų ir vartotojų pasitenkinimą, todėl nėra abejonių kurią iš

šių organizacijų jie pasirinks.


Mokymo medžiaga 32

Organizacijos CMM lygis

Trukmė

(mėnesiais)

Pastangos (žmogaus mėnesiais)

Sistemos defektų skaičius

Vidutinė kaina ($M)

Minimali kaina ($M)

Maksimali kaina ($M)

Lygis 1 30 600 61 5,5 1,8 100+

Lygis 2 18.5 143 12 1,3 0,96 1.7

Lygis 3 15 80 7 0,728 0,518 0,933

3.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čioms

procesą 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 prireiks

daugiau nei 6 metų.

Esminės sąvokos

Programų kūrimo procesas apima visas veiklas, vykdomas organizacijoje, kuriant

programinį produktą ar teikiant paslaugas, todėl jis dar vadinamas visuminiu procesu. Šis

procesas nėra vienalytis ir modeliavimui tikslinga jį suskaidyti į sudedamąsias dalis, atitinkamai

grupuojant veiklas. Vienas iš taikomų principų yra išskirti grupes veiklų, susijusių pagal tikslus

programinio produkto gyvavimo cikle. Toks veiklų rinkinys vadinamas vardiniu procesu.

Veiklų suskirstymas į vardinius procesus nėra unikalus ir priklauso nuo modelio paskirties ir

autorių požiūrio. Naudojamas ir kitas principas: grupuoti veiklas pagal jų prisidėjimą prie

proceso 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ą, pasiskirstymą (diapazoną), t.y. galimybę (tikimybę), kad procesas įvykdys jam keliamus

tikslus. Tradiciškai gebėjimo sąvoka taikoma vardiniam procesui, nors ją galima taikyti ir

visuminiam programų kūrimo procesui. Gebėjimas yra proceso charakteristika, išreiškiama

gaunamais 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 33

Gebėjimo lygis yra įvertis diskrečioje skalėje, nusakantis tam tikrą proceso gebėjimo

pasiekimą. Tačiau praktiškai yra neįmanoma išmatuoti galimybės gauti siekiamus rezultatus,

todėl remiamasi praktikoje patvirtinta prielaida, kad kokybiškų rezultatų gavimo tikimybė

tiesiogiai priklauso nuo paties proceso charakteristikų, todėl proceso gebėjimo lygis

apibrėžiamas konstruktyviai, nurodant proceso indikatorius - veiklas, kurias atliekant sukuriama

proceso aplinka, užtikrinanti proceso rezultatų stabilumą.

Visuminio proceso gebėjimui apibūdinimui tradiciškai naudojamos brandos ir brandos

lygio sąvokos, kurios apibrėžiamos konstruktyviai. Branda yra proceso charakteristika,

nusakanti, kiek procesas yra apibrėžtas, valdomas, matuojamas, kontroliuojamas ir nuolatos

gerinamas, o brandos lygis yra aiškiai apibrėžta pakopa proceso brandos evoliucijoje, nusakoma

rinkiniu veiklų, kurių tikslai turi būti įgyvendinami, kad būtų pasiektas tam tikras to proceso

gebė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ės

skiriasi nuo žemesnio lygio organizacijų. Akivaizdu, kad aukštesnis brandos lygis implikuoja

aukštesnį proceso gebėjimą. Matavimui brandos lygiai išreiškiami rinkiniais veiklų – proceso

sritimis – kurias organizacija turi vykdyti, kad pasiektų tą brandos lygį.

Visus programų kūrimo proceso brandos modelius pagal architektūrą galima suskirstyti į

pakopinius ir tolydinius.

Programų kūrimo proceso modelis, leidžiantis vertinti visuminio organizacijos proceso

brandą, 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 proceso

gebėjimą, vadinamas tolydinės architektūros brandos modeliu, kadangi leidžia įvertinti proceso

gebėjimą detalesniame – vardinio proceso – lygmenyje. Šiuo atveju organizacijos įvertinimas yra

vardinių procesų gebėjimų lygių profilis, akivaizdžiai parodantis „atsiliekančius“ – žemesnio

gebėjimo lygio – procesus. Atrodytų, kad galima būtų siekti maksimaliai pakelti tik kažkurio

vieno pasirinkto vardinio proceso gebėjimus, tačiau iš tikrųjų vardiniai procesai yra tarpusavyje

susiję: norint iš esmės pakelti vieno vardinio proceso gebėjimą reikia didinti ir susijusių procesų

gebėjimus.

Kurios architektūros modelis tinkamesnis, apibrėžtų taisyklių nėra. Įvairių brandos

modelių taikymo patirtis rodo, kad pasirenkant architektūrą, naudotini modelių detalumo ir

taikymo tikslų argumentai. Tolydinės architektūros modelis leidžia detaliau vertinti organizacijos


Mokymo medžiaga 34

procesus, todėl yra lankstesnis proceso tobulinimo kelių pasirinkimo ir investicijų į tobulinimą

atžvilgiu, tačiau pagal jo duodamus vertinimo rezultatus sudėtinga palyginti organizacijas

tarpusavyje. Pakopinis modelis leidžia gauti vertinimo rezultatą kaip vieną skaičių, kuris lengvai

palyginamas su kitos organizacijos vertinimu, todėl tinka konkurenciniam vertinimui, bet jis nėra

tiek detalus ir lankstus, siūlydamas pakankamai vienareikšmį proceso gerinimo kelią ir

nesuteikdamas galimybės detaliau stebėti proceso pagerėjimo. Taigi, jei pagrindinis tikslas yra

programų kūrimo proceso gerinimas, labiau tinkamas yra tolydinis modelis.

Procesų gebėjimo lygių ir brandos lygių panašumas leidžia teigti, kad galima atrasti

pakopinės ir 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ą su

brandos lygio įverčiu pagal pakopinę architektūrą. Tokio atitikimo egzistavimas leidžia

organizacijai taikyti tolydinės architektūros brandos modelį, o pasiekus tam tikrą vardinių

procesų gebėjimų lygių profilį, patvirtinti, kad visuminis organizacijos procesas yra tam tikro

brandos lygio pagal pakopinės architektūros modelį.

Standartas ISO/IEC 15504

Standartas ISO/IEC 15504 išsivystė iš SPICE modelio. Nuo pat pradžios jo paskirtis buvo

apibrėžti vertinimo kriterijus ir principus, kurių pagrindu būtų galima kurti kitus programų

kūrimo proceso gebėjimo vertinimo ir 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. pasirinkus programinės įrangos gyvavimo ciklo

procesų modelį ISO/IEC 12207, jis gali būti taikomas programų kūrimo proceso vertinimui, o

pasirinkus kitos srities procesų modelį, jis gali būti taikomas tos srities procesų gebėjimo

vertinimui. 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 karkasas Procesų gebėjimas apibrėžiamas 6 lygiais, kurie sudaro proceso vertinimo skalę: nuo

nevykdomo, kai proceso tikslai yra nepasiekiami, iki optimizuojamo. Vertinimo rezultate

procesas yra priskiriamas vienam iš tų šešių proceso gebėjimo lygių, kuris yra nustatomas pagal

proceso atributų reikšmes. Kiekvienas atributas, esantis vertinamo proceso atributų rinkinyje,

apibrėžia tam tikrą proceso gebėjimo aspektą. Proceso atributų pasiekimo apimtis yra

charakterizuojama vertinimo skalėje. Proceso atributų pasiekimas ir apibrėžtas tų atributų

grupavimas kartu nusako proceso gebėjimo lygį.


Mokymo medžiaga 35

Lygis 0: Nevykdomas procesas. Procesas yra nevykdomas, arba nepasiekiami proceso

tikslai. Šiame lygyje nesurenkama jokių arba surenkama mažai įrodymų, kad proceso tikslai yra

pasiekiami.

Lygis 1: Vykdomas procesas. Vykdant procesą yra pasiekiami proceso tikslai. Pirmo lygio

pasiekimą 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. Pirmo lygio (vykdomo) proceso atlikimas šiame lygyje yra

valdomas (planuojamas, stebimas, koreguojamas), o proceso darbo produktai yra atitinkamai

(tinkamai) sukuriami, kontroliuojami ir palaikomi. Antro lygio pasiekimą kartu su pirmo lygio

atributais rodo du proceso atributai:

PA 2.1 Proceso vykdymo valdymo atributas. Proceso atlikimo atributas nusako, kokiu

laipsniu (kokia apimtimi) yra valdomas proceso vykdymas (atlikimas). Pilno šio atributo

pasiekimo (įgyvendinimo, išpildymo) rezultatai: proceso vykdymo tikslai yra identifikuoti,

proceso vykdymas yra planuojamas ir stebimas, proceso vykdymas yra koreguojamas, kad

atitiktų planus, proceso vykdymo atsakomybės ir įgaliojimai yra apibrėžti ir priskirti, o susijusios

šalys informuotos, proceso vykdymui reikalingi resursai ir informacija yra identifikuoti,

pasiekiami, priskirti ir naudojami, sąveika tarp susijusių šalių yra valdoma, kad užtikrintų

efektyvią komunikaciją ir aiškų atsakomybių priskyrimą.

PA 2.2 Darbo produktų valdymo atributas. Darbo produktų valdymo atributas nusako

kokiu 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 ir darbo

produktų kontrolei yra apibrėžti, darbo produktai yra tinkamai identifikuoti, dokumentuoti ir

kontroliuojami, darbo produktai yra peržiūrėti pagal planinius susitarimus, ir kur būtina

koreguojami, kad atitiktų reikalavimus.

Lygis 3: Apibrėžtas procesas. Antro lygio (valdomo) proceso vykdymas šiame lygyje yra

apibrėžtas. Proceso atlikimas yra apibrėžtas taip, kad procesas pasiektų apibrėžtus rezultatus.

Trečio lygio pasiekimą kartu su pirmo ir antro lygių atributais rodo šie proceso atributai:

PA 3.1 Proceso apibrėžimo atributas. Proceso apibrėžimo atributas nusako kokia apimtimi

standartinis procesas yra palaikomas, kad paremtų apibrėžto proceso įdiegimą. Pilno šio atributo

pasiekimo (įgyvendinimo, išpildymo) rezultatai: standartinis procesas, įskaitant pritaikymo

gaires, yra apibrėžtas ir aprašo pagrindinius, į apibrėžtą procesą įeinančius elementus,

standartinio proceso ir kitų procesų seka bei sąveika tarp jų yra nustatyta, reikalaujama


Mokymo medžiaga 36

kompetencija ir proceso atlikimo rolės yra identifikuotos kaip standartinio proceso dalys,

proceso atlikimui reikiama infrastruktūra ir darbo aplinka yra identifikuotos kaip standartinio

proceso dalys, proceso efektyvumo ir 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, kad

pasiektų proceso rezultatus. Pilno šio atributo pasiekimo (įgyvendinimo, išpildymo) rezultatai:

apibrėžtas procesas yra įdiegtas pagal tinkamai parinktą ir/arba pritaikytą standartinį procesą,

apibrėžto proceso atlikimui reikalaujamos rolės, atsakomybės ir įgaliojimai yra priskirti ir

išplatinti, personalas, vykdantis apibrėžtą procesą, yra kompetentingas - turi reikiamą

išsilavinimą, patirtį bei yra tinkamai apmokytas, apibrėžto proceso vykdymui reikalingi resursai

ir informacija yra pasiekiami, priskirti ir naudojami, apibrėžto proceso vykdymui reikalinga

infrastruktūra bei darbo aplinka yra pasiekiamos, valdomos ir palaikomos, atitinkami duomenys

yra surenkami ir analizuojami tam, kad suprastas proceso funkcionavimas (elgesys), kad būtų

parodytas proceso tinkamumas ir efektyvumas ir, kad būtų įvertintos sritys, kuriose turėtų būti

atliekamas ištisinis proceso gerinimas.

Lygis 4: Prognozuojamas procesas. Trečio lygio (apibrėžtas) procesas šiame lygyje yra

vykdomas apibrėžtose ribose tam, kad pasiektų proceso rezultatus. Ketvirto lygio pasiekimą

kartu su pirmo, antro ir trečio lygių atributais rodo šie proceso atributai:

PA 4.1 Proceso matavimo atributas. Proceso matavimo atributas nusako kokia apimtimi

yra naudojami matavimo rezultatai, kad būtų užtikrinta, kad proceso vykdymas užtikrina proceso

tikslų pasiekimą remiant apibrėžtus verslo tikslus. Pilno šio atributo pasiekimo rezultatai:proceso

informacijos poreikiai verslo tikslų siekimui yra nustatyti, iš proceso informacijos poreikių yra

gauti proceso matavimo tikslai, kiekybiškai išreikšti proceso vykdymo tikslai remiantys

atitinkamus verslo tikslus yra nustatyti, matavimai ir matavimų dažnumas yra identifikuoti bei

apibrėžti remiantis proceso matavimo tikslais ir proceso vykdymo kiekybiniais tikslais,

matavimų rezultatai yra surinkti, išanalizuoti ir išdėstomi ataskaitoje, kad būtų galima stebėti

kokia apimtimi yra pasiekiami kiekybiniai proceso vykdymo tikslai, matavimų rezultatai yra

naudojami proceso vykdymo apibūdinimui

PA 4.2 Proceso kontrolės atributas. Proceso kontrolės atributas nusako kokia apimtimi

procesas yra kiekybiškai valdomas, kad būtų stabilus, gebantis ir prognozuojamas apibrėžtose

ribose. Pilno šio atributo pasiekimo rezultatai: analizės ir kontrolės metodai yra apibrėžti ir

taikomi tinkamose vietose, nukrypimų valdymo ribos yra nustatytos normaliam proceso

vykdymui, matavimo duomenys yra analizuojami atskiriems nukrypimų atvejams, atskiriems

nukrypimų atvejams yra daromi koreguojantys veiksmai, jeigu reikia, įvykdžius korekcinius

veiksmus yra iš naujo nustatomos nukrypimų valdymo ribos.


Mokymo medžiaga 37

Lygis 5: Optimizuojamas procesas. Ketvirto lygio (prognozuojamas) procesas šiame lygyje

yra be perstojo gerinamas, kad pasiektų aktualius esamus bei numatomus verslo tikslus. Penkto

lygio pasiekimą kartu su pirmo, antro, trečio ir ketvirto lygių atributais rodo šie proceso atributai:

PA 5.1 Proceso inovatyvumo atributas. Proceso inovatyvumo atributas nusako kokia

apimtimi yra identifikuojami proceso pakeitimai, kurie atsiranda analizuojant proceso vykdymo

nukrypimo nuo normos priežastis bei tyrinėjant naujoviškus proceso apibrėžimo ir įdiegimo

būdus. Pilno šio atributo pasiekimo rezultatai: verslo tikslus remiantys proceso gerinimo tikslai

yra apibrėžti, reikiami duomenys yra analizuojami, kad būtų nustatytos pasikartojančios proceso

vykdymo 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 strategija

yra nustatyta, kad būtų pasiekti proceso gerinimo tikslai.

PA 5.2 Proceso optimizavimo atributas. Proceso optimizavimo atributas nusako kokia

apimtimi pakeitimai proceso apibrėžime, valdyme ir vykdyme įtakoja efektyvius pokyčius

proceso gerinimo tikslų siekimui. Pilno šio atributo pasiekimo rezultatai: visų pasiūlytų

pakeitimų įtaka yra įvertinama atsižvelgiant į apibrėžto ir standartinio proceso tikslus, patvirtintų

pakeitimų įgyvendinimas yra valdomas, kad būtų užtikrinta, kad bet kokie proceso vykdymo

nesklandumai būtų suprasti ir į juos būtų tinkamai reaguojama, proceso pakeitimo efektyvumas

yra vertinamas esamo vykdymo atžvilgiu pagal apibrėžtus reikalavimus produktui ir proceso

tikslus, kad būtų nustatyta, ar gauti rezultatai yra bendrinis ar išskirtinis atvejis.

Proceso atributo įverčiai

N – 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ą prie

vertinamo proceso atributo ir dalinį jo pasiekimą. Kai kurie atributo pasiekimo aspektai gali būti

nenusakomi.

L – Didžiąja dalimi pasiektas (51% - 85% pasiekimo). Yra įrodymų apie sisteminį

priartėjimą prie vertinamo proceso atributo ir žymų jo pasiekimą. Vertinamame procese gali būti

dalis su atributu susijusių silpnų vietų.

F – Pilnai pasiektas (6% - 100% pasiekimo). Yra įrodymų apie pilną ir sisteminį priėjimą

prie vertinamo proceso atributo ir pilną jo pasiekimą. Neaptinkama jokių reikšmingų trūkumų

susijusių su vertinamo proceso atributu.

Lygis Proceso atributai Įvertinimas

Lygis 1 Proceso atlikimo atributas L arba F


Mokymo medžiaga 38

Lygis 2 Proceso atlikimo atributas Proceso vykdymo valdymo atributas Darbo produktų valdymo atributas

F L arba F L arba F

Lygis 3 Proceso atlikimo atributas Proceso vykdymo valdymo atributas Darbo produktų valdymo atributas Proceso apibrėžimo atributas Proceso įdiegimo atributas

F F F L arba F L arba F

Lygis 4 Proceso atlikimo atributas Proceso vykdymo valdymo atributas Darbo produktų valdymo atributas Proceso apibrėžimo atributas Proceso įdiegimo atributas Proceso matavimo atributas Proceso kontrolės atributas

F F F F F L arba F L arba F

Lygis 5 Proceso atlikimo atributas Proceso vykdymo valdymo atributas Darbo produktų valdymo atributas Proceso apibrėžimo atributas Proceso įdiegimo atributas Proceso matavimo atributas Proceso kontrolės atributas Proceso inovacijos atributas Proceso optimizavimo atributas

F F F F F F F L arba F L arba F

3.2 lentelė. Proceso atributų įverčiai būtini gebėjimo lygiams

Reikalavimai procesų modeliui Tam, kad procesus būtų galima įvertinti, jie procesų modelyje turi būti apibrėžti tinkamu

bū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 tokie

reikalavimai procesų modeliui:

1. Procesų modelyje turi būti:

a. Procesų modelio taikomosios srities apibūdinimas;

b. Procesų modelio taikomosios srities procesų aprašymas, atitinkantis proceso

aprašymui keliamus reikalavimus;

c. Ryšių tarp procesų modelio ir 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 ir veiksmai,

kurių imtasi pasiekti pritarimą modeliui toje bendrijoje:

a. Turi būti apibūdinta arba specifikuota tiesiogiai su procesų modeliu susijusi

suinteresuota bendrija;

b. Turi būti dokumentuotas pritarimo procesų modeliui laipsnis;


Mokymo medžiaga 39

c. Jei nėra imtasi jokių veiksmų pasiekti pritarimą procesų modeliui suinteresuotoje

bendrijoje, tokia situacija turi būti pagrįsta.

3. Procesų modelyje apibrėžti procesai turi turėti unikalius identifikatorius ir aprašymus.

Reikalavimai proceso aprašymui

Esminė procesų modelio dalis yra procesų modelio taikomosios srities procesų aprašymas.

Proceso aprašymas procesų modelyje susideda iš proceso paskirties formulavimo, kurioje aukštu

lygiu apibūdinami bendrieji proceso vykdymo tikslai, ir proceso rezultatų rinkinio, parodančio

sėkmingą proceso tikslų pasiekimą. Proceso aprašymas turi tenkinti šiuos reikalavimus:

1. Proceso aprašyme turi būti pateikti proceso tikslai ir rezultatai;

2. Proceso aprašyme pateiktas proceso rezultatų rinkinys turi būti būtinas ir pakankamas

pasiekti proceso tikslus;

3. Proceso aprašyme neturi būti tiesiogiai ar netiesiogiai pateikti jokie aukštesnių už

pirmąjį gebėjimo lygių aspektai.

Proceso rezultatas aprašo:

1) darbo produkto sukūrimą arba

2) svarbų organizacijos būsenos pasikeitimą, arba

3) apibrėžtų sąlygų, tokių kaip reikalavimai, tikslai ir pan. išpildymą.

Reikalavimai vertinimo modeliui Procesų vertinimo modelis yra susietas su vienu arba daugiau procesų modelių. Vertinimo

modelis suformuoja įrodymų rinkimo ir procesų gebėjimo vertinimo pagrindą. Šis modelis

pateikia dviejų dimensijų požiūrį į proceso gebėjimą. Vienoje iš dimensijų – procesų

dimensijoje, aprašomi procesai kurie atitinka procesų modelyje aprašytus taikomosios srities

procesus. Kitoje – gebėjimų dimensijoje, vertinimo modelis aprašo gebėjimus kurie išreiškiami

gebėjimo lygiais ir procesų atributais. Normatyvinėje standarto dalyje ISO/IEC 15504-2

[ISO04b] pateikiami tokie reikalavimai vertinimo modeliui:

Vertinimo modelyje turi būti pateikta:

1. Procesų vertinimo modelio tikslas, apimtis ir sudedamieji elementai;

2. Procesų gebėjimo matavimo karkaso ir procesų modelio susiejimas;

3. Pastovaus rezultatų išreiškimo mechanizmas.

Vertinimo modelio apimtis

ISO/IEC 15504-2 pateikia tokius reikalavimus vertinimo modelio apimčiai:

1. Procesų vertinimo modelis turi susieti bent vieną procesą iš pateikto(ų) procesų

modelio(ų);


Mokymo medžiaga 40

2. Duotam procesui procesų vertinimo modelis turi susieti visus procesų gebėjimo

matavimo karkaso gebėjimo lygius arba ištisinį šių gebėjimo lygių rinkinį (pradedant pirmu

lygiu);

3. Procesų vertinimo modelyje turi būti apibrėžta jo apimtis pateikiant:

a. pasirinktą(us) procesų modelį(ius),

b. pasirinktus procesų modelio procesus,

c. pasirinktus procesų gebėjimo matavimo karkaso lygius.

Vertinimo modelio indikatoriai

ISO/IEC 15504-2 nurodo, kad procesų vertinimo modelyje turi būti rinkinys indikatorių,

kurie:

1. Aiškiai, tokia pat forma kaip ir pasirinktame procesų modelyje, nurodo proceso tikslus ir

rezultatus procesų vertinimo modelyje pasirinktiems procesams;

2. Rodo proceso atributų pasiekimą procesų vertinimo modelyje pasirinktuose procesų

gebėjimo lygiuose.

Indikatoriai operuoja procesų vertinimo modelyje pasirinktų procesų įgyvendinimo

lygmeniu.

Vertinimo modelio ir procesų modelio susiejimas

ISO/IEC 15504-2 sakoma, kad vertinimo modelyje turi būti pateiktas aiškus susiejimas

tarp vertinimo modelio sudedamųjų elementų ir pasirinkto procesų modelio procesų bei

atitinkamų proceso atributų iš procesų gebėjimo matavimo karkaso.

Susiejimas turi būti pilnas, aiškus ir vienareikšmis. Procesų vertinimo modelio indikatoriai

turi susieti:

1) pasirinkto procesų modelio procesus, apibrėžtus tikslais ir rezultatais ir

2) proceso atributus iš procesų gebėjimo vertinimo karkaso (įskaitant kiekvieno proceso

atributų pasiekimo rezultatus).

Tai įgalima procesų vertinimo modelius susieti su atitinkamais procesų modeliais, nors tų

modelių struktūra skiriasi.

Vertinimo rezultatų išreiškimas

ISO/IEC 15504-2 sakoma, kad vertinimo modelyje turi būti pateiktas formalus ir

patikrinamas vertinimo rezultatų pateikimo mechanizmas. Vertinimo rezultatai turi būti pateikti

kaip kiekvieno proceso, pasirinkto iš naudojamo procesų modelio, atributų įvertinimų rinkinys.

Pavyzdinis ISO/IEC 15504-2 reikalavimus atitinkantis programų kūrimo procesų gebėjimo

vertinimo modelis pateiktas penktojoje informacinėje ISO/IEC 15504 standarto dalyje. Esamos

CMMI versijos neatitinka ISO/IEC 15504 standarto reikalavimų: proceso sričių apibrėžimai turi

gebėjimo bruožų.


Mokymo medžiaga 41


[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 Software

Process Improvement and Capability Determination. IEEE Computer Society

Press, 1998.

[ISO98] ISO/IEC 15504: Information technology – Software process assessment, (parts 1-

9). International Organization for Standardization and the International

Electrotechnical 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 CMM

in 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 for

Software, Version 1.1 (CMU/SEI-93-TR-024). Pittsburgh, PA: Software

Engineering Institute, Carnegie Mellon University, 1993

[SEI04] Software Engineering Institute, Process Maturity Profile. Software CMM® 2004

Mid-Year Update. Software Engineering Institute, Carnegie Mellon University,

August 2004

[StG01] Standish Group, Extreme CHAOS. The Standish Group International, Inc, 2001.


Mokymo medžiaga 42

Programų sistemų inžinerija 4. Integruotas gebėjimo brandos modelis

Mokymo medžiaga 43

4. Integruotas gebėjimo brandos modelis

Motyvacija domėtis procesu IT sferoje buvo paskatinta sėkmės proceso efektyvumo

gerinime kitose pramonės šakose. Orientacijos į procesą ištakomis galima laikyti 1930 Walter

Shewhart pasiūlytus statistinės kokybės kontrolės principus, kuriuos toliau išvystė W. Edwards

Deming ir Joseph Juran.

Šių principų taikymo programų sistemoms pionieriumi galima laikyti Watts Humphrey ir

jo su kolegomis darbus, atliktus IBM ir SEI. Juose paskelbti principai ir sąvokos tapo gebėjimo

brandos modelių (angl. Capability Maturity Model - CMM) pagrindu.

CMM atsiradimas

Gebėjimo brandos modelis buvo sukurtas JAV vyriausybės užsakymu kaip metodas

programų sistemų kūrimo paslaugų teikėjų gebėjimo įvertinimui ir pirmą kartą paskelbtas 1987

metais. CMM pateikia evoliucinį kelią programų kūrimo proceso gerinimui. 1991 metais SEI

paskelbė gebėjimo brandos modelio programų sistemų kūrimui SW-CMM (angl. Capability

Maturity Model for Software) versiją 1.0, o 1993 metais – versiją 1.1. Buvo planuota rengti ir

versiją 2.0, bet atliktų darbų rezultatai buvo panaudoti CMMI kūrimui, pradėtam 1997 metais.

Nuo daugybės CMM prie vieno CMMI Nuo 1991 buvo sukurta visa eilė CMM modelių, skirtų įvairioms disciplinoms: programų

sistemų inžinerijai, sistemų inžinerijai, programų sistemų įsigijimui, darbo jėgos valdymui ir

ugdymui, integruotam produkto ir proceso kūrimui ir kt. Buvo suprasta, kad naudinga būtų turėti

vieną modelį, apimantį daugelį disciplinų. Tuo tikslu JAV Gynybos departamentas inicijavo

integruoto modelio CMM (angl. Capability Maturity Model Integration) kūrimą. Integruotas

modelis turėjo suteikti tokius privalumus:

- daugelio modelių integravimas leidžia pašalinti nesuderinamumus ir sumažinti

dubliavimąsi;

- bendras karkasas leidžia padidinti aiškumą ir suprantamumą, nes naudojama vieninga

terminologija, stilius ir bendri komponentai;

- tolydinės architektūros versija įgalina suderinamumą su ISO 15504;

- pakopinės architektūros versija užtikrina tiesioginį ryšį su CMM ir palengvina

migravimą nuo CMM prie CMMI;

- CMMI suteiks lankstų išplečiamą karkasą, kuris gali būti naudojamas kaip pagrindas

kuriant brandos modelius kitoms disciplinoms.

Šiuo metu yra išleistos keturios CMMI versijos, skirtos atitinkamai:

- programų sistemų kūrimui CMMI-SW (angl. CMMI for Software Engineering),


Mokymo medžiaga 44

- programų sistemų ir sistemų kūrimui CMMI-SE/SW (angl. CMMI for Systems

Engineering/ Software Engineering),

- programų sistemų, sistemų bei integruoto produkto ir proceso kūrimui CMMI-

SE/SW/IPPD (angl. CMMI for Systems Engineering/ Software Engineering/ Integrated

Product and Process Development),

- programų sistemų, sistemų bei integruoto produkto ir proceso kūrimui bei sistemų

įsigijimui CMMI-SE/SW/IPPD/SS (angl. CMMI for Systems Engineering/ Software

Engineering/ Integrated Product and Process Development/ Supplier Sourcing).

Trumpa CMMI istorija 1997 metais: JAV Gynybos departamentas inicijavo CMMI kūrimą

1998 metais: paskelbta CMMI modelio versija 1.0

1999 metais: paskelbta CMMI modelio versija 2.0

2000 metais: paskelbtas CMMI-SE/SW/IPPD

2002 metais: paskelbtas CMMI-SE/SW/IPPD/SS

Pagrindiniai CMMI šaltiniai CMMI 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ūra

Kaip jau buvo minėta, CMMI turi tiek pakopinės (palengvinimui migravimo iš CMM), tiek

tolydinė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):

Pavadinimas Tikslas

CAR Priežasčių analizė ir panaikinimas

(angl. Causal Analysis and

Resolution)

Identifikuoti defektų ir kitų problemų priežastis ir

imtis prevencinių veiksmų, siekiant išvengti

problemų ateityje.

CM Konfigūracijos valdymas (angl.

Configuration Management)

Nustatyti ir valdyti darbo produktų integralumą,

naudojant konfigūracijos identifikavimą,

konfigūracijos valdymą, konfigūracijos būsenos

apskaitą ir konfigūracijos auditus.


Mokymo medžiaga 45

Pavadinimas Tikslas

DAR Sprendimų analizė ir priėmimas

(angl. Decision Analysis and

Resolution)

Analizuoti galimus sprendimus, naudojant formalų

vertinimo procesą, kuris įvertina identifikuotas

alternatyvas pagal nustatytus kriterijus.

IPM Integruotas projekto valdymas

(angl. Integrated Project

Management)

Valdyti projektą ir suinteresuotų asmenų įtraukimą

pagal integruotą ir apibrėžtą procesą, kuris yra

pritaikomas konkrečiam projektui iš organizacijos

standartinių procesų aibės.

ISM Integruotas tiekėjo valdymas

(angl. Integrated Supplier

Management)

Iniciatyviai identifikuoti šaltinius produktų, kurie

gali būti panaudoti projekto reikalavimams

patenkinti, ir valdyti pasirinktus tiekėjus, užmezgant

bendradarbiavimo ryšius.

IT Integruotas komandų valdymas

(angl. Integrated Teaming)

Suformuoti ir palaikyti integruotą komandą darbo

produktų kūrimui.

MA Matavimai ir analizė (angl.

Measurement and Analysis)

Sukurti ir palaikyti matavimų sistemą valdymo

informaciniams poreikiams patenkinti.

OEI Organizacinė aplinka

integravimui (angl.

Organizational Environment for

Integration)

Pateikti infrastruktūrą integruoto produkto ir

proceso kūrimui ir valdyti personalo integravimą.

OID Organizacinės inovacijos ir

skleidimas (angl. Organizational

Innovation and Deployment)

Parinkti ir paskleisti inkrementinius ir inovatyvius

proceso pagerinimus, kurie išmatuojamai pagerina

organizacijos procesus ir naudojamas technologijas.

Pagerinimai palaiko organizacijos kokybės ir

proceso efektyvumo tikslus, išplaukiančius iš

organizacijos verslo tikslų.

OPD Organizacinis proceso

apibrėžimas (angl.

Organizational Process

Definition)

Apibrėžti ir valdyti aibę vartotinų organizacijos

procesų apibrėžimų.

OPF Organizacinis dėmesys procesui

(angl. Organizational Process

Focus)

Planuoti ir įgyvendinti organizacijos proceso

gerinimą, remiantis giliu supratimu einamojo

organizacijos proceso stipriųjų ir silpnųjų pusių.


Mokymo medžiaga 46

Pavadinimas Tikslas

OPP Organizacinis proceso vykdymas

(angl. Organizational Process

Performance)

Suformuoti ir valdyti kiekybinę organizacijos

procesų vykdymo efektyvumo sampratą, palaikant

kokybės ir proceso efektyvumo tikslus, pateikti

proceso efektyvumo duomenis, bazinius

komplektus ir modelius kiekybiniam organizacijos

vykdomų projektų valdymui.

OT Organizaciniai mokymai

(angl. Organizational Training)

Vystyti žmonių įgūdžius ir žinias taip, kad jie galėtų

atlikti savo roles tinkamai ir efektyviai.

PI Produkto integravimas

(angl. Product Integration)

Surinkti produktą iš produkto komponentų,

užtikrinti, kad integruotas produktas funkcionuoja

tinkamai, ir pateikti produktą.

PMC Projekto stebėjimas ir kontrolė

(angl. Project Monitoring and

Control)

Pateikti supratimą apie projekto progresą taip, kad

būtų galima imtis tinkamų korekcinių veiksmų, kai

projekto vykdymas iš esmės skiriasi nuo plano.

PP Projekto planavimas

(angl. Project Planning)

Sukurti ir valdyti planus, apibrėžiančius projekto

veiklas.

PPQA Proceso ir produkto kokybės

užtikrinimas (angl. Process and

Product Quality Assurance)

Pateikti darbuotojams ir vadovybei objektyvų

procesų ir susijusių darbo produktų supratimą.

QPM Kiekybinis projekto valdymas

(angl. Quantitative Project

Management)

Kiekybiškai valdyti apibrėžtas projekto veiklas, kad

pasiekti nustatytus projekto kokybės ir proceso

efektyvumo tikslus.

RD Reikalavimų apibrėžimas (angl.

Requirements Development)

Sukurti ir analizuoti užsakovo, produkto ir produkto

komponentų reikalavimus.

REQM Reikalavimų valdymas (angl.

Requirements Management)

Valdyti reikalavimus projekto produktams ir

produktų komponentams ir identifikuoti

neatitikimus tarp šių reikalavimų ir projekto planų

bei darbo produktų.

RSKM Rizikos valdymas (angl. Risk

Management)

Identifikuoti potencialias problemas prieš joms

įvykstant taip, kad rizikos valdymo veiklos gali būti

suplanuotos ir prireikus panaudotos produkto ar

projekto gyvavimo metu tam, kad sumažinti

neigiamą įtaką tikslų pasiekimui.


Mokymo medžiaga 47

Pavadinimas Tikslas

SAM Sutarties su tiekėju valdymas

(angl. Supplier Agreement

Management)

Valdyti įsigijimą produktų iš tiekėjų, su kuriais yra

formalūs susitarimai.

TS Techninis sprendimas

(angl. Technical Solution)

Suprojektuoti, sukurti ir įgyvendinti sprendimą,

tenkinantį reikalavimus. Sprendimas, projektavimas

ir įgyvendinimas pagal poreikius apima atskirus

produktus, produktų komponentus, produkto

gyvavimo ciklo procesus ar jų kombinacijas.

VAL Validavimas

(angl. Validation)

Parodyti, kad produkto komponentas, patalpintas į

tikslinę aplinką, tenkina numatyto naudojimo

reikalavimus.

VER Verifikavimas

(angl. Verification)

Užtikrinti, kad darbo produktai tinka jiems

apibrėžtai aplinkai.

Pakopinės architektūros CMMI modelis

Pakopinės architektūros CMMI modelio struktūra pateikta 4.1 paveikslėlyje.

Bendrieji bruožai

Brandos lygiai

Proceso sritis 1 (PA1) Proceso sritis 2 (PA2) Proceso sritis n (PAn)

Specifiniai tikslai Bendrieji tikslai

Specifinės praktikosĮsipareigojimas

atlikti

Sugebėjimas

atlikti

Tiesioginis

įgyvendinimas

Verifikavimo

įgyvendinimas

Bendrosios praktikos

4.1 pav. Pakopinės architektūros CMMI modelio struktūra

Pakopinėje architektūroje proceso sritys yra sugrupuotos į penkis brandos lygius. Tokiu

būdu nurodomas organizacijos proceso gerinimo kelias – kokios proceso sritys turi būti


Mokymo medžiaga 48

įgyvendintos, kad pasiekti atitinkamą brandos lygį. Tam, kad brandos lygis būtų pasiektas turi

būti įgyvendintos to lygio ir visų žemesnių brandos lygių proceso sritys.

Brandos lygiai numeruojami nuo 1 iki 5.

Brandos lygis Pakopinės architektūros brandos lygis

1 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 pirmą, yra priskirtos tokios proceso sričių aibės:

Brandos lygis Priskirtos proceso sritys

1: Pradinis -

2: Valdomas 7 proceso sritys:

REQM: Reikalavimų valdymas,

PP: Projekto planavimas,

PMC: Projekto stebėjimas ir kontrolė,

SAM: Sutarties su tiekėju valdymas,

MA: Matavimai ir analizė,

PPQA: Proceso ir produkto kokybės užtikrinimas,

CM: Konfigūracijos valdymas

3: 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ė ir priėmimas,


Mokymo medžiaga 49

Brandos lygis Priskirtos proceso sritys

OEI: 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 ir skleidimas,

CAR: Priežasčių analizė ir panaikinimas.

Tolydinės architektūros CMMI modelis

Tolydinė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 tikslai Bendrieji tikslai

Specifinės praktikos Bendrosios praktikosGebėjimo lygiai

4.2 pav. Tolydinės architektūros CMMI modelio struktūra

Tolydinės architektūros modelis nagrinėja kiekvienos proceso srities gebėjimą (gebėjimo

lygį) atskirai. 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 lygis

0 Nevykdomas (Incomplete)

1 Vykdomas (Performed)

2 Valdomas (Managed)

3 Apibrėžtas (Defined)

4 Kiekybiškai valdomas (Quantitatively Managed)

5 Optimizuojamas (Optimizing)


Mokymo medžiaga 50

Svarbu atkreipti dėmesį, kad pakopinėje architektūroje bet kuri organizacija automatiškai

turi 1-ą brandos lygį, t.y. šiam lygiui nėra jokių reikalavimų. Kad tolydinėje architektūroje

proceso sritis atitiktų 1-ą gebėjimo lygį, ji pati turi būti „pilnai“ įgyvendinta, t.y. turi vykdomos

visos š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ą brandos

lygiams. Tolydinėje architektūroje proceso sritys grupuojamos į 4 kategorijas: inžineriniai

procesai, projekto valdymo procesai, proceso valdymo procesai ir palaikantys procesai.

Kiekvienai kategorijai priskiriamos tokios proceso sričių aibės:

Kategorija Priskirtos proceso sritys

Proceso 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 ir skleidimas.

Projekto valdymo 8 proceso sritys:

PP: Projekto planavimas,

PMC: Projekto stebėjimas ir 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.

Palaikymo 6 proceso sritys:

CAR: Priežasčių analizė ir panaikinimas,

CM: Konfigūracijos valdymas,


Mokymo medžiaga 51

Kategorija Priskirtos proceso sritys

DAR: Sprendimų analizė ir priėmimas,

MA: Matavimai ir analizė,

PPQA: Proceso ir produkto kokybės užtikrinimas,

OEI: Organizacinė aplinka integravimui.

Bendra proceso sričių struktūra

Visų proceso sričių aprašymas CMMI pateikiamas pagal tokią bendrą struktūrą:

� Proceso srities vardas

• Tikslas

• Įvadinės pastabos

• Susijusios proceso sritys

• Specifiniai tikslai

o Specifinės praktikos

- Tipiniai darbo produktai

- Veiklos

• Bendrieji tikslai

o Bendrosios praktikos

- Bendrųjų praktikų detalizavimas

Proceso srities komponentus galima suskirstyti į tris klases, nusakančias komponentų

svarbumą, patenkinant gebėjimo lygio reikalavimus. Siūlomas toks komponentų klasifikavimas:

1. Privalomi komponentai

Privalomi komponentai aprašo, ką organizacija turi pasiekti, kad įgyvendinti gebėjimo

lygio reikalavimus. Šis pasiekimas turi būti matomas organizacijos procese, t.y. turi egzistuoti

įgyvendinimo įrodymai.

Privalomus komponentus naudoja vertinimo komanda tam, kad priimtų sprendimą, ar

proceso sritis įgyvendinta.

CMMI privalomi komponentai yra specifiniai tikslai ir bendrieji tikslai.

2. Tikėtini komponentai

Tikėtini komponentai aprašo, ką organizacija tipiškai įgyvendina, norėdama pasiekti

privalomus komponentus. Tikėtinus komponentus kaip gaires naudoja:

- įgyvendinantys proceso gerinimą;

- atliekantys proceso vertinimą.

CMMI tikėtini komponentai yra specifinės praktikos ir bendrosios praktikos.


Mokymo medžiaga 52

3. Informaciniai komponentai

Informaciniai komponentai pateikia detales, padedančias organizacijai susiformuoti kelią,

kaip įgyvendinti privalomus ir tikėtinus komponentus.

CMMI pateikia informacinius komponentus veiklų aprašymuose. Galima išskirti tokių tipų

informacinius komponentus: tipiniai darbo produktai, bendrųjų praktikų detalizavimas,

disciplinos plėtojimas, uždaviniai, praktiniai patarimai ir nuorodos.

Privalomi komponentai

Tikėtini komponentai

Informaciniai komponentai

Specifiniai tikslai

Bendrieji tikslai

Specifinės praktikos


Bendrųjų praktikų detalizavimas

Uždaviniai, praktiniai patarimai

Veiklos

Tipiniai darbo produktai

Disciplinos plėtojimas

Nuorodos

4.3 pav. CMMI proceso sričių struktūra

Bendrieji tikslai

Bendrųjų tikslų ir gebėjimo lygių sampratos yra labai glaudžiai susijusios. Štai kodėl

gebėjimo lygiai 2-5 ir bendrieji tikslai 2-5 formuluojami vienodais terminais. Bendrieji tikslai

atitinka 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 53

Bendrasis tikslas 1 yra susijęs su paties proceso įgyvendinimu, o kiti bendrieji tikslai

atitinka skirtingus proceso institucionalizavimo lygius. Reikia pastebėti, kad bendrieji tikslai yra

orientuoti į proceso palaikymo infrastruktūros sukūrimą.

Atitikimas tarp organizacijos brandos lygio ir proceso sričių gebėjimo lygių

Abi – pakopinė ir tolydinė – architektūros turi savų privalumų ir trūkumų, todėl kyla

natūralus klausimas: kaip brandos lygiai yra susiję su proceso sričių gebėjimais? Arba kitaip

sakant: jei žinome, kad organizacijos brandos lygis yra, pavyzdžiui, 2, ar galime pasakyti, kokio

gebėjimo lygio kiekviena proceso sritis toje organizacijoje? Arba jei žinome organizacijos

proceso sričių gebėjimo lygius, ar galime nustatyti organizacijos brandos lygį?

Atsakymai į šiuos klausimus nėra vienareikšmiai. Pirmiausia reikia pastebėti, kad

vertinimas pagal tolydinį modelį yra detalesnis, t.y. informacija apie proceso sričių gebėjimą yra

detalesnė, todėl įvertinimą pagal tolydinį modelį galima nesudėtingai atvaizduoti į vertinimo

pagal pakopinį modelį rezultatą – organizacijos brandos lygį. Taigi atvaizdavimas į gautų

gebėjimo įvertinimų į brandos lygį yra galimas.

Prieš atsakant į klausimą dėl atvirkš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ės

kalbame apie atvaizdavimą tarp vertinimų pagal skirtingos 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 skirtingi.

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) ir brandos lygių (BL),

pateikiamas 4.4 pav.

Proceso sritis BL GL1 GL2 GL3 GL4 GL5 Reikalavimų valdymas 2 Matavimai ir analizė 2 Projekto stebėjimas ir kontrolė 2 Projekto planavimas 2 Proceso ir produkto kokybės užtikrinimas 2 Sutarties su tiekėju valdymas 2 Konfigūracijos valdymas 2

Tikslinis profilis

2

Sprendimų analizė ir priėmimas 3 Produkto integravimas 3 Reikalavimų apibrėžimas 3 Techninis sprendimas 3 Validavimas 3 Verifikavimas 3

Tikslinis profilis

3


Mokymo medžiaga 54

Organizacinis proceso apibrėžimas 3 Organizacinis dėmesys procesui 3 Integruotas projekto valdymas 3 Rizikos valdymas 3 Organizaciniai mokymai 3 Organizacinis proceso vykdymas 4 Kiekybinis projekto valdymas 4

Tikslinis profilis 4

Organizacinės inovacijos ir skleidimas 5 Priežasčių analizė ir panaikinimas 5

Tikslinis profilis 5

4.4 pav. Atitikimas tarp CMMI proceso sričių gebėjimo lygių ir organizacijos brandos lygių

Vertinimas pagal CMMI

Vertinimas 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 Requirements for CMMI). Išskiriamos 3 pagrindinės vertinimo pagal CMMI

metodų klasės:

Klasė Pagrindinės metodo charakteristikos

A klasės vertinimo

metodas

� Pilnai įgyvendina visus ARC reikalavimus

� CMMI įvertinimai yra užfiksuoti, apie juos oficialiai informuota ir

jie gali būti naudojami organizacijų palyginimui

� Rezultatai gali būti transformuoti į ISO 15504*

B klasės vertinimo

metodas

� Dalinai įgyvendina ARC reikalavimus

� Pirminių vertinimo rezultatų pateikimas nebūtinas

� Nėra nurodymų galutinių rezultatų pateikimui

� Įvertinimai nėra aprašyti

� Rezultatai negali būti transformuoti į ISO 15504

C klasės vertinimo

metodas

� Dalinai įgyvendina ARC reikalavimus

� Pirminių 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 ir įrodymų pateikimas nėra būtinas

� Vertinimo komandos narių konsensusas nėra būtinas


Mokymo medžiaga 55

* 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 ir be tokio atvaizdavimo.

SCAMPI: standartinis vertinimo pagal CMMI proceso gerinimui metodas Vertinimas pagal SCAMPI įgalina:

- nustatyti dabartinio organizacijos darbo proceso stipriąsias ir silpnąsias vietas;

- sutelkti dėmesį į darbo proceso tobulinimus, kurie šiuo metu naudingiausi

organizacijai;

- nustatyti organizacijos gebėjimų brandos lygį.

Vertinimas pagal SCAMPI susideda iš trijų fazių ir vienuolikos esminių veiklų.

Fazė Veiklos

1.1 Reikalavimų analizė

1.2 Planavimas

1.3 Komandos subūrimas ir paruošimas

1.4 Reikiamų duomenų nustatymas

1. Planavimas ir

pasiruošimas vertinimui

1.5 Pasiruošimas duomenų rinkimui

2.1 Duomenų rinkimas

2.2 Gautų duomenų tikrinimas ir įvertinimas

2.3 Surinktos informacijos dokumentavimas

2. Vertinimas

2.4 Vertinimo rezultatų generavimas

3.1 Vertinimo rezultatų paskelbimas 3. Rezultatų pateikimas

3.2 Vertinimo rezultatų ir aprašų surinkimas ir perdavimas į archyvą

Reikalavimų analizės tikslas - nustatyti organizacijos verslo poreikius ir susieti vertinimo

tikslus su organizacijos verslo tikslais. Reikalavimų analizė numato vertinimo tikslų, apribojimų

(terminai, finansavimas ir kt.), apimties ir rezultatų nustatymą.

Planavimas apima reikalavimų (reikalingų resursų), susitarimų ir rizikų, susijusių su

vertinimu, dokumentavimą, darbų grafiko sudarymą.

Komandos subūrimo ir paruošimo tikslas – užtikrinti, kad komanda gali ir yra pasiruošusi

atlikti vertinimą. Veikla numato 3 žingsnius: nustatyti lyderį, parinkti komandos narius, paruošti

komandą vertinimui (komandos nariai turi susipažinti su SCAMPI metodika, vertinimo planu ir

pan.).

Reikiami duomenys – duomenys, betarpiškai reikalingi galutiniam įvertinimui gauti, o taip

pat palengvinantys pasiruošimą vertinimui, padedantys suprasti, kaip vyksta organizacijos darbo

procesas. Reikiamų duomenų nustatymas apima vertinimo procesui reikalingų duomenų ir


Mokymo medžiaga 56

instrumentų (anketų, duomenų bazių ir t.t.) dokumentavimas (sąrašo sudarymas), rolių

komandoje paskirstymą.

Pasiruošimas duomenų rinkimui numato reikiamų duomenų šaltinių nustatymą,

instrumentų ir technologijų, kurias nuspręsta naudoti, aprašymą (pvz. anketų sudarymą) bei

plano 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 ir įvertinami veiklų realizavimo trūkumai.

Kiekvienos veiklos realizavimas įvertinamas taip, kad jį būtų galima palyginti su CMMI

veiklomis. Yra keturi galimi įvertinimai:

• veikla yra pilnai realizuota, jeigu:

o egzistuoja tiesioginiai veiklos produktai ir jie pripažinti (vertinimo komandos)

tinkamais;

o yra bent vienas netiesioginis veiklos produktas ar veiklos įgyvendinimo patvirtinimas;

o veiklos įgyvendinime nepastebėta nei vieno esminio trūkumo;

• veikla yra didžia dalimi realizuota, jeigu:

o egzistuoja tiesioginiai veiklos produktai ir jie pripažinti (vertinimo komandos)

tinkamais;


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 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) ir stipriąsias vietas. Surinktos informacijos dokumentavimo

veikla taip pat numato duomenų rinkimo plano peržiūrą ir (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ų ir/ar brandos lygio įvertinimas.

Visi daromi pastebėjimai ir charakteristikos yra fiksuojami raštu. Pirmiausia yra

nagrinėjamos silpnosios proceso veiklų vietos, lyginant su atitinkamų CMMI modelio praktikų


Mokymo medžiaga 57

tikslais. Stipriųjų vietų apžvalga turi apimti tik tas realizuotas proceso veiklas, kurios yra

išskirtinai efektyvios, „nereikalingos“ stipriosios vietos, kurios tik pavaizduoja pakankamą

praktikų realizavimą, gali stipriai apsunkinti duomenų valdymą. Gali būti nagrinėjamos ir

veiklos, naudojamos kaip alternatyva CMMI praktikoms ir padedančios pasiekti atitinkamos

proceso srities tikslus.

Vertinimo rezultatų generavimas. Remiantis visa surinkta informacija yra vertinamas

kiekvieno CMMI tikslo pasiekiamumas. Tikslas yra pasiektas, jeigu:

- visos susijusios su tuo tikslu veiklos organizacijoje yra pilnai ar didžia dalimi

realizuotos, ir

- trūkumai, susiję su tuo tikslu, neturi reikšmingos įtakos tikslo pasiekiamumui.

Vertinimo rezultatų paskelbimo tikslas – pateikti organizacijos vadovybei patikimus atlikto

vertinimo rezultatus, kurie gali naudojami tolimesnių sprendimų priėmimui, pristatyti dabartinio

organizacijos darbo proceso stipriąsias ir silpnąsias vietas, pateikti darbo proceso brandos

įvertinimą.

Vertinimo rezultatai, organizacijos pageidavimu, tampa konfidencialia informacija. Todėl

SCAMPI numato vertinimo rezultatų surinkimo ir perdavimo į organizacijos archyvą procedūrą.


[SWc02] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Software

Engineering, Continuous Representation (CMU/SEI-2002-TR-028). Pittsburgh,

PA: Software Engineering Institute, Carnegie Mellon University, 2002.

[SWs02] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Software

Engineering, Staged Representation (CMU/SEI-2002-TR-029). Pittsburgh, PA:

Software Engineering Institute, Carnegie Mellon University, 2002.

[SEc02] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems

Engineering and Software Engineering, Continuous Representation (CMU/SEI-

2002-TR-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon

University, 2002.

[SEs02] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems

Engineering and Software Engineering, Staged Representation (CMU/SEI-2002-

TR-002). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon

University, 2002.

[IPPDc02] Capability Maturity Model Integration (CMMI), Version 1.1 CMMI for Systems

Engineering/Software Engineering/Integrated Product and Process Development,


Mokymo medžiaga 58

Continuous Representation (CMU/SEI-2002-TR-003). Pittsburgh, PA: Software

Engineering Institute, Carnegie Mellon University, 2002.

[IPPDs02] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems

Engineering/Software Engineering/Integrated Product and Process Development,

Staged Representation (CMU/SEI-2002-TR-004). Pittsburgh, PA: Software

Engineering Institute, Carnegie Mellon University, 2002.

[SSc02] Capability Maturity Model Integration (CMMI), Version 1.1 CMMI for Systems

Engineering/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.

[SSs02] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems

Engineering/Software Engineering/Integrated Product and Process Development/

Supplier Sourcing, Staged Representation (CMU/SEI-2002-TR-012). Pittsburgh,


[ARC01] Appraisal Requirements for CMMI, Version 1.1 (ARC, V1.1) (CMU/SEI-2001-

TR-034) Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon

University, 2001.

[SCA01] Standard CMMI® Appraisal Method for Process Improvement (SCAMPI),

Version 1.1: Method Definition Document (CMU/SEI-2001-HB-001) Pittsburgh,


[KJ03] M.K. Kulpa, K.A. Johnson, Interpreting the CMMI: A Process Improvement

Approach. Auerbach Publications, 2003, ISBN: 0849316545

Programų sistemų inžinerija 5. Programų kūrimo proceso modelių sąryšis

Mokymo medžiaga 59

5. Programų kūrimo proceso modelių sąryšis

Du pagrindiniai programų kūrimo proceso vertinimo ir gerinimo modeliai yra CMMI ir

ISO/IEC 15504. CMMI pakopinės architektūros modelis pateikia standartinį proceso gerinimo

kelią ir patrauklų bei paprastą organizacijos programų kūrimo proceso brandos matą.

ISO/IEC 15504 užtikrina organizacijos programų kūrimo procesų gebėjimo detalaus profilio

sudarymo galimybę ir įgalina individualų programų kūrimo procesų gerinimo kelią.

Priklausomai nuo veiklos tikslų organizacijos pasirenka pakopinės ar tolydinės

architektūros modeliu paremtą programų kūrimo proceso gerinimo kelią. Tačiau net ir pasirinkę

vieną iš modelių, organizacijos nori pasinaudoti kito modelio teikiamais privalumais.

Pavyzdžiui, organizacija pasirinkusi pakopinį gerinimo kelią, kur vienos pakopos siekimo

trukmė tęsiasi iki 2 metų, smulkesnių žingsnių atlikimui gali pasiremti tolydiniu procesų

modeliu. Antra vertus, organizacija taikanti tolydinį veiklos gerinimo modelį, kuris operuoja

procesų gebėjimo profiliu, gali norėti savo veiklos brandą pasilyginti paprastu brandos lygio

matu, o taip pat gali norėti pasinaudoti CMMI siūlomu standartiniu organizacijos programų

kūrimo proceso gerinimo keliu.

ISO/IEC 15504

Process

PA1.1

Process Area

PA2-PA5

Outcome

Achievement

CMMI

Generic Practice

Specific Practice

5.1 pav. Modelių sąryšio schema

Išnagrinėjus atitinkamybę tarp CMMI brandos lygių ir ISO/IEC 15504 procesų gebėjimų

profilių, remiantis Software Quality Institute (Australija) mokslininkų darbais [RTC01], vis dar


Mokymo medžiaga 60

cituojamais naujausiose knygose [Loo04a, Loo04b], gauti nauji rezultatai, patikslinantys

atitinkamybę tarp CMMI brandos lygių ir ISO/IEC 15504 procesų gebėjimų profilių [MR06].

Supaprastinta modelių struktūra ir 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ų ir

ISO/IEC 15504 procesų gebėjimo profilių (žiūr. 5.2 pav.: “ML” yra CMMI pakopinės

architektū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 priskiriamas “brandos lygio N” profiliui, jei jo gebėjimo lygis yra N


Mokymo medžiaga 61

5.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, nors

dalis jų rezultatų (outcomes) ir pasiekimų (achievements) yra užtikrinami atitinkamo brandos

lygio CMMI proceso sritimis. Norėtųsi detalesnio modelių atvaizdavimo, kuris parodytų tikslius

gebėjimo profilius, kuriuos užtikrina CMMI brandos lygiai.

Be to, kyla abejonės dėl 4-o ir 5-o brandos lygio atvaizdavimo, nes remiantis sąryšiu tarp

CMMI pakopinio ir tolydinio modelių galima teigti, kad 4-as ir 5-as brandos lygiai negali

garantuoti 4-o ar 5-o gebėjimo lygio nė vienai proceso sričiai, taigi natūralu, kad ir nė vienam

ISO/IEC 15504 modelio procesui. Žinoma, realioje 4-o ar 5-o brandos lygio organizacijoje turėtų

būti 4-o ir 5-o gebėjimo lygio proceso sričių/procesų, bet pats CMMI pakopinis modelis

nesuteikia pakankamai informacijos nustatymui, kokios konkrečios proceso sritys/procesai bus

4-o ir 5-o gebėjimo lygio.

5.3 pav. Patikslinti ISO/IEC 15504 procesų gebėjimo profiliai, atitinkantys CMMI brandos lygius [MR06]


Mokymo medžiaga 62

Remiantis ta pačia CMMI proceso sričių atvaizdavimo į ISO/IEC 15504 proceso dimensiją

schema, procesų vykdymas (1-as gebėjimo lygis) ir gebėjimo atributų pasiekimas buvo įvertinti

procentais, darant prielaidą, kad visi procesų rezultatai (outcomes) ir pasiekimai turi vienodus

svorius.

Proceso atributų (PA) pasiekimas įvertintas procentais (N – iki 15 %, P – nuo 15 % iki

50 %, L – nuo 50 % iki 85 %, F - virš 85 %) ir šių įvertinimų pagrindu nustatyti procesų

gebėjimo lygiai.

Patikslinti ISO/IEC 15504 procesų gebėjimo profiliai, atitinkantys CMMI brandos lygius

pateikti 5.3 pav.

Darytina bendra išvada, kad pakopinės architektūros modeliai yra atskiras atvejis tolydinės

architektūros modelių, nes pakopinės architektūros brandos lygiai gali būti išreikšti tolydinės

architektūros modelių procesų gebėjimo profiliais. Šių dviejų architektūrų modeliai gali būti

suderinti: smulkius gerinimo veiksmus valdant tolydinio modelio priemonėmis, o sudaryti

gerinimo veiksmų programą ir fiksuoti etapinius brandos pasiekimus remiantis pakopinės

architektūros modeliais.


[MR06] A. Mitasiunas, S. Ragaisis, Relationship between CMMI Maturity Levels and

ISO/IEC 15504 Processes Capability Profiles, 2006.

[RTC01] T.P.Rout, A.Tuffley, B.Cahill. CMMI Evaluation: Capability Maturity Model

Integration Mapping to ISO/IEC 15504 2:1998, Software Quality Institute, Griffith

University, Brisbane, 2001.



[Loo04b] H.V. Loon, Process Assessment and ISO/IEC 15504. A Reference Book. Springer,

2004.

Programų sistemų inžinerija 6. Projektas PKP Branda

Mokymo medžiaga 63

6. Projektas PKP Branda

Šiame skyriuje aptariami Vilniaus universiteto, Kauno technologijos universiteto ir

pirmaujančių Lietuvos IT įmonių „Alna“ ir „Sintagma“ atlikto projekto „Brandaus programų

kūrimo proceso įdiegimo metodikos ir instrumentinių priemonių sukūrimas (PKP Branda)“

[VU05] rezultatai. Projektą rėmė Lietuvos valstybinio mokslo ir studijų fondas pagal „Aukštųjų

technologijų plėtros programą“, kurios pagrindinis tikslas buvo sudaryti sąlygas Lietuvos

įmonėms eksportuoti produktus ir paslaugas.

Vienas iš projekto rezultatų yra brandaus programų kūrimo proceso modelis, sukurtas

orientuojantis į programų kūrimo proceso vertinimą ir gerinimą Lietuvos IT įmonėse. Jam buvo

parinkta tolydinė architektūra, nes ji geriau tinkama proceso gerinimui.

Brandaus programų kūrimo proceso modelis

Brandaus programų kūrimo proceso modelio paskirtis – suteikti pagrindą proceso

apibrėžimui ir vertinimui, užtikrinant, kad proceso apibrėžimas bei vertinimo rezultatai remiasi

programų kūrimo proceso inžinerijos geriausia patirtimi, yra sulyginami su kitų vertinimų

rezultatais bei dera su pasaulyje pripažintais standartais.

Per paskutinius metus įvyko esminė evoliucija programų kūrimo proceso vertinimo ir

gerinimo standartizacijoje. Evoliucijos kryptis – abstrahavimasis nuo programų kūrimo proceso

ir aplamai nuo konkrečių vertinamų procesų ir akcentavimas procesų vertinimo, paliekant

proceso gerinimo aspektus informatyviame lygmenyje.

Šios evoliucijos pasekoje priimta procesų vertinimo standarto dalis ISO/IEC 15504-2

bendroji dalis, kurioje apibrėžta vertinamų procesų gebėjimo (brandos) dimensija, suformuluoti

reikalavimai vertinamų procesų dimensijai ir vertinimo modeliui, susiejančiam vertinamų

procesų dimensiją su procesų gebėjimo dimensija. Programų kūrimo proceso dimensija, buvusi

ankstesnių versijų standarto ISO/IEC 15504 sudėtine dalimi, pašalinta iš šio standarto ir perėjo į

adaptuotą programų kūrimo proceso gyvavimo ciklo standartą ISO/IEC 12207:2002 amd1 ir

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, tenkinantis

ISO/IEC 15504-2 reikalavimus procesų gebėjimo vertinimo modeliui. Pagrindinis reikalavimas

naudojamam vertinimo modeliui yra gebėjimo dimensijoje apimti ištisinę sritį, pradedant

pirmuoju lygiu, o procesų dimensijoje apimti bent vieną vertinamą procesą. Pavyzdinis

programų kūrimo procesų gebėjimo vertinimo modelis yra rengiamas kaip standarto dalis

ISO/IEC 15504-5, o pavyzdinis sistemų kūrimo procesų gebėjimo vertinimo modelis yra


Mokymo medžiaga 64

rengiamas kaip standarto dalis ISO/IEC 15504-6. Standarto dalis ISO/IEC 15504-5 turėjo

pasirodyti 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 ir yra

suderinamas su pavyzdiniu programų kūrimo proceso vertinimo modeliu ISO/IEC 15504-5.

6.1 pav. PKP Branda programų kūrimo proceso modelio architektūra

Modelyje visuminio proceso veiklos grupuojamos į vardinius procesus. Vardiniai procesai

apibrėžiami jiems keliamais tikslais ir tuos tikslus įgyvendinančiomis veiklomis, modelyje

vadinamomis bazinėmis praktikomis. Taip pat su kiekvienu vardiniu procesu asocijuojami

sukuriami ir naudojami darbo produktai.

Kiekvieno vardinio proceso gebėjimo lygis nustatomas pagal bendrinių proceso

charakteristikų, esminių proceso gebėjimui užtikrinti, buvimą. Bendrinės proceso

charakteristikos modelyje vadinamos proceso atributais ir apibrėžiamos bendrosiomis

praktikomis, bendriniais resursais bei susijusiais darbo produktais, kurie padeda pasiekti proceso

charakteristikas.

Brandaus programų kūrimo proceso charakteristikos išskiriamos į proceso ir brandos

dimensijas. Proceso dimensija apibrėžiama, nusakant programų kūrimo procesų kategorijas,

pačius vardinius procesus, procesų tikslus, bazines praktikas ir darbo produktus. Brandos

dimensija apibrėžiama proceso atributais, kuriais turi pasižymėti vardiniai procesai ir kurie

Procesai

PKP Branda programų kūrimo proceso modelis

Procesų kategorijos

Bazinės praktikos

Darbo produktai

Gebėjimo lygiai

Proceso atributai


Bendriniai resursai

Bendriniai darbo produktai

Procesų dimensija Brandos dimensija


Mokymo medžiaga 65

modeliuoja minėtas išmatuojamas proceso charakteristikas, įgyvendinamas bendrosiomis

praktikomis, bendriniais resursais ir susijusiais darbo produktais.

Brandaus programų kūrimo proceso modelio proceso dimensiją sudaro 9 procesų

kategorijos ir 48 vardiniai procesai:

ACQ.1 Pasiruošimas įsigijimui ENG.1 Reikalavimų išsiaiškinimas

ACQ.2 Tiekėjo pasirinkimas ENG.2 Sistemos reikalavimų analizė

ACQ.3 Susitarimas dėl kontrakto ENG.3 Sistemos architektūros projektavimas

ACQ.4 Tiekėjo stebėjimas ENG.4 Programinės įrangos reikalavimų analizė

ACQ.5 Kliento apsisprendimas ENG.5 Programinės įrangos projektavimas

SPL.1 Tiekėjo pasiūlymai ENG.6 Programinės įrangos projekto realizavimas

SPL.2 Produkto laida ENG.7 Programinės įrangos integravimas

SPL.3 Produkto priėmimo palaikymas ENG.8 Programinės įrangos testavimas

OPE.1 Eksploatacinis naudojimas ENG.9 Sistemos integravimas

OPE.2 Kliento palaikymas ENG.10 Sistemos testavimas

SUP.1 Kokybės užtikrinimas ENG.11 Programinės įrangos instaliavimas

SUP.2 Verifikavimas ENG.12 Programinės įrangos ir sistemos priežiūra

SUP.3 Validavimas MAN.1 Organizacijos vieningumo užtikrinimas

SUP.4 Jungtinės peržiūros MAN.2 Organizacijos valdymas

SUP.5 Auditas MAN.3 Projekto valdymas

SUP.6 Produkto vertinimas MAN.4 Kokybės valdymas

SUP.7 Dokumentavimas MAN.5 Rizikos valdymas

SUP.8 Konfigūracijos valdymas MAN.6 Matavimai

SUP.9 Problemų sprendimo valdymas PIM.1 Proceso įtvirtinimas

SUP.10 Keitimų poreikio valdymas PIM.2 Proceso vertinimas

RIN.1 Personalo vadyba PIM.3 Proceso gerinimas

RIN.2 Apmokymai REU.1 Inventoriaus valdymas

RIN.3 Žinių valdymas REU.2 Pakartotinio panaudojimo valdymas

RIN.4 Infrastruktūra REU.3 Dalykinės srities inžinerija

Modelio brandos dimensiją sudaro 6 lygiai ir 9 atributai:

0 lygis: Nevykdomas -

1 lygis: Vykdomas PA1.1 Proceso atlikimo atributas

2 lygis: Valdomas PA2.1 Proceso atlikimo valdymo atributas

PA2.2 Darbo produktų valdymo atributas

3 lygis: Apibrėžtas PA3.1 Proceso apibrėžimo atributas


Mokymo medžiaga 66

PA3.2 Proceso paplitimo atributas

4 lygis: Nusakomas PA4.1 Proceso matavimo atributas

PA4.2 Proceso kontroliavimo atributas

5 lygis: Optimizuojamas PA5.1 Proceso inovatyvumo atributas

PA5.2 Proceso gerinimo atributas

Programų kūrimo proceso gerinimo metodika

Proceso gerinimo iniciatyva gali atsirasti bet kuriame organizacijos hierarchiniame lygyje,

tačiau bet kuriuo atveju būtinas vadovybės dalyvavimas, nes be jo proceso gerinimui nebus

suteiktas reikiamas prioritetas ir nebus užtikrinti būtini resursai.

Proceso gerinimas reikalauja einamojo proceso supratimo ir aiškių gerinimo tikslų. Tam,

kad proceso gerinimas būtų sėkmingas, reikia investicijų, planavimo, dedikuotų žmonių,

vadovybės laiko ir pastangų. Proceso gerinimas turi teikti naudą organizacijai ir suinteresuotumą

dalyvaujantiems žmonėms. Gerinimas turi būti pastovus, evoliucionuojantis, apimantis visus

organizacijos darbuotojus ir nuolatinį mokymąsi. Proceso pakeitimai nebus išlaikyti be

sąmoningų pastangų ir reguliaraus palaikymo. Organizacijos poreikiai ir verslo tikslai nusako

proceso gerinimo tikslus ir padeda nustatyti gerinimo prioritetus.

Organizacijoms, siekiančioms pagerinti savo programų kūrimo procesą, siūloma naudoti

proceso gerinimo programą, sudarytą iš 8 pagrindinių žingsnių:

Nagrinėti organizacijosverslo tikslus

Paskleisti proceso

pakeitimus

Įgyvendinti gerinimo veiksmus

Sudaryti veiksmų planą

Patvirtinti proceso

pakeitimus

Stebėti proceso vykdymą

Inicijuoti proceso gerinimą

Atlikti proceso vertinimą

6.2 pav. Programų kūrimo proceso gerinimo schema

Toks ciklas yra skirtas planingam, nuosekliam ir valdomam organizacijos proceso

gerinimui (pavienis proceso pakeitimas gali būti atliktas paprasčiau). Apibrėžti žingsniai yra


Mokymo medžiaga 67

esminiai sėkmingam proceso gerinimui, bet taikant mažose organizacijose kai kurie žingsniai

gali būti apjungti.

Nagrinėti organizacijos verslo tikslus Programų kūrimo proceso gerinimas turi remtis organizacijos verslo tikslais ir padėti juos

pasiekti, todėl prieš pradėdama proceso gerinimą, organizacija turi išanalizuoti savo poreikius ir

nustatyti verslo tikslus, jei tai nebuvo padaryta. Ši analizė padeda identifikuoti proceso gerinimo

poreikį ir ko bus siekiama.

Labai svarbu turėti gerinimo „sponsorių“ organizacijos vadovybėje, kad užtikrinti finansinį

ir motyvuojantį palaikymą, todėl organizacijos verslo tikslų nustatymą tikslinga pradėti

susitikimu su vadovybe.

Organizacijos verslo tikslai tradiciškai yra susiję su užsakovų pasitenkinimo siekimu,

organizacijos konkurencingumo ir verslo vertės didinimu. Šie verslo tikslai gali būti pasiekiami:

didinant produktų ir paslaugų kokybę, mažinant kūrimo ir palaikymo sąnaudas, pagreitinant

projektų atlikimą, gerinant proceso valdymą, mažinant skirtumus tarp vykdomų projektų.

Proceso gerinimo inicijavimo veiksniais gali būti: užsakovų nepasitenkinimas dėl vėluojančių

projektų ir klaidų pateiktuose produktuose, per dideli projektų kaštai, noras pagerinti turimų

resursų panaudojimą ir organizacijos veiklos efektyvumą.

Reikia susieti aukšto lygio verslo tikslus su proceso tikslais ir 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, kuriuo

bus 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 ir įsipareigoja diegti proceso

pakeitimus. Reikia įvertinti, ar organizacijoje nusistovėjusi pripažinimo ir skatinimo sistema

palaikys gerinime dalyvaujančius darbuotojus, ar organizacinė kultūra palanki proceso

gerinimui.

Jei organizacija yra nepasiruoš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 ir

reikalaujantis investicijų procesas, kad diegiant proceso pakeitimus teks įveikti organizacines,

kultūrines ir, galbūt, technologines kliūtis. Proceso gerinimui pristatyti reikia organizuoti

susitikimus su vadovybe ir dalyvausiančiais darbuotojais.


Mokymo medžiaga 68

Organizacijos verslo tikslai yra pakankamai pastovūs ir kiekvienoje gerinimo ciklo

iteracijoje nebūtina juos iš naujo nagrinėti, tačiau laikas nuo laiko jie turėtų būti peržiūrimi ir

prireikus atnaujinami.

Šio žingsnio rezultatai yra:

- identifikuoti organizacijos aukščiausio lygio verslo tikslai;

- verslo tikslai susieti su proceso tikslais ir jo gerinimo poreikiais;

- įvertintas organizacijos pasirengimas 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, priskirtais

resursais, projekto planu ir valdymu, kontroliniais taškais. Svarbu, kad šiam projektui

organizacijoje 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 sudarytas

proceso gerinimo projekto Priežiūros komitetas, kuris seka projekto eigą ir užtikrina resursus.

Priežiūros komitetas sudaromas iš vadovybės atstovo (gerinimo „sponsoriaus“), proceso

gerinimo projekto vadovo ir atsakingų už resursų skyrimą. Mažose organizacijose priežiūros

komitetas gali būti ir 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į ir išaugančias sąnaudas. Be to, didelei komandai bus sudėtinga reguliariai

susirinkti. 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 ir

Priežiūros komitetas.

Atliekant proceso gerinimą pirmą kartą, kad geriau susivokti esamoje situacijoje, sudaryti

sąlygas vertinimui ir 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ų organizacijos

projektų gyvavimo ciklo modelio aprašymo:

- nurodant vykdomus procesus, jų bazines praktikas, naudojamus ir sukuriamus darbo

produktus;

- pateikiant naudojamų ir sukuriamų darbo produktų charakteristikas (aprašymus).


Mokymo medžiaga 69

Realios organizacijos veiklos atvaizdavimas į PKP Branda modelį padeda suderinti

sąvokas (rasti atitikmenis tarp organizacijoje naudojamų ir modelio sąvokų), labiau struktūrizuoti

ir detalizuoti organizacijos veiklos apibrėžimą (kai kurie organizacijos veiklos aspektai yra tarsi

savaime suprantami ir todėl gali likti neįtraukti į veiklos modelį). Net jei organizacijos ir

vertinimo modelio procesų apibrėžimai panašūs, pravartu turėti išreikštinai dokumentuotą jų

atitikimą. Jeigu organizacijos procesai bei naudojama terminologija smarkiai skiriasi nuo

modelio, tai parengti detalų organizacijos veiklos atvaizdavimą į modelio procesus yra tiesiog

būtina, kadangi vertinimas atliekamas pagal modelio procesų apibrėžimus ir reikia aiškiai žinoti,

kurios organizacijos veiklos atitinka modelyje apibrėžtų procesų veiklas. Organizacijos veiklos

atvaizdavimas į PKP Branda modelį parengiamas procesų darbo produktų lygmenyje.

Rekomenduojama organizacijos veiklos konkretizavimą ir atvaizdavimą į PKP Branda

modelį daryti iteratyviai.

Atlikti proceso vertinimą Proceso vertinimo metu nustatomas organizacijos procesų gebėjimo profilis ir kartu

surenkama procesų būklės medžiaga, kurios pagrindu galima nustatyti gerinimo veiksmus ir

prioritetus.

Prieš pradedant proceso vertinimą, nustatoma vertinimo apimtis: kokie procesai ir iki kurio

gebėjimo lygio bus vertinami. Vertinimo apimtį gali tekti nustatyti tiek organizacijos

naudojamais procesų terminais, tiek PKP Branda modelio procesų terminais (organizacijos –

tam, kad būtų natūraliai suprantama organizacijos atstovams, modelio terminais – vertinimo

tikslais). Vertinimo apimties apibrėžime fiksuojama vertinimo apimtis PKP Branda modelio

terminais.

Lietuvoje yra aktualu visų pirma 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) ir priežiūrą (ENG.12). Tam, kad programinės įrangos kūrimo

inžineriniai procesai galėtų pasiekti antrą gebėjimo lygį, yra būtina, kad jų atlikimą ir valdymą

paremtų organizacinių procesų ir pagalbinių procesų kategorijų procesai.

Minimalų būtiną tokių procesų rinkinį sudaro Projektų valdymo procesas (MAN.3) ir

pagalbiniai procesai: Konfigūracijos valdymas (SUP.8), Kokybės užtikrinimas (SUP.1) ir

Problemų sprendimo valdymas (SUP.9). Daugumos Lietuvos IT įmonių tikslinis procesų

gebėjimo profilis artimiausių 2-3 metų laikotarpiui yra parodytas lentelėje:

Procesas Siekiamas lygis

ENG.1 Reikalavimų išsiaiškinimas 2

ENG.4 Programinės įrangos reikalavimų analizė 2


Mokymo medžiaga 70

ENG.5 Programinės įrangos projektavimas 2

ENG.6 Programinės įrangos projekto realizavimas 2

ENG.7 Programinės įrangos integravimas 2

ENG.8 Programinės įrangos testavimas 2

ENG.11 Programinės įrangos instaliavimas 2

ENG.12 Programinės įrangos ir sistemos priežiūra 2

MAN.3 Projekto valdymas 1

SUP.1 Kokybės užtikrinimas 1

SUP.8 Konfigūracijos valdymas 1

SUP.9 Problemų sprendimo valdymas 1

Jei organizacija turi tikslą sertifikuoti savo programų kūrimo procesą antram CMMI

pakopinės architektūros lygiui, į vertinimą galėtų būti įtraukti visi procesai, susiję su antro lygio

CMMI proceso sritimis. Toks procesų sąrašas buvo nustatytas pakopinės ir tolydinės

architektūros modelių sąryšio tyrimais.

Pasirinkus vertinamų procesų rinkinį, kiekvieno proceso vertinimas techniškai yra panašus

– kiekvienam procesui, pagal siekiamą nustatyti gebėjimą, tikrinama kokiais proceso atributais

jis pasižymi.

Vertinimo modelis reikalauja, kad, norint nustatyti (arba įrodyti), jog vertinamas procesas

yra pirmojo arba antrojo gebėjimo lygio, reikalinga pagrįsti, kad to proceso kontekste pirmojo ir

antrojo gebėjimo lygio proceso atributai yra įgyvendinti su tokiais įverčiais:

Proceso atributas Vertinant 1-ajam lygiui Vertinant 2-ajam lygiui

PA 1.1 Proceso atlikimas Dažnai arba visada Visada

PA 2.1 Vykdymo valdymas - Dažnai arba visada

PA 2.2 Darbo produktų valdymas - Dažnai arba visada

Tai yra, norint įvertinti, ar proceso gebėjimas pasiekia pirmąjį gebėjimo lygį, reikia

pagrįsti, kad to proceso kontekste PA 1.1 reikalavimai įgyvendinami dažnai. Norint įvertinti, ar

pasiekia antrąjį lygį, reikia pagrįsti, kad procesas PA 1.1 reikalavimus įgyvendina visada bei

dažnai įgyvendina PA 2.1 ir PA 2.2 reikalavimus.

Norint pagrįsti proceso atributo įgyvendinimą, tikrinama, ar procesas pasiekia vertinimo

modelyje apibrėžtus to atributo pasiekimus (proceso gebėjimo tikslus). Gebėjimo pasiekimus

organizacijai leidžia pasiekti modelyje aprašytos bendrosios praktikos, todėl praktiškai

pasiekimų patikrinimas susiveda į bendrųjų praktikų įgyvendinimo patikrinimą, pagal praktikų

paplitimą išvedant proceso atributo įgyvendinimo lygį (dažnai ar visada). Kiekvieno atributo


Mokymo medžiaga 71

nustatyti įgyvendinimo lygiai ir aukščiau pateikta lentelė leidžia išvesti vertinamo proceso

gebė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 ir proceso

atributų pasiekimo įrodymai arba, priešingai, proceso trūkumai, neleidžiantys pasiekti proceso

gebėjimo. Vertinimo metu užfiksuoti trūkumai tampa įeities duomenimis rengiant proceso

gerinimo veiksmų planą.

Sudaryti veiksmų planą Remiantis vertinimo rezultatais (faktiniu procesų gebėjimo profiliu, vertinimo metu

nustatytomis problemomis) ir organizacijos verslo tikslais, nustatomas tikslinis (siekiamas)

procesų gebėjimo profilis, nurodant reikiamus procesus ir jų gebėjimo atributų reikiamas

reikšmes, ir sudaromas veiksmų planas.

Netikslinga siekiamą procesų profilį iš karto apibrėžti kaip „idealų“ (visi procesai 4-5

lygio). Tikslinis procesų profilis turėtų atspindėti einamuosius verslo tikslus: jei kažkurie

procesai, būdami antro ar net pirmo lygio, atitinka einamuosius verslo tikslus, reikėtų investuoti į

kitų procesų gerinimą. Paprastai sakant, tikslinis procesų profilis turėtų atspindėti verslo tikslus,

o ne atvirkščiai. Tam tikrą išimtį iš šios taisyklės sudaro atvejis, kai organizacija yra nusistačiusi

tikslą gauti, pavyzdžiui, 2-ą lygį pagal CMMI. Tokio įvertinimo turėjimas gali sudaryti

galimybes gauti naujus užsakymus iš užsienio. Šiuo atveju tikslinį procesų profilį nusako CMMI

2-o lygio reikalavimai.

Proceso gerinimą reikėtų daryti evoliuciniu būdu, nes per daug radikalūs proceso

pakeitimai gali įnešti sumaištį į organizacijos veiklą, sulaukti darbuotojų pasipriešinimo ir tokiu

bū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 pateikiamas

1 priedo pavyzdyje).

Remiantis procesų gebėjimo tiksliniu (tarpiniu) profiliu, sudaromas veiksmų planas. Jei

organizacija siekia pasirinkto gerinimui vardinio proceso pirmo gebėjimo lygio, tai nustatant,

kokios šio vardinio proceso veiklos turi būti atnaujintos ar įdiegtos ir kokie darbo produktai

turėtų būti sukuriami, reikia remtis programų kūrimo proceso modelyje šiam procesui

apibrėžtomis bazinėmis praktikomis ir jų darbo produktais. Nebūtina, kad įmonės realiame

procese vykdomos veiklos ir kuriami darbo produktai „vienas prie vieno“ sutaptų su modelyje


Mokymo medžiaga 72

apibrėžtais, ypatingai nedideliuose ir mažuose projektuose: kelios modelio bazinės praktikos ar

darbo produktai gali būti apjungiami į vieną.

Siekiant antro (ar aukštesnio) lygio atributų įgyvendinimo pasirinktame gerinimui

vardiniame procese, reikia remtis programų kūrimo proceso modelyje apibrėžtomis

bendrosiomis praktikomis. Kadangi jos apibrėžiamos visiems vardiniams procesams, proceso

gerinimo komanda turi pritaikyti bendrosios praktikos apibrėžimą pasirinktam procesui.

Bendrųjų praktikų įgyvendinimą užtikrina kitų procesų iš valdymo ir pagalbinių kategorijų

vykdymas. Paprastai sakant, kad inžinerinis procesas pasiektų antrą gebėjimo lygį, turi būti

įgyvendinti jį palaikantys valdymo ir pagalbinių kategorijų procesai.

Nustačius reikalingus procesų pakeitimus, einamojo organizacijos veiklos modelio

(apibrėžto inicijavimo žingsnyje) pagrindu sudaromas pagerintas veiklos modelis, įgyvendinantis

procesų gebėjimo tikslinį (tarpinį) profilį.

Veiksmų plane turi būti nurodomi gerinimo veiksmai, jų įgyvendinimo seka ir tvarkaraštis,

atsakingi asmenys, būdai proceso gerinimo tikslų pasiekimui nustatyti. Veiksmų plano detalumas

turi būti pakankamas jo įgyvendinimui, nebūtinas didelis ir išsamus dokumentas (turėtų pakakti

vieno-dviejų puslapių).

Prieš įgyvendinant veiksmų planą, jį turi patvirtinti proceso gerinimo projekto Priežiūros

komitetas.

Įgyvendinti gerinimo veiksmus Gerinimo veiksmus reikėtų išbandyti pasirinktame, jokiu būdu ne kritiniame organizacijai

projekte. Įgyvendinimo metu reikia atkreipti dėmesį į žmogiškąjį faktorių, organizacinę kultūrą,

papildomų mokymų poreikį. Darbuotojai, kuriuos betarpiškai paliečia proceso pakeitimai, turi

būti supažindinti su proceso gerinimo tikslais, jie turi jaustis ne „bandomaisiais triušiais“, o

progresyvių pakeitimų diegėjais. To siekiant yra labai svarbus vadovybės palaikymas ir

domėjimasis proceso gerinimo eiga.

Šiame etape ypač svarbu identifikuoti iškylančias problemas ir kuo greičiau bandyti jas

išspręsti: darbuotojai turėtų būti skatinami išsakyti savo nuomonę ir siūlyti galimus sprendimus,

tokiu būdu jie tampa naujo proceso „savininkais“ ir gynėjais.

Įgyvendinus proceso gerinimo veiksmus, reikia stebėti jų poveikį programų kūrimo

proceso efektyvumui, ar nustatyti gerinimo tikslai buvo pasiekti.

Patvirtinti proceso pakeitimus Kai veiksmų plano įgyvendinimas pasirinktame bandomajame projekte baigtas, proceso

gerinimo projekto Priežiūros komitetas turi priimti sprendimą, ar numatyti proceso gerinimo

tikslai buvo pasiekti ir gauta nauda, kurios buvo tikėtasi, įvertinti pakeisto proceso paskleidimo


Mokymo medžiaga 73

organizacijoje riziką. Turėtų būti išklausyti darbuotojų, kuriuos betarpiškai palietė proceso

pakeitimai, atsiliepimai.

Jei pakeisto proceso bandymai buvo nesėkmingi - gerinimo tikslai nebuvo pasiekti, turi

būti išanalizuotos nesėkmės priežastys ir grįžtama prie 3-io ciklo žingsnio: nustatomi nauji, gal

būt mažesni (ne tokie ambicingi) gerinimo tikslai, sudaromas naujas veiksmų planas, tiems

tikslams pasiekti.

Jei gerinimo veiksmai buvo sėkmingai įdiegti ir nustatyti gerinimo tikslai pasiekti,

priimamas sprendimas dėl pakeisto proceso paskleidimo. Reikėtų, kad visi įmonės darbuotojai

sužinotų apie sėkmingą gerinimo projektą ir jį vykdžiusius žmones, tai motyvuoja juos ir kitus

darbuotojus aktyviau įsijungti į proceso gerinimo veiklą.

Paskleisti proceso pakeitimus Kai proceso gerinimo veiksmai patvirtinami, turi būti sudarytas proceso pakeitimų

paskleidimo organizacijoje planas: kokiuose projektuose (jei ne visuose) bus taikomas pakeistas

procesas, kaip jis bus diegiamas, kokių papildomų mokymų įmonės darbuotojams reikia, kaip

bus užtikrinama, kad pasiektas proceso gebėjimas nebus prarastas ir gerinimo veiksmai „prigis“

organizacijoje (pavyzdžiui, peržiūros, auditas, gebėjimo vertinimas).

Pakeisto proceso diegimo planą organizacijoje turi patvirtinti Priežiūros komitetas.

Stebėti proceso vykdymą Proceso gerinimo projekto komanda turi stebėti organizacijos procesą ir jo efektyvumą.

Būdai pasirenkami pagal organizacijos poreikius ir verslo tikslus. Komanda turėtų apibendrinti

proceso gerinimo patirtį ir darbuotojų atsiliepimus. Turėtų būti įsitikinta, kad proceso pakeitimai

buvo įdiegti organizacijoje pagal planą. Informacija apie proceso būseną turėtų būti skleidžiama

organizacijoje.

Situacija turėtų būti reguliariai peržiūrima Priežiūros komitete. Įvertinęs, kad pakeistas

procesas jau pakankamai įdiegtas organizacijoje, Priežiūros komitetas priima sprendimą dėl

naujo proceso gerinimo ciklo inicijavimo.

Programų kūrimo proceso instrumentinės priemonės

Šiame skyriuje aptariamos PKP Branda projekto metu sukurtos programų kūrimo proceso

vertinimo ir 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 proceso

diegimą, palaikymą ir gerinimą, o taip pat padėti atlikti proceso vertinimą. Jos turi apimti:

- Modelio medžiagos pateikimo priemones;

- Organizacijos proceso apibrėžimo ir pavaizdavimo priemones;


Mokymo medžiaga 74

- Proceso nuolatinio matavimo duomenų surinkimo priemones;

- Proceso vertinimo priemones;

- Apsikeitimo proceso vertinimo duomenimis priemones;

- Apmokymo priemones.

6.3 pav. Pradinis sistemos puslapis

Modelio medžiagos pateikimo priemonės turi būti su užpildytu turiniu. Kartu su modeliu

turi būti pateikiamas programų kūrimo proceso terminų žodynas, pasižymintis hiperteksto

savybėmis.

Organizacijos proceso apibrėžimo ir pavaizdavimo priemonės turi suteikti galimybes

modifikuoti pateikiamą brandaus proceso modelio turinį, priderinant jį pagal konkrečios

organizacijos atliekamą veiklą ir specifiką.

Modelio medžiaga ir organizacijos proceso apibrėžimas turi būti pateikiami per vieningą

naršyklę, išnaudojant hiperteksto sistemų savybes. Naršyklė turi pateikti galimybę gauti bet kurio

lygio modelio informaciją, atspindint jos vietą bendroje struktūroje, t.y. turi būti užtikrintos

galimybės nuo bet kurio pasirinkto modelio elemento pereiti prie konkretaus jo apibrėžimo

Projekto informacija

Kalbos pasirinkimas

Svečiui prieinama informacija

Atverti prisijungimo puslapį


Mokymo medžiaga 75

organizacijoje. Ir atvirkščiai, pasirinkus 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 ir

diegimo metodikoje apibrėžtus duomenis apie proceso vykdymą. Duomenų surinkimas turi būti,

kiek įmanoma, automatizuotas: darbuotojams atliekant procese numatytus veiksmus, sistemoje

turi būti kaupiami duomenų įrašai. Instrumentinės priemonės turi sudaryti duomenų analizės

galimybes: gauti iš anksto apibrėžtas ataskaitas, formuluoti interaktyvias užklausas, rezultatai

turi būti pateikiami vartotojo pasirinkta forma (lentelėmis ar pasirinkto tipo diagramomis) su

galimybe juos eksportuoti tolimesniam apdorojimui ar publikavimui.

6.4 pav. Sistemos architektūra

Proceso 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ūti

panaudojami proceso nuolatinio matavimo duomenys. Sistema turi identifikuoti trūkstamus

duomenis ir sudaryti galimybes juos įvesti interaktyviai arba importuoti. Turi būti galimybės

analizuoti vertinimo rezultatus įvairiais pjūviais, palyginti su ankstesnių vertinimų rezultatais,

sekti pasikeitimus, eksportuoti vertinimo rezultatus.


Mokymo medžiaga 76

Apsikeitimo proceso vertinimo duomenimis priemonės turi padėti keistis vertinimo

duomenimis tarp skirtingų organizacijų, užtikrinant reikiamą anonimiškumą, jautrių duomenų

apsaugą ir suteikiant analizės priemones.

Apmokymo priemonės turi apimti darbo su sistema apmokymus, apimančius visas

sistemos funkcijas, naudojamo programų kūrimo proceso modelio apmokymus, modelio

pritaikymo organizacijos reikmėms apmokymus.

6.5 pav. Puslapio modelio medis iliustracija

Visos instrumentinės priemonės turi būti nepriklausomos nuo specifinių brandaus

programų kūrimo proceso adaptacijų ar taikymų.

Sistemos architektūra turi užtikrinti paskirstytą duomenų įvedimą, kad instrumentinėmis

priemonėmis galėtų naudotis visi organizacijos darbuotojai. Sistema turi būti diegiama ir

prižiūrima su nedideliais kaštais, užtikrinti normalų darbą vartotojams su vidutinių pajėgumų


Mokymo medžiaga 77

kompiuteriais. Realizacijai turi būti naudojamos technologijos, užtikrinančios sistemos

pernešamumą į programų kūrimo įmonių dažniausiai naudojamas operacines sistemas.

Turi būti užtikrintas duomenų saugumas, galimybės nustatyti teises vartotojams ir 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 nuo

nesankcionuoto prisijungimo, bet ir 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 įvairius specifinius proceso aspektus, pavyzdžiui, projektų

planavimą.

6.6 pav. Puslapio vertinimas iliustracija

Projektuojant sistemą buvo remiamasi analogiškų programinių produktų analizės

rezultatais. Papildomai išnagrinėjus esamas instrumentines priemones, buvo priimta nuostata,

kad sistema turėtų užtikrinti efektyvų panaudojimą ir tuo pačiu skatinti domėjimąsi pačiu

brandaus programų kūrimo procesu. Programų kūrimo proceso modelis yra sudėtingas ir, norint

juo pasinaudoti, tenka analizuoti sudėtingais sąryšiais susijusius informacinius elementus.

Nenaudojant arba naudojant tik elementarias priemones vartotojas instinktyviai stengiasi išvengti

Trečias žingsnis: atliekamas greitasis vertinimas įrašant

reikšmes procesų atributams

Paspaudus mygtuką Atnaujinti išsaugomi daryti keitimai


Mokymo medžiaga 78

sudėtingų klausimų sprendimo. Tik patogių priemonių naudojimas leidžia operatyviai spręsti

iškilusius klausimus.

Buvo išnagrinėti tiek komerciniai įrankiai, tiek atvirojo kodo instrumentinės priemonės.

Pastebėti komercinių produktų trūkumai: dažniausiai neegzistuoja administravimo posistemis,

nėra paskirstyto 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 ir į tai, kad praktiškai reikalingos ir instrumentinės

priemonės sistemoje naudojamam programų kūrimo proceso modeliui vystyti: tikslinti, papildyti,

pritaikyti organizacijos poreikiams. Vystymo aplinkos įtraukimas leidžia užtikrinti projekto

tęstinumą.

Vystymo posistemiui buvo iškelti tokie reikalavimai:

- Vystymo medžiaga (turinys) turi būti kaip galima labiau atskirta nuo jos pavaizdavimo

būdo , kad ją būtų galima pateikti įvairiose 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ą, kad

naudojimas 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 ir kontrolės įrankiai);

- Sistema turi įtraukti ir programavimo galimybę, kad būtų užtikrinta galimybė realizuoti

veiksmus, kuriems nepakanka esamo žymėjimo.

Vystymo medžiagos formatavimui buvo pasirinktas MediaWiki žymių poaibis. Kadangi

Wiki formatavimo žymės skirtos tik teksto formatavimui, todėl modeliui ir modelio elementams

aprašyti suprojektuotas atskiras žymių poaibis.


[VU05] Vilniaus universitetas. Brandaus programų kūrimo proceso įdiegimo metodikos ir

instrumentinių priemonių sukūrimas (PKP Branda), 2005

(http://www.mif.vu.lt/se/Branda/)

[ISO98] ISO/IEC 15504: Information technology – Software process assessment, (parts

1-9). International Organization for Standardization and the International

Electrotechnical Commission, 1998


Mokymo medžiaga 79



[IDE96] IDEAL: A User’s Guide for Software Improvement, CMU/SEI-96-HB-001,

Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996.

Programų sistemų inžinerija 7. Asmeninis programų kūrimo procesas

Mokymo medžiaga 80

7. Asmeninis programų kūrimo procesas

Vienas iš nedaugelio modelių, orientuotų į asmens disciplinos formavimą, kuriant

programų 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ės

siekimą, tvarkaraščio/planų laikymąsi ir pastovų tobulėjimą. Pagal PSP metodiką, asmuo kuria

programas, naudodamasis griežtai apibrėžtais ir struktūrizuotais metodais, leidžiančiais kurti

aukštos kokybės produktus suplanuotais terminais. Savo darbe įtraukdamas vis daugiau proceso

apibrėž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 paskirtis – padėti inžinieriui atlikti savo darbus

disciplinuotai, 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 planuoti

savo darbą, o tai, savo ruožtu, lemia darbo kokybę, produktyvumą ir tobulėjimo galimybę.

PSP atsiradimas

Šis modelis buvo sukurtas Watts Humphrey kaip tęsinys jo ankstesnių darbų, kurių metu

buvo kuriamas organizacijos lygio programų kūrimo proceso modelis CMM. Gaudamas

atsiliepimus, jog CMM modelis nėra tinkamas mažoms organizacijoms, autorius sukūrė

programų sistemų kūrimo proceso modelį, tinkamą pačiai mažiausiai “organizacijai” – vienam

asmeniui. 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 tinkamos

asmeniniam procesui. Šis naujasis modelis buvo pavadintas PSP (angl. Personal Software

Process) ir pirmą kartą pristatytas knygoje „A Discipline for Software Engineering” [Hum95].

PSP modelis

Procesą galima apibrėžti kaip seką žingsnių, kuriuos įvykdžius pasiekiamas norimas

tikslas. Tikslas, šiuo atveju, yra asmens pasiruošimas pastoviai kurti aukštos kokybės

programinius 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 for

Software Engineering” [Hum95]. Ši knyga buvo orientuota į magistro studijas.

Skirtingai 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 knygoje


Mokymo medžiaga 81

„Introduction to the Personal Software ProcessSM”, skirtoje bakalauro studijoms modelis iš viso

nepateikiamas ir siūloma diegti veiklas kiek kitokiu eiliškumu.

PSP1Dydžio prognozavimas (PROBE)

Testavimo ataskaita

PSP0Dabartinis procesasLaiko fiksavimas

Defektų fiksavimasDefektų tipų standartas

PSP3Ciklinis kūrimas

PSP2Projekto peržiūra

Kodo peržiūra

PSP2.1Projektavimo šablonai

PSP1.1Laiko prognozavimas (PROBE)

Užduočių planavimasDarbo grafiko planavimas

PSP0.1Dydžio fiksavimas

Kodavimo standartasDydžio standartas (LOC)

Proceso gerinimo pasiūlymaiBazinisprocesas

Planavimoprocesas

Kokybėsvaldymoprocesas

Ciklinisprocesas

7.1 pav. PSP modelis (1994 metai)

Dar viena modelio „revizija“ buvo atlikta, peržiūrint jį ir 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 specialiai

paruoštas instrukcijas, scenarijus, formas, standartus, kuriuose nurodoma, ko reikia veiklai

įvykdyti, kokia informacija turi būti surinkta ir kaip pateikta bei kokių rezultatų tikimasi.

PSP apimtis

Paprasčiausias PSP proceso apibūdinimas būtų toks: tai procesas, kuris pateikia

nurodymus, kaip reikia kurti programinius produktus. Šis procesas skirtas vienam asmeniui – ne

komandai ir ne organizacijai. Proceso metu kalbama apie programinių produktų kūrimą – ne apie

ataskaitų 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 ir kitoms programų sistemų kūrimo veikloms. Be

abejo, procesas neapima komandinio darbo organizavimo.


Mokymo medžiaga 82

PSP1

Dydžio prognozavimas

Testavimo ataskaita

PSP0

Dabartinis procesas

Bazinės metrikos

TSP

Komandos formavimasRizikos valdymas

Projekto planavimas ir stebėjimas

PSP2

Kodo peržiūra

Projekto peržiūra

PSP2.1

Projektavimo šablonai

PSP1.1

Užduočių planavimas

Darbo grafiko planavimas

PSP0.1Kodavimo standartas

Proceso gerinimo pasiūlymai

Dydžio fiksavimas

Procesodisciplina irmatavimas

Vertinimasir

planavimas

Kokybėsvaldymas ir

projektavimas

Komandinisprocesas

7.2 pav. PSP modelis (2005 metai)

PSP struktūra

PSP procesas apima tris stambias programų sistemų kūrimo fazes: užduočių planavimą,

kūrimą ir 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 ir proceso peržiūros. Planavimo fazės metu

paruošiamas planas, įtraukiantis prognozuojamą kuriamo produkto dydį bei jo sukūrimui

reikalingą laiką. Kūrimo fazė apima visą „gamybinį“ procesą. Proceso gerinimo fazės metu

peržiūrimi surinkti duomenys ir siūlomi patobulinimai.

PSP metrikos PSP procesas naudoja pagrindines metrikas:

• laikas,

• defektai,

• dydis.

Iš šių bazinių metrikų išvedamos visos kitos PSP metrikos. Metrikos, kurios paremtos

bazine laiko metrika, būtinos sudarant grafiką ir užduočių planus, matuojant produktyvumą ir t.t.

Metrikos, paremtos bazine defektų metrika, būtinos produkto kokybei matuoti, prognozuoti ir


Mokymo medžiaga 83

valdyti, 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 modelis PSP procesas produkto kokybę užtikrina trimis pagrindiniais būdais:

• kiekvienam produktui yra atliekama peržiūra (eskizinio projekto peržiūra, detaliojo

projekto peržiūra, kodo peržiūra), didžiausią dėmesį skiriant defektams, užfiksuotiems

daž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 ir vertinama, naudojantis proceso metu surinktais

duomenimis.

PSP prognozavimo modelis PSP proceso metu prognozavimas vykdomas remiantis prielaida, jog ateityje procesas

vyks taip, kaip vyko praeityje, t.y. ateities prognozėms naudojami istoriniai duomenys. PSP

procesas pristato prognozavimo metodą PROBE (angl. Proxy Based Estimating). Šis metodas

naudojamas laiko ir dydžio prognozavimui. Jis įgalina pakankamai tiksliai prognozuoti, nes

remiasi istoriniais duomenimis, kuriuos kiekvienas pagal PSP procesą dirbantis asmuo renka

projektų 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 ir dydžius, galima apskaičiuoti, kiek laiko užtruktų tokios

kategorijos objekto kūrimas ir kokio dydžio jis būtų (skaičiuojamas aritmetinis vidurkis arba

naudojamasi sudėtingesniais statistiniais metodais).

PSP tobulinimo modelis Asmeninio proceso evoliucionavimas yra vienas iš svarbiausių PSP proceso aspektų. PSP

procesas tobulinamas, remiantis pasiūlymais, pateiktais proceso peržiūros fazės metu. Tam

tikslui yra paruošta proceso gerinimo pasiūlymų forma, kurioje fiksuojami visi galimi proceso

tobulinimo 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 dirbs efektyviai jei naudos apibrėžtą ir matuojamą procesą

(apibrėžtas, matuojamas).


Mokymo medžiaga 84

• Kad procesas geriausiai atitiktų individualius poreikius ir asmens sugebėjimus, jis turi

būti pritaikytas (pritaikytas).

• Suteikti galimybę programų kūrėjams dirbti taip, kaip jie įpratę, tačiau prisilaikant

nustatytų nurodymų, procedūrų bei atsižvelgiant į jų pačių surinktus duomenis ir kolegų

patirtį (efektyvus).

• Norint pastoviai gerinti savo veiklą reikia nuolat tobulinti procesą, atsižvelgiant į

proceso naudojimo metu sukauptus istorinius duomenis ir rodiklius (evoliucionuojantis).

• Kad gamintum kokybiškus produktus, privalai jaustis atsakingu už jų kokybę.

• Surasti ir ištaisyti defektus projekto pradžioje kainuoja mažiau nei projekto pabaigoje;

daug veiksmingiau užkirsti kelią defektų atsiradimui nei jų vėliau ieškoti ir taisyti

(orientuotas į kokybę, ankstyvas defektų šalinimas).

PSP praktikos PSP procese išskiriama 11 praktikų, kurių taikymas sąlygoja aukščiau įvardintų proceso

principų į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 ir agregavimui PSP

naudojami pakankamai primityvūs ir ne itin patogūs naudoti įrankiai, kurie neįgalina atlikti bent

minimalų surenkamų duomenų integralumo patikrinimą.

Laiko fiksavimas

Tikslas: Vartotojui tinkamoje formoje užfiksuoti minimalią aibę duomenų, būtinų būsimai

laiko prognozavimo praktikai vykdyti.

Veiklos:

• Reikalingų duomenų aibės, matavimo tikslumo apibrėžimas.

• Duomenų surinkimo ir kaupimo formos apibrėžimas.

• Duomenų surinkimas.


Mokymo medžiaga 85

Aprašymas. Metrikos, paremtos bazine laiko metrika, būtinos sudarant grafiką ir užduočių

planus, matuojant produktyvumą ir t.t. Remiantis surinktais duomenimis, bus nustatoma kiek

laiko galėtų užtrukti panašaus dydžio ir sudėtingumo objekto projektavimas, sukūrimas,

testavimas. Laiko fiksavimo praktika įvedama jau pačiame pirmajame 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ąnaudas

bei 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 ir pan.). Kadangi PSP proceso

metu renkami duomenys ne tik apie užduotims įgyvendinti sugaištą laiką, bet ir fiksuojama

kiekvienos nedarbo pertraukėlės (“trukdžių”) trukmė, tai įgalina nustatyti tokių “trukdžių” kainą

ir jų santykį su užduotims įgyvendinti sugaištu laiku. Prieš pradedant rinkti duomenis priimamas

standartas, kuris nusako, kaip turi būti fiksuojamas laikas bei kokios paklaidos gali būti

užfiksuotuose duomenyse.

Defektų fiksavimas

Tikslas. Vartotojui tinkamoje formoje užfiksuoti aibę reikalingų duomenų, būtinų

identifikuoti pasitaikančius defektus bei užtikrinti jų prevencijos ir atsiradimo priežasčių

eliminavimo veiklas, vertinti būsimo produkto kokybę.

Veiklos:

• Reikalingų duomenų aibės, matavimo tikslumo apibrėžimas (remiantis apibrėžtu

defektų tipų standartu).



Aprašymas. Metrikos, paremtos bazine defektų metrika, būtinos produkto kokybei

matuoti, prognozuoti ir valdyti, taip užtikrinant kokybiško produkto gamybą. Defektų fiksavimo

praktika įvedama jau pačiame pirmajame PSP proceso lygyje – PSP0, kadangi surinkti

duomenys taps pagrindu planavimo procesui ir leis prognozuoti kuriamo produkto kokybę bei

paruošti defektų prevencijos procedūras. PSP siūlomas defektų fiksavimas ir kategorizavimas bei

pastovus klaidų kontrolinių sąrašų atnaujinimas leidžia susidaryti gana tikslų vaizdą apie

dažniausiai sutinkamas klaidas ir netgi iš anksto numatyti ir paruošti tam tikrus nurodymus, kaip

tokių klaidų išvengti. Asmens lygmenyje klaidų sąrašai įgalina žinoti savo dažniausiai įveliamas

klaidas ir 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 ir pastoviai


Mokymo medžiaga 86

atnaujinami defektų kontroliniai sąrašai, pateikiantys tikrintinas situacijas, kuriose dažniausiai

būna defektų.

Dydžio fiksavimas

Tikslas. Vartotojui tinkamoje formoje užfiksuoti minimalią aibę duomenų, būtinų būsimai

objektų/komponentų dydžio prognozavimo veiklai vykdyti.

Veiklos:

• Reikalingų duomenų aibės, matavimo tikslumo apibrėžimas.



Aprašymas. Metrikos, paremtos bazine dydžio metrika, būtinos dydžio matavimui bei

prognozavimui, taip pat, kaip sudėtinis dėmuo, naudojamos klaidų “tankiui” bei produktyvumui

matuoti. Objektų/komponentų kategorizavimas bei istorinių duomenų apie kiekvienos rūšies

objektus/komponentus rinkimas leidžia tiksliau prognozuoti būsimo produkto dydį. Dydžio

fiksavimo praktika įvedama jau pačiame pirmajame PSP proceso lygyje – PSP0.1, kadangi

surinkti duomenys taps pagrindu planavimo procesui ir leis tiksliau prognozuoti būsimo

produkto dydį.

Surenkamų duomenų aibė. Fiksuojami objektų/komponentų dydžiai remiantis dydžio

standartu. Prieš pradedant rinkti duomenis priimamas dydžio standartas, kuris apibrėžia kaip

matuojamas dydis. Turint keleto tai pačiai kategorijai priklausančių objektų dydžius, galima

apskaičiuoti, koks prognozuojamas tokios kategorijos objekto dydis (skaičiuojamas aritmetinis

vidurkis arba naudojamasi sudėtingesniais statistiniais metodais).

Standartų apibrėžimas

Tikslas. Vartotojui tinkamoje formoje pateikti nurodymų rinkinį, kurių laikantis turi būti

atliekama arba pagal kuriuos matuojama atlikta veikla.

Veiklos:

• Defektų tipų standarto paruošimas.

• Kodavimo standarto paruošimas.

• Dydžio standarto paruošimas.

Aprašymas

1. Defektų tipų standartas: įveda sistemą, nurodančią kaip klasifikuoti projekto metu

rastus defektus. Šioje sistemoje kiekvienas defekto tipas turi jį identifikuojantį numerį ir 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 skirtingą programų kūrimo metodiką, t.y. turi savo


Mokymo medžiaga 87

savitą programavimo “stilių”. Norint PSP proceso metu pasinaudoti kitų programų sistemų

kūrėjų surinktais duomenimis ir taip patobulinti savo naudojamą procesą, būtina, jog kodavimo

sritis 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 standartas

glaudžiai susijęs su kodavimo standartu, kadangi dydžio matavimo procesas ir tikslumas

priklausys nuo to, kaip apibrėžtas kodavimo standartas.

Dydžio prognozavimas

Tikslas. Naudojantis turimais istoriniais duomenimis ir apibrėžtais standartais prognozuoti

būsimų projekto produktų (pvz., objektų/komponentų) dydžius.

Veiklos:

• Prognozavimo metodikos pasirinkimas ir procedūrų apibrėžimas.

• Projekto produktų (pvz., objektų/komponentų) dydžio prognozavimas.

• Dydžio prognozavimo tikslumo didinimas (duomenų, rodiklių koregavimas), lyginant

prognozes su realiais projekto produktų (pvz., objektų/komponentų) dydžiais.

Aprašymas. Turint keleto tai pačiai kategorijai priklausančių objektų dydžius, galima

apskaičiuoti, koks prognozuojamas tokios kategorijos objekto dydis (skaičiuojamas aritmetinis

vidurkis arba naudojamasi sudėtingesniais statistiniais metodais). Dydžio prognozavimo praktika

įvedama PSP proceso planavimo lygmenyje PSP1. Šios praktikos išeities duomenys bus

naudojami planavimo praktikos metu.

Prognozavimo metodikos pasirinkimas ir procedūrų apibrėžimas. PSP procesas dydžiui

matuoti siūlo naudoti kodo eilučių skaičiavimo metodą (LOC), tačiau šis metodas dažnai

praktikoje nepateisina lūkesčių, nes metodas sunkiai panaudojamas, jei nėra griežtai apibrėžtas

kodavimo standartas, projektas realizuojamas skirtingomis programavimo kalbomis. Dydžio

prognozavimui naudojamas metodas PROBE, kuris apibrėžiamas PSP1 lygio (planavimo)

procese, įgalina pakankamai tiksliai nusakyti, kiek laiko užtruks užduoties vykdymas, nes jis

remiasi istoriniais duomenimis, surinktais dydžio fiksavimo praktikos metu.

Dydžio prognozavimo tikslumo didinimas. Turint istorinius duomenis ir prognozuotus

komponentų/objektų dydžius, tikslinamas/keičiamas prognozavimo metodas, pasirenkami labiau

tinkantys metodai.

Laiko prognozavimas

Tikslas. Naudojantis surinktais istoriniais duomenimis ir pasirinkta metodika, kiek galima

tiksliau prognozuoti produkto/komponento/objekto sukūrimui reikalingą laiką.


Mokymo medžiaga 88

Veiklos:

• Prognozavimo metodikos pasirinkimas ir procedūrų apibrėžimas.

• Projekto produktų sukūrimui (pvz., objektų/komponentų) reikalingo laiko

prognozavimas.

• Laiko prognozavimo tikslumo didinimas (duomenų, rodiklių koregavimas), lyginant

prognozes su realiais projekto produktų sukūrimo laikais.

Aprašymas. “Istorinių duomenų” naudojimas, vertinant būsimas laiko sąnaudas yra priimta

praktika programų sistemų kūrimo industrijoje. Tačiau vertinti individualaus asmens laiko

sąnaudas vis dar yra pakankamai sudėtinga. PSP proceso metu asmuo įgyja teorinių ir praktinių

žinių, kaip šią veiklą atlikti kiek įmanoma tiksliau ir kokybiškiau. Turint keleto tai pačiai

kategorijai priklausančių objektų, galima apskaičiuoti, koks prognozuojamas tokios kategorijos

objekto sukūrimo laikas (skaičiuojamas aritmetinis vidurkis arba naudojamasi sudėtingesniais

statistiniais metodais). Laiko prognozavimo praktika įvedama PSP proceso planavimo lygmenyje

PSP1.1. Šios praktikos išeities duomenys bus naudojami planavimo praktikos metu.

Prognozavimo metodikos pasirinkimas ir procedūrų apibrėžimas. Laiko prognozavimui

naudojamas metodas PROBE, kuris apibrėžiamas PSP1 lygio (planavimo) procese, įgalina

pakankamai tiksliai nusakyti, kiek laiko užtruks užduoties vykdymas, nes jis remiasi istoriniais

duomenimis, surinktais laiko fiksavimo praktikos 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, galima apskaičiuoti,

kiek laiko užtruktų tokios kategorijos objekto kūrimas (skaičiuojamas laikų aritmetinis vidurkis

arba naudojamasi sudėtingesniais statistiniais metodais).

Laiko prognozavimo tikslumo didinimas. Turint istorinius duomenis ir prognozuotus

komponentų/objektų sukūrimui reikalingus laiko įverčius, tikslinamas/keičiamas prognozavimo

metodas, pasirenkami labiau tinkantys įrankiai.

Peržiūros

Tikslas. Naudojantis apibrėžtais metodais, patikrinti objekto kokybę.

Aprašymas. Projekto ir kodo peržiūrų veiklos bei kontrolinių sąrašų (angl. checklists)

naudojimas pripažinti vienomis iš svarbiausių ir didžiausią įtaką kuriamo produkto kokybei

turinčių veiklų. Jų įdiegimo nauda akivaizdi: pastoviai atnaujinami kontroliniai sąrašai įgalina

atsekti dažniausiai pasitaikančias klaidas, jų rūšis ir tendencijas, padeda užtikrinti projekto ir

kodo išbaigtumą ir darbo kokybę, tuo pačiu šios veiklos neužima daug laiko ir nereikalauja

didelių 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žniausiai


Mokymo medžiaga 89

programų sistemų kūrėjo pasitaikančius defektus. Peržiūrų metų ypatingas dėmesys kaip tik ir

kreipiamas dažniausiai pasitaikančių defektų paieškai. Atliekant peržiūras visi defektai

fiksuojami ir kontroliniai sąrašai atnaujinami.

Proceso tobulinimas

Tikslas. Pastoviai tobulinti procesą, atsižvelgiant į proceso metu sukauptus istorinius

duomenis ir rodiklius.

Aprašymas. Šios veiklos metu atliekama ciklo metu surinktų duomenų peržiūra. Peržiūros

tikslai - surinkti proceso duomenis bei rodiklius ir juos išanalizuoti, identifikuoti, kada procesas

veikė sklandžiai, o kada kilo problemų.

Analizės metu nustatoma, ar pasiteisino prieš ciklą pasiūlyti proceso ir veiklų

pakeitimai/patobulinimai. Jeigu peržiūros metu paaiškėja, jog naudinga keisti procesą ar kurias

nors 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, proceso

gerinimo veiklos atsiranda jau pradiniame procese.

PSP principų ir praktikų sąryšiai Žemiau pateikiama PSP procesų principų ir praktikų sąryšių lentelė, t.y. kokius PSP

principus kokios praktikos įgyvendina.

Principas Įgyvendinančios

praktikos

Praktikos veiklos

Reikalingų duomenų aibės, matavimo

tikslumo apibrėžimas

Duomenų surinkimo ir kaupimo formos

apibrėžimas

Laiko

fiksavimas

Duomenų surinkimas




apibrėžimas

Defektų

fiksavimas

Duomenų surinkimas



Programų sistemų kūrėjai

dirbs efektyviai jei naudos

apibrėžtą ir matuojamą

procesą (apibrėžtas,

matuojamas)

Dydžio

fiksavimas


apibrėžimas


Mokymo medžiaga 90


praktikos

Praktikos veiklos

Duomenų surinkimas

Defektų tipų standarto paruošimas

Kodavimo standarto paruošimas

Standartų

apibrėžimas

Dydžio standarto paruošimas

Kad procesas geriausiai

atitiktų individualius

poreikius ir asmens

sugebėjimus, jis turi būti

pritaikytas (pritaikytas)

Visos praktikos turi būti pritaikytos asmeniniam naudojimui

Prognozavimo metodikos pasirinkimas ir

procedūrų apibrėžimas

Projekto produktų (pvz.

objektų/komponentų) dydžio prognozavimas

Dydžio

prognozavimas

Dydžio prognozavimo tikslumo didinimas

(duomenų, rodiklių koregavimas), lyginant

prognozes su realiais projekto produktų

(pvz. objektų/komponentų) dydžiais

Prognozavimo metodikos pasirinkimas ir

procedūrų apibrėžimas

Projekto produktų sukūrimui (pvz.

objektų/komponentų) reikalingo laiko

prognozavimas

Suteikti galimybę programų

kūrėjams dirbti taip, kaip jie

įpratę, tačiau prisilaikant

nustatytų nurodymų,

procedūrų bei atsižvelgiant į

jų pačių surinktus duomenis

ir kolegų patirtį (efektyvus).

Laiko

prognozavimas

Laiko prognozavimo tikslumo didinimas

(duomenų, rodiklių koregavimas), lyginant

prognozes su realiais projekto produktų

sukūrimo laiko įverčiais.

Norint pastoviai gerinti savo

veiklą reikia nuolat tobulinti

procesą, atsižvelgiant į

proceso naudojimo metu

sukauptus istorinius

duomenis ir rodiklius

(evoliucionuojantis).

Proceso

tobulinimas

Tobulinimo pasiūlymų surinkimas ir bendrų

tobulinimo žingsnių numatymas.


Mokymo medžiaga 91


praktikos

Praktikos veiklos

Kad gamintum kokybiškus

produktus, privalai jaustis

atsakingu už jų kokybę.

Surasti ir ištaisyti defektus

projekto pradžioje kainuoja

mažiau nei projekto

pabaigoje; daug

veiksmingiau užkirsti kelią

defektų atsiradimui nei jų

vėliau ieškoti ir taisyti

(orientuotas į kokybę,

ankstyvas defektų šalinimas).

Peržiūros Peržiūros atlikimas.

PSP mokymų įtakos asmeniniam procesui tyrimai

Buvo atlikti bandymai statistiniais metodais nustatyti, kokią įtaką atskiro inžinieriaus

asmeniniam procesui turi PSP proceso metu gautos žinios ir kaip tai atsispindi surinktuose

duomenyse. W.Hayes ir J.W.Over atliktuose tyrimuose dalyvavo 298 inžinieriai, kurie visi kartu

praleido daugiau nei 15.000 valandų rašydami daugiau nei 300.000 eilučių kodo. Į 23 grupes

suskirstyti inžinieriai buvo apmokomi tiek akademinėje, tiek ir realioje darbinėje aplinkoje. PSP

proceso metu surinkti duomenys buvo naudojami paties PSP proceso vertinimui atlikti, norint

parodyti, jog įsisavinus PSP procesą geriau atliekamos laiko bei dydžio vertinimo veiklos,

sumažėjo klaidų kiekiai ir tai visiškai nepaveikė produktyvumo.

Duomenų imtis ir statistinis modelis

Kiekvienos užduoties atlikimo metu inžinieriai surinko iki 70 rodiklių, kurie naudojami

asmeninio programų kūrimo proceso analizei bei jo tobulinimui. Taip pat PSP mokymų metu

buvo apibrėžtos surinktų duomenų analizės veiklos, kurių rezultatai buvo pateikiami kartu su

proceso duomenimis užpildytomis formomis ir ataskaitomis. Visi duomenys buvo pateikiami

popierinių formų pavidalu, o instruktoriai šiuos duomenis suvesdavo į PSP proceso duomenų

analizei paruoštas lenteles. Surinkti duomenys išanalizuojami, o bendri grupės rezultatai

pateikiami 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ų ir analizei

pateikiamų duomenų kokybės. Surinktų duomenų analizei ir agregavimui autoriai nenaudojo

jokių automatinių įrankių (tik tam skirtas popierines formas), taip pat nebuvo atliekamas


Mokymo medžiaga 92

nepriklausomas surinktų duomenų patikrinimas ar jų kokybės vertinimas. Nepaisant to, autoriai

teigia, jog surinkti duomenys buvo “išskirtinė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, bet

kiekvieno iš inžinierių surinktų ir apdorotų rodiklių pokyčiai. Statistinei analizei naudotas

pasikartojančių matavimų skirtumų analizės metodas (ANOVA). Šis metodas naudingas tada,

kai reikia pamatuoti to paties individo progresą, atliekant eilę bandymų. Ankstesni bandymai

laikomi pagrindu ir analizuojami tik skirtumai tarp bandymų metu surinktų duomenų. Šis

metodas buvo naudojamas visų kursų metu surinktų svarbiausių rodiklių statistinei analizei.

Dydžio vertinimas

Sugebė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į ir tuo

pačiu geriau suplanuoti savo laiką jo kūrimui. Vidutiniškai inžinieriai 2,5 karto tiksliau vertino

būsimo produkto dydį pasiekę PSP 2-ąjį lygį, lyginant su PSP 0 lygiu. 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ė ir matavimų

tikslumas bei kokios priemonės naudotos PSP duomenų kaupimui, analizavimui ir apdorojimui.

Pastangų ir laiko vertinimas

“Istorinių duomenų” naudojimas, vertinant būsimas laiko sąnaudas, yra priimta praktika

programų sistemų kūrimo industrijoje. Tačiau vertinti individualaus asmens laiko sąnaudas vis

dar yra pakankamai sudėtinga. PSP proceso metu asmuo įgyja teorinių ir praktinių žinių kaip šią

veiklą atlikti kiek įmanoma tiksliau ir kokybiškiau. Vidutiniškai inžinieriai 1,75 karto tiksliau

vertino būsimam produktui sukurti reikalingą laiką pasiekę PSP 2-ąjį lygį lyginant su PSP 0

lygiu. 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ė ir matavimų tikslumas bei kokios priemonės naudotos PSP duomenų kaupimui,

analizavimui ir apdorojimui.

Klaidų kiekis

Klaidų kiekio mažinimas tiesiogiai susijęs su laiko sąnaudų sumažėjimu, reikalingu toms

klaidoms ištaisyti. Tuo pačiu, PSP procesas įgalina klaidas ištaisyti ankstyvoje produkto kūrimo

stadijoje, o tai sumažina klaidų taisymo išlaidas. Vidutiniškai inžinieriai 1,5 karto sumažino

paliekamų klaidų kiekį savo programose pasiekę PSP 2-ąjį lygį lyginant su PSP 0 lygiu.

Skelbdami tokius įspūdingus tyrimo rezultatus, autoriai nepateikia duomenų, kaip buvo


Mokymo medžiaga 93

vertinama surinktų duomenų kokybė ir matavimų tikslumas bei kokios priemonės naudotos PSP

duomenų kaupimui, analizavimui ir apdorojimui.

Produktyvumas

Kadangi naudojamas statistinis metodas (ANOVA) įgalina stebėti pokyčius vieno asmens

lygyje, tai padeda išryškinti tam tikras tendencijas bei asmens produktyvumo pokyčius. Tyrimo

autoriai pastebi, jog nors ir pastebimi tam tikri produktyvumo svyravimai, jie yra pakankamai

nežymūs. Tai leidžia teigti, jog PSP proceso naudojimas produktyvumo nesumažina.

Išvados

Šį tyrimą galima priskirti tokių tyrimų, kurių rezultatai gali nevisiškai atitikti realią

situaciją dėl nekontroliuojamos tyrimo metu surinktų duomenų kokybės ir nepriklausomo

matavimų tikslumo vertinimo nebuvimo. Tyrimo autoriai teigia, jog kursų metu nekilo jokių

abejonių dėl inžinierių surenkamų ir analizei pateikiamų duomenų kokybės. Surinktų duomenų

analizei ir agregavimui autoriai nenaudojo jokių automatinių įrankių (tik tam skirtas popierines

formas), taip pat nebuvo atliekamas nepriklausomas surinktų duomenų patikrinimas ar jų

kokybės vertinimas. Nepaisant to, autoriai teigia, jog surinkti duomenys buvo “išskirtinės

kokybės”. Tuo pačiu, nėra apibrėžiama kokios PSP priemonės buvo naudotos atliekant laiko,

dydžio vertinimus ir 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 duomenys

surenkami popierinėse formose, o apdorojimui nenaudojami automatiniai įrankiai. Žinant, jog

pagal PSP proceso metu surinktus duomenis yra vertinamas pats procesas ir siūlomi jo

keitimai/tobulinimai, netikslūs duomenys gali neigiamai įtakoti asmens procesą ir jo tobulinimo

kelią.

PSP proceso taikymo pramonėje pavyzdžiai

Nepaisant didelio susidomėjimo PSP procesu, literatūros, aprašančios šio proceso taikymus

pramonėje, yra labai mažai. Didžioji dauguma darbų aprašo bandymus ir jų metu pasiektus

įspūdingus rezultatus izoliuotoje mokymų klasės aplinkoje, todėl tai neleidžia spręsti apie PSP

proceso tinkamumą realioje – pramoninėje aplinkoje. Vieni iš nedaugelio darbų, aprašančių PSP

proceso diegimo pramonėje rezultatus yra M.Stavros, M.Morisio ir E.George paskelbti darbai.

Šių darbų autoriai tiesiogiai dalyvavo PSP diegimo procesuose kaip vykdytojai arba konsultantai

ir identifikavo su PSP proceso diegimu susijusias problemas bei paties proceso privalumus ir

trūkumus. Diegimai buvo vykdomi kompanijose, turinčiose pakankamai dideles programuotojų

komandas (40-50 programuotojų) ir jau nusistovėjusius programinių produktų kūrimo procesus.

PSP proceso diegimo rezultatai pakankamai panašūs: nemodifikavus PSP proceso, nepritaikius

prie organizacinių procesų ir neautomatizavus duomenų surinkimo ir apdorojimo, jo

panaudojimas pramonėje yra pakankamai komplikuotas ir ribotas.


Mokymo medžiaga 94

PSP apmokymai

Abiejose kompanijose buvo pasirinkti panašūs PSP proceso apmokymo keliai – pasirinkta

nuotolinio PSP mokymo programa, specialiai paruošta įmonėms, norinčios įsidiegti PSP procesą,

bet negalinčioms viso darbuotojų laiko skirti vien tik mokymams. Pasirinktos panašios savo

struktūra ir pritaikymu, tačiau skirtingos trukmės PSP apmokymų programos:

• 8 savaičių trukmės programa, viso mokymų periodo metu organizacija turėjo galimybę

bendrauti su savo mokytojais ir jiems pateikinėjo savo atliktas užduotis bei surinktus duomenis;

• intensyvesnė 3 savaičių trukmės programa, suskaidyta į 3 dviejų dienų seminarus; toks

sprendimas buvo priimtas, atsižvelgiant į resursų, galinčių pakeisti/pavaduoti pilną darbo dieną

mokymams skiriančius darbuotojus, trūkumą.

Kitas sprendimas, kurį turėjo priimti kiekviena iš aprašomų organizacijų – parinkti

darbuotojus, kurie bus apmokomi PSP mokymo programoje. Abiem atvejais buvo pasirinkti

aukštesnes pareigas užimantys darbuotojai (vyresnieji programuotojai), turintys daugiau nei 5

metų programavimo darbų patirtį, laiku įvykdantys jiems paskirtas užduotis, dalyvavę

projektuojant aukštos kokybės produktus bei gerai susipažinę su organizacijų programų kūrimo

procesais. Pasirinkti 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 skirti viso savo

laiko, buvo pasirinkti skirtingi šios problemos sprendimo būdai.

Pirmu atveju organizacija stengėsi kuo mažiau nukrypti nuo mokymo programoje siūlomų

terminų. Atsižvelgiant į programoje dalyvaujančių darbuotojų kompetenciją, buvo pasirinkta 20

valandų per savaitę skirti mokymams, o likusias 20 – tiesioginėms darbuotojų užduotims atlikti.

Tokios proporcijos buvo išlaikytos praktiškai viso mokymo kurso metu. Toks laiko skirstymas

pasirinktas neatsitiktinai – tai leido mokymų metu įgytas žinias iš karto taikyti praktikoje.

Kadangi šie darbuotojai turėjo būti instruktoriai, apmokysiantys visus programinius produktus

kuriančius organizacijos darbuotojus, buvo suformuota antra darbuotojų grupė, kuriuos ir turėjo

apmokyti PSP mokymo kursą baigę pirmosios grupės darbuotojai. Ši komanda buvo sudaryta iš

jauniausių ir mažiausią patirtį turinčių bei su organizacijos procesu nesusipažinusių darbuotojų.

Priežastys, dėl kurių buvo nuspręsta formuoti antrąją grupę yra tokios:

• Nustatyti pirmosios komandos narių galimybes ir jiems kylančius sunkumus, apmokant

likusius programinius produktus kuriančius organizacijos darbuotojus.

• Identifikuoti problemas ir kylančius sunkumus, mažiausią patirtį turintiems komandos

nariams naudojant PSP procesą kasdienėje veikloje. Perprasti, kaip mažiausią patirtį turintys

komandos nariai supranta ir sprendžia problemas, kurdami programinius produktus.


Mokymo medžiaga 95

• Įtraukti mažiausią patirtį 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 ir 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 skirtas

pristatyti vieną iš PSP lygmenų), su kelių mėnesių pertrauka tarp jų, skirta eksperimentavimui -

gautų teorinių žinių pritaikymui darbinėje aplinkoje. Tuo pačiu buvo atsisakyta kai kurių

praktinių užduočių, kadangi jos pasirodė pernelyg paprastos ir teikiančios mažai naudos.

Abiem atvejais buvo atkreiptas dėmesys į PSP mokymams parinktas praktines užduotis:

jos pasirodė pernelyg paprastos ir 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 juos

apmoko kviestiniai instruktoriai/konsultantai, o ne tos pačios organizacijos žmonės.

Kadangi abi organizacijos mokymams skyrė nevienodai laiko, tai gauti gana skirtingi

rezultatai. Pirmu atveju organizacija mokymams skyrė itin didelį dėmesį, todėl didžioji dalis

pirmosios grupės narių sėkmingai įsisavino PSP procesą. Tačiau priešingai nei pirmosios

komandos atveju, tik nedidelė dalis antrosios komandos narių sėkmingai baigė PSP mokymo

kursą. Tai lėmė kelios priežastys: nepakankamas instruktorių (pirmosios komandos narių)

dėmesys besimokantiems bei motyvacijos trūkumas.

Antru atveju organizacijos darbuotojai patiems mokymams skyrė gana nedaug laiko, tačiau

daug laiko skyrė eksperimentavimams. Toks laiko paskirstymas taip pat turėjo neigiamos įtakos

ir tik dalis PSP kursą baigusių narių procesą tinkamai naudojo eksperimentavimo laikotarpiu.

PSP adaptavimas

Nė viename iš nagrinėjamų atvejų PSP procesas nebuvo panaudotas toks, koks jis pateiktas

Watts 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 ir silpnosios PSP

proceso pusės, į kurias taip pat turėjo būti atsižvelgta. PSP proceso analizės metu buvo išryškinti

tokie proceso trūkumai ir privalumai.

Trūkumai:

• Programų sistemų kūrimo proceso metu programuotojas koduoja, renka ir analizuoja

didelius kiekius duomenų, todėl PSP proceso duomenų rinkimas ir analizė ne tik reikalauja

papildomo laiko, bet ir atitraukia nuo tiesioginių užduočių vykdymo. Programuotojo atliekamos

kasdienės užduotys ženkliai skiriasi nuo PSP proceso mokymams pateikiamų užduočių. To

pasekoje programuotojui sunku taikyti PSP įrankius, atliekant kasdienes užduotis ir užduotis


Mokymo medžiaga 96

atlikti per nustatytus terminus. Tai bene svarbiausia priežastis, verčianti programuotojus

atsisakyti PSP proceso.

• Pateikiamų įrankių neužtenka tam, kad būtų automatizuotas PSP duomenų surinkimas ir

apdorojimas, ypač kodo dydžio vertinimo atveju (LOC matavimas).

• PSP numato, kad jau egzistuoja tinkamai apibrėžtas ir išanalizuotas bei dokumentuotas

sistemos projektas, prieš pradedant įgyvendinimo (kodavimo) darbus. Tai skelbiama kaip būtina

sąlyga, tačiau bendru atveju ši sąlyga yra retai patenkinama gamybos aplinkoje, kai reikia

ypatingai greitai reaguoti į pasikeitusius kliento poreikius. PSP aprašomas modelis daugiau

tinkamas programų sistemų kūrimo projektams, kuriuose įgyvendinimo fazės kaštai yra labai

dideli, lyginant su projektavimo fazės kaštais.

• PSP proceso duomenims analizuoti reikalingi įrankiai, kurie būtų integruoti su

organizacijos naudojamais įrankiais, o tai dar labiau padidina tokių įrankių įsigijimo kaštus.

Išeitis - patiems kurti organizacijai ir konkrečiam procesui pritaikytus automatinius įrankius.

• Bene sudėtingiausia PSP proceso taikymo dalis yra kodo eilučių skaičiavimo (LOC)

standartizavimas ir jo taikymas: pridėtų, pakeistų, pašalintų kodo eilučių skaičiavimas. Šios

rūšies duomenų rinkimas užima daug laiko netgi naudojant automatinius įrankius. Buvo

nuspręsta komponentų ir objektų vertinimui naudoti ne kodo eilučių skaičiavimo metodą, bet

vertinant atsižvelgti į objekto tipą ir jam priskirtą atitinkamą kategoriją bei jo sukūrimui

reikalingą laiką.

• PSP procese ypatingas dėmesys kreipiamas į turimų komponentų pakartotinį

panaudojamumą kodavimo metu. Tuo tarpu organizacijoje komponentų pakartotinis

panaudojamumas apsprendžiamas jau analizės ir projektavimo fazių metu.

Privalumai:

• Projekto ir kodo peržiūrų veiklos bei kontrolinių sąrašų (checklists) naudojimas

pripažinti vienos iš svarbiausių ir didžiausią įtaką kuriamo produkto kokybei turinčių veiklų. Jų

įdiegimo nauda akivaizdi: pastoviai atnaujinami kontroliniai sąrašai įgalina atsekti dažniausias

pasitaikančias klaidas, jų rūšis ir tendencijas, padeda užtikrinti projekto ir kodo išbaigtumą ir

darbo kokybę, tuo pačiu šios veiklos neužima daug laiko ir nereikalauja didelių pradinių

investicijų.

• Laiko sąnaudų užduotims įgyvendinti fiksavimas leidžia tiksliau prognozuoti produkto

kūrimui reikalingo laiko sąnaudas bei nuspėti, kiek vidutiniškai laiko trunka “trukdžiai”.

• PSP siūlomas klaidų fiksavimas ir kategorizavimas bei pastovus klaidų kontrolinių

sąrašų atnaujinimas leidžia susidaryti gana tikslų vaizdą apie dažniausiai sutinkamas klaidas ir

netgi iš anksto numatyti ir paruošti tam tikrus nurodymus, kaip tokių klaidų išvengti. Asmens


Mokymo medžiaga 97

lygmenyje klaidų sąrašai įgalina žinoti savo dažniausiai įveliamas klaidas ir geriau atlikti

projektavimo bei kodavimo darbus.

• Komponentų/objektų kategorizavimas bei istorinių duomenų apie kiekvienos rūšies

komponentus/objektus rinkimas leidžia tiksliau prognozuoti būsimo produkto dydį bei jo

sukū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 ir testų scenarijai.

• PSP suteikia galimybę programų kūrėjams dirbti taip, kaip jie įpratę, tačiau prisilaikant

nustatytų nurodymų, procedūrų bei atsižvelgiant į jų pačių surinktus duomenis ir kolegų patirtį.

Adaptacija

Atsižvelgiant į aukščiau įvardintus PSP proceso privalumus ir trūkumus bei organizacijos

įsisavintą programinių produktų kūrimo metodologiją ir įrankius, buvo adaptuotas PSP procesas.

Adaptuotas procesas turėjo atitikti tokius reikalavimus:

• Palikti tik reikalingiausias veiklas ir įnešti kuo mažiau painiavos.

• Ypatingą dėmesį kreipti būsimų produktų laiko ir dydžio prognozuojamumo gerinimui.

• Sumažinti klaidų kiekį klientams pateikiamuose produktuose.

• Sekti ir fiksuoti kiekvieno iš vykdomų projektų duomenis vėlesnei analizei.

• Pritaikyti projekto ir kodo peržiūrų bei kontrolinių sąrašų dokumentus.

• Sumažinti projektams įgyvendinti sugaištamo laiko kiekį.

• Proceso gerinimo veiklą įtvirtinti kaip besitęsiantį procesą, kuris teikia naudos tiek

programų sistemų kūrėjui, tiek ir organizacijai.

Adaptuojant procesą didžioji dauguma scenarijų ir formų buvo įtraukti be pakeitimų.

Daugiausia pakeitimų buvo atlikta komponentų/objektų dydžio vertinimo veiklose ir

atitinkamose formose.

Antru atveju PSP proceso adaptacijos metu buvo atlikti tokie svarbiausi pakeitimai:

• PSP buvo modifikuotas taip, kad atsižvelgtų į skirtingus projektus (naujų funkcijų

diegimo projektai, klaidų taisymai) bei suteiktų galimybę dalintis užduotimis tarp komandos

narių ir 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ų ir neįvertina

defektų atrastų jau naudojant produktą, PSP procesas papildytas šiomis veiklomis ir kokybės

vertinimo metu atsižvelgta į tokius defektus.


Mokymo medžiaga 98

• Įvesti du proceso vertinimo lygiai – asmeninis ir komandinis. Asmeniniam procesui

vertinti naudojamos PSP proceso metu surinkti rodikliai, o komandiniam – agreguoti visų

komandos narių rodikliai: bendro komandos laiko matavimas, komandos laiko matavimas

kiekvienam ciklui, taisymų ir tobulinimų vertinimas ir pan.

• Sukurtas įmonės darbuotojams pritaikytas įrankis, automatizuojantis formų pildymą ir

rodiklių skaičiavimą.

• Užtikrintas surinktų duomenų ir rodiklių privatumas.

Adaptuoto PSP proceso taikymas

Sekantis žingsnis, adaptavus PSP procesą, buvo visų programinius produktus kuriančių

darbuotojų apmokymas. Pagrindinė problema, su kuria susidurta apmokymų metu - darbuotojų

nenoras priimti naują procesą ir visus su jo diegimu ir naudojimu susijusias sunkumus.

Darbuotojų nuomone PSP buvo vertinamas kaip vadovybės noras nurodinėti kaip reikia dirbti, o

ne noras padėti jiems tobulėti. Pabrėžiama, jog ši problema buvo išspręsta specialiai tam skirtų

seminarų metu, kuriuose įspūdžiais ir patarimais dalinosi pirmosios grupės nariai, pirmieji

išbandę ir adaptavę PSP procesą, todėl geriausiai žinantys jo privalumus ir trūkumus.

PSP diegimo rezultatai

PSP procesas buvo taikomas daugiau nei 4 mėnesius, per kuriuos išryškėjo tam tikri

adaptuoto proceso privalumai ir trūkumai. Išanalizavus per šį laikotarpį surinktus duomenis buvo

paruošta eksperimentinio PSP diegimo projekto ataskaita.

Apibendrinimas

• Testų metu randamų klaidų skaičius sumažėjo 15%.

• Laiko sąnaudos ir 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čiau

sumažėjo laiko, skiriamo produkto kompiliavimui sąnaudos.

• PSP proceso taikymas padidina laiko sąnaudas 15%, tačiau ilgainiui jos turėtų sumažėti

iki 5%, kadangi PSP proceso veiklų taikymas turi tapti įpročiu.

• Reikalinga jau egzistuojanti proceso infrastruktūra, kuri būtų tarpinis žingsnis diegiant

PSP procesą. Konkrečiu atveju CMM 2 lygio organizacijos procesas žymiai pagreitino PSP

proceso 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ę toliau

optimizuoti PSP procesą bei pritaikyti jį kitose srityse.


Mokymo medžiaga 99

Veiklos rezultatai

Vadovybė, analizuodama organizacijos veiklos rezultatus, įsitikino, jog įdėtas pastangas,

diegiant PSP procesą organizacijoje, atperka pagerėjusi kuriamų produktų kokybė, o ilgainiui - ir

išaugsiantis produktyvumas. Įdėtas investicijas ir su PSP diegimu susijusius sunkumus atsvers

pagerėjęs laiko sąnaudų ir pastangų, reikalingų produktui sukurti, vertinimas. Tai svarbūs

faktoriai, norint išlikti konkurencingais rinkoje. Tuo pačiu, patraukliai atrodo ir galimybė PSP

procesą pritaikyti kitose, su kodavimu nesusijusiose srityse. Pirmasis bandymas pritaikyti

atitinkamai modifikuotą PSP procesą ataskaitų kūrimo veiklai pavyko, todėl neatmetama

galimybė jį adaptuoti ir produkto palaikymo veikloms. Žvelgiant dar toliau, PSP proceso

įdiegimas organizacijoje galėtų jai padėti pasiekti ir aukštesnį CMM proceso lygį.

Organizacija

Didžiausią susirūpinimą organizacijos vadovams kėlė galimas darbuotojų nenoras priimti

su PSP proceso diegimu susijusius pasikeitimus jų kasdieninėje veikloje, kadangi šie

pasikeitimai būtų priimti kaip vadovų noras kontroliuoti kiekvieną iš darbuotojų. Tačiau

pasirodė, jog PSP procesas leidžia darbuotojams dirbti taip, kaip jie yra įpratę, tačiau laikantis

tam tikrų procedūrų, leidžiančių kiekvienam iš jų kiekybiškai ir kokybiškai įvertinti savo veiklą

bei palyginti savo rezultatus su kolegų pasiekimais. Todėl adaptuojant PSP procesą buvo

stengiamasi minimizuoti pokyčius esamo proceso infrastruktūroje. Dėl šios priežasties nebuvo

kuriamos nei naujos procedūros, nei diegiami nauji įrankiai - jau egzistuojančios procedūros ir

į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žiai

PSP proceso diegimo metu paaiškėjo, jog PSP mokymų metu gautų įgūdžių nepakanka

norint sėkmingai įdiegti procesą. Pirmu atveju šį trūkumą organizacija kompensavo

organizuodama specialius seminarus, kurių metu buvo analizuojamas PSP procesas ir numatoma

kaip jis galėtų būti diegiamas gamybinėje aplinkoje. Taip pat paaiškėjo, jog darbuotojai labiau

stengiasi ir jų motyvacija ženkliai didesnė, kai juos apmoko konsultantai, o ne apmokyti pačios

organizacijos darbuotojai. Teigiamai motyvaciją veikia ir galimybė gauti sertifikatą, kuris yra

kaip atlygis už mokymams sugaištą laiką.

Antru atveju buvo gauti kitokie PSP proceso diegimo rezultatai ir išvados. Organizacijai

nepavyko 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 skirstomų užduočių prioritetų, kas neleidžia pakankamai tiksliai įvertinti

reikalingų laiko sąnaudų ir sudaryti tikslių planų.

• Netiesioginių veiklų vykdymo (pvz.: pagalba marketingo žmonėms).


Mokymo medžiaga 100

• Nesugebėjimo panaudoti produkto dydžio vertinimui kodo eilučių skaičiaus matavimo

vienetą (LOC).Atmestino proceso duomenų rinkimo.Nepakankamo vadovybės palaikymo.

Pagrindinės išvados:

• PSP įvestos klaidų klasifikavimo ir analizės veiklos užtikrino geresnę galutinio

produkto 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, inspiruojantis esančio proceso kaitą nei kaip

modifikacijų nereikalaujantis ir pilnai paruoštas naudojimui proceso modelis.

• Norint tikėtis teigiamų rezultatų diegiant PSP procesą (komandos kontekste), būtina

PSP proceso adaptacija konkrečiam atvejui, automatinių įrankių sukūrimas ir visapusiškas

vadovų palaikymas.

PSP proceso duomenų kokybės problema

PSP 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 ir pastovų tobulėjimą. Pagal PSP metodiką, asmuo kuria programas, naudodamasis

griežtai apibrėžtais ir struktūrizuotais metodais, leidžiančiais kurti aukštos kokybės produktus

suplanuotais terminais. Nors PSP proceso naudojimas suteikia galimybę programų sistemų

kūrėjui dirbti disciplinuotai, tačiau dideli surenkamų duomenų kiekiai (daugiau kaip 500

skirtingų rodiklių reikšmių vieno projekto metu) bei jų pateikimas popieriniu pavidalu (PSP2

proceso lygyje reikia pildyti 12 skirtingų formų) verčia abejoti, ar galima pasitikėti surinktų

duomenų kokybe bei jais remtis, priimant tam tikrus sprendimus. Norint atsakyti į šį klausimą,

A.M.Disney ir P.M.Johnson atlikto specialų tyrimą.

Prieš atliekant tyrimą, buvo iškelta hipotezė, jog klaidos PSP proceso surenkamuose

duomenyse gali ženkliai pakeisti kai kurių rodiklių, naudojamų pačiam procesui vertinti, vertes.

Apskaičiuotos ir tikrosios rodiklių vertės gali skirtis tiek, kad to užtektų programuotojui priimti

klaidingus sprendimus, lemiančius jo asmeninio proceso tobulinimo eigą. Šiai hipotezei

patikrinti buvo atitinkamai paruoštas PSP procesas (užtikrinta geresnė proceso surenkamų

duomenų kokybė) ir pristatytas 10 studentų grupei, kuri jį naudojo viso tyrimo metu. Vėlesnė

surinktų duomenų analizė patvirtino tyrimo autorių hipotezę: buvo nustatyta virš 1500 klaidų

pateikiamuose PSP proceso duomenyse, tiek pakeitusių kai kurių rodiklių vertes, jog buvo

pasirinkti klaidingi proceso tobulinimo keliai.



Analizės rezultatai

Autorių atlikta surinktų duomenų analizė parodė, jog tiriamųjų pateiktuose duomenyse

buvo 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 ir duomenims atstatyti buvo apibrėžtas taisyklių rinkinys, kuriuo

naudojantis pavyko atstatyti didžiąją daugumą klaidingai pateiktų rodiklių verčių. Palyginus

pateiktus ir ištaisytus duomenis, buvo nustatyta, jog didžiausią įtaką klaidos turėjo klaidų tankio

bei kainos-efektyvumo rodiklių vertėms. Tam tikrais atvejais skirtumas buvo pakankamai

didelis, kad būtų pasirinktas klaidingas išanalizuotų duomenų interpretavimas ir tuo pačiu

neteisingas proceso tobulinimo kelias.

Išvados ir rekomendacijos

• Mokymų metu naudoti įrankius, leidžiančius automatizuoti PSP proceso surenkamų

duomenų agregavimą ir analizę. Šie įrankiai turi būti pilnai integruoti, t.y. programuotojas

pateikia tik pradinius 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ėkmingai naudoti PSP procesą ir būti užtikrintiems gautų duomenų kokybe.

• PSP proceso vertinimui nenaudoti PSP metrikų. Didžioji dalis skelbiamų PSP proceso

studijų procesą vertina naudojant paties PSP proceso metrikas, t.y. lyginami PSP proceso

duomenys surinkti mokymų pradžioje su duomenimis surinktais mokymo kursų pabaigoje. Tai

vadinama “vidinių matavimų vertinimu”, kadangi PSP procesas vertinamas paties proceso metu

surinktų duomenų pagalba. Norint tinkamai įvertinti PSP proceso naudą reiktų naudoti “išorinių

matavimų vertinimą”, kai PSP proceso efektyvumui vertinti lyginama programų sistemų kūrėjo

darbo kokybė nenaudojant PSP proceso ir naudojant PSP procesą.

• Nors automatiniai įrankiai užtikrina surinktų duomenų analizės kokybę, tačiau užtikrinti

surenkamų duomenų kokybę beveik neįmanoma. Tai priklauso nuo kiekvieno PSP procesą

vykdančio asmens noro ir motyvacijos pateikti pilnus ir korektiškus duomenis.

• Aiškiai apibrėžti kokiu tikslu renkami duomenys, taip bus išvengta tyčinio duomenų

klastojimo.


[BOK05] The Personal Software ProcessSM (PSPSM) Body of Knowledge, Version 1.0

CMU/SEI-2005-SR-003



[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 ProcessSM. Addison-

Wesley, 1996.

[Hum98] Watts S. Humphrey. Three Dimensions of Process Improvement Part II: The

Personal 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. PSPSM: A Self-Improvement Process for Software Engineers.

Addison-Wesley Professional, 2005.

[Mor00] Maurizio Morisio. Applying the PSP in Industry, IEEE Software

November/December 2000, 0740-7459/00, 2000.

[Sta98] Menegos Stavros. PERsonal Software Process Improvement PERSPI, Process

improvement experiment final report, ESSI project number: 24158, 1998.

Programų sistemų inžinerija 8. Komandinis programų kūrimo procesas


8. Komandinis programų kūrimo procesas

Turint apmokytus disciplinuotai dirbti inžinierius, iškyla klausimas, kaip reikia suburti

komandą ir organizuoti komandinį darbą, kad kiekvienas galėtų efektyviai taikyti disciplinuoto

darbo įgūdžius. Be atitinkamų nurodymų ir paramos, komanda bus priversta bandymų ir klaidų

keliu išradinėti tai, kas jau pakankamai gerai žinoma ir sėkmingai naudojama. Tai verčia ieškoti

metodų, remiančių komandos formavimą ir 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. Komandos

palaikymo veiklos yra tokios, kurios palaiko pasirinktą komandos taktiką ir kryptį, siekiant

iškeltų tikslų, bei didina komandos vertę. Vienas iš modelių, pateikiančių atsakymus į iškeltus

klausimus yra komandinio programų kūrimo proceso modelis TSP (angl. Team Software

Process), kurio mokymui skirta versija buvo pristatyta Watts S.Humphrey knygoje “Introduction

to the Team Software Process” [Hum99], o pilnos TSP versijos apžvalgos pristatytos

moksliniuose darbuose [Hum98, Hum00]4.

TSP procesas pakankamai smulkiai apibrėžia projektuose dalyvaujančių asmenų roles ir

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 ir be

trukdžių. Ypatingai daug dėmesio skiriama tiksliam viso proceso žingsnių dokumentavimui ir

nuosekliam jų vykdymui. Tai turi padėti pereiti nuo bandymų ir ieškojimų kelio, prie konkrečiai

ir labai tiksliai apibrėžto proceso metodų įsisavinimo ir jų įgyvendinimo. Susipažinus su šia

medžiaga turi sumažėti klausimų “kaip daryti”, “ką daryti” ir “kada daryti”, nes jie dažniausiai

sutinkami esant neaiškumams projekto organizavime ir valdyme, o ši medžiaga kaip tik ir

padeda, sekant nurodytu procesu, pereiti nuo organizavimo ir valdymo problemų sprendimo, prie

produkto kūrimo.

TSP projektiniai sprendimai

Yra daug būdų suprojektuoti procesą. TSP atveju buvo įgyvendinti septyni pagrindiniai

projektiniai sprendimai

Procesas turi remtis PSP

TSP turi daug formų ir scenarijų, bet daug iš jų sutampa su PSP. Žinant PSP, nesunku bus

išmokti atlikti naujus TSP darbus, nes jie remiasi panašiais principais. Nežinant PSP, greičiausiai

TSP procesai gali pasirodyti sunkiai įveikiami.

4 Reikia pažymėti, kad galima rasti tik apžvalgas, o pilnas TSP aprašymas yra viešai neprieinamas.



Kurti produktus keliais ciklais

Siūloma produktą kurti keliais ciklais, kurių kiekvienas apima reikalavimų apibrėžimo,

projektavimo, įgyvendinimo ir testavimo procesus. Pirmo ciklo eigoje kuriama produkto dalis su

minimaliomis funkcijomis. Kitų ciklų metu produktas plečiamas, be to, prireikus gali būti

pakoreguotas pats procesas.

Pasiūlyti standartinius kokybės ir progreso vertinimo būdus

Vertinimas yra esminė kokybiško darbo prielaida. TSP siūlomi vertinimai remiasi

naudotais PSP.

Pateikti komandų ir narių vertinimo būdus

Pagrindinis vertinimo tikslas yra padėti kuo geriau atlikti darbą, vertinimas taip pat parodo

darbo 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 ne

kaip kiekvienas žmogus dirbo. Net jei rolės vertinimas gali būti suprastas kaip vertinimas, kaip

dirbo tas žmogus, kuris atliko tą rolę, bet TSP svarbiausia, kaip veikia procesas, o ne kaip

pasirodė žmogus.

Reikalauti iš inžinierių proceso disciplinos

Programų sistemų kūrėjams sunku nuosekliai ir drausmingai atlikti savo darbą. Yra trys

priež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 gaires

Netgi gerai vykstantis projektas gali turėti komandinio darbo problemų. Kiekvienas

komandos narys vykdo skirtingas roles ir kiekviena iš jų turi savo tikslus. Kai tikslai susikerta,

atsiranda prieštaravimų tarp komandos narių. Geriausia komandos nesutarimus spręsti pasitelkus

visą komandą. Dauguma žmonių yra susirūpinę savo kaip komandos nario įvaizdžiu, siekia

pripažinimo komandoje norėdami pritapti prie komandos. Jei komandos nariai negali dirbti kartu

efektyviai, reikia kreiptis į vadovybę. Jei nepavyksta išspręsti komandos problemų, gali tekti

pašalinti kažkuri narį iš komandos.

TSP struktūra ir eiga

TSP 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 ir

testuojamas.



3. Sujungus dalis turi gautis galutinis norimas produktas.

TSP kūrimo ciklų struktūra pateikiama paveikslėlyje:

8.1 pav. TSP kūrimo ciklų struktūra

Startavimas

Projekto startavimo tikslai: suformuoti komandą, pasiskirstyti rolėmis, nusistatyti projekte

siekiamus 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 patirtimi gerinti (tikslinti) bei išskirti naujus tikslus.

Siūlomi standartiniai komandos tikslai: kurti kokybiška produktą; gerai valdyti projektą ir

jį produktyviai vykdyti; baigti laiku.

Siūlomi standartiniai komandos narių tikslai: būti efektyviu bei bendradarbiaujančiu

komandos nariu; dirbti tvarkingai (drausmingai metodiškai); planuotis ir sekti savo asmeninį

darbą; kurti kokybišką produktą

TSP taip pat siūlo standartinius tikslus kiekvienai rolei.

Strategija

Pagal TSP reikia planuoti prieš atliekant pilną reikalavimų analizę. Tam yra trys

pagrindinė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 pat

Startavimas1

Planavimas 1

Reikalavimai 1

Testavimas1

Aptarimas 1

Strategija 1

Projektavimas 1

Įgyvendinimas 1

Startavimas 2

Planavimas 2

Reikalavimai 2

Testavimas 2

Aptarimas 2

Strategija 2

Projektavimas 2

Įgyvendinimas 2

Startavimas 3

Planavimas 3

Reikalavimai 3

Testavimas 3

Aptarimas 3

Strategija 3

Projektavimas 3

Įgyvendinimas 3

Galutinis produktas



numatyti kitus rizikos faktorius; (3) jei nėra plano, komanda yra priversta pasirašyti sutartį pagal

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

gairių, kaip sistema bus realizuota.

Pagrindinis tikslas kuriant strategiją - minimizuoti riziką. Strategijos kūrimo žingsnyje

identifikuojamos rizikos, prognozuojamas produkto dydis ir laikas, reikalingas jam sukurti,

sudaromas konfigūracijos valdymo planas.

Planavimas

Kam reikalingi planai:

1. Efektyvesnis darbas. Turint detalų planą galima efektyviau dirbti. Be plano žmonės

paprastai atlieka darbus tokia tvarka kaip išeina o ne kaip greičiau, švaisto laiką perplanuodami

kiekviename ž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, ir kada baigsi. Tokie įsipareigojimai bus realistiški ir kiti komandos nariai

galės jais pasitikėti.

3. Kokybiškesnis darbas. Spaudžiant terminams kai kurie darbai būna atliekami

paskubomis, dėl ko kenčia produkto kokybė. Turint realistišką planą to neatsitiks.

Subalansuoti planai. Viena iš pagrindinių planavimo problemų yra nesubalansuotas darbo

krūvis. Tie inžinieriai, kurie turi daugiau darbo, dažniausiai užlaiko visą komandą. Subalansuotu

vadinamas toks planas, pagal kurį visi baigia darbus maždaug tuo pačiu metu ir niekam nereikia

nieko 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. TSP

pagrindiniai progreso sekimo matai yra suplanuota vertė (angl. planed value - PV) ir uždirbta

vertė (angl. earned value - EV). Šie matai padeda nustatyti, kiek kiekviena užduotis įtakoja

tvarkaraš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ų, bet

detaliau nesuplanuota. Kaip po 150 valandų pasakyti, ar atsiliekama nuo tvarkaraščio, ar darbas

bus baigtas laiku? Štai kam reikalingi detalūs planai. TSP reikalauja planuoti 10 valandų arba

mažesniais „gabaliukais“, tokiu būdų netikrumas dėl progreso bus daugiausia 10 valandų. Toks



tikslumas reikalingas tik žmogaus lygyje, t.y. jei užduočiai skirta daugiau negu 10 valandų, bet ją

atlieka keli žmonės, užduotį skaidyti nebūtina.

Neplanuotos užduotys. Visada atsiranda užduočių, kurios nebuvo numatytos. Dėl to gali

tekti planuoti iš naujo. Tačiau turint apibrėžtą procesą tokios užduotys nebūtų labai didelės ir

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žduotys

neduotų EV. Siūloma pirmuosiuose 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); procentas

be defektų (angl. Percent Defect-Free); defektai puslapyje (angl. Defects Per Page); defektai /

KLOC (angl. Defects / KLOC); defektų santykiai (angl. Defect Ratios); projekto vykdymo laiko

santykiai (angl. Development Time Ratios); A / FR; peržiūrų ir inspekcijų greičiai (angl. Review

and Inspection Rates); defektų darymo greičiai (angl. Defect-Injection Rates); defektų šalinimo

greičiai (angl. Defect-Removal Rates); defektų šalinimas etapuose (angl. Phase Yield); defektų

šalinimas procese (angl. Process Yield).

Reikalavimai

Proceso reikalavimų fazėje komanda formuluoja ir 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 ir prasmingi. Nuo reikalavimų kokybės tiesiogiai priklauso

viso 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 papildomus

klausimus projekto užsakovui (instruktoriui). Šioje vietoje dar kartą yra pasitikrinama, ar gerai

buvo suprasti pradiniai kliento norai.

Reikalavimų dokumentavimas: Sistemos Reikalavimų Specifikacija (SRS). Suformuluoti

reikalavimai turi būti užrašomi į Sistemos Reikalavimų Specifikaciją. Šis dokumentas yra derybų

objektas tarp projekto užsakovo ir jo vykdytojo.

Kodėl reikalavimai yra svarbūs?

Svarbiausia yra reikalavimų apibrėžimo procesas. Šis procesas yra labai svarbus, nes

leidžia inžinieriams „įsijausti“ į projektą. Pirmą kartą visi projekte dalyvaujantys žmonės (tiek

užsakovas, tiek vykdytojai) aiškiai suvokia darbo tikslą ir viziją. Dėl šios priežasties reikalavimų

formulavime turi dalyvauti visi komandos nariai. Jų patirtis šiame etape yra vertingesnė net už

patį SRS dokumentą.



Reikalavimų formulavimo rezultatas yra bendras susitarimas. Projektas bus sėkmingas tik

tada, jei komanda šiame etape vieningai sutars dėl projekto detalių tiek tarpusavyje, tiek su

užsakovu. Kartu tai yra ir įsipareigojimas (tarp kliento ir vykdytojo) dėl projekto rezultatų.

Nepatyrę inžinieriai kartais į tai kreipia nepakankamai dėmesio – ir tai yra dažniausiai

pasitaikanti projektų žlugimo priežastis.

Reikalavimų pasikeitimai ir jų valdymas. Reikalavimų pasikeitimai yra potencialus

projekto problemų šaltinis. Netinkamai juos valdant, projektas gali užsitęsti, kainuoti daugiau nei

buvo numatyta ar iš viso nepavykti. Todėl yra būtina kiek galima anksčiau ir tiksliau juos

apibrėžti.

Dažniausiai reikalavimų pasikeitimus inicijuoja užsakovas. Viena svarbiausių ir

dažniausiai pasitaikančių problemų, trukdanti tinkamai apibrėžti reikalavimus yra užsakovo

neapsisprendimas. Kartais gali net susidaryti įspūdis, kad klientas nežino ko nori – tai nutinka

dėl tokių priežasčių: užsakovas neturi patirties IT srityje ir tiesiog nežino, kokius sprendimus ji

gali pateikti; užsakovams sunku tiksliai įsivaizduoti naujos sistemos galutinį variantą, jei jiems

tenka 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š pirmo žvilgsnio nežymūs pakeitimai

reikalauja papildomo laiko ar išlaidų. Kuo vėliau projekte šie pakeitimai yra inicijuojami, tuo

daugiau jie kainuoja. Svarbu yra tiksliai numatyti, kokią įtaką projektui turės reikalavimų

pasikeitimas – ir suderinti tai su komanda bei užsakovu. Taip pat svarbu yra atskirti reikalavimų

pasikeitimą nuo reikalavimų pridėjimo – tai padaryti padės tik tiksliai parengta SRS. Vienintelis

komandos ginklas prieš nevaldomus reikalavimų pakeitimus yra patvirtinta Sistemos

Reikalavimų Specifikacija.

Reikalavimų formulavimas, kai poreikių specifikacija yra nepilna ar neaiški. Dažnai

projekto 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 sistemos

naudotojais - yra tiriamas procesas, jo aplinka bei kiti veiksniai, kurie gali įtakoti projekto baigtį.

Projektavimas

Projektavimo fazės tikslas yra sistemos bendra struktūra. Šitoje fazėje sudaroma

programos projekto specifikacija (angl. Software Design Specification - SDS), kurioje

dokumentuojamas 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ą ir pilną specifikaciją, kaip turi būti sukonstruotas objektas. Pilnas

projektavimas apibrėžia produkto pagrindines dalis, jų sąveiką ir jų derinimo būdą. Po



reikalavimų apibrėžimo visas procesas apjungia įvairių lygių projektavimą. Aukšto lygio

projektavimas skiriasi nuo detaliojo projektavimo tik mastu ir detalėmis. Todėl aukšto lygio

projektavimo metu reikia sukurti tokią specifikaciją, kurią keli inžinieriai galėtų naudoti

nepriklausomai kurdami dalis. Kai aukšto lygio projektas yra pilnas ir tikslus, inžinierius gali

greitai atlikti komponentų detalųjį projektavimą. Tam jiems reikia žinoti pilnas funkcines

specifikacijas kiekvienam komponentui, jo interfeisus ir būsenas.

Projektavimas komandose. Kai vienas žmogus kuria projektą, jam rūpi tiktai, kaip jį

sukurti ir kokia tvarka kurti skirtingas projekto dalis. Kai kuriama komandoje, iškyla dar trys

svarbūs klausimai: kas kokią dalį turi kurti, kokia tvarka jie turi atlikti darbą ir kaip suderinti tas

dalis.

Paprastai kuriant programų sistemą reikia apibrėžti bendrą sistemos struktūrą prieš darant

ką nors kitą. Iki to sunku paskirti 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, tai

yra gerai, bet iš tikrųjų tai tik laiko gaišimas. Nes kai kuriama didelė sistema, tik keli žmonės

produktyviai dirba, o kiti tik užduoda klausimus ir siūlo idėjas. O tai tik trukdo projektuotojams

dirbti. Paprastai reikia tik vieno ar dviejų žmonių aukščiausio lygio projektui sudokumentuoti,

interfeisams apibrėžti, sistemos funkcijoms paskirstyti tarp komponentų ir bendroms programos

struktūrai ir logikai apibrėžti.

Kol sistemos projektuotojai kuria išorines komponentų specifikacijas, kiti inžinieriai gali

apmąstyti alternatyvius būdus komponentams sukurti. Jie netgi gal kurti prototipus. Vartotojo

interfeisas –viena iš funkcijų, kuriai gali reikėti sukurti prototipą. Vienas ar du inžinieriai gali

sukurti primityvų vartotojo interfeisą ir netgi išbandyti jį su paprastais vartotojais.

Kuriant produktą, reikia efektyviausiai panaudoti visų komandos narių idėjas. Viena iš

pagrindinių problemų yra paskatinti narius dirbti kartu. Nes žmonės labai nenoriai reiškia savo

mintis ir pasiūlymus. Visi komandos nariai turi suprasti, kad komandoje susirinko žmonės su

įvairiomis žiniomis ir patirtimi. 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ų ir minčių, gal kas turi patirties aptariamoje temoje, o paskui tai

pritaikyti. Komandos, kurios tą daro, paprastai dirba žymiai efektyviau.

Projektavimo standartai: vardų standartas; interfeisų formatai; defektų standartas; kodo

eilučių skaičiavimo standartas; projekto apiforminimo standartas.

Projektavimas pakartotiniam naudojimui. Vienas iš būdų produktyviai panaudoti

komandos narių laisvą laiką aukšto lygio projektavimo metu yra apibrėžti komandos pakartotinio

naudojimo standartus. Tai gali reikšti galimų bendrų funkcijų identifikavimą ir pradinio

pakartotinio naudojimo dalių rinkinio pasiūlymą. Paprastai komanda pasiekia geresnių rezultatų,



kai kažkas sukuria pradinį pakartotinio naudojimo standartą ir apibrėžia pakartotinių dalių

rinkinį.

Pakartotinis naudojimas – potencialiai galingas būdas padidinti komandos produktyvumą.

Nustačius pakartotinio naudojimo programą visada galima sutaupyti konstravimo laiką pirmame

kūrimo cikle ir dar daugiau laiko vėlesniuose cikluose. Paprastai pakartotinis naudojimas

nagrinėjamas projekto pradžioje: mažuose projektuose projektavimo fazėje, dideliuose

projektuose apie tai galima pradėti galvoti jau reikalavimų ir strategijos metu.

Projektavimas naudojimo patogumui. Vienas iš būdų užtikrinti produktų naudojimo

patogumą yra sukurti scenarijus visoms pagrindinėms funkcijoms, išanalizuoti tuos scenarijus ir

patikrinti, ar jie atitinka sistemą, kurios projektuotojų manymu reikia užsakovams. Jeigu

abejojama, kaip kokia nors funkcija turi veikti, reikia arba peržiūrėti atitinkamus scenarijus su

programos ekspertu, arba sukonstruoti paprastą prototipą. Paprastai patartina konstruoti ir

demonstruoti visus vartotojų interfeisų prototipus.

Projektavimas testavimui. Kelių ciklų projektui yra svarbus pilnas testavimas. Tačiau

reikia papildomo programavimo tam, kad programa palaikytų šiuos testus. Taip pat reikia gerai

suplanuoti testavimą. Kai komanda gerai suplanuoja integravimą ir sistemos testus, jie paprastai

suranda daugiau defektų per testų planavimą, negu per tikrąjį testavimą.

Yra dvi testavimo rūšys: juodosios dėžės ir baltosios dėžės testavimai. Juodosios dėžės

testavimas nagrinėja programos išorines specifikacijas ir nesigilina į programos vidinę struktūrą.

Baltosios dėžės testavimas, atvirkščiai, nagrinėja programos logiką ir struktūrą. Labai svarbu

atlikti abu šiuos testavimus.

Projekto peržiūra ir inspektavimas. Projekto peržiūra ir inspektavimas gali padėti padidinti

produkto kokybę. Pirmiausia reikia gerai sudokumentuoti projektą. Paskui, kai ruošiamasi

projektavimo 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š kitos

pusės kuo daugiau žmonių atlieka inspektavimą, tuo daugiau laiko tai užima. Jei laiko yra daug,

geriau turėti daugiau inspektuotojų.

Įgyvendinimas

Prieš 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.

Pirmame lygmenyje sistema dalinama į posistemes, komponentus ar modulius, ir apibrėžiamos

jų išorinės specifikacijos bei suprojektuojama aukščiausio lygio logika. Tuomet pereinama į

antrą ir tolimesnius lygmenis, ir juose veiksmai kartojami smulkesnėms sistemos dalims. Tai turi

būti pakartota tiek kartų, kiek yra reikalinga gauti atominiams sistemos elementams, kuriuos



galima nesudėtingai realizuoti (siūlomas atominių elementų sudėtingumas – ne daugiau kaip 150

kodo eilučių).

Realizacijos standartai. Prieš pradedant produktų realizavimą, kaip ir prieš bet kurį kitą

proceso etapą, komanda turėtų skirti laiko standartų apsibrėžimui. Tam neturėtų būti gaištama

daug laiko, užteks paprašyti kelių komandos narių paruošti standartų juodraščius, pasirinkti

tinkamiausią ir eigoje jį papildyti ar patobulinti. Už komandos darbą su standartais atsakingas

kokybės/procesų vadovas.

Standartų peržiūra. Peržiūrint ir priimant standartus, reikia būti pragmatiškais – galima be

galo ilgai ginčytis, kas geriau tinka komandai, kiekvienas narys turės savo nuomonę ir gali

niekada nesutarti. Kaip minėta, reikia nebijoti pasirinkti iš pažiūros tinkantį standartą ir eigoje jį

pritaikyti savo reikmėms.

Reikia peržiūrėti vardų, interfeisų, pranešimų standartus sukurtus projektavimo stadijoje,

kad įsitikinti, jog jie ir toliau tinka naudojimui, taip pat pasitikrinti ar visi komandos nariai turi

pilną pakartotinai panaudotinų funkcijų sąrašą ir juo naudojasi. Peržiūrėti terminų žodyną,

įsitikinti ar viskam yra neprieštaringi pavadinimai ir ar jie nenaudojami skirtingai.

Kodavimo standartai. Su kodavimo standartais komanda turėtų būti susipažinusi asmeninio

proceso (PSP) metu, ir šie standartai turėtų būti taikomi. Kai visa komanda naudoja tuos pačius

kodavimo standartus, visas rašomas kodas yra panašus, tai labai palengvina kodo peržiūras,

padaro jas greitesnėmis ir efektyvesnėmis.

Geras kodavimo standartas apibrėžia ir komentavimą, taip pat palengvinantį peržiūras.

Naudojant kodavimo standartus, skatinamas ir pakartotinis kodo panaudojamumas - kai

„gabalas“ programos kodo atrodo panašus į tokį, kokį pats parašytumėte, labiau tikėtina, kad

paimsite jį ir panaudosite, vietoj to, kad rašytumėte pats.

Dydžių standartai. Reikia nepamiršti ir matavimo standartų. Procesai sukuria įvairių,

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 prie

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



Defektų standartai. Standartinių PSP defektų tipų turėtų būti gana, kad identifikuoti

savuosius defektus. Kartais gali tekti pridėti vieną kitą savo sugalvotą tipą, tačiau reikėtų

nepersistengti juos kuriant, nepatartina perdaug smulkiai sudalinti defektus į tipus, susikurti

gremėzdiško defektų standarto, kuriame įvyks klaidos bandant priskirti defektą kažkuriam tipui,

nes jų bus paprasčiausiai perdaug. Taip pat reikia stengtis nemaišyti defekto tipo su defekto

priežastimi (pvz., nepilni reikalavimai, nepakankamos žinios – tai defektų priežastys, bet ne

tipai. Dauguma defektų, kylančių dėl nepilnų reikalavimų, turėtų būti priskirti funkcinių

reikalavimų tipui). Dažniausi defektų tipai – duomenų, funkciniai ir sisteminiai.

Realizacijos strategija. Realizacijos strategija susijusi su peržiūromis, pakartotiniu

panaudojimu bei testavimu. Kodo peržiūras lengviausia vykdyti iš apačios į viršų, t.y. pradėti

nuo smulkiausių, atominių kodo dalių, ir kilti į viršų. 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ūris

suformuoja ir realizacijos strategiją – pradėti realizuoti reikia nuo smulkiausių, atominių dalių, ir

jungiant jas tarpusavyje kilti į aukštesnius lygmenis.

Kadangi žemiausio lygmens atominius objektus lengviausia pakartotinai panaudoti,

strategija „iš apačios į viršų“ tokį panaudojimą skatina. Kad pakartotinis panaudojimas būtų

didesnis, kiekvienas išeities tekstas turėtų turėti antraštę, pasakančią viską apie galima jo

panaudojimą. Taip pat kasdieniuose komandos susitikimuose turėtų būti dalinamasi informacija

apie galimas pakartotinai panaudojamas dalis.

Kitas svarbus strategijos rūpestis – atitikti testavimo planą. Realizavimas turi vykti tokia

tvarka, kuri neprieštarautų iš anksto sudarytiems testavimo planams.

Peržiūros ir inspekcijos. Labai svarbu pabrėžti, kad peržiūros ir inspekcijos yra

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

Testavimas

Pagrindinės TSP testavimo veiklos:

1. Surinkti sistemą, naudojant sukurtus ir jau ištestuotus atskirus modulius.

2. Atlikti integracijos testus: patikrinti, ar sistema “teisingai” surinkta, ar yra visi

komponentai ir kaip jie kartu funkcionuoja.

3. Atlikti sistemos testus: patikrinti, ar produktas atlieka tai, kas apibrėžta sistemos

reikalavimuose.

Tuo pat metu atliekamos ir šios veiklos:



- Identifikuoti prastos kokybės modulius ir 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 ir po pataisymų bei grąžinti

juos kokybės/proceso vadovui, kuris turi juos atiduoti perdirbti 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 ir atlikti. Taip pat

reikalingi planai surinkimo, integracijos testavimo bei sistemos testavimo veikloms.

Galutinis testavimo planas turi parodyti, kaip bus testuojamas kiekvienas reikalavimas ir

kaip testai tikrins tam tikras reikalavimų sritis. Galutinis testavimo planas turi aprašyti

numatomus vykdyti testus, jų vykdymo tvarką ir testo medžiagą, reikalingą kiekvienam testui.

Be to, jis turi apibrėžti testavimo tikslus ir užduotis.

Galutiniame testavimo plane turi būti:

• Testo atliekami žingsniai;

• Medžiaga (programos/skriptai ir duomenys) kiekvienam testui;

• Kokius rezultatus testas turi gauti;

• Įverčiai: testo vykdymo bedefektis laiko tarpas, galimų defektų skaičius, bendras laikas

kiekvienam testui atlikti.

• Visos testavimo medžiagos sąrašas;

• Kiekvieno testo tikslai;

• Testavimo medžiagos dydis;

• Kas ir kada sukurs testavimo medžiagą ir kiek laiko tai užtruks.

Testų rezultatų sekimas ir matavimas. Planuojant atlikti daug testų, svarbu matuoti testų

efektyvumą – rastų defektų ir testo vykdymo laiko santykį. Vertinat atliktus testus, patogu vesti

testavimo protokolą (test-log), kurio struktūra yra tokia: Testavimo data; Asmuo, atlikęs testus;

Kokie testai buvo atliekami (jų pavadinimai/numeriai); Testuotas produktas ir 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: visi

testai, kurie anksčiau yra aptikę defektų, visi testai, kurie tikrino tas sistemos sritis, kurios buvo

modifikuotos vėlesniuose cikluose.

Dokumentavimas. Kol viena komandos dalis planuoja, kuria ir vykdo testus, likusi dalis

rašo vartotojo dokumentaciją. Siūloma pradiniuose kūrimo cikluose daugiau žmonių skirti

testavimui, o galutiniuose – dokumentavimui. Didesnėse sistemose dokumentavimas turėtų

prasidėti daug anksčiau už testų rengimą.



Dokumentavimas yra labai svarbi kiekvieno programinio produkto dalis – galbūt net

svarbesnė už programos kodą. Ir geriausia dokumentuoti kažkurią sistemos funkciją tuoj pat po

jos suprojektavimo. Jei dokumentacija bus paruošta anksčiau nei užbaigta sistemos projektinė

specifikacija – reikės atlikti daug dokumentacijos pakeitimų, jei dokumentavimo darbai bus per

ilgai atidėliojami – tada tai užims daugiau laiko, nes reikės prisiminti projektavimo metu

priimtus sprendimus.

Kokia turi būti gera vartotojo dokumentacija (“vartotojo vadovas”):

• Pirmiausia, reikia rašyti ne tai, kokia sistema buvo sukurta, o tai, ko labiausiai reikia

vartotojui, dirbančiam su sistema: kaip vartotojui pradėti naudotis produktu, ką vartotojas gali

daryti su produktu, kaip jam surasti reikiamą informaciją;

• Siūloma naudoti: Terminų žodyną; Klaidų pranešimų skyrių ir pan.; Esminių skyrių

rodyklę; Detalų turinį;

• Kitos rekomendacijos: Rašyti trumpus sakinius; Naudoti paprastus žodžius ir frazes;

Naudoti sąrašus bei struktūrizuoti informaciją;

• Dokumentas turi būti gerai skaitomas ir suprantamas.

Iš pradžių parengiamas dokumentacijos eskizas, vėliau jis konkretizuojamas. Vartotojo

dokumentacija turi būti peržiūrima vieno ar kelių komandos narių. Peržiūrint, turi būti paliesti šie

aspektai:

• Dokumento struktūra: ar dokumente išdėstytas produkto turinys, ar tai, ką vartotojas gali

daryti su šiuo produktu?

• Dokumento terminologija: ar vartotojas turi turėti specialių žinių, kad galėtų efektyviai

naudotis dokumentu?

• Dokumento turinys: ar dokumentas apima visą produktą?

• Kruopštumas: ar metodai ir 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ėti

vartotojams, anksčiau nesinaudojusiems šia sistema ir jų prašoma atlikti veiksmus su sistema,

aprašytus vartotojo dokumentacijoje.

Aptarimas

Aptarimas yra galutinis žingsnis TSP procese. Jame peržiūrimas visas padarytas darbas

tam, kad įsitikinti, jog mes užbaigėme visus uždavinius ir užrašėme visą reikalingą informaciją

(užpildėme visas formas). Analizuojama, kas buvo padaryta ciklo eigoje su tikslu ištirti, kas

sekėsi, o kas – nelabai, ir padaryti išvadas, kaip kitą kartą atlikti darbą geriau.



Šis procesas labai reikalingas, nes jeigu mes nepakeisime savo darbo pobūdžio, tai ir toliau

dirbsime taip, kaip anksčiau (t.y., galbūt blogai). Aptarimas - tvarkingas būdas nustatyti sritis,

kurios reikalauja tobulinimo, ir 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ūrimo

grupėse daugiau nei pusė inžinierių užsiėmę programinės įrangos kūrimu. Todėl žinojimas, kaip

ją kurti, yra lemiamas kiekvienam inžinieriui.

Kaip aptarimas gali padėti? Kiekvienas ciklas baigiasi aptarimu, kuris suteikia

struktūriškai apibrėžtą būdą mokytis ir tobulėti. Aptarimo metu nagrinėjama tai, kas buvo

padaryta palyginus su tuo, ką buvo suplanuota padaryti. Ieškoma tobulinimosi galimybių ir

sprendžiama, kaip pakeisti darbo pobūdį kitame cikle arba kitame projekte. Galima keisti darbo

procesą, arba atrasti, kaip geriau sekti turimu procesu. Aptarimo procesas leidžia pamatyti

pokyčius, pereinant nuo vieno ciklo prie kito. Pirmas ciklas duoda pagrindą. Analizuojama, kas

padaryta, kiek tam buvo skirta jėgų, kokiais žingsniais viskas vyko. Nustatomas plano tikslumas

ir kaip tiksliai buvo laikomasi plano ir ar buvo proceso planas tinkamas. Identifikuojamos

problemos ir nustatomos jų priežastys, o taip pat klaidų išvengimo priemonės. Aptarimo fazė yra

patogus laikas nustatyti tobulinimosi galimybes ir nuspręsti, kur ir kaip padaryti pakeitimus

asmeniniuose ir komandiniuose procesuose.

Proceso pagerinimo pasiūlymai. Raktas sėkmingo tobulinimosi link yra

susikoncentravimas ties nedideliu pakeitimu. Šansai dideliems pokyčiams irgi atsiranda, bet

nedažnai. Dirbant projekte galima pastebėti, kad yra daug nežymių dalykų, kuriuos galima

pakeisti. Kiekvienas nepastebimas tobulinimasis tik truputį padeda, bet laikui bėgant iš jų

susidaro pastebimi žymūs pakeitimai. O svarbiausia, išmokstama, kaip pastoviai tobulinti savo

veiklą ir darbo pobūdį.

Su nedideliais pakeitimais yra susijusi viena problema – juos lengva užmiršti. Todėl ir

PSP ir 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 tobulinimosi

idėjas, kurios atsiranda. Idėjos galėtų būti: kaip geriau pasipraktikuoti kažkurioje srityje, išmokti

naudoti naujus įrankius, kaip pakeisti procesą ir panašiai. Kai ateina laikas aptarimui, labai

patogu turėti visus įrašus po ranka, atkurti visas savo idėjas ir tvarkingai jas nagrinėti.

Pagrindiniai TSP principai

• Programų sistemų kūrėjai dirbs efektyviai, jei naudos apibrėžtą ir matuojamą procesą

(efektyvus, apibrėžtas, matuojamas).



• Komanda bus motyvuota, jei dirbs turėdama bendrą viziją ir žinodama jai keliamus

tikslus (užtikrinantis efektyvios komandos sukūrimą).

• Procesas geriausiai atitiks komandos poreikius, jei bus jai pritaikytas (pritaikytas).

• Komandos nariai žinos už ką jie atsakingi ir kam turi atsiskaityti, jei komandoje bus

įtvirtintos aiškios atsakomybės ir atskaitomybė (įtvirtinantis atsakomybes, atskaitomybę)

• Programų sistemų kūrėjai aktyviai keisis informacija ir žiniomis, jei komandoje bus

skatinamas nuolatinis bendravimas (užtikrinantis informacijos mainus).

• Suteikti galimybę programų sistemų kūrėjams dirbti taip, kaip jie įpratę, tačiau

prisilaikant nustatyto komandos proceso ir atsižvelgiant į jų pačių surinktus duomenis ir kolegų

patirtį (disciplinuojantis).

• Norint pastoviai gerinti savo veiklą, reikia nuolat tobulinti procesą, atsižvelgiant į

proceso metu sukauptus istorinius duomenis ir rodiklius (evoliucionuojantis).

• Skatinti būsimų produktų kokybės užtikrinimą ir galimų rizikų įvertinimą bei valdymą

(užtikrinantis kokybės valdymą).

TSP praktikos

TSP procese išskiriama 11 praktikų, kurių taikymas sąlygoja aukščiau įvardintų proceso

principų įgyvendinimą:

1. Komandos tikslų suformulavimas ir dokumentavimas.

2. Rolių ir jų atsakomybių apibrėžimas bei priskyrimas.

3. Komunikavimo procedūrų apibrėžimas.

4. Projekto progreso sekimas.

5. Komandos proceso evoliucionavimo/pritaikymo plano paruošimas ir jo įgyvendinimas.

6. Produkto kūrimo strategijos ruošimas.

7. Produkto kūrimo plano ir tvarkaraščio ruošimas.

8. Reikalavimų specifikacijos ruošimas.

9. Projektavimas.

10. Rizikų įvertinimas ir valdymas.

11. Kokybės planavimas ir valdymas.

Komandos tikslų suformulavimas ir dokumentavimas

Tikslas. Suformuluoti komandai ir kiekvienam jos nariui keliamus tikslus, kurių bus

siekiama projekto metu.

Veiklos:

• Komandai keliamų tikslų suformulavimas ir dokumentavimas.

• Komandos nariams keliamų tikslų suformulavimas ir dokumentavimas.



• Kriterijų, kuriais remiantis bus vertinamas produkto ir komandos atitikimas

iškeltiems tikslams, apibrėžimas.

Aprašymas. Tikslų komandai ir jos nariams iškėlimas užtikrina, jog visi komandos nariai

žino, kokie uždaviniai jiems keliami projekto metu ir ko iš kiekvieno jų tikimąsi. Tuo pačiu,

bendrai iškelti ir patvirtinti tikslai apjungia komandos narius ir veikia motyvuojančiai, kadangi

formuluojant tikslus dalyvauja visi komandos nariai. Ši veikla ypač svarbi buriant naujas

komandas. Labai svarbu komandai iškelti tokius tikslus, kurie būtų realiai įgyvendinami, tik

tuomet tikslų iškėlimas turės realią vertę ir prasmę.

Komandai keliamų tikslų suformulavimas ir dokumentavimas. Tipiniai komandoms keliami

tikslai orientuoti į tokius aspektus: pagaminti kokybišką produktą (pvz.: sistemos integravimo

fazėje neužfiksuoti nė vienos klaidos); dirbti produktyviai ir efektyviai valdyti projektą; projektą

baigti laiku (pvz.: laiko prognozavimo paklaida mažesnė nei 5 procentai). Be abejo, komanda

gali papildyti ar pakeisti siūlomus tikslus kitais, tobulinti jų metrikas, tačiau nurodytieji yra

pritaikomi daugumai komandų.

Komandos nariams keliamų tikslų suformulavimas ir dokumentavimas. Komandos nariams

gali būti keliami skirtingi tikslai projekto metu, atsižvelgiant į kiekvieno iš jų patirtį ir įgūdžius.

Be to, komandos nariams keliami tikslai neturi prieštarauti komandai keliamiems tikslams.

Komandos nariams keliamų tikslų pavyzdžiai: efektyviai bendradarbiauti komandoje, dirbti

disciplinuotai, planuoti ir matuoti/vertinti visas savo užduotis, gaminti kokybiškus produktus. Jei

nurodytieji tikslai neatitinka komandos narių poreikių, komanda gali juos papildyti/pakeisti

savais.

Kriterijų, kuriais remiantis bus vertinamas produkto ir komandos atitikimas iškeltiems

tikslams, apibrėžimas. Komanda apibrėžia kriterijus, kuriais remiantis bus vertinama ar iškeltas

tikslas buvo įgyvendintas. Tai užtikrina, jog iškeliami tikslai bus išmatuojami ir realiai

pasiekiami. Priklausomai nuo iškeltų tikslų, kriterijai gali būti laikas, kokybė ir pan.

Rolių ir jų atsakomybių apibrėžimas bei priskyrimas

Tikslas. Apibrėžti rolių atsakomybes ir įsipareigojimus bei jas priskirti komandos nariams.

Veiklos:

• Apibrėžti kiekvienos rolės atsakomybes ir įsipareigojimus.

• Roles paskirstyti komandos nariams.



Aprašymas. Praktika savo pobūdžiu primena veiklą „Komandos narių tikslų iškėlimas”,

nes ir ją vykdant komandos nariams priskiriame tam tikrus įsipareigojimus. Tačiau čia komandos

nariams yra priskiriamos rolės, t.y. jie tampa atsakingi už paskirtą sritį. Kiekvienos rolės atstovui

apibrėžiamos atsakomybės ir įsipareigojimai, kuriuos jis turi vykdyti projekto metu kuruodamas

savo sritį.

Apibrėžti kiekvienos rolės atsakomybes ir įsipareigojimus. Komanda apibrėžia kiekvienos

rolės atsakomybes ir įsipareigojimus. Taip pat apibrėžiama kaip bus vertinamas rolių

įgyvendinimas. Reikalavimai dokumentuojami specialiose formose.

Roles paskirstyti komandos nariams. Atsižvelgiant į kiekvieno komandos nario įgūdžius,

sugebėjimus, patirtį bei jam keliamus tikslus projekte, paskiriama viena iš penkių projekto rolių.

Komunikavimo procedūrų apibrėžimas

Tikslas. Apibrėžti, kaip bus vykdomi informacijos mainai projekto metu.

Veiklos:

• Nurodyti pateikiamos informacijos rūšis ir atsakingus asmenis.

• Paruošti komandos susirinkimų grafiką.

Aprašymas. Informacijos mainai užtikrinami įtvirtinant kassavaitinius komandos narių

susirinkimus. TSP modelyje bendriems visų komandos narių susirinkimams skiriamas ypatingas

dėmesys, kadangi tai yra svarbiausias visų komandos narių bendravimo užtikrinimo būdų.

Komandos susirinkimų metu įvertinamas komandos progresas, planuojami darbai bei

analizuojamos einamosios problemos. Susirinkimuose dalyvauja visi komandos nariai, kadangi

kiekvienas privalo žinoti situaciją ir dalyvauti priimant sprendimus. TSP proceso aprašomas

kassavaitinis komandos susirinkimas užima pakankamai nedaug projekto laiko, kadangi

vykdomas pagal iš anksto žinomą scenarijų.

Nurodyti pateikiamos informacijos rūšis ir atsakingus asmenis. Apibrėžiamos pateikiamos

informacijos rūšys, kokią informaciją turi pateikti kiekvienos rolės atstovas bei kas atsakingas už

pateiktos informacijos peržiūrą ir analizę.

Paruošti komandos susirinkimų grafiką. Vienas svarbiausių efektyvios komandos

formavimo principų – informacijos mainų komandoje užtikrinimas. TSP procese tai sprendžiama

įtvirtinant kassavaitinius komandos susirinkimus, kurių metu keičiamasi informacija ir

pristatomos problemos. Paruoštą komandos susirinkimų grafiką tvirtina komandos vadovas.

Patvirtintas grafikas dokumentuojamas specialioje formoje.

Projekto progreso sekimas

Tikslas. Užtikrinti visapusišką vykdomo projekto kontrolę.



Veiklos:

• 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 rinkti

bei kokių ataskaitų pavidalu jie turi būti pateikiami kiekvieną savaitę. Iš visų komandos narių

pateiktų ataskaitų suformuojama viena bendra, kuri naudojama komandos narių susirinkimų

metu. Surinkti duomenys naudojami projekto progreso sekimui ir 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ę pateikia

tokio tipo informaciją:

• planuotų ir dirbtų valandų skaičius,

• kiekvienai iš užduočių planuoto ir realiai sugaišto laiko įverčius,

• kitos savaitės užduotis ir planuojamą laiką joms įvykdyti,

• identifikuotas problemas.

Apibrėžti informacijos pateikimo formą. Informacija pateikiama ataskaitų pavidalu

specialiai pritaikytose formose.

Pastabos. Šios praktikos tikslas – sekti projekto progresą, todėl duomenys turi būti tikslūs

ir 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 ir jo įgyvendinimas

Tikslas. Užtikrinti nuolatinį proceso evoliucionavimą, keičiant, eliminuojant ar pridedant

atitinkamas praktikų veiklas, o esant reikalui ir pačias praktikas.

Veiklos:

• Išanalizuoti proceso duomenis.

• Įvertinti rolių įgyvendinimą.

• Paruošti projekto (ciklo) ataskaitą ir tobulinimo pasiūlymus.



Aprašymas. Proceso peržiūra yra paskutinė TSP proceso fazė. Jos metu yra peržiūrimi

komandos atlikti darbai ir analizuojama tai, kas buvo atlikta, lyginant su tuo, ką buvo planuota

atlikti. Šios fazės metu ieškoma galimų proceso tobulinimų ir sprendžiama, kurias veiklas būtų

galima keisti/tobulinti ir 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 ir kiekvieno jos nario veiklas ir juos išanalizuoti,

• identifikuoti, kada procesas veikė sklandžiai, o kada kilo problemų.

Analizės metu nustatoma, ar pasiteisino prieš ciklą pasiūlyti proceso ir veiklų

pakeitimai/patobulinimai. Jeigu peržiūros metu paaiškėja, jog naudinga keisti procesą ar kurias

nors 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 įgyvendinta

kiekviena iš rolių. Vertinant roles, keliami tokie klausimai: Kas buvo atlikta gerai? Kur iškilo

problemų? Ką būtų galima tobulinti? Kokius tikslus būtų galima iškelti sekančiam ciklui ar

projektui?

Vertinimo rezultatai pateikiami tam tikslui paruoštoje formoje, kurią pildo kiekvienas

komandos narys.

Paruošti projekto (ciklo) ataskaitą ir tobulinimo pasiūlymus. Ši veikla aprašo ciklo

ataskaitos ruošimą. Projekto (ciklo) ataskaitoje pateikiama tokio pobūdžio informacija: ką

komanda gamino, kokį procesą naudojo, ką pavyko įvykdyti, ko nepavyko įvykdyti, ką ir kaip

bū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žiamos

realiais pavyzdžiais-įrodymais (pvz., veiklos rodikliais).

Pastabos. Proceso vertinimui negalima naudoti paties proceso metrikų. Tam tikslui turi

bū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) bei

vertinami programų sistemų kūrėjo rezultatai (kaip jie keitėsi, naudojant TSP procesą). Tai leis

nustatyti, kur procesą (praktikas) reikia tobulinti ar keisti.

Produkto kūrimo strategijos ruošimas

Tikslas. Parinkti, apibrėžti ir dokumentuoti produkto kūrimo strategiją.



Veiklos:

• Nustatyti strategijos kriterijus.

• Paruošti koncepcinį projektą.

• Pasirinkti kūrimo strategiją.

• Nustatyti preliminarius įverčius.

• Dokumentuoti kūrimo strategiją.

Aprašymas. Pasirenkant produkto kūrimo strategiją, sprendžiamas itin svarbus klausimas –

kaip bus atliekama atskirų produkto dalių integracija į vieningą sistemą. Sekant TSP procesu,

visas darbas ir laikas, reikalingi produktui sukurti, suskaidomi į kelis ciklus. Kaip ir į kelis

ciklus bus padalintas visas produkto kūrimas - sprendžia visa komanda. Šis sprendimas tiesiogiai

veiks tolimesnę darbų seką: reikės nuspręsti, kokias funkcijas įgyvendinti ir prognozuoti kiek

laiko skirti kiekvienam iš ciklų, apytikriai nustatyti darbų kiekį bei numatyti metodus kaip

ištestuoti kiekvieną iš sistemos modulių. Komandai, atsižvelgiant į būsimo produkto struktūrą ir

jo ciklinį kūrimą, reikės nuspręsti ir kurią iš cikliniam produkto kūrimui pritaikytų strategijų jie

pasirinks.

Nustatyti strategijos kriterijus. Vykdant šią veiklą komanda aptaria ir suformuluoja

kriterijus, kuriuos turi tenkinti produkto kūrimo strategija. Atsižvelgiant į šiuos kriterijus

komanda peržiūrės ir vertins visus galimus produkto kūrimo strategijų variantus. Tinkamai

suformuluoti kriterijai padeda greitai ir svarbiausia objektyviai palyginti ir įvertinti alternatyvias

strategijas. TSP procesas akcentuoja vieną iš svarbiausių strategijos tikslų – užtikrinimą, jog

produktas 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 nei

planuota.

Paruošti koncepcinį projektą. Šio žingsnio metu komanda sukuria viso produkto

koncepcinį projektą bei nurodo funkcijas, kurias produktas turės realizuoti.

Pasirinkti kūrimo strategiją. Ši TSP veikla susideda iš tokių žingsnių:

• alternatyvių kūrimo strategijų peržiūros ir įvertinimo,

• produkto funkcijų paskirstymo kiekvienam kūrimo ciklui,

• numatymo, kaip produktas bus integruojamas.

TSP siūloma strategija įgalina produkto funkcionalumą didinti laipsniškai, t.y. kiekvieno

ciklo metu produktas papildomas naujomis funkcijomis. Kurią iš cikliniam kūrimui pritaikytų

strategijų pasirinkti, sprendžia komanda, atsižvelgdama į būsimo produkto struktūrą bei galimus

rizikos faktorius.

Nustatyti preliminarius įverčius. Vienas iš strategijos kūrimo uždavinių yra numatyti, kiek

gali užtrukti produkto kūrimas ir kokio dydžio produktas bus. TSP procese produkto dydis



matuojamas kodo eilučių skaičiumi, o laikas – valandų įverčiu, kuris gaunamas imant

prognozuojamą produkto dydžio įverčio sandaugą su programuotojo efektyvumo įverčiu (kiek

kodo eilučių programuotojas gali parašyti per valandą). Matuojant produkto dydį imama

kiekviena iš koncepciniame projekte aprašytų produkto funkcijų ir prognozuojamas jos dydis.

Įvertinus visų produkto funkcijų dydį ir sudėtingumą, paprasčiau planuoti, kurios funkcijos bus

kuriamos kiekvienos iš iteracijų metu. Taip apsidraudžiama, kad užteks laiko įgyvendinti visas

iteracijai numatytas funkcijas. Kadangi ir PSP, ir TSP modeliuose produkto dydis vertinamas jį

sudarančių eilučių skaičiumi, tai dydžiui prognozuoti efektyviausia naudotis PSP modelyje

pateikta PROBE metodika, nes TSP nepateikia konkrečių prognozavimo metodų.

Dokumentuoti kūrimo strategiją. Produkto kūrimo strategija dokumentuojama tam tikslui

skirtose formose.

Rizikų įvertinimas ir valdymas

Tikslas. Identifikuoti projekto rizikas ir 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 ir valdymas svarbus faktorius vykdant projektą. Naudinga

apibrėžti keletą įvykių, kuriuos būtų galima įtraukti į rizikingų grupę ir iš anksto apgalvoti

būdus, kaip jų išvengti ar bent sumažinti jų įtaką projekto baigčiai. Įvykius verta kategorizuoti

pagal jų įvykimo tikimybę ir jų padarinius. TSP procesas apibrėžia keletą dažniausiai

pasitaikanč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 ir nustatomas kiekvienos

rizikos laipsnis.

Planų, rizikų valdymui, paruošimas. Aukščiausią laipsnio rizikoms valdyti paruošiami

planai.

Pastovus identifikuotų rizikų stebėjimas. Komandos susirinkimų metu aptariamos

potencialios rizikos ir kaip jas valdyti.

Kokybės planavimas ir valdymas

Tikslas. Apibrėžti ir dokumentuoti kokybės kriterijus bei paruošti kokybės valdymo planą.



Veiklos:

• Apibrėžti kokybės kriterijus.

• Paruošti kokybės valdymo planą.

Aprašymas. Praktikos metu komanda įvardina kokybei keliamus tikslus ir kokiomis

metrikomis remiantis ji bus vertinama. Veiklos rezultatas yra kokybės valdymo planas,

pateikiantis informaciją apie:

• klaidų kiekius programų išeities tekstuose bei projekto dokumentuose ir šių kiekių

kitimą kiekvienos iš iteracijų metu;

• nurodo klaidų radimui, projekto dokumentų peržiūrai ir pačių komponentų kūrimui

sugaiš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. defect

density by phase).

Paruošti kokybės valdymo planą. Paruošiamas kokybės valdymo planas, kuriame

dokumentuojami apibrėžti kokybės kriterijai. Projekto metu kokybės valdymo plane pateikiami

klaidų kiekiai ir jų kitimas kiekvienos iš produkto kūrimo iteracijų metu.

Pastabos. Praktika turi būti diegiama kartu su automatiniais įrankiais, padedančiais

automatizuoti duomenų surinkimą bei projekto ataskaitų, reikalingų kokybės valdymo plano

paruošimui (defektų kiekio, peržiūrų efektyvumo, vidutinio defektų kiekio metrikos),

generavimą.

Produkto kūrimo plano ir tvarkaraščio ruošimas

Tikslas. Numatyti užduočių įgyvendinimui skiriamus terminus, užduočių įgyvendinimo

tvarką bei kiekvienam iš komandos narių užduotims įvykdyti planuojamą laiką.

Veiklos:

• Įvardinamos ciklo metu kuriamos sistemos dalys ir į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 ir

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ų



specifikavimas, eskizinio projekto paruošimas, vartotojo dokumentacijos paruošimas, testų planų

sukūrimas ir kitų ciklo metu atliekamų užduočių įvykdymas. Kuriamų sistemos dalių dydžiui

matuoti naudojama kodo eilučių skaičiavimo metodika bei vertinamas detaliojo projekto

dokumento eilučių skaičius. Tuo tarpu reikalavimų specifikacijos dydis vertinamas teksto

puslapių skaičiumi, eskizinio projekto dydis – eskizinio projekto puslapių skaičiumi. Kadangi

strategijos kūrimo fazėje sistemos dalių dydis jau buvo įvertintas, tai naudojamasi jau turimais

įverčiais.

Įvardinamos ciklo metu kuriamos sistemos dalys ir įvertinami bei dokumentuojami jų

dydžiai. Vykdant šį žingsnį įvardinamos ciklo metu kuriamos produkto dalys ir dokumentuojami

jų 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 atlikti

kiekvienai iš sąraše įvardintų užduočių. Kadangi kiekviena iš užduočių yra atliekama bent vienos

rolės atstovo, tai prie užduoties konkrečiai nurodomas jos vykdytojas (vykdytojai) ir

prognozuojamas užduoties įvykdymo laikas. Laiko prognozavimui gali būti naudojamas PROBE

metodas, kuris naudojamas PSP planavimo procese. PROBE metodas naudos PSP proceso metu

surinktus duomenis to komandos nario, kuriam priskirtas 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 dirbdamas projekte.

Jeigu užduočių plane randamos klaidos, laiko prognozavimo darbai gali būti atliekami

pakartotinai. Naudojantis užduočių planu, komanda paruošia tvarkaraščio projektą.

Subalansuojamas komandos narių apkrovimas. Šios TSP veiklos tikslas - identifikuoti

labiausiai apkrautus komandos narius ir perkelti kai kurias jų užduotis kitiems komandos

nariams, taip subalansuojant visų komandos narių apkrovimą.

Pastabos. Užduočių plano ir tvarkaraščio paruošimą labai palengvintų specialiai

planavimui paruoštų įrankių naudojimas. Idealiausia, jei planavimo įrankiui būtų prieinami

komandos narių surinkti asmeniniai rodikliai, kadangi tai užtikrintų ne tik kokybiškesnį, bet ir

operatyvesnį planavimo procesą.

Reikalavimų specifikacijos ruošimas

Tikslas. Paruošti vartotojo poreikius atitinkančią reikalavimų specifikaciją.

Veiklos:

• Poreikių išsiaiškinimas ir specifikavimas.

• Reikalavimų specifikavimas.



Aprašymas. Vykdydamas šią praktiką kiekvienas komandos narys specifikuoja

reikalavimus tos produkto dalies, kuri jam buvo paskirta ankstesnio žingsnio metu, t.y.

įvardinant reikalavimų specifikacijos ruošimo užduotis.

Poreikių išsiaiškinimas ir specifikavimas. Vykdant šį žingsnį, išsiaiškinami ir

dokumentuojami vartotojo poreikiai. Specifikavus vartotojo poreikius, atliekama jų peržiūra.

Peržiūra yra skirta tam, kad komandos nariai identifikuotų specifikavimo metu padarytas klaidas

(neatsižvelgta į tam tikrus poreikius, neteisingai suprasti poreikiai ir pan.), o peržiūros pabaigoje

turėtų vienodą supratimą apie poreikius būsimam produktui. Šios peržiūros metu komanda

koncentruojasi ties tomis funkcijomis, kurios bus kuriamos sekančio ciklo metu. Nors iki

projektavimo fazės pabaigos visos šios funkcijos ir nėra tiksliai žinomos, tačiau preliminarią

kuriamų funkcijų aibę komanda gali įvardinti.

Reikalavimų specifikavimas. Vykdydamas šią veiklą, kiekvienas komandos narys

specifikuoja reikalavimus tos produkto dalies, kuri jam buvo paskirta ankstesnio žingsnio metu,

t.y. įvardinant reikalavimų specifikacijos ruošimo užduotis. TSP pateikia nurodymų ir

rekomendacijų, kaip specifikuoti reikalavimus, kad projektuojant jie būtų vienodai suprasti visų

projektuotojų. Klaidingai specifikuotiems reikalavimams ištaisyti reikės laiko, todėl komanda

negalės laiku įvykdyti visų užduočių, o tai tiesiogiai veiks planavimo ir paties produkto kokybę

Projektavimas

Tikslas. Paruošti projektą, kuriame būtų nurodyta, kaip bus kuriamas produktas, kokia

tvarka projektuojamos įvairios produkto dalys, kas projektuos kiekvieną iš dalių ir kaip visos

dalys dirbs kartu.

Veiklos:

• Bendros kuriamo produkto struktūros numatymas ir aptarimas.

• Produkto funkcijų paskirstymas 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 ir aiškiai nurodomos produktą sudarysiančios

dalys, apibrėžiama, kaip jos sąveikauja tarpusavyje bei nurodomi būdai, kaip ir kokia tvarka jas

apjungti į vientisą produktą.

Bendros kuriamo produkto struktūros numatymas ir aptarimas. Šios veiklos metu

komanda tiksliai apibrėžia komponentus, kurie bus sukurti kiekvieno iš ciklų metu bei

nusprendžia, kokie tarpusavio ryšiai juos sies.

Produkto funkcijų paskirstymas jį sudarantiems komponentams. Šios veiklos vykdymo

metu yra priskiriamos ciklo metu kuriamo produkto funkcijos jį sudarantiems komponentams.

Taip pat numatoma, kurių ciklų metu komponentai bus papildomi naujomis funkcijomis.



Kiekvieno iš komponentų aprašų sudarymas. Paruošiami visų komponentų interfeisų

aprašai.

Projektavimo užduočių, kurias reikia atlikti norint paruošti projektą, įvardinimas. Šio

veiklos metu paruošiama projekto dokumento struktūra ir įvardinamos projektavimo užduotys,

kurias reikia atlikti, norint paruošti dokumentą. Suformuluotos užduotys padalinamos komandos

nariams, nurodant kiekvienos iš jų įvykdymo terminus. Užduotys padalinamos atsižvelgiant į

komandos narių žinias, įgūdžius bei projektavimo praktiką.

TSP principų ir praktikų sąryšiai

Žemiau pateikiama TSP procesų principų ir praktikų sąryšių lentelė, t.y. kokius TSP

principus kokios praktikos įgyvendina.


praktikos

Praktikos veiklos

Apibrėžti pateikiamos informacijos

rūšis, kas jas turi pateikti bei kam jos

pateikiamos.

Programų sistemų kūrėjai

dirbs efektyviai, jei naudos

apibrėžtą ir matuojamą

procesą.

Projekto progreso

sekimas (PSP

praktikos laiko,

defektų, dydžio

matavimui)

Apibrėžti informacijos pateikimo formą

Komandai keliamų tikslų

suformulavimas ir dokumentavimas

Komandos nariams keliamų tikslų

suformulavimas ir dokumentavimas

Komanda bus motyvuota, jei

dirbs turėdama bendrą viziją

ir žinodama jai keliamus

tikslus.

Komandos tikslų

suformulavimas ir

dokumentavimas

Kriterijų, kuriais remiantis bus

vertinamas produkto ir komandos

atitikimas iškeltiems tikslams,

apibrėžimas

Procesas geriausiai atitiks

komandos poreikius, jei bus

jai pritaikytas.

Pritaikytos visos TSP ir PSP praktikos

Apibrėžti kiekvienos rolės atsakomybes

ir įsipareigojimus.

Komandos nariai žinos už ką

jie atsakingi ir kam turi

atsiskaityti, jei komandoje

bus įtvirtintos aiškios

atsakomybės ir atskaitomybė

Rolių ir jų

atsakomybių

apibrėžimas bei

priskyrimas Roles paskirstyti komandos nariams

Programų sistemų kūrėjai Komunikavimo Nurodyti pateikiamos informacijos rūšis




praktikos

Praktikos veiklos

ir atsakingus asmenis aktyviai keisis informacija ir

žiniomis, jei komandoje bus

skatinamas nuolatinis

bendravimas.

procedūrų

apibrėžimas Paruošti komandos susirinkimų grafiką

Produkto kūrimo

strategijos ruošimas

Produkto kūrimo

plano ir tvarkaraščio

ruošimas

Reikalavimų

specifikacijos

ruošimas

Suteikti galimybę programų

sistemų kūrėjams dirbti taip,

kaip jie įpratę, tačiau

prisilaikant nustatyto

komandos proceso ir

atsižvelgiant į jų pačių

surinktus duomenis ir kolegų

patirtį.

Projektavimas

Visos nurodytus etapus atitinkančios

gyvavimo ciklo veiklos

Išanalizuoti proceso duomenis.

Įvertinti rolių įgyvendinimą.

Norint pastoviai gerinti savo

veiklą, reikia nuolat tobulinti

procesą, atsižvelgiant į

proceso metu sukauptus

istorinius duomenis ir

rodiklius.

Komandos proceso

evoliucionavimo/

pritaikymo plano

paruošimas ir jo

įgyvendinimas

Paruošti projekto (ciklo) ataskaitą ir

tobulinimo pasiūlymus

Rizikų identifikavimas.

Detali kiekvienos įvardintos rizikos

analizė.

Planų, rizikų valdymui, paruošimas.

Rizikų įvertinimas ir

valdymas

Pastovus identifikuotų rizikų stebėjimas

Apibrėžti kokybės kriterijus.

Skatinti būsimų produktų

kokybės užtikrinimą ir

galimų rizikų įvertinimą bei

valdymą.

Kokybės

planavimas ir

valdymas

Paruošti kokybės valdymo planą

TSP taikymų praktikoje rezultatų analizė

Nors komandinis programų sistemų kūrimo procesas (TSP) buvo pristatytas dar 1999

metais, tačiau paskelbta itin mažai darbų, aprašančių šio proceso taikymą praktikoje. Vienas iš



tokių darbų pavyzdžių yra Carnegie Mellon universiteto darbuotojų paskelbtas darbas, aprašantis

4 organizacijų (nuo CMM 1 iki CMM 5 lygio) TSP proceso taikymo rezultatus. Šis darbas yra

statistinės analizės ataskaita, kurioje naudojant statistinius metodus bandoma įrodyti TSP

proceso taikymo naudą. Darbo autorių teigimu, taikydamos TSP procesą, komandos gali

tinkamai paruošti projekto planus ir laiku įgyvendinti paskirtas 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į produkto

kūrimo ciklą, o tai leidžia klientui produktą pateikti per maksimaliai trumpus terminus.

Statistinei analizei naudotas pasikartojančių matavimų skirtumų analizės metodas

(ANOVA). Šis metodas naudingas tada, kai reikia pamatuoti progresą atliekant eilę bandymų.

Ankstesni bandymai laikomi pagrindu ir analizuojami tik skirtumai tarp bandymų metu surinktų

duomenų. Šis metodas buvo naudojamas visų svarbiausių rodiklių statistinei analizei.

Surinktų duomenų pirminė analizė. Kadangi tyrime dalyvaujančių 4 organizacijų pateikti

duomenys yra nepilni, tai negalima atlikti išsamios analizės, tačiau tai įgalina nustatyti tam tikras

tendencijas. Atliekant duomenų analizę buvo laikomasi tokių prielaidų: pateikti duomenų

rinkiniai nėra homogeniški; duomenys nėra pasiskirstę pagal normalinį skirstinį; duomenų aibės

yra pakankamai mažos.

Pastangų ir laiko vertinimo tikslumas. Projekto kaštų apskaičiavimo ir planų sudarymo

problemos iškyla tada, kai programų sistemų kūrėjai įsipareigoja įgyvendinti projektą,

remdamiesi klaidingais produkto dydžio bei reikalingų laiko sąnaudų vertinimais. Šiems

vertinimams atlikti TSP naudoja PSP procese aprašytus vertinimo metodus. Vertinant metu

naudojami istoriniai duomenys, surinkti PSP proceso metu. Organizacijų pateiktų duomenų

statistinė analizė parodė, jog komandos sugebėjo gana tiksliai suplanuoti produkto kūrimą bei su

minimalia paklaida pateikė produkto kūrimo kaštus. Prieš įdiegiant TSP procesą laiko planavimo

prognozavimo 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ž jo

kuriamo komponento ar komponento dalies kokybę. Norint išvengti klaidų galutiniame produkte,

kiekvienas komandos narys atlieka savo kuriamo komponento peržiūrą. Sėkmingai įvykdžius

komponento peržiūrą, kodas yra sukompiliuojamas ir kartu su jo dokumentacija patikrinamas

kitų komandos narių, naudojant apibrėžtus metodus. Tai užtikrina, jog sukurti produktai turės

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



Naudodamos 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. Nors

produkto kūrimo (kodavimo) laiko sąnaudos gali būti tos pačios kaip ir nenaudojant TSP

proceso, tačiau sutrumpėjusi sistemos testavimo fazė leidžia sutaupyti gana daug laiko. Nors

tyrime dalyvaujančios organizacijos nepateikė duomenų apie komandų produktyvumo

padidėjimą ar sumažėjimą, tačiau iš pateiktų duomenų matosi, jog sutrumpėjo produkto

testavimo fazės.

Išvados. Šį tyrimą galima priskirti tokių tyrimų kategorijai, kurių rezultatai gali nevisiškai

atitikti 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 ir kaip jos buvo

standartizuotos kiekvienoje iš organizacijų. Autoriai atmeta prielaidą, jog duomenų aibėse

galimos tam tikros paklaidos. Taip pat tyrimo autoriai nepateikia jokių duomenų apie tyrime

dalyvavusius inžinierius: jų išsilavinimą, darbo patirtį ir t.t.

PSP ir TSP taikymų patirties analizės išvados Nors asmeninis programų kūrimo procesas (PSP) ir komandos programų kūrimo procesas

(TSP) literatūroje pristatyti jau pakankamai seniai, tačiau vis dar trūksta medžiagos, aprašančios

jų pritaikymą pramonėje. Didžioji dalis esamos literatūros aprašo procesų taikymo pavyzdžius

izoliuotoje 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 pasirinkti procesų adaptacijos ir 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 tiriami ir diegiami ne izoliuotoje

aplinkoje, o realiose pramonės įmonėse, galima suformuluoti tokias išvadas:

• Įdiegus procesus, nepastebėta jokių esminių produktyvumo pokyčių, tačiau sumažėjo

laiko skiriamo produkto kompiliavimui ir testavimui sąnaudos.

• Procesų taikymas padidina laiko sąnaudas, tačiau ilgainiui jos turėtų sumažėti,

kadangi proceso veiklų taikymas turi tapti įpročiu.

• Ž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ę toliau

optimizuoti procesus bei juos pritaikyti kitose srityse.

• Būtina naudoti įrankius, leidžiančius automatizuoti procesų metu surenkamų duomenų

agregavimą ir analizę. Šie įrankiai turi būti pilnai integruoti, t.y. komandos narys pateikia tik



pradinius 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ėkmingai

naudoti įdiegtus procesus ir 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čiau

užtikrinti surenkamų duomenų kokybę beveik neįmanoma. Tai priklauso nuo kiekvieno procesą

vykdančio asmens noro ir motyvacijos pateikti pilnus ir korektiškus duomenis.

• Aiškiai apibrėžti, kokiu tikslu renkami duomenys, kad būtų išvengta tyčinio duomenų

klastojimo.


[Hum98] Watts S. Humphrey. Three Dimensions of Process Improvement Part III: The

Team 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 and

Preliminary Results of Using Disciplined Practices, Technical Report, CMU/SEI-

2000-TR-015, ESC-TR-2000-015, 2000.

Programų sistemų inžinerija 9. Testavimo brandos modelis


9. Testavimo brandos modelis

Testavimo brandos modelis TMM buvo sukurtas 1996 m. Ilene Burnstein vadovaujamos

grupės Ilinojaus technologijos institute.

9.1 pav. Ilene Burnstein (http://www.cs.iit.edu/faculty/burnstein.html)

Pagrindinis TMM tikslas yra testavimo proceso vertinimas ir gerinimas. Jis parodo

pakopinį testavimo proceso gerinimo kelią, todėl, autorių nuomone, jis gali būti naudojamas ir

mokymui, kad palaipsniui supažindinti su testavimo sąvokomis, principais ir geriausiomis

praktikomis.

TMM orientuojasi į procesą, konkrečiai į testavimo procesą. Testavimas suprantamas

plačiąja prasme, kaip visos veiklos, susijusios su programų kokybe.

Apibrėžimas. Testavimas: (1) Grupė procedūrų, atliekamų programinės įrangos5 dalies

kokybės įvertinimui. (2) Procesas, naudojamas radimui programinės įrangos defektų ir

nustatymui, kad programinė įranga atitinka apibrėžtą kokybės lygį pagal pasirinktus atributus.

TMM modelį gali naudoti (kas ir 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 ir 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 kaip

CMM, CMMI, SPICE, ISO/IEC 15504, Bootstrap, nepakankamai dėmesio skiria testavimui.

TMM pagrindiniai komponentai:

1. Testavimo brandos lygiai.

2. Brandos tikslai ir 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ų ir, galbūt, susijusios dokumentacijos bei duomenų.“



a. Su brandos tikslais susijusių klausimų, skirtų testavimo proceso einamajai būsenai

nustatyti.

b. Nurodymų vertinimo komandos parinkimui ir parengimui.

c. Vertinimo procedūros, apibrėžiančios testavimo proceso vertinimo ir gerinimo

žingsnius.

Reikalavimai, kuriuos turėjo patenkinti TMM:

- Modelis turi būti priimtinas programinę įrangą kuriančioms įmonėms ir remtis

pripažintais programų sistemų inžinerijos principais ir praktikomis. Aukštesni brandos lygiai turi

būti pakankamai lankstūs, kad galėtų būti taikomos naujai atsiradusios geriausios praktikos.

- Modelis turi leisti testavimo proceso brandos vystymą fazėmis, atitinkančiomis natūralią

proceso evoliuciją.

- Turi būti pateikiamas testavimo proceso vertinimo ir gerinimo būdas.

TMM buvo kuriamas, remiantis tokiais šaltiniais: SW-CMM, evoliuciniu testavimo

modeliu [GH88], esama testavimo praktika [Dur93] ir testuotojo mentalinio modelio vystymosi

fazėmis [Bei90].

Lygis 5Lygis 4

Lygis 3Lygis 2

Lygis 1

Testavimo brandos modelis

Evoliucinistestavimomodelis

Esamatestavimopraktika

Gebėjimobrandosmodelis

Testuotojomentalinio

modeliovystymosi fazės

9.2 pav. PagrindiniaiTMM šaltiniai



TMM savo struktūra ir principais panašus į CMM. TMM gali būti naudojamas kartu su

CMM, 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žioje

testavimas buvo neatskiriamas nuo derinimo (angl. debugging), jis buvo atliekamas kartu su

derinimu, kai prireikdavo rasti ir pašalinti defektus. Nuo to laiko testavimas praėjo keletą fazių,

kol tapo prevencine veikla, atitinkančia 5-ą CMM ir TMM lygį.

Lygis 1. Pradinis

Lygis 2. Fazės apibrėžimo

Bazinių testavimo būdų ir metodų institucionalizavimasTestavimo proceso incijavimasTestavimo ir derinimo tikslų apibrėžimas

Lygis 3. Integravimo

Testavimo proceso stebėjimas ir valdymasTestavimo integrvaimas į gyvavimo cikląTechninių apmokymų programos įdiegimasTestavimo organizacijos įkūrimas

Lygis 4. Valdymo ir matavimo

Kokybės įvertinimasMatavimų programos įdiegimasPeržiūrų programos įdiegimas visoje organizacijoje

Lygis 5. 5. Optimizavimo, defektų prevencijos irkokybės kontrolės

Testavimo proceso optimizavimasKokybės kontrolėProceso duomenų taikymas defektų prevencijai

9.3 pav. 5 lygių TMM struktūra



Esamos testavimo praktikos tyrimas [Dur93] parodė tiek geriausias, tiek blogiausias

testavimo aplinkas, kurių pagrindu buvo pasiūlyti atitinkantys realybę testavimo proceso

vertinimo ir gerinimo rodikliai.

Atskiro testuotojo mentalinio modelio vystymosi [Bei90] idėjos buvo panaudotos TMM:

brandi testavimo organizacija remiasi įgūdžiais, galimybėmis ir nuostatomis (požiūriu) joje

dirbančių individų

TMM struktūra

TMM yra pakopinės architektūros proceso modelis. Jame yra apibrėžti 5 testavimo proceso

brandos lygiai (angl. Maturity Levels):

1. Pradinis (angl. Initial)

2. Fazės apibrėžimo (angl. Phase Definition)

3. Integravimo (angl. Integration)

4. Valdymo ir matavimo (angl. Management and Measurement)

5. Optimizavimo, defektų prevencijos ir kokybės kontrolės (angl. Optimization, Defect

Prevention and Quality Control)

Kiekvienam brandos lygiui, išskyrus 1-ą lygį, apibrėžiami brandos tikslai (angl. Maturity

Goals).

Detalesnė (vidinė) modelio struktūra pateikta 9.4 pav. Kiekvienas brandos lygis parodo

atitinkamą 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į ir

rezultatus. Tikslų yra siekiama atliekant veiklas, užduotis ir apibrėžiant atsakomybes (angl.

Activities/Tasks/Responsibilities). Veiklos ir užduotys apibrėžia, kas turi būti daroma testavimo

proceso pagerinimui atitinkamame lygyje; jos turi būti pritaikomos organizacijai ir

įgyvendinamos (angl. Implementation and organizational adaptation). Veikloms yra

priskiriamos atsakomybės ir užduotys yra grupuojamos į 3 grupes, atitinkančias esminius

testavimo proceso dalyvius – vadovus, kūrėjus/testuotojus ir naudotojus/užsakovus. Modelyje jos

vadinamos kritiniais požiūriais (angl. Critical views).

Vadovų (angl. Manager) požiūris apima įsipareigojimą ir gebėjimą atlikti veiklas ir

užduotis, susijusias sutestavimo proceso gerinimu. Vadovų TMM kontekste pavyzdžiai: projekto

vadovas, testavimo grupės vadovas, kokybės užtikrinimo vadovas, o taip pat ir aukštesnio lygio

vadovai – skyriaus ar padalinio vadovas.



Kūrėjų/testuotojų (angl. Developer/tester) požiūris apima technines veiklas ir užduotis,

įgyvendinančias testavimą. Kūrėjai ir testuotojai tai žmonės specifikuojantys, projektuojantys,

koduojantys ir testuojantys programinę įrangą.

Naudotojų/užsakovų (angl. User/client) požiūris apibrėžtas kaip bendradarbiaujantis ar

palaikantis. Jis orientuojasi į pastangas gauti naudotojų/užsakovų palaikymą, konsensuso

pasiekimą ir įtraukimą į reikalavimų analizę, naudojamumo testavimą, sistemos veikimo

aplinkos apibrėžimą ir priėmimo testų (angl. acceptance testing) planavimą.

Lygis

Testavimogebėjimas

nurodo apibrėžia

Brandos tikslai

Brandospotiksliai

palaiko

Veiklos, užduotys, atsakomybės

pasiekiami per

Diegimas irpritaikymas

organizacijoje

skirti sugrupuoti pagal

Kritiniaipožiūriai

VadovųKūrėjų/

testuotojųNaudotojų/užsakovų

9.4 pav. Vidinė TMM brandos lygio struktūra

TMM vertinimo modelis

Vertinimo modelis turi pateikti žingsnius, veiklas, užduotis ir formas proceso vertinimui

pagal formalų proceso modelį. Jis taip pat turėtų padėti, atlikus vertinimą, gerinti procesą.

TMM vertinimo modelis tenkina šiuos reikalavimus: naudoja TMM proceso modelį ir

vertina, kaip (kiek) organizacija pasiekia TMM brandos tikslus.

Vertinimo modelį sudaro 3 pagrindinės komponentės:

1) vertinimo komandos parinkimas ir apmokymas;

2) vertinimo procedūra;



3) vertinimo instrumentas (klausimynas).

Vertinimo modelio schema pateikta 9.5 pav.

TMM vertinimoprocesas

Testavimo brandosmodelis

TMM vertinimoprocedūra

TMM vertinimoklausimynas

TMM apmokymai irkomandos

parinkimo kriterijai

TMM lygis

Testavimo proceso profilis

Stipriosios/silpnosios pusės

Veiksmų planai

Vertinimo įrašai

Interviu duomenys

Klausimynų duomenys

Vertinimo planas

Susiję dokumentai

RezultataiPradiniaiduomenys

9.5 pav. TMM vertinimo modelio struktūra

Vertinimo komandos parinkimas ir apmokymas Komandos nariai turi būti kvalifikuoti ir motyvuoti: kandidatai į vertinimo komandą turi

išmanyti TMM vertinimą, būti gerbiami organizacijoje, suinteresuoti pagerinti testavimo

procesą, turėti galimybę įgyvendinti pakeitimus ir turėti kūrimo/testavimo/vadovavimo patirties

(rekomenduojama vidutinė 7 metų patirtis). Komandai būtinas lyderis, kuriam būtinos aukšto

lygio kūrimo ir vadovavimo žinios bei patirtis. Siūloma vertinimo komandą sudaryti iš 4-8 narių.

Komandos pasirengimui 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ūra TMM vertinimo procedūra apibrėžia tokius žingsnius (reikia pastebėti, kad iš esmės tai yra

proceso gerinimo procedūra):

- Pasirengimas

- TMM vertinimo atlikimas

- Vertinimo rezultatų ataskaita

- Vertinimo rezultatų analizė



- Gerinimo veiksmų planavimas

- Gerinimo įgyvendinimas.

Vertinimo klausimynas Vertinimo klausimynas yra tokios struktūros lentelė (toliau vardinami jos stulpeliai):

- Klausimas. Pavyzdžiui, Ar testavimo ir derinimo komitetas buvo įkurtas?

- Taip - atsakoma tuo atveju, kai praktika yra įgyvendinta ir tinkamai atliekama.

- Ne - atsakoma tuo atveju, kai praktika nėra įgyvendinta arba netinkamai atliekama.

- Netaikoma - atsakoma tuo atveju, kai turima pakankamai žinių apie projektą ar

organizaciją ir manoma, kad šis klausimas neturi būti projektui ar organizacijai.

- Nežinoma - atsakoma tuo atveju, kai nežinoma, kaip atsakyti, arba neturima

pakankamai informacijos ar patirties.

- Pastabos.

Kiekvienas respondentas prieš atsakinėdamas turi pateikti:

1) informaciją apie save (vardas, pareigos, projektas, kontaktinė informacija), savo

pareigų kategoriją, už ką jis atsakingas, ar buvo apmokytas TMM, patirtį organizacijoje

ir iš viso, ar anksčiau dalyvavo vertinimuose;

2) informaciją apie organizaciją: kokio tipo programinę įrangą kuria, vidiniam ar išoriniam

naudojimui, kiek žmonių dirba organizacijoje, kiek dalyvauja testavime, ar proceso

gerinime dalyvaujantys žmonės yra gerbiami organizacijoje, ar testavimo proceso

gerinimo atsakomybės aiškiai apibrėžtos, kaip organizuota testavimo grupė, kaip galima

apibūdinti testavimo procesą (nuo chaotiško iki labai struktūrizuoto), kaip dažnai

keičiasi užsakovų reikalavimai.

Klausimyne kiekvienam brandos lygiui pateikiami:

- jo tikslai, pvz.:

TMM 2 lygis: Fazės apibrėžimas

Brandos tikslas 2.1: Apibrėžti testavimo ir derinimo tikslus ir politiką

Šis tikslas turi aiškiai atskirti testavimo ir derinimo procesus. Kiekvienam iš jų turi būti

identifikuoti tikslai, veiklos, užduotys ir įrankiai bei priskirtos atsakomybės. Vadovybė

turi nustatyti politiką abiejų procesų pritaikymui ir įdiegimui.

- potiksliai, pvz.:

2.1.1. Organizacijos lygmens testavimo ir derinimo komitetas ar grupė yra suformuota

ir aprūpinta finansavimu bei palaikymu. Tikslai, politikos ir procedūros patvirtintos ir

periodiškai peržiūrimos.

2.1.2. Testavimo ir derinimo politikos/tikslai atspindimi projekto/testavimo planuose.

2.1.3. Apibrėžta bazinė defektų klasifikacija ir įdiegta defektų saugykla.



2.1.4. Esminiai testavimo ir derinimo matavimai apibrėžti ir renkami.

- klausimai (į kuriuos reikia atsakyti Taip/Ne/Netaikoma/Nežinoma ir galima pateikti

komentarus), pvz.:

1. Ar testavimo ir derinimo komitetas buvo įkurtas?

2. Ar testavimo proceso politika, tikslai, veiklos ir įrankiai identifikuoti,

dokumentuoti ir patvirtinti?

3. Ar derinimo proceso politika, tikslai, veiklos ir įrankiai identifikuoti, dokumentuoti

ir patvirtinti?

4. Ar testavimo procesas apibrėžtas?

5. Ar derinimo procesas apibrėžtas?

6. Ar testavimo politikos dokumentai paskleisti projekto vadovams ir kūrėjams

(testuotojams)?

7. Ar derinimo politikos dokumentai paskleisti projekto vadovams ir kūrėjams

(testuotojams)?

8. Ar planuodami testavimą kūrėjai (testuotojai) vadovaujasi rašytine organizacijos

politika?

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ą ir tikslus buvo atsižvelgta į klientų/vartotojų grupės

atsiliepimus ir poreikius?

13. Ar kuriant derinimo politiką ir tikslus buvo atsižvelgta į klientų/vartotojų grupės

atsiliepimus ir 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 ir tikslai reguliariai peržiūrimi?

Išvados

TMM yra pavyzdys modelio, paruošto praktiniam taikymui, t.y. tokie modeliai kaip

CMMI, ISO 15504 yra per daug bendri ir „nutolę“ nuo praktikos, kad juos taikyti reikia juos

„nuleisti“ iki praktinio taikymo (pvz., norint atlikti vertinimą) ir iki konkrečios organizacijos

(pvz., susieti organizacijoje naudojamus terminus su modelio terminais), todėl kad organizacija

pradėtų taikyti modelį ji turi samdytis konsultantus arba/ir pati nueiti ilgą mokymosi kelią.

TMM atveju modelis yra maksimaliai sukonkretizuotas, kad būtų galima bandyti jį taikyti

organizacijoje - pateikiama visa būtina taikymui medžiaga (visa medžiaga yra knygoje [Bur03],



kurią galima rasti internete ir atsisiųsti, o šiame dokumente yra pateikiama tik apžvalga, kurios

žinoma, nepakanka praktiniam taikymui).


[Bur03] I. Burnstein, Practical software testing: a process-oriented approach. Springer-

Verlag, 2003, ISBN 0-387-95131-8.

[GH88] D. Helperin, B. Hetzel, The growth of software testing. Communications of ACM,

Vol. 31, No. 6, 1988, pp. 687-695.

[Dur93] J. Durant, Software testing practices survey report. Technical Report, TR5-93,

Software Practices Research Center, 1993.

[Bei90] B. Beizer, Software Testing Techniques, 2nd edition, Van Nostrand Reinhold, New

York, 1990.

Programų sistemų inžinerija 10. Judriosios programų kūrimo metodikos


10. Judriosios programų kūrimo metodikos

Judriosios (angl. agile) programų kūrimo metodikos – jauniausia programų sistemų

inžinerijos atšaka. Atsiradusios 90-ųjų metų pabaigoje, jos greitai išpopuliarėjo ir sprendžiant

pagal skelbiamą statistiką šiandien yra plačiai naudojamos programinės įrangos kūrimo srityje.

Visame pasaulyje diskutuojamos judriųjų metodikų paplitimo priežastys ir jų taikymo galimybės.

Nesėkmingi projektai yra didelė problema ne tik juos vykdančių organizacijų, bet ir

pasaulinės ekonomikos mastu. JAV Nacionalinio standartų ir technologijos instituto duomenimis

nekokybiškos programinės įrangos produktai vien JAV nacionalinei ekonomikai padaro 59,5

milijardo dolerių per metus žalos.

Standish Group atliktuose tyrimuose kaip pagrindiniai nesėkmės veiksniai buvo įvardinti:

naudotojo neįtraukimas į kūrimo procesą; nepilni ir /arba besikeičiantys reikalavimai; nerealūs

planai ir terminai; netinkamas vadovavimas; neaiškūs tikslai; nepakankamos naudojamų

technologijų žinios.

Tradicinės metodikos nuolat apibūdinamos kaip lėtos, pernelyg formalios ir nelanksčios,

todėl sunkiai išsprendžiančios išvardintas problemas. Tai paskatino naujų programų kūrimo

metodų paiešką ir ko pasėkoje imta siūlyti naujas metodikas (XP, DSDM, Scrum), skirtas

daugiausiai mažoms komandoms nedideliems projektams su besikeičiančiais reikalavimais

vykdyti. 90-ųjų pabaigoje jos pradėtos vadinti lengvosiomis (angl. lightweight) arba judriosiomis

(angl. agile) programų kūrimo metodikomis.

Judriųjų programų kūrimo metodikų manifestas

2001 metais grupė programinės įrangos praktikų ir konsultantų paskelbė judriųjų programų

sistemų kūrimo metodikų manifestą (angl. Agile Software Development Manifesto), kuriame

formuluojami tokie principai:

• Individai ir jų bendradarbiavimas yra svarbesni už procesus ir įrankius. Judriosios

metodikos teigia, kad programų kūrimo procese ypač svarbūs individualūs žmonių

sugebėjimai ir dalyvaujančių žmonių sugebėjimas dirbti komandoje.

• Veikianti programinė įranga yra svarbesnė už išsamią jos dokumentaciją. Judriosios

metodikos teigia, kad kur kas svarbiau sukurti veikiančią ir atitinkančią kliento

poreikius programų sistemą, negu parengti dokumentaciją, nes priešingu atveju sistema

nebus diegiama. Šiuo teiginiu yra akcentuojama ir testavimo svarba.

• Bendradarbiavimas su užsakovu svarbesnis už kontrakto derybas. Pabrėžiama

užsakovo galimybė įtakoti projekto eigą. Skatinami dažni produkto pristatymai



už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 artimiau

susipažinus su sistema, o inžinieriams su verslo modeliu, kyla nauji reikalavimai.

Projekto dalyviai turi būti pasiruošę daryti pakeitimus ir sutartyje turi būti numatytos

priemonė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 ir nepakankamai efektyvios

dabartiniams projektams, pasižymintiems didele reikalavimų, resursų, terminų kaita, vykdyti.

Sanjay Murthi pateikia tokį palyginimą, kuriame nurodoma kokiems veiksniams esant

patartina naudoti judriąsias programų kūrimo metodikas:

Veiksnys Tradicinės metodikos Judriosios metodikos

Apimtis (reikalavimai) Tiksliai žinoma;

Dydis gerai suvokiamas;

Nesikeičianti.

Neaiški (ar reikalavimai

teisingi?);

Nežinoma (Kas yra apimtis?)

Besikeičianti.

Resursai (pinigai,

infrastruktūra, žmonės)

Patvirtinti ir prieinami;

Nustatyti iš anksto;

Biudžetas pakankamas ir

finansuojamas;

Žmonės susipažinę su

užduotimis ir įrankiais

Nepilnai patvirtinti arba

prieinami;

Patikrinimo poreikis;

Pinigų nepakanka;

Biudžetas neapibrėžtas;

Naujų įgūdžių poreikis.

Laikas Aiškiai nustatytas;

Aiškūs etapai.

Netiksliai nustatytas, atviras;

Neaiškūs etapai;

Linkęs keistis.

Rizikos Gerai suprantamos;

Nedidelė įtaka.

Naujos technologijos;

Nežinomos rizikos;

Didelė įtaka.

Nepaisant to, kad judriosios programų kūrimo metodikos buvo kuriamos daugiausiai

mažoms komandoms nedideliems projektams vykdyti, pastaraisiais metais bandoma taikyti ir

nuolat pranešama apie įvairius sėkmingus taikymus skirtinguose tiek dydžiu, tiek apimtimi, tiek

taikymo sritimi projektuose.



Populiariausia judrioji metodika yra ekstremalaus programavimo (XP), kuri pagal 2001

metais surinktus statistinius duomenis buvo naudojama 38% judriąsias metodikas taikiusiuose

projektuose, be to, ji ir toliau tobulinama.

Pagal to paties tyrimo rezultatus DSDM metodiką taikė 19% apklaustų respondentų. Ji

įdomi ir tuo, kad yra pakankamai formali ir tarp judriųjų metodikų yra viena iš labiausiai artimų

tradiciniams metodams.

Ekstremalus programavimas

Ekstremalus programavimas (angl. eXtreme Programming, XP) – metodika, kurios

pagrindinės idėjos pradėjo formuotis 1990-ųjų viduryje ir kurios autoriais laikomi Kent Beck,

Ron Jeffrees ir Ward Cunninghan.

XP metodika skirta daugiausia mažoms ir vidutinėms komandoms, kurios vykdo projektą,

pasižymintį reikalavimų neapibrėžtumu arba kitimu.

XP procesas XP metodika yra gana plačiai aprašyta, tačiau vis dėlto nepakankamai formali, todėl nėra

formaliai aprašytas ir XP kūrimo procesas.

PasakojimaiPasakojimai

Tyrimas Planavimas Iteracijos iki versijos išleidimo Gamyba Priežiūra "Mirtis"

Pasakojimai

PasakojimaiPasakojimaiPasakojimai

kitai iteracijai

Reguliarūsatnaujinimai

Prioritetai

Apimtiesvertinimas

Programavimas poromis

Ana

lizė

Pro

jekt

avim

as

Tes

tavi

mas

Tes

tųpl

anav

imas

Pastoviosperžiūros

Grįžtamasisryšys

TestaiBendra

kodo bazė

Pastovusintegravimas

Mažoslaidos

Užsakovopatvirtinimas

Papildytosversijos

Galutinėversija

10.1 pav. XP proceso struktūra

XP 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);



- mirtis (angl. Death).

Tyrimo fazės metu užsakovas rašo vadinamuosius pasakojimus (angl. story), kuriuose

nurodomi reikalavimai, kuriuos reikia įgyvendinti pirmai sistemos versijai. Kiekvienas

pasakojimas atitinka vieną savybę, kuri turi būti realizuota programų sistemoje. Taip pat šiame

etape projekto komanda susipažįsta su įrankiais, technologijomis, metodais, kurie bus naudojami

projekto įgyvendinimui.

Po tyrimo fazės vykdoma planavimo fazė, kurios metu kūrimo komanda turi nuspręsti, kas

bus įtraukiama į pirmąją naujos iteracijos sistemos versiją. Programuotojai nustato kiek laiko

reikės įgyvendinti kiekvienam pasakojimui, užsakovas pasakojimams priskiria prioritetus ir

kūrimo komanda sudaro projekto tvarkaraštį.

Iteracijų iki versijos išleidimo fazę sudaro keletas iteracijų, kol yra išleidžiama pirmoji

sistemos versija. Planavimo fazėje sudarytas tvarkaraštis suskaidomas į iteracijas, kurios trunka

nuo vienos iki keturių savaičių. Jau pirmojoje iteracijoje sukuriama sistema, kurios architektūra

atitinka pilnos sistemos architektūrą. Kurie pasakojimai kokioje iteracijoje įgyvendinami,

nusprendžia užsakovas. Kiekvienos iteracijos pabaigoje atliekami užsakovo parengti funkciniai

testai. Paskutinės iteracijos pabaigoje sukurta sistema jau yra parengta naudojimui.

Sėkmingai atlikus testus pereinama į gamybos fazę, kurioje atliekamas papildomas

testavimas ir prieš sistemą pristatant užsakovui tikrinamas sistemos efektyvumas. Šioje fazėje

sistema gali būti dar keičiama ir 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 pirmosios sistemos versijos XP projekto

komanda privalo prižiūrėti veikiančią sistemą ir tęsti programų sistemos kūrimą, vykdant kitas

iteracijas. Priežiūros fazė gali pareikalauti įtraukti į projekto komandą naujų žmonių ir pakeisti

komandos struktūrą.

Po to, kai užsakovas nebepateikia jokių pasakojimų, kuriuos reikėtų įgyvendinti, XP

projektas laikomas baigtu – mirties fazė. Šitoje fazėje realizuojami ne tik užsakovo poreikiai, bet

kartu ir kiti reikalavimai, pvz., efektyvumo, patikimumo.

Pagrindinės XP vertybės XP išskiria keturias pagrindines vertybes:

- bendravimas (angl. communication);

- paprastumas (angl. simplicity);

- grįžtamasis ryšys (angl. feedback);

- drąsa (angl. courage).



XP metodika teigia, kad norint pasiekti tinkamą rezultatą reikia mažiau dėmesio skirti

dokumentacijos 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 tam

tikrą funkcionalumą, jei šiuo metu klientas jo nereikalauja, kadangi jeigu tam tikra sistemos

funkcija nereikalinga dabar, galbūt jos nereikės ir vėliau.

Grįžtamasis ryšys išreiškia tai, kad siekiant sukurti sistemą reikia kuo dažniau gauti

atsiliepimus iš užsakovo apie sistemą. Grįžtamasis ryšys XP metodikoje yra daug svarbesnis

negu sistemos pristatymas užsakovui (angl. feedforward).

Kai visos trys vertybės įgyvendintos atsiranda drąsa. Drąsa yra reikalinga tada, kai reikia

keisti architektūrą, atsisakyti jau atlikto darbo, kai pasikeičia užsakovo reikalavimai.

XP praktikos

XP vertybėms įgyvendinti yra suformuluotos 12 praktikų:

Planavimo žaidimas. XP planavimą sudaro verslo ir techninių prioritetų nustatymas ir

pasakojimų priskyrimas iteracijoms.

Mažos laidos. Kiekviena sistemos laida turi būti kiek įmanoma mažesnė, realizuojanti

svarbiausius verslo reikalavimus. Taip siekiama kuo greičiau pateikti sistemą naudojimui.

Metafora. Metafora reiškia tai, kad sistemos kūrimas turi būti paprastas ir suprantamas

tiek kūrėjams, tiek klientams.

Paprastas projektas. Paprastas projektas nusako du dalykus: sistemoje neturi būti

realizuotas nereikalingas funkcionalumas, bet reikia sukurti geriausią projektą, kad būtų

realizuotas reikalingas funkcionalumas.

Pertvarkymas. XP reikalauja nuolatinio sistemos projektavimo. Sistema nuolat

pertvarkoma, kad būtų pašalinamas nereikalingas funkcionalumas ir būtų išlaikytas paprastas

projektas.

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 projekte

dalyvaujantis asmuo gali keisti bet kurią kodo dalį.



Nuolatinis integravimas. Sistema integruojama kelis kartus per dieną kas keletą valandų.

XP grįžtamasis ciklas yra trumpas: parašyti testus, sukoduoti, integruoti, ištestuoti. Vienu metu

integruoti kodą leidžiama tik vienai programuotojų porai.

40-ies darbo valandų savaitė. Ši taisyklė sako tai, kad darbuotojai neturi dirbti 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 apie

sistemą.

Kodavimo standartai. Visos šios praktikos susijusios viena su kita. Jeigu programuojama

poromis ir leidžiama keisti svetimą kodą, kodas turi būti rašomas pagal taisykles, kad būtų

visiems suprantamas.

DSDM

DSDM (angl. Dynamic Systems Development Method) – dinaminis programų kūrimo

metodas, sukurtas 1994 metais ir 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ėms

metodikoms, tai grafiškai pavaizduota paveikslėlyje:

10.2 pav. DSDM ir tradicinės metodikos

DSDM vadove teigiama, kad tradicinėse metodikose reikalavimai apibrėžiami iš anksto ir

fiksuoti visą sistemos kūrimo laiką, taigi siekiama sukurti programinę įrangą, kuri tenkintų visus

numatytus reikalavimus, o laikas ir resursai skiriami pagal tai, kiek bus reikalinga apibrėžtam

funkcionalumui pasiekti. DSDM priešingai nustato fiskuotą projekto laiką ir stengiasi kiek

įmanoma fiksuoti resursus, tačiau reikalavimai gali būti keičiami pagal verslo poreikius.

Fiksuota

Kintamas

Tradi- cinės

Funkcionalumas

Laikas Resursai

DSDM

Funkcionalumas

Laikas Resursai



DSDM procesas DSDM naudoja iteratyvų ir ciklinį gyvavimo ciklą, kas reiškia, kad sistema sukuriama ne

per 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 ir produktus.

Taikymotyrimas

Verslo analizė

Funkcinio modelioiteracija

Projektavimo irkonstravimo iteracija

Realizavimas

1 5

23

6

74

10.3 pav. DSDM proceso struktūra

Kū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 ir konstravimo iteracija (angl. design and build iteration);

- realizavimas (angl. implementation).

DSDM taikymo galimybių tyrimas ir verslo analizė atliekami nuosekliai. Šiose fazėse

nustatomos pagrindinės taisyklės likusioms kūrimo fazėms, kurie atliekami iteratyviai ir

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 skirtas patikrinti, ar DSDM metodika priimtina

projektui vykdyti. Kartu šioje fazėje nustatoma, kiek laiko reikės įvykdyti projektą, nustatomi

sistemos kaštai ir ar įmanoma techniškai išspręsti keliamą verslo problemą.

Verslo analizėje pagrindinis dėmesys skiriamas verslo procesams ir jų informaciniams

poreikiams nustatyti. Apibrėžiami ir prioritetizuojami reikalavimai, apibrėžiama sistemos

architektūra ir parengiamas prototipų planas.



Funkcinio modelio iteracija susidaro iš analizės, kurios metu peržiūrimi ir koreguojami

verslo analizės fazėje apibrėžti reikalavimai, identifikuojami nefunkciniai reikalavimai, ir

prototipų, kurie skirti pagrindiniam funkcionalumui pavaizduoti, kūrimo. Į šią fazę įtrauktas ir

funkcinių reikalavimų testavimas.

Projektavimo ir konstravimo iteracijoje sukuriama sistema, kuri nebūtinai atitinka visus jai

keliamus reikalavimus, tačiau tenkina visus ciklui sutartus reikalavimus. Sukurtą produktą –

vadinamą testuota sistema (angl. Tested System) – testuoja sistemos naudotojai. Šiame etape

realizuojami ir testuojami nefunkciniai reikalavimai. Netenkinant pastarųjų grįžtama į funkcinio

modelio iteracijos fazę (4 rodyklė).

Realizavimo fazėje sukuriama visus ciklui iškeltus reikalavimus tenkinanti sistema, kuri

gali būti pateikiama naudojimui (angl. Delivered System), apmokomi naudotojai, kurie

nedalyvavo kūrimo procese. Yra galimi 4 perėjimai iš šios fazės:

- 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 projekto

terminas dar nesibaigė, grįžtama į funkcinio modelio iteracijos fazę tam, kad

reikalingas funkcionalumas būtų realizuotas (6 rodyklė).

- Jei dėl laiko spaudimo mažiau svarbūs techniniai aspektai buvo praleisti, bet projekto

terminas nesibaigė, grįžtama į projektavimo ir konstravimo iteraciją (7 rodyklė).

Pagrindiniai DSDM principai DSDM metodikoje išskiriami 9 principai, kurių kiekvienas apibūdina skirtingas metodikos

sritis:

Principas Komentarai

1. Būtinas aktyvus naudotojo

įtraukimas

DSDM yra į naudotojus orientuotas metodas. Į kūrimo

procesą įtraukiama tam tikra nedidelė grupė naudotojų, kurie

pateikia atsiliepimus apie sistemą.

2. DSDM komandai privalo būti

suteikta sprendimo teisė

DSDM komandą sudaro kūrėjai ir naudotojai. Pastariesiems

turi būti suteikta spręsti, kokius reikalavimus sistema privalo

tenkinti, kurie iš jų turėtų būti peržiūrėti arba pakeisti

išvengiant dažno vadovybės dalyvavimo.



Principas Komentarai

3. Reikalingas dažnas produkto

pristatymas užsakovui.

DSDM komandos darbas orientuotas į produktus, kurie gali

būti sukurti per sutartą laiko tarpą. Pagal tai, kiek laiko yra

skirta užduočiai komanda pasirenka užduoties įgyvendinimo

būdą. Iteracijas siekiama daryti kuo trumpesnes, todėl galima

anksti sulaukti užsakovo vertinimo.

4. Esminis produkto priėmimo

kriterijus – tinkamumas verslo

paskirčiai

DSDM kelia tikslą realizuoti reikalingą funkcionalumą per

pageidaujamą laiko tarpą. Atitikimas pagrindiniams verslo

poreikiams, atsižvelgiant, kad jie gali keistis, yra svarbesnis

už sistemos techninį tobulumą.

5. Siekiant rasti verslui tinkamą

sprendimą naudojamas cikliškas

kūrimo procesas.

Dėl cikliško kūrimo proceso anksti sulaukiama naudotojo

vertinimų, todėl ankstyvose fazėse ištaisomos klaidos.

6. Kūrimo metu visi keitimai

gali būti atšaukiami.

DSDM palaiko grįžimo metodą (angl. backtracking).

Priėmus neteisingą sprendimą, grįžtama į ankstesnę kūrimo

fazę, tokiu būdu neteisingas kūrimo kelias gali būti

ištaisomas. Pakeitimų atsisakymas apribojamas kūrimo

ciklais.

7. Reikalavimai projektuojami

abstrakčiu lygiu.

Apibrėžiami tik pagrindiniai reikalavimai, kurie turėtų

apibūdinti sistemos apimtį. Reikalavimai detalizuojami

vėlesnėse kūrimo fazėse ir gali būti keičiami esant poreikiui.

8. Testavimas integruojamas į

gyvavimo ciklą.

Testavimas nėra laikomas atskira veikla. Sistema testuojama

tiek kūrėjų, tiek naudotojų. Ankstyvose fazėse

orientuojamasi atitikimą verslo poreikiams, vėliau

testuojama, ar sistema veikia efektyviai.

9. Labai svarbus

bendradarbiavimas tarp visų

suinteresuotų asmenų (angl.

stakeholders).

Reikalavimai detalizuojami projekto vykdymo metu ir norint

išlaikyti trumpus terminus, reikia priimti sprendimus

atsisakant varžančių pakeitimų kontrolės procedūrų, todėl

reikalinga įtraukti visus suinteresuotus asmenis ne tik iš

verslo pusės, tačiau ir atstovus iš paslaugų teikimo,

logistikos srities.

Pagrindiniai DSDM metodai Pagrindiniai DSDM metodai yra laiko skaidymas intervalais (angl. timeboxing),

reikalavimų prioritetizavimas (angl. prioritization) ir prototipavimas (angl. prototyping).



Laiko skaidymas intervalais

Kiekvienas DSDM projektas turi fiksuotą pabaigos datą – šitas laikotarpis nurodo sistemos

realizavimo terminą, kuris savo ruožtu skirstomas į 2-6 savaičių trukmės intervalus. Kiekvienas

laiko intervalas turi galutinį terminą ir priskirtą reikalavimų, suskirstytų pagal prioritetus, rinkinį.

Kiekvieno intervalo tikslus nustato kūrėjai ir naudotojai. Pirmieji 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 intervale

nebuvo pasiekti tam tikri rezultatai, apimtis peržiūrima – reikalavimai gali būti nukeliami, tačiau

terminas – 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ūti

naudojamas reikalingų resursų, sukurti veikiančią sistemą, kiekiui įvertinti. Toks kontroliavimo

būdas žymiai intensyvina valdymą.

Reikalavimų prioritetizavimas

Reikalavimams suskirstyti pagal prioritetus DSDM naudojamos vadinamosios MoSCoW

taisyklės. Pagal jas reikalavimai suskirstomi į 4 grupes:

• Privalomieji (angl. Must have). Esminiai sistemos reikalavimai, kurių nerealizavus

sistema neveiktų. Privalomieji reikalavimai apibūdina minimalų tinkamos naudoti

sistemos reikalavimų poaibį. DSDM projektas privalo tenkinti visus šio poaibio

reikalavimus.

• Reikalingi (angl. Should have). Svarbūs reikalavimai, kurie būtų klasifikuoti kaip

privalomi mažiau į laiką orientuotose metodikose, tačiau net jų nerealizavus sistema

bū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 ir reikšmingi tik tam tikrai

naudotojų grupei.

Visi šitie reikalavimai sudaro pilną sistemą, tačiau paprastai ne visi reikalavimai išpildomi

vieno laiko intervalo metu arba jų naudotojas gali atsisakyti dėl įgautų naujų žinių apie technines

galimybes, arba dėl darbo aplinkos pokyčių. Reikalavimų, kurie nepriklauso privalomųjų grupei

gali būti atsisakyta, kadangi reikalavimai gali būti keičiami, tačiau pabaigos terminas – ne.

Prototipavimas

DSDM kūrimo pradžioje reikalauja suformuluoti tik pagrindinius reikalavimus, kurie

apibūdina sistemos apimtį ir kūrimo eigoje yra konkretizuojami. Detalizuoti reikalavimai



užsakovui demonstruojami prototipais. Prototipų demonstravimas išplečia naudotojo supratimą

apie sistemos galimybes ir yra tinkamas sužinoti, kaip naudotojai vertina sistemos korektiškumą,

tinkamumą naudoti, ir nustatyti užsakovo poreikiams. Prototipuose paprastai nėra realizuojami

visi iškelti funkciniai ir nefunkciniai reikalavimai, bet DSDM kelia reikalavimą, kad prototipai

būtų pakankamai kokybiški, nes yra įtraukiami į galutinę sistemą.

DSDM metodika rekomenduoja 4 tipų prototipus:

1. Verslo, skirti automatizuojamų verslo aspektų demonstravimui.

2. Tinkamumo naudoti – naudotojo interfeiso demonstravimui.

3. Efektyvumo/sugebėjimų – sistemos sugebėjimo sėkmingai atlikti numatytą darbą. Šis

prototipas skirtas kūrėjams, kadangi susijęs su nefunkciniais reikalavimais.

4. Gebėjimų/metodų – koncepcijos tikrinimui ir projektavimo bandymams.

Scrum

Pavadinimas „pasiskolintas“ iš regbio žaidimo, kai komanda bendromis pastangomis

neleidžia kamuoliui nukristi ant žemės.

Ši judrioji programų kūrimo metodika buvo sukurta 90-aisiais metais grupės, kuriai

vadovavo Jeff Sutherland. Paskutiniu metu ji vystoma K.Schwaber ir M.Beedle darbuose.

Scrum principai atitinka judriųjų metodikų manifestą:

- Mažos komandos turi maksimizuoti bendravimą, neformalų keitimąsi informacija ir

žiniomis bei minimizuoti papildomas valdymo sąnaudas.

- Procesas turi būti pritaikomas prie techninių ir verslo sąlygų pasikeitimų, kad užtikrintų

geriausio įmanomo produkto sukūrimą.

- Procesas orientuotas į dažnas programos laidas (versijas).

- Darbai ir juos atliekantys žmonės dalinami į aiškias ir mažai susijusias grupes.

- Kuriamas produktas būtinai testuojamas ir dokumentuojamas.

- Scrum procesas sudaro galimybę paskelbti produktą „sukurtu“, kada tik to reikia.

Esminės Scrum proceso veiklos yra reikalavimai (angl. requirements), analizė (angl.

analysis), projektavimas (angl. design), įgyvendinimas (angl. evolution) ir pateikimas (angl.

delivery). Produktas kuriamas iteracijomis, kurios vadinamos sprintais (angl. sprints). Bendra

proceso schema pateikta 10.4 pav.



Produkto užsakymų krepšelis:prioritetizuotos užsakovo pageidaujamos produkto savybės

Sprinto užsakymų krepšelis:sprintui priskirtos produktosavybės

Naujasfunkcionalumas

Komandospatikslintiužsakymai

30 dienų

24 valandos Scrumsusirinkimas

10.4 pav. Scrum proceso struktūra

Užsakymų krepšelis (angl. backlog) – prioritetizuotas sąrašas svarbių užsakovo verslui

reikalavimų ar sistemos savybių. Šis sąrašas gali būti papildomas/patikslinamas bet kuriuo metu.

Kai prireikia, produkto vadovas (angl. product manager) įvertina užsakymus ir patikslina

prioritetus.

Sprintas (angl. sprint) – darbai, kurie turi būti atlikti pasirinktų užsakymų iš krepšelio

(angl. backlog) įgyvendinimui per nustatytą laiko intervalą (angl. time-box), kuris tradiciškai yra

30 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 dirbti stabilioje

aplinkoje.

Scrum susirinkimai (angl. Scrum meetings) – trumpi (tradiciškai 15 minučių) kasdieniniai

Scrum komandos susirinkimai, 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 ir komandos narių atsakymus vertina komandos lyderis, vadinamas

Scrum meistru (angl. Scrum master). Susirinkimai padeda komandai identifikuoti galimas



problemas, kiek įmanoma, anksčiau. Be to, šie susirinkimai veda prie „žinių suvisuomeninimo“

(visi žino tikslią projekto būseną) ir skatina saviorganizuojančią komandos struktūrą.

Demo (angl. demos) – programos laidos pateikiamos užsakovams tam, kad įgyvendintas

funkcionalumas galėtų būti išbandytas ir įvertintas. Svarbu pastebėti, kad demo gali neturėti viso

planuoto funkcionalumo, iš esmės jame yra funkcijos, kurios galėjo būti įgyvendintos per

nustatytą laiko intervalą (angl. time-box), t.y. prioritetas teikiamas laikui, o ne planuotam

funkcionalumui.

Teigiama, kad Scrum metodika įgalina komandą sėkmingai dirbti aplinkoje, kurioje

neapibrėžtumų išvengti neįmanoma.

Crystal

Crystal judriųjų metodikų šeimą sukūrė Alistair Cockburn ir Jim Highsmith. Pavadinimas

„Crystal“ buvo parinktas pagal geologinių kristalų charakteristikas – kiekvienas kristalas yra

unikalus, turintis savo spalvą, formą ir kietumą. Siekiamas tikslas buvo maksimalus

manevringumas, kuris charakterizuojamas kaip „kolektyvinis kūrimo ir bendravimo žaidimas su

ribotais resursais, siekiant pirmiausia patiekti naudingą, veikiančią programų sistemą, o taip pat

pasirengti sekančiam žaidimui“.

Siekdami manevringumo autoriai apibrėžė aibę metodikų, turinčių bendrus esminius

elementus, tačiau unikalius procesus, šablonus, darbo produktus, roles ir praktikas. Praktiškai tai

aibė judriųjų metodikų, kurios pasirodė efektyvios skirtingo tipo projektuose. Siekiamas tikslas

suteikti „judrioms“ komandoms galimybę pasirinkti iš metodikų šeimos tą, kuri labiausiai tinka

jų projektui ir aplinkai.

Judriųjų ir planais paremtų metodų derinimas

Šeši esminiai principai:

1. Nei judriosios metodikos, nei planais paremti metodai nepateikia sidabrinės kulkos.

2. Judriosios metodikos ir planais paremti metodai turi taikymo sąlygas, kuriose

neabejotinai dominuoja prieš kitus metodus.

3. Ateities tendencijos yra link programų sistemų kūrimo, kuriam reikia ir judrumo, ir

disciplinos.

4. Atsiranda subalansuoti metodai.

5. Geriau konstruoti savo metodą „į viršų“ nei prisitaikyti jį „žemyn“.

6. Metodai yra svarbūs, tačiau labiau tikėtina rasti sidabrinę kulką užsiimant žmonėmis,

vertybėmis, komunikavimu ir vilčių valdymu.



Nei judriosios metodikos, nei planais paremti metodai nepateikia sidabrinės kulkos

Nei judriosios metodikos, nei planais paremti metodai nepateikia sidabrinės kulkos, kuri

užmuštų programinės įrangos krizės vaiduoklį. Šio vaiduoklio esmė yra susijusi su esminiais

programų sistemų inžinerijos sunkumais kovojant su programų sistemų sudėtingumu,

suderinamumu, keičiamumu ir nematomumu. Kai kurie metodai pasiekė „švininės kulkos“ lygį,

t.y. jie sprendžia dalį programų sistemų inžinerijos problemų. Judriųjų metodikų ir planais

paremtų metodų elementai gali būti apibūdinti kaip švininės kulkos.

Judriosios metodikos valdo kintamumą ir nematomumą, sukurdamos bendrą visiems

komandos nariams projekto tikslų ir strategijos viziją. Bet judriosios metodikos žlunga

sprendžiant sudėtingumo ir tam tikru lygiu suderinamumo problemas. Jos „neišplečiamos“

dideliems sudėtingiems projektams, be to, jos neskiria dėmesio kartais kritiniam suderinamumo

reikalavimui, pavyzdžiui, interfeiso specifikacijoms ar produktų linijos architektūrai.

Planais paremti metodai valdo suderinamumą ir nematomumą, investuodami į išsamią

dokumentaciją. Tačiau jie žlunga sprendžiant kintamumo (dokumentacijos perdarymas) ir

augančio sudėtingumo problemas.

Judriųjų metodikų ir planais paremtų metodų taikymo sąlygos

Be abejonės yra sąlygos tinkamos grynoms judriosioms metodikoms ar gryniems planais

paremtiems metodams, tačiau tokių specifinių atvejų nėra daug. Nustatyti situaciją ir įvertinti

metodo 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 ir judrumo, ir disciplinos

Praeityje buvo pakankamai daug nedidelių, nekritinių, įgudusių, greitai besivystančių

projektų, pataikančių į patį centrą sąlygų, tinkamų judriųjų metodikų taikymui. Taip pat buvo

daug žmonių, dirbančių dideliuose, kritiniuose, įvairių į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ūs

proceso ir produkto planai reikalauja didelių sąnaudų ir stabdo. Judriosios metodikos

pradedamos taikyti dideliems projektams ir neišvengiamai susiduriama su naujomis –

sudėtingumo ir suderinamumo - problemomis. Todėl didžiausią naudą duos turėjimas metodų,

derinančių judrumą ir discipliną, priklausomai nuo situacijos.



Atsiranda subalansuoti metodai

Kai kurios judriosios metodikos, pavyzdžiui, Crystal Orange, DSDM, FDD ir Lean

Development, siūlo būdus pasiekti balansui. Tai būdinga ir naujoms, „lengvesnėms RUP

(Rational Unified Process) versijoms.

Yra pritaikytų metodikų pavyzdžių pateikiančių rizikomis paremtą, spiralinį gyvavimo

ciklą, derinantį judriuosius ir 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 ir

kiekviename projekte jis turi būti taikomas, priklausomai nuo situacijos.

Konstruok metodą („į viršų“) – 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. Judrusis

požiūris yra geresnis - jis siūlo pradėti nuo minimalaus rinkinio praktikų ir papildomas į vesti tik

tada, kai aiškus jų poreikis ir naudingumas. Kai kuriais atvejais, pavyzdžiui, Crystal, yra

skirtingi baziniai rinkiniai, kurie naudojami priklausomai nuo dydžio ir/ar kritiškumo. Panašių

tikslų yra siekiama vystant RUP.

Mažiau dėmesio metodams - daugiau žmonėms, vertybėms, komunikavimui ir vilčių

valdymui

Judriojo požiūrio šalininkai yra teisus labiau vertindamas individus ir bendravimą nei

procesą ir įrankius. Jie nebuvo pirmieji, tai pabrėžę, yra ilgas sąrašas giminingo požiūrio darbų:

Weinberg kompiuterių programavimo psichologija(1971), skandinavų projektavimas kartu

dalyvaujant (1990), DeMarco ir Lister Peopleware (1987), Curtis žmogiškojo faktoriaus tyrimai

(1988), žmonių gebėjimo brandos modelio (People Capability Maturity Model) kūrimas. Yra

gausybė patvirtinimų, kad žmogiškasis faktorius dominuoja prieš kitus programų sistemų kainos

ir kokybės faktorius: pavyzdžiui, Grant-Sackman 1986 metų eksperimentai, rodantys žmonių

produktyvumo varijavimą 26:1; COCOMO ir COCOMO II modelių kalibravimas 1981 ir 2000

metais, parodęs 10:1 efektą priklausomai nuo darbuotojų gebėjimo, patirties ir tęstinumo.

Žmonės

Programų 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, ir kiti žmonės

sukuria ją.

- Žmonės apmoka sąskaitas už programų sistemų kūrimą ir naudoja sukurtus produktus.



Tačiau programų sistemų inžinerija vis dar „vargsta“ su atskirtų 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 ir

programų sistemų inžinerijoje;

- sistemos reikalavimų analizė ir paskirstymas nėra programų sistemų inžinerijos grupės

darbas ir turi būti pateiktas jai prieš pradedant darbą;

- programų sistemų inžinerija nėra projektų valdymas.

Šiandieniniame ir ateities pasaulyje toks aspektų atskyrimas tampa vis labiau pavojingas.

Vertybės

Kartu su žmonėmis yra vertybės - įvairios vertybės. Vienas iš svarbiausių programų

sistemų inžinerijos iššūkių, kuriam, deja, neteikiama daug reikšmės, yra suderinti skirtingus

vartotojų, užsakovų, kūrėjų ir kitų suinteresuotų asmenų vertybes įžvelgiamas planuojamoje

programų sistemoje į visus patenkinančios ir visiems naudingos sistemos apibrėžimą ir galutinį

rezultatą. Deja, programų sistemų inžinieriai dažnai dar veikia neutralioje aplinkoje, kur

kiekvienas reikalavimas, vartojimo scenarijus, objektas, testas ir defektas yra vertinami kaip

vienodai svarbūs. Didžioji dalis proceso gerinimo iniciatyvų ir 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

ir atsižvelgdamos į vartotojo vertybių pasikeitimus veda prie labiau atsiperkančių sprendimų.

Komunikavimas

Netgi vidiniuose projektuose „aš negaliu išreikšti tiksliai, ko noriu, bet aš žinosiu, kai

pamatysiu 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 sistemos

apibrėžimas ir kūrimas vyksta keliose organizacijose, reikalingas dar aktyvesnis bendravimas,

kad apibrėžti ir suderinti bendrą sistemos viziją ir jos kūrimo strategiją. Augantis pasikeitimų

tempas dar paaštrina problemą ir padidina netinkamo komunikavimo pasekmes.

Be jau minėtų darbų, orientuotų į žmones, yra labai nedaug šaltinių nagrinėjančių, kokie

komunikavimo būdai geriausiai tinka kokiose situacijose. Iš jų reiktų išskirti Cockburn knygą

„Agile Software Development“, kurioje ne tik akivaizdžiai parodomas problemos, kylančios dėl

netinkamo komunikavimo, programų sistemų kūrimas apibūdinamas kaip bendras išradimo ir

komunikavimo žaidimas, bet ir pateikiama visa eilė naudingų komunikavimo principų bei

konkrečių būdų.



Vilčių valdymas

Viena iš svarbių išvadų, padarytų nagrinėjant JAV Gynybos departamento užsakomus

projektus, yra ta, kad skirtumas tarp sėkmingų ir probleminių projektų dažniausiai yra skirtumas

tarp gero ir blogo vilčių valdymo.

Dauguma programų sistemų kūrėjų nėra nei kvalifikuoti, nei patyrę vilčių valdyme. Jie turi

didelį norą įtikti ir išvengti konfrontacijos ir tuo pačiu turi per mažai pasitikėjimo savo

galimybėmis numatyti projekto biudžetą ir tvarkaraštį. Tai daro juos silpnais priešininkais

agresyvių užsakovų ir vadovų, besistengiančių gauti daugiau programų per mažesnį laiką ir už

mažesnius pinigus. Esminis PSP/TSP ir XP komandų bruožas, kad jos turi pakankamai proceso

žinių, pasirengimo ir drąsos, kad gauti savo užsakovų sutikimą sumažinti funkcionalumą ar

padidinti laiką tam, kad būtų įgyvendinti nauji aukšto prioriteto pakeitimai. Jie žino, kad gavimas

nerealių 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 naudojamas

produktyvumo kalibravimas yra keliai į sėkmingą vilčių valdymą.


[Agi01] Manifesto for Agile Software Development, 2001. http://www.agilemanifesto.org.

[ASRW02] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Juhani Warsta. Agile software

development 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/

Programų sistemų inžinerija 11. Projekto valdymas pagal PMBOK


11. Projekto valdymas pagal PMBOK

PMBOK6 (angl. Project Management Body Of Knowledge) yra projektų valdymo

profesijos žinių visuma. Pilnas PMBOK suprantamas kaip apimantis tiek pasitvirtinusias ir

plačiai taikomas projektų valdymo žinias ir praktikas, tiek naujai atsiradusias profesines

praktikas, tame tarpe publikuotas ir nepublikuotas. Todėl PMBOK pastoviai vystosi.

PMBOK gairių [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 ir 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ų ir tai, kad kažkas nėra įtraukta į PMBOK, nereiškia, jog šis aspektas yra

nesvarbus. Galimos kelios priežastys, kodėl aspektas nėra įtrauktas į PMBOK: jis aptariamas

kituose 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 kas

organizacijoje 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 charakteristikos

Apribotas laike reiškia, kad kiekvienas projektas turi apibrėžtą pradžią ir pabaigą.

Projektas baigiamas, kai jo tikslai pasiekiami, arba nutraukiamas, kai tampa aišku, kad projekto

tikslai negali būti pasiekti ar projektas tampa nebereikalingu. Apribotas laike nebūtinai reiškia

neilgas, nes projektas gali tęstis ir kelis metus. Tačiau visais atvejais projekto trukmė yra

apribota. 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 ir projektui pasibaigus.

Projektų ribotumas laike susijęs ir su kitais aspektais, pavyzdžiui: galimybė ar rinkos

„langas“ dažniausiai būna apribotas laike, todėl projektas turi ribotą laiką produktui ar paslaugai

sukurti; projekto komanda retai gyvuoja ilgiau nei projektas - komanda suburta projektui atlikti,

jam pasibaigus, tradiciškai yra išformuojami ir komandos nariai gauna kitus paskyrimus.

6 PMBOK skirtas bet kokių projektų, ne tik programų sistemų kūrimo, valdymui.



Projekto rezultatų unikalumas. Projektas gali sukurti:

- produktą ar artefaktą, kuris yra kiekybiškai įvertinamas ir yra savarankiškas vienetas

arba kažko dalis;

- galimybes suteikti paslaugas, pavyzdžiui, verslo funkcijas gamybai ar platinimui;

- rezultatą, pavyzdžiui, dokumentą ar žinias (mokslo tiriamojo projekto atveju).

Projekto rezultatų unikalumas yra svarbi charakteristika. Pavyzdžiui, yra suprojektuota

daugybė namų, bet kiekvienas yra unikalus – skirtinga išvaizda, vieta, užsakovas ir 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

ir unikalumu. Laipsniškas plėtojimas reiškia kūrimą žingsniais, pavyzdžiui, projekto apimtis iš

esmės apibrėžiama projekto pradžioje ir detalizuojama, kai projekto komanda pilniau išsiaiškina

projekto tikslus ir darbo produktus. Laipsniškas plėtojimas neturėtų būti painiojamas su projekto

apimties pasikeitimu. Laipsniškas projekto specifikacijos plėtojimas turi būti atidžiai

koordinuojamas su tinkamu projekto apimties apibrėžimu, ypač jei projektas atliekamas pagal

sutartį. Tinkamai apibrėžta projekto apimtis (kas turi būti padaryta) turi būti kontroliuojama

projektui palaipsniui vystantis.

Projektas vs. einamoji veikla

Organizacijos dirba 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 ir kontroliuojami.

Esminis skirtumas tarp jų yra tai, kad procesas (einamoji veikla) yra nuolatinis ir

pasikartojantis, o projektas yra apribotas laike ir unikalus. Be to, jų tikslai yra iš esmės skirtingi:

projekto paskirtis pasiekti tikslus ir pasibaigti, o proceso (einamosios veiklos) tikslas yra

palaikyti verslą. Projektas baigiasi, kai pasiekia specifinius jam iškeltus tikslus, o procesas

(einamoji veikla) prisitaiko prie naujų tikslų ir tęsia darbą.

Projektai vykdomi visuose organizaciniuose lygiuose ir juose gali dalyvauti nuo vieno iki

kelių 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;



- visuomeninės vandentiekio sistemos pastatymas;

- politinė kampanija;

- naujų veiklos procedūrų ar procesų įdiegimas

ir t.t.

Projektai ir strateginis planavimas

Projektai 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ų arba

išorinių paslaugų teikėjų.

Projektai tipiškai yra inicijuojami kaip rezultatas vieno ar daugiau tokių strateginių

sumetimų (aplinkybių):

- Rinkos poreikis (pvz., naftos perdirbimo kompanija inicijuoja naujos perdirbimo

į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ą naujo

pramoninio parko aptarnavimui);

- Technologinė pažanga (pvz., programinės įrangos kūrimo įmonė inicijuoja naujos

kartos žaidimo kūrimą atsiradus 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ų ir metodų taikymas projekto veikloms, kad

patenkinti projekto reikalavimus. Projekto valdymas atliekamas taikant projekto valdymo

procesus: inicijavimą, planavimą, vykdymą, stebėjimą ir kontrolę, uždarymą. Projekto vadovas

yra asmuo, atsakingas už projekto tikslų pasiekimą.

Projekto valdymas apima:

- reikalavimų identifikavimą;

- nustatymą aiškių ir pasiekiamų tikslų;

- prieštaringų kokybės, apimties, kainos ir laiko poreikių balansavimą;

- pritaikymą specifikacijų, planų ir metodų skirtingiems įvairių suinteresuotų asmenų

poreikiams ir lūkesčiams.

Projektų vadovai dažnai kalba apie „trigubą apribojimą“ (projekto apimtis, laikas ir kaina)

prieštaringų projekto reikalavimų valdymui. Projekto kokybė priklauso nuo šių trijų faktorių



suderinimo. Aukštos kokybės projektai pateikia numatytos apimties rezultatus, laiku ir už sutartą

kainą. Šie trys faktoriai yra susiję taip, kad jei bet kuris vienas iš jų pasikeičia, tai įtakoja dar

bent vieną kitą faktorių. Projektų vadovai turi atsižvelgti į neapibrėžtumus. Projekto rizika yra

tikė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ą ir visuomenę. Visi projekto valdymo grupės nariai

turi laikytis etikos kodekso (angl. Code of Ethics), o sertifikuoti profesionalai (angl. Project

Management Professional certified) turi laikytis profesinės veiklos kodekso (angl. Code of

Professional Conduct).

Svarbu pastebėti, kad daugelis projekto valdymo procesų yra iteratyvūs dėl laipsniško

projekto plėtojimo poreikio jo gyvavimo ciklo eigoje, t.y. kai projekto eigoje yra sužinoma apie

projektą daugiau (detaliau), jis gali būti tiksliau valdomas.

Daug projektų valdymo žinių, įrankių ir metodų yra specifiniai projektų valdymui (pvz.,

darbų skleistinė, kritinio kelio analizė ar uždirbtos vertės valdymas). Tačiau pripažintų žinių,

įgūdžių, įrankių ir metodų taikymo nepakanka efektyviam projekto valdymui, tam būtina, kad

projekto valdymo grupė žinotų ir taikytų žinias ir įgūdžius bent jau iš penkių sričių:

- projektų valdymo žinios (PMBOK);

- taikomosios srities žinios, standartai, įstatymai ir taisyklės;

- projekto aplinkos supratimas;

- bendrosios valdymo žinios ir įgūdžiai;

- tarpasmeniniai (darbo grupėje) įgūdžiai.

Šios penkios sritys persidengia. Nebūtina (ir mažai tikėtina), kad kiekvienas komandos

narys bus visų penkių sričių ekspertas, bet efektyviam darbui reikia, kad projekto valdymo grupė

turėtų pakankamai žinių ir įgūdžių visose penkiose srityse.

Projektų valdymo žinių sritys

PMBOK išskiria 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).



Projekto gyvavimo ciklas

Projekto vadovai ar organizacija gali suskirstyti projektus į fazes, kad užtikrinti geresnį

valdymą ir kontrolę. Šios fazės kartu yra vadinamos projekto gyvavimo ciklu. Daugelis

organizacijų 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 inicijuoja

galimybių studiją (angl. feasibility study), kad nuspręsti, ar pradėti projektą. Gyvavimo ciklo

apibrėžimas nusako, ar galimybių studija yra laikoma pirma projekto faze, ar atskiru,

nepriklausomu projektu. Kai šios preliminarios veiklos rezultatai nėra aiškūs, geriau ją traktuoti

kaip atskirą projektą. Projekto gyvavimo ciklo fazės yra ne tas pats, kas projekto valdymo

procesų grupės.

Nėra idealaus gyvavimo ciklo tinkamo visiems projektams. Kai kurios organizacijos

apibrėžia vieningą gyvavimo ciklą, kuris taikomas visiems jų projektams, kitos organizacijos

leidž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 ir kaip jie yra peržiūrimi,

verifikuojami ir validuojami;

- kas dalyvauja kiekvienoje fazėje;

- kaip valdoma ir patvirtinama kiekviena fazė.

Projekto gyvavimo ciklas apibrėžimai gali būti labai bendri ir labai detalūs (su

konkrečiomis formomis, schemomis, kontroliniais sąrašais ir pan.) Dauguma projekto gyvavimo

ciklo apibrėžimų pasižymi tokiomis savybėmis:

- fazės yra iš esmės nuoseklios ir dažniausiai apibrėžiamos techninės informacijos ar

produktų perdavimu;

- finansavimo ir personalo resursų poreikis yra nedidelis pradžioje, maksimaliai išauga

vidurinėse fazėse ir staigiai mažėja projektui artėjant prie pabaigos;

- projekto pradžioje neapibrėžtumo lygis yra aukščiausias ir rizika nepasiekti tikslų yra

didžiausia (projekto eigoje jie mažėja);

- suinteresuotų asmenų galimybės įtakoti projekto rezultatų galutines charakteristikas ir

projekto kainą yra didžiausia projekto pradžioje.

Projektu suinteresuoti asmenys

Suinteresuoti asmenys (angl. stakeholders) yra asmenys ir organizacijos, kurie aktyviai

dalyvauja projekte arba kurių interesus gali įtakoti projekto vykdymas ar įgyvendinimas

(projekto tikslai ir rezultatai). Projekto valdymo grupė turi identifikuoti suinteresuotus asmenis,



išsiaiškinti jų reikalavimus ir lūkesčius bei pagal galimybes valdyti jų reikalavimus, kad

projektas būtų sėkmingas.

Suinteresuoti asmenys turi projekte skirtingo lygio atsakomybes ir įgaliojimus, kurie gali

keistis projekto eigoje. Suinteresuoti asmenys gali įtakoti projektą tiek teigiamai (tie, kurie gaus

naudos iš sėkmingo projekto rezultatų), tiek neigiamai (tie, kurie mato neigiamas projekto

pasekmes).

Kiekvieno projekto suinteresuoti asmenys apima:

- Projekto vadovas: asmuo atsakingas už projekto valdymą.

- Užsakovas/naudotojas: asmuo ar organizacija, kuri naudos projekto produktą. Galimi

kelių lygių užsakovai, pavyzdžiui, naujų vaistų atveju tai ir gydytojai, ir ligoniai, ir

ligonių kasos. Kai kuriose taikymo srityse užsakovas ir naudotojas yra sinonimai,

kitose – užsakovas yra esybė, įsigyjanti projekto produktą, o naudotojas yra tas, kuris

betarpiš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 dalyvauja

projekto valdyme.

- Sponsorius: asmuo ar grupė, suteikianti projektui finansinius resursus.

- Įtakojantys: asmenys ar grupės, tiesiogiai nesusiję projekto produkto įsigijimu ar

naudojimu, bet dėl savo individualios pozicijos užsakovo ar vykdančioje organizacijoje

galintys teigiamai ar neigiamai įtakoti projekto eigą.

- Projektų valdymo skyrius (angl. PMO – Project Management Office): jei toks yra

vykdančioje organizacijoje, gali būti suinteresuotas asmuo, jei tiesiogiai ar netiesiogiai

atsakingas už projekto rezultatus.

Be išvardintų gali būti daugybė kitų projektu suinteresuotų asmenų, pavyzdžiui: savininkai

ir investuotojai, pardavėjai ir kontraktoriai, komandos nariai ir jų šeimos, valstybinės

organizacijos, atskiri gyventojai ir visa visuomenė.

Projekto vadovas turi valdyti suinteresuotų asmenų lūkesčius, kas nėra paprasta, nes

suinteresuoti asmenys dažnai turi skirtingus ir konfliktuojančius tikslus.

Projekto valdymo procesai

Projekto valdymo procesai apibrėžti kaip diskretūs elementai su savo interfeisais, tačiau

praktikoje jie persidengia. Labiausiai patyrę praktikai pripažįsta, kad yra ne vienas būdas valdyti

projektą. Projekto specifiką sudaro tikslai, kuriuos reikia pasiekti atsižvelgiant į sudėtingumą,

riziką, dydį, laiką, projekto komandos patirtį, prieinamus resursus, turimą istorinę informaciją,



organizacijos projektų valdymo brandumą ir taikomąją sritį. Projekto valdymo procesai taikomi

projekte iteratyviai ir daug procesų projekto eigoje yra kartojama ar peržiūrima. Projekto

vadovas ir komanda yra atsakingi už nustatymą, kas kuriuos procesus ir kaip reglamentuotai turi

taikyti, 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ės

PMBOK apibrėžia 5 projekto valdymo procesų grupes:

- Inicijavimo procesų grupė (angl. Initiating Process Group): apibrėžia ir inicijuoja

projektą ar projekto fazę.

- Planavimo procesų grupė (angl. Planning Process Group): apibrėžia ir detalizuoja

tikslus ir planuoja veiklas projekto tikslų ir apimties pasiekimui.

- Vykdymo procesų grupė (angl. Executing Process Group): apjungia žmones ir kitus

resursus projekto valdymo plano įgyvendinimui.

- Stebėjimo ir kontroliavimo procesų grupė (angl. Monitoring and Controlling Process

Group): reguliariai matuoja ir stebi projekto progresą, kad identifikuoti nukrypimus

nuo projekto plano taip, kad būtų galima imtis korekcinių veiksmų, reikalingų projekto

tikslams pasiekti.

- Uždarymo procesų grupė (angl. Closing Process Group): formalizuoja produkto,

paslaugos ar rezultatų priėmimą ir tvarkingai užbaigia projektą ar projekto fazę.

Projekto integravimo valdymas Projekto integravimo valdymo žinių sritis apima procesus ir veiklas, reikalingas

identifikavimui, apibrėžimui, kombinavimui, unifikavimui ir koordinavimui skirtingų procesų ir

veiklų projekto valdymo procesų grupėse (jų viduje). Projekto valdymo kontekste integravimas

yra priėmimas sprendimų, kur kiekvienu momentu koncentruoti pastangas ir resursus, numatant

potencialias problemas, sprendžiant jas prieš tampant kritiškomis ir koordinuojant darbus.

Integravimas taip pat apima derybas dėl prieštaringų tikslų ir alternatyvų.

Integravimo poreikis darosi akivaizdus situacijose, kai atskiri procesai sąveikauja,

pavyzdžiui: kainos įvertinimas, reikalingas sudarant atstatymo (contingency) planą, apima

integravimą planavimo procesų, susijusių su projekto kainos, laiko ir rizikos valdymu.

Projekto integravimo valdymo procesai:

- Sukurti projekto įsakymą (angl. Develop Project Charter): įsakymas formaliai

inicijuoja (sankcionuoja) projektą ar projekto fazę.



- Sukurti preliminarų projekto apimties apibrėžimą (angl. Develop Preliminary Project

Scope 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 ir koordinuoti visus

dalinius planus į projekto valdymo planą.

- Vadovauti ir valdyti projekto vykdymą (angl. Direct and Manage Project Execution):

vykdyti projekto valdymo plane numatytas veiklas, kad pasiekti projekto tikslus,

apibrėžtus projekto apimties dokumente.

- Stebėti ir kontroliuoti projekto darbą (angl. Monitor and Control Project Work): stebėti

ir kontroliuoti procesus, naudojamus projekto inicijavimui, planavimui, vykdymui ir

uždarymui, kad pasiekti projekto efektyvumo rodiklius, apibrėžtus projekto valdymo

plane.

- Integruotas pakeitimų valdymas (angl. Integrated Change Control): peržiūrėti visus

prašymus pakeitimams, patvirtinti pakeitimus ir kontroliuoti pakeitimus.

- Uždaryti projektą (angl. Close Project): pabaigti visas veiklas, kad formaliai uždaryti

projektą ar projekto fazę.

Projekto apimties valdymas Projekto apimties valdymas apima procesus, reikalingus užtikrinimui, kad projekte

numatyti visi tie ir tik tie darbai, kurie reikalingi įvykdyti projektą sėkmingai. Projekto apimties

valdymas iš esmės yra susijęs su apibrėžimu ir kontroliavimu, kas turi ir kas neturi būti įtraukta į

projektą.

Projekto apimties valdymo procesai:

- Apimties planavimas (angl. Scope Planning): sukūrimas projekto apimties plano, kuris

dokumentuoja, kaip bus nustatoma, tikrinama, kontroliuojama projekto apimtis ir kaip

bus sudaroma darbų skleistinė (angl. WBS – Work breakdown Structure).

- Apimties apibrėžimas (angl. Scope Definition): sukūrimas detalaus projekto apimties

apibrėžimo, kuris bus pagrindu tolimesniems projekto sprendimams.

- Darbų skleistinės sukūrimas (angl. Create WBS): pagrindinių projekto darbo produktų

ir darbų suskaidymas į mažesnius ir lengviau valdomus komponentus.

- Apimties patikrinimas (angl. Scope Verification): baigtų projekto darbo produktų

priėmimo formalizavimas.

- Apimties kontroliavimas (angl. Scope Control): projekto apimties pasikeitimų

kontroliavimas.



Projekto laiko valdymas Projekto laiko valdymas apima procesus, reikalingus laiku užbaigti projektą:

- Veiklų apibrėžimas (angl. Activity Definition): identifikavimas specifinių veiklų, kurios

turi būti atliktos, kad būtų sukurti projekto darbo produktai.

- Veiklų sekų nustatymas (angl. Activity Sequencing): nustatyti ir dokumentuoti

priklausomybes tarp veiklų.

- Resursų veikloms vertinimas (angl. Activity Resource Estimating): kiekvienai veiklai

nustatyti pobūdį ir apimtis jau vykdyti reikalingų resursų.

- Veiklų trukmės vertinimas (angl. Activity Duration Estimating): kiekvienai veiklai

nustatyti, kiek laiko reikia jos įvykdymui.

- Tvarkaraščio sukūrimas (angl. Schedule Development): analizuoti veiklų sekas,

trukmes, resursų poreikius ir apribojimus tvarkaraščiui ir sudaryti projekto tvarkaraštį.

- Tvarkaraščio kontroliavimas (angl. Schedule Control): projekto tvarkaraščio

pasikeitimų kontroliavimas.

Projekto kainos valdymas Projekto kainos valdymas apima procesus, naudojamus kainos planavime, vertinime,

biudžetavime ir kontroliavime taip, kad projektas būtų įvykdytas su patvirtintu finansavimu:

- Kainos vertinimas (angl. Cost Estimating): įvertinimas resursų, reikalingų projekto

veikloms atlikti, kainos.

- Biudžeto sudarymas (angl. Cost Budgeting): agregavimas atskirų veiklų kainų įverčių

ir sudarymas projekto biudžeto (cost baseline).

- Kainos kontroliavimas (angl. Cost Control): įtakojimas faktorių, kurie sąlygoja

projekto kainos nukrypimus, ir kontroliavimas projekto biudžeto pasikeitimų.

Projekto kokybės valdymas Projekto kokybės valdymas apima visas organizacijas atliekamas veiklas, nustatant

kokybės politiką, tikslus ir atsakomybes taip, kad projektas patenkintų poreikius, kuriems jis

buvo skirtas. Tai kokybės valdymo sistemos įgyvendinimas, apibrėžiant politiką, procedūras ir

procesus kokybės planavimui, kokybės užtikrinimui, kokybės kontroliavimui ir nuolatiniam

proceso gerinimui.

Projekto kokybės valdymo procesai:

- Kokybės planavimas (angl. Quality Planning): nustatymas, kokie kokybės standartai

yra susiję su projektu ir kaip juos patenkinti.



- Kokybės užtikrinimas (angl. Perform Quality Assurance): taikymas planuotų

sistemingų kokybės veiklų, kad projekte vykdomi visi procesai, reikalingi

reikalavimams patenkinti.

- Kokybės kontroliavimas (angl. Perform Quality Control): stebėjimas specifinių

projekto rezultatų, kad nustatyti, ar jie atitinka susijusius kokybės standartus, ir

nustatymas būdų eliminavimui netinkamo vykdymo priežasčių.

Projekto žmogiškųjų resursų valdymas Projekto žmogiškųjų resursų valdymas apima projekto komandos organizavimo ir valdymo

procesus. Projekto komanda sudaryta iš asmenų, kuriems priskirtos rolės ir atsakomybės

projekte. Komandos nariai turėtų būti įtraukiami į projekto planavimą ir sprendimų priėmimą.

Projekto žmogiškųjų resursų valdymo procesai:

- Žmogiškųjų resursų planavimas (angl. Human Resource Planning): identifikavimas ir

dokumentavimas projekto rolių, atsakomybių ir atsiskaitomybių bei kadrų

komplektavimo valdymo plano sudarymas.

- Projekto komandos surinkimas (angl. Acquire Project Team): gavimas žmogiškųjų

resursų, reikalingų projektui vykdyti.

- Projekto komandos suformavimas (angl. Develop Project Team): pagerinimas

komandos narių kompetencijos ir tarpusavio bendravimo, kad padidinti darbo

efektyvumą.

- Projekto komandos valdymas (angl. Manage Project Team): komandos narių darbo

efektyvumo stebėjimas, grįžtamojo ryšio užtikrinimas, problemų sprendimas ir

pakeitimų koordinavimas, siekiant padidinti darbo efektyvumą.

Projekto komunikavimo valdymas Projekto komunikavimo valdymas apima procesus, užtikrinančius savalaikį ir tinkamą

projekto informacijos generavimą, surinkimą, paskirstymą, saugojimą, gavimą ir galutinį

„atsikratymą“. Šie procesai užtikrina kritinius ryšius tarp žmonių ir sėkmingam darbui

reikalingos informacijos. Projekto vadovas gali sugaišti neleistinai daug laiko komunikuodamas

su projekto komanda, suinteresuotais asmenimis, užsakovu ir sponsorium. Kiekvienas,

dalyvaujantis projekte, turi suprasti, kokį poveikį komunikavimas daro visam projektui.

Projekto komunikavimo valdymo procesai:

- Komunikavimo planavimas (angl. Communication Planning): nustatymas

suinteresuotų asmenų poreikių informacijai ir komunikavimui.

- Informacijos platinimas (angl. Information Distribution): užtikrinti, kad suinteresuoti

asmenys galėtų gauti reikalingą informaciją laiku.



- Informavimas apie eigą (angl. Performance Reporting): surinkimas ir paskleidimas

informacijos apie eigą (būsenos ataskaitos, progreso matavimas ir prognozavimas).

- Suinteresuotų asmenų valdymas (angl. Manage Stakeholders): komunikavimo

valdymas, siekiant patenkinti suinteresuotų asmenų reikalavimus ir išspręsti problemas.

Projekto rizikos valdymas Projekto rizikos valdymas apima procesus, susijusius su rizikos valdymo planavimu,

identifikavimu, analize, reagavimu, stebėjimu ir kontroliavimu. Rizikos valdymo tikslai yra

padidinti teigiamų įvykių tikimybes ir poveikį bei sumažinti neigiamų įvykių tikimybes ir

poveikį.

Projekto rizikos valdymo procesai:

- Rizikos valdymo planavimas (angl. Risk Management Planning): nuspręsti, kaip

planuoti ir vykdyti rizikos valdymą projekte.

- Rizikos identifikavimas (angl. Risk Identification): nustatyti, kokios rizikos gali

paveikti projektą ir dokumentuoti jų charakteristikas.

- Kokybinė rizikos analizė (angl. Qualitative Risk Analysis): rizikų prioritetizavimas,

nustatant jų įvykimo tikimybes ir 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ų

ir veiksmų padidinimui galimybių ir sumažinimui grėsmių projekto tikslams pasiekti.

- Rizikos stebėjimas ir kontroliavimas (angl. Risk Monitoring and Control): sekimas

identifikuotų rizikų, stebėjimas neišaiškintų rizikų, identifikavimas naujų rizikų,

vykdymas reagavimo į rizikas planų ir vertinimas jų efektyvumo.

Projekto įsigijimų valdymas Projekto įsigijimų valdymas apima procesus, skirtus pirkimui ar įsigijimui iš išorės

produktų, paslaugų ar rezultatų, reikalingų projekto komandai atlikti darbą. Nagrinėjamos abi

perspektyvos: organizacija gali būti arba pirkėjas, arba pardavėjas.

Projekto įsigijimų valdymas apima: sutarties valdymo ir pakeitimų kontroliavimo procesus,

naudojamus administravimui projekto komandos sudarytų sutarčių ar pirkimo dokumentų;

administravimą bet kokių išorinių organizacijų (pirkėjų) sudarytų sutarčių su projektą vykdančia

organizacija (pardavėju) ir administravimą sutartinių įsipareigojimų, už kurių įvykdymą

atsakinga projekto komanda.



Projekto įsigijimų valdymo procesai:

- Pirkimų ir įsigijimų planavimas (angl. Plan Purchases and Acquisitions): nustatymas,

ką pirkti ar įsigyti bei kada ir kaip tai padaryti.

- Sutarčių planavimas (angl. Plan Contracting): dokumentavimas reikalavimų

produktams, paslaugoms ir rezultatams ir identifikavimas potencialių pardavėjų.

- Informacijos iš pardavėjų gavimas (angl. Request Seller Responses): gavimas

informacijos, kainų, pasiūlymų.

- Tiekėjų pasirinkimas (angl. Select Sellers): pasiūlymų peržiūrėjimas, pasirinkimas tarp

potencialių pardavėjų, derybos ir pasirašymas sutarčių su tiekėjais.

- Sutarties administravimas (angl. Contract Administration): valdymas sutarties ir

santykių tarp pirkėjo ir pardavėjo, peržiūra ir dokumentavimas, kaip pardavėjas atlieka

ar atliko įsipareigojimus, nustatyti pataisas ir pagrindus tolimesniam bendravimui su

pardavėju, valdymas su sutartimi susijusių pakeitimų ir, kai aktualu, valdymas

sutartinių santykių su išoriniu projekto pirkėju.

- Sutarties uždarymas angl. (Contract Closure): užbaigimas ir sureguliavimas kiekvienos

sutarties, įskaitant išsprendimą atvirų problemų, uždarymas visų kontraktų, susijusių su

projektu ar projekto faze.


[PMI04] A Guide to Project Management Body of Knowledge (PMBOK Guide). Project

Management Institue, 2004.

(an American National Standard: ANSI/PMI 99-001-2004).

Programų sistemų inžinerija 12. Vadovavimas programų sistemų projektams


12. Vadovavimas programų sistemų projektams

Programų sistemų projekto lyderis

Lyderio tikslai Svarbiausias techninio lyderio vaidmuo yra nustatyti tikslus ir vesti, kad jie būtų pasiekti.

Pavyzdys su IMB 370 kompiuterio kūrimu: kaip tik tuo metu atsirado virtualios atminties

koncepcija ir būtent lyderiui reikėjo priimti sprendimą, ar reikia ją realizuoti kuriamame

kompiuteryje; situacija buvo labai neaiški, nes toks sprendimas atidėtų naujo kompiuterio

sukūrimą metams. Paprasčiausia buvo nieko nekeisti, bet buvo priimtas (iš perspektyvos žiūrint,

akivaizdžiai teisingas) sprendimas realizuoti virtualią atmintį

Lyderio įsitikinimas Jei lyderis priėmė sprendimą, jis turi vesti, kad įveikti visas kliūtis, ir kai jo žmonės jau

pasiruošę pasiduoti, jis turi vėl juos sutelkti dar vienam bandymui.

Pavyzdys su spalvotos televizijos standartu. 1950 m. iškilo klausimas, kokiu standartu bus

transliuojama spalvota TV JAV. Buvo 2 alternatyvos: jau egzistuojanti CBS mechaninė sistema

ir dar tik kuriama RCA trijų spalvų tūbos sistema. 1950 m. Valstybinė komisija priėmė nutarimą

nerizikuoti ir naudoti egzistuojančią CBS sistemą. Visi galvojo, kad trispalvė sistema jau mirusi,

bet projekto lyderis tikėjo, kad ši sistema tikrai geresnė, tęsė darbus ir 1953 m. po

demonstracijos ši sistema buvo patvirtinta.

Lyderiai ir jų pasekėjai Be pasekėjų lyderis neturi pakankamai jėgų. Lyderio jėga yra patraukti žmones, o valdymo

direktyvos riboja pasirinkimo laisvę. Galimybė valdyti yra ne tas pats kas galimybė vesti.

Lyderis turi rūpintis savo pasekėjais, t.y. galvoti apie žmones, jų poreikius ir viltis.

Rūpinimasis yra parodomas, pavyzdžiui, kai Napoleonas žinojo savo karių vardus, o Tomas

Vatsonas atsiminė savo fabriko darbininkų žmonas ir vaikus. Štai kodėl, pavyzdžiui, didieji

generolai atsisako leisti savo pajėgas į riziką, su kuria patys jie nesusidurtų. Kai lyderiai taip

elgiasi, žmonės jaučia tai ir pasiryžę sekti paskui juos bet kur.

Transformacinis lyderiavimas Vienas iš būdų sužadinti žmonių vaizduotę yra remtis jų svajonėmis ir ambicijomis.

Dauguma inžinierių ir mokslininkų siekia didybės ir 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 valandas

dirbo, kad sukurtų geriausią kompiuterį, kokį jie galėjo įsivaizduoti.



Įtikindami žmones pasišvęsti jų tikslo pasiekimui, lyderiai naudoja tai, ką Burns vadina

"transformaciniu lyderiavimu". Toks lyderiavimas yra naudingas visiems dalyvaujantiems.

Inžinieriai ir programuotojai gauna didžiulį vidinį pasitenkinimą, o kompanija puikiausią

produktą. Toks susijaudinimas yra tipiškas tokiems projektams kaip RCA trijų spalvų tūba ar

IBM 370 kompiuteris. Nevisi projektai turi šią savybę, bet nė vienas projektas negali būti toks

visą laiką. Kiekvienas inžinierius susiduria su mėnesiais rutininio darbo kiekvienai susijaudinimo

dienai, o tipinis mokslininkas metais ruošiasi kiekvienam atradimui. Henris Kisendžeris yra

pasakęs, kad lyderiavimas atsiranda "iš akumuliavimo niuansų, šimtų daiktų padarytų truputėlį

geriau".

Pareigybinis lyderiavimas Kiekvienas 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 ir kas skatinamas.

Darbuotojai žino, kad vadovo nuomonė yra svarbi, ir stengiasi būti vadovo mėgstami. Tačiau

vadovai retai naudoja šias savo galimybes tiesiogiai, jos glūdi už visko, ką jie daro.

Lyderiavimas, pagrįstas oficialia jėga, vadinamas pareigybiniu lyderiavimu. Jis suteikia

motyvaciją veiklai, bet tuo pačiu turi apribojimų. Pavyzdžiui, darbuotojai, besirūpindami savo

atlyginimu ir paskatinimu, gali stengtis daryti tai, ko bosas nori, o ne tai, ko reikia darbui. Be to,

jie nelinkę prieštarauti.

Kadangi inžinieriai ir mokslininkai turi profesinę garbę, dauguma trokšta atlikti darbą gerai

net, jei tai nėra vertinama. Pavyzdys kaip produkto vadovas išsaugojo svarbų spausdintuvo

projektą. Inžinieriai pasiūlė naują spausdintuvą, kuris pakeistų senesnį, tačiau senesni

spausdintuvai buvo labai pelningi, todėl finansiniai vadovai abejojo dėl pakeitimo projekto.

Inžinieriai kovojo su šiais finansiniais aspektais, bet greitai pasidavė ir nuėjo pas produkto

vadovą sutikimo nutraukti projektą. Jų nuostabai vadovas pasakė, kad jų darbas daryti geresnius

produktus ir, jei finansininkai nėra patenkinti, reikia juos patenkinti. Jis tikėjo, kad jiems

pasiseks. Grįžę inžinieriai sugebėjo parodyti finansininkams, kad jų mašinos techniniai

privalumai turi prasmę ir piniginiu požiūriu. Programa buvo baigta ir rezultatas buvo labai

sėkmingas produktas.

Produkto vadovas pasielgė kaip lyderis, bet jo poelgis buvo netradicinis. Tikri

profesionalai susigėdo, kai tapo aišku, kad jie nepavyko padaryti tai, ką turėjo, ir iššūkis

pabandyti dar kartą buvo didelis stimulas.

Kodėl inžinieriai neatliko savo darbo gerai iš pirmo karto? Daugumai žmonių reikia

periodinio paraginimo dirbti geriausiai. Technologijoje kiekvienai sėkmei tenka daug nesėkmių,

todėl lengva nusivilti. Pirmas kainos vertinimas visada per didelis, pradinis grafikas netikslus.

Kūrėjai, kurie per lengvai pasiduoda, niekada nepabaigs produkto, ir jų vadovai turi jausti tai ir



raginti stengtis labiau. Vadovai turi vesti, palaikyti, padėti, bet viso šito jie turi neleisti savo

žmonėms pasiduoti per anksti.

Lyderiavimas iš apačios Kiekvienas vadovas turi elgtis kaip lyderis, ar vadovautų didelei korporacijai ar dviems

žmonėms. Ir lyderio vaidmens svarba nepriklauso nuo organizacijos dydžio. Organizacija

negalės sėkmingai funkcionuoti, jei nebus lyderių visuose lygiuose.

Iš principo, lyderio vaidmuo nelabai priklauso nuo lygio, bet praktiškai yra vienas didžiulis

skirtumas: aukščiausi vadovai tipiškai suvokia poreikį imtis veiksmų, o žemiausi vadovai dažnai

paskęsta biurokratinių ir rutininių darbų jūroje. Todėl labai svarbu kūrybiškai žiūrėti į rutininius

darbus ir stengtis patobulinti jų atlikimą. Pavyzdys kaip viena žemiausio lygio vadovė sugebėjo

iš esmės pagerinti darbą.

Lyderio vizija Matyt, viena svarbiausių lyderio charakteristikų yra vizija. Tomas Vatsonas jaunesnysis

1950-aisiais matė kompiuterių svarbą ir, nepaisydamas kliūčių, suorientavo IBM į kompiuterių

sritį. Deja, 1970 nauji vadovai perėmė IBM. Jų vizija iš esmės buvo orientuota į finansinį IBM

augimą. Tai buvo tikrai pajėgūs vadovai, bet jie nepateikė principų, taip reikalingų kompanijai.

Šio vizijos trūkumo rezultatas buvo esminės klaidos ir 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, 1970

pabaigoje pabrėžiantis kompiuterių tinklų svarbą. Deja, į juos nebuvo tinkamai atsižvelgta.

Techninių profesionalų lyderis Lyderiui tenka didžiulė atsakomybė. Keletas patarimų lyderiams, pateiktų Lee Lacocca: jei

jūs krizėje, nėra laiko atlikti studijas; susirašykite ant popieriaus lapo 10 dalykų, kuriuos jūs

būtinai turite padaryti; visa kitą - pamirškite; mirties šešėlis verčia skubiai sutelkti dėmesį.

Lyderiai taip pat apibrėžia organizacijos tempą: boso greitis yra komandos greitis. Jūs

negalite visiems projektams suteikti nutrūktgalviško greičio, bet jei bosas atsipalaiduoja dienai ar

dviems, 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 ir lengvai. Kai žmonės jau pasirengę pasiduoti,

dažniausiai dar yra likę neišbandytų kelių. Lyderis turi paklausti: kokios yra nebandytos

alternatyvos, ar kas nors buvo susidūręs su čia problema anksčiau, su kuo iš ekspertų buvo

kontaktuota? Nuostabu, kaip dažnai techniniai žmonės randa kūrybinį sprendimą, kai bosas juos

paragina pabandyti dar kartą. Bokso čempionas yra pasakęs: pakovok dar vieną raundą tada, kai



jau atrodo, kad nebeturi jėgų, nebeklauso nei rankos, nei kojos, ir atsimink, kad žmogus, kuris

kovoja dar vieną raundą yra nesumušamas.

Įsipareigojimų etika

Humphrey pateikia pavyzdį, kaip jis pirmą kartą dalyvavo priimant sprendimą pradėti

naujos mašinos gamybą. Viskas buvo paruošta labai kruopščiai ir atrodė, kad patvirtinimas turėtų

būti tik formalumas. Bet užvirė labai aktyvus svarstymas, aibė detaliausių klausimų, kas labai

nustebino Humphrey. Tada vienas patyręs inžinierius jam paaiškino, kad šie žmonės pasiryžę

prisiimti įsipareigojimus, o kai jie tai padarys, "apvers žemę ir pragarą", kad šiuos įvykdyti, todėl

jiems reikia laiko, kad jaustųsi komfortabiliai.

Kai grupės žmonių daro bendrą produktą, reikalingas grafikas, paremtas abipusiais

susitarimais ar įsipareigojimais. Deja, žmonės retai daro tikslius vertinimus ir visada iškyla kas

nors netikėta, kas vėlina pabaigimą. Tada kiekvienas turi kautis, kad sutilpti į grafiką. Bet kodėl

kiekvienas kovoja vietoje to, kad susitaikyti su vėlavimu ir keikti blogą likimą? Skirtumas yra

požiūryje į įsipareigojimus.

Įsipareigojimų elementai Kai vienas žmogus sudaro paktą su kitu ir abu tikisi, kad jo bus laikomasi, tai ir vadinama

įsipareigojimu. Beveik viskas, ką daro inžinieriai ir mokslininkai, yra kažkuria prasme daroma

pirmą kartą. Kai žmonės dirba kartu stebinančioje aplinkoje, jie turi padėti vienas kitam; ir ši

pagalba turi remtis įsipareigojimų disciplina.

Motyvacija vykdyti įsipareigojimus yra daugiausia rezultatas būdo, kaip tie įsipareigojimai

prisiimami. Pirma, įsipareigojimas turi būti prisiimamas laisvai. Nors praktikoje įsipareigojimų

lankstumo laipsnis dažnai ribotas, žmogus turi jausti, kad turi kažkokį pasirinkimą. Net gavę

galimybę trumpai pasisakyti, paprieštarauti ar pasiūlyti pakeitimus, jie jausis surišti pažado tik

tada, kai jausis, kad davė jį savanoriškai.

Įsipareigojimo matomumas (viešumas) yra vienodai svarbus. Asmeniškas įsipareigojimas

stato 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 labai

atsiliko nuo grafiko ir tapo aišku, kad negalės būti baigtas laiku. Marketingo vadovybė labai

piktinosi ir 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ą jis

galėjo padaryti be didžiulio kompanijos nagrinėjimo, programuotojai neapsidžiaugė ir 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ę.



Atsakingų įsipareigojimų sudarymas Kitas reikalavimas atsakingiems įsipareigojimams yra pasiruošimas. Įsipareigojimas turėtų

būti pirmiausia aiškiai apibrėžtas ir įvertintas. Jei įtraukta keletas žmonių, jie visi turėtų dalyvauti

ir jų požiūriai turėtų būti kruopščiai aptarti. Supažindinti kiekvieną su darbu ir tuo, ko iš jo

tikimasi, reikalauja laiko, bet tai vienintelis būdas padėti tvirtus pamatus įsipareigojimui.

Po to seka pats susitarimas. Paprasčiausiu atveju dalyvauja 2 žmonės: vienas nori, kad

darbas būtų atliktas, o kitas potencialus atlikėjas. Abu nori paskatinimo ir ekonominio efekto, bet

jų 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 ir 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ų, ir nerašyta technologijos taisyklė sako, kad

visi 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 ir

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

savo 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 pigiu

banko spausdintuvu. Buvo nutarta panaudoti specialų plastikinį spausdinimo rato mechanizmą.

Iš pradžių viskas atrodė puiku, bet vis iškildavo įvairios problemos, kurios reikalavo

konstrukcijos patobulinimų, todėl galiausiai vietoj paprasto gavosi labai sudėtingas ir brangus

spausdintuvas, kuris nebeteko praktinės prasmės.

Inžinieriai taip stengėsi spręsti iškilusias problemas, kad pamiršo pradinį tikslą, aklai

bandydami įvykdyti duotus įsipareigojimus.

Įsipareigojimų hipnozė yra santykinai bendra problema. Žmonės įsitikinę, kad tai, ko jie

nori, kad įvyktų, turi įvykti. Pamatę, kad jų projektas akivaizdžiai neveikia, inžinieriai dažnai

padvigubina pastangas. Jie atrodo įsitikinę, kad truputį daugiau laiko ir dar vienas bandymas

išspręs šią paskutinę problemą.

Per griežti įsipareigojimai Vienas 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,



tikėdamiesi, kad tai apsaugos nuo planų pakeitimo. Kraštutinis atvejis buvo lėktuvo Konkord

kūrimo pradžioje. Sutartyje tarp Britanijos ir 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 punktas

padarė kiekvienos iš pusių pasitraukimą nepraktišku, nežiūrint į tolimesnes problemas, kadangi

iš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 prisiimti

neatšaukimus įsipareigojimus. Dažnai inžinieriai jaučia problemą ir stengiasi apsaugoti projektą

nuo nutraukimo.

Paprastai reikia stengtis įveikti visas kliūtis, bet kartais tai tik didina beviltiško nuotykio

kainą. Nevisi projektai gali būti sėkmingi, ir labiausiai įsitraukę inžinieriai paprastai paskutiniai

suvokia realybę. Dažnai reikalinga nepriklausoma priežiūra entuziazmo subalansavimui, nes

techninė komanda pati įstūmusi save į bėdą retai pati be pagalbos išsikapstys.

Vadovybės įsipareigojimai Pavyzdys iliustruojantis bendrą įsipareigojimų problemą. 1963 IBM turėjo pateikti

pasiūlymą Skrydžių kontrolės kompiuteriui. Atkakliai dirbdami, inžinieriai paruošė puikų

technologiškai pasiūlymą, bet nekonkurentabilų kainos ir laiko požiūriu. Klientas norėjo gauti

mašiną per 9 mėnesius ir buvo konkurentų, sutinkančių tai padaryti už 65 mln. $. Nors ir labai

stengdamiesi, IBM inžinieriai nesugebėjo kainos sumažinti mažiau nei iki 100 mln. $, o

geriausias grafikas 12 mėnesių ir tai su didele rizika.

Pardavimų vadovas manė, kad užsakymas bus prarastas, bet inžinieriai tikėjo, kad

užsakovas supras techninę pasiūlymo kokybę. Valdžia parėmė inžinierių poziciją ir liepė stengtis

parduoti 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 ir spaudžia inžinierius ir programuotojus. Grafikas

visada per ilgas, o kaina per aukšta. Kuo svarbesnis užsakymas, tuo didesnis spaudimas

sumažinti ir 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ės

pagerinti programą, bet kai jų idėjos išsenka, jie gali įsipareigoti atlikti tik tai, ką jie mano gali

atlikti. 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ų keitimas Kita 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,



tarpusavio 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 ir

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 pirmas apie tai prabilti. Štai tada vadovas turi

organizuoti visapusišką peržiūrą, kad išsiaiškinti realią padėtį. Be aiškaus einamosios situacijos

supratimo, nėra pagrindo naujo plano darymui.

Kruopštus darbo atlikimas Judy teisingai vadovavo, bet projektas susidūrė su nenumatytomis problemomis. Ji aptarė

su žmonėm padėtį ir suderino naują planą su betarpiškais vadovais. Po to nuėjo pas laboratorijos

direktorių, 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 ir pasakė, kad viena

kritinė funkcija buvo praleista ir prireiks daugiau laiko nei pagal naują grafiką. Judy buvo

šokiruota, bet prieš kažką darydama, sušaukė savo žmones peržiūrėti, ar dar kas nors nebuvo

praleista. Buvo rasti dar 2 punktai ir atitinkamai pakoreguotas grafikas. Kai ji pateikė tai

vyresniesiems vadovams, jie labai kritiškai žiūrėjo į šiuos pakeitimus, bet paaiškinus problemą ir

kas buvo padaryta, sutiko, kad pasirinkti teisingi veiksmai.

Įsipareigojimų etikos kūrimas Įsipareigojimas yra bendras susitarimas dviejų ar daugiau žmonių, kurie tiki, kad kiti jo

laikysis. IBM projekto vadovas suvokė, kad jo pavaldiniai nedirba kartu taip efektyviai kaip

galėtų. Problema buvo tarpusavio pasitikėjimas, todėl jis paprašė skyrių vadovus apibrėžti ir

dokumentuoti jų tarpusavio įsipareigojimus. Tam buvo skirti savaitiniai susitikimai ir visa

komanda sukūrė tikslų jų tarpusavio ryšių supratimą ir galėjo lengviau bendrauti. Tai sukūrė

pasitikėjimą būtiną efektyviai įsipareigojimų disciplinai.

Efektyvi valdymo komanda turi bendrauti atvirai ir laisvai. Šie susitarimai tarp skyrių

atvėrė bendravimą ir, kai jie pasitarnavo šiam tikslui, formalūs susitarimai tapo nebereikalingi.

Įsipareigojimų nuosavybė Žmogus prisiimantis įsipareigojimą turėtų jaustis atsakingu įvykdyti jį. Pavyzdys tai

parodo. Grupė buvo atsakinga už kokybės ataskaitų paruošimą. Duomenys buvo išmėtyti po

daugelį failų, be to, dažnai buvo atliekami specialūs tyrimai, todėl visa tai tekdavo daryti

rankomis ir 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ėms

paruošti pasiūlymą. Kadangi atliekamų žmonių nebuvo, tai jie suplanavo skirti dalį to paties



laiko, kurio ir taip trūkdavo. Kai jie nunešė planą direktoriui, buvo tikimasi, kad darbas užims

metus. Tačiau direktoriui reikėjo naujo operacijų plano kitą vasarą ir jis suprato, kad bazė būtų

labai naudinga. Bet iki vasaros buvo 9 mėnesiai ir jis buvo nelinkęs įsakyti šiai per daug užimtai

grupei sutrumpinti grafiką. Jis paaiškino, kodėl jam tai svarbu, ir paprašė padaryti, ką gali.

Visas skyrius įnirtingai dirbo kelis mėnesius ir atrado, kaip darbą galima padaryti žymiai

greičiau: jie rado egzistuojančią programą, atliekančią didelę dalį darbo. Jie didžiavosi, kad

išpildė direktoriaus prašymą.

Tai puikus įsipareigojimo pavyzdys. Direktorius įsitikino, kad žmonės supranta problemą,

ir prašė padaryti viską, ką gali. Jis nereikalavo, kad darbas būtų atliktas per 9 mėnesius, nes tai

būtų jo data, o ne žmonių. Tačiau nurodydamas tikslą ir prašydamas pagalbos, jis perdavė jiems

valdymą. Todėl jie jautėsi asmeniškai įsipareigoję padaryti viską, ką gali.


[Hum96] Watts S. Humphrey. Managing Technical People: Innovation, Teamwork, and the

Software Process. Addison-Wesley Professional, 1996.

Programų sistemų inžinerija 13. Profesiniai, teisiniai ir etiniai aspektai


13. Profesiniai, teisiniai ir etiniai aspektai

Profesija apibrėžiama kaip darbas, reikalaujantis išankstinio paruošimo. Kompiuterinių

informacinių sistemų vystymas ir bet koks darbas susijęs su IT taip pat yra profesijos.

Profesionalumas - tai dirbti taip, kad būtų patenkinti aukščiausi šiai profesinei grupei keliami

reikalavimai. Tokie reikalavimai užfiksuoti įvairių organizacijų profesinės etikos kodeksuose.

Informacinių sistemų profesijoms artimiausiai esančios organizacijos yra ACM (angl.

Association of Computing Machinery) ir DPMA (angl. Data Processing Management

Association). Abi šios organizacijos turi etiško elgesio kodeksus ir 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 neskelbti

neteisingų faktų apie esamą ar tikimąsi sistemos būklę; nepiktnaudžiauti konfidencialia ar

įmonės informacija; likti dėmesingais potencialiems konfliktams ir padėti juos spręsti;

2) stengtis pastoviai gerinti savo profesinę kompetenciją: kurti sistemas, kurios vykdytų

joms numatytas funkcijas ir patenkintų vartotojų poreikius; padėti savo kolegoms dirbti

profesionaliai;

3) prisiimti tik tuos įgaliojimus, kurie priimtinai padeda siekti kuriamos sistemos tikslų;

4) panaudoti savo profesines žinias visuomenės individų asmeniniam gyvenimui, sveikatai

ir bendrai gerovei gerinti: dirbdami su duomenimis, visada skaitytis su asmenų teise į asmeninį

gyvenimą; susilaikyti nuo dalyvavimo projekte, jei tai galėtų sukelti neigiamas pasekmes

visuomenei.

Atidžiai perskaičius šį kodeksą, galima pastebėti, kad į jį įeina tiek etikos, tiek

profesionalumo temos. Tam, kad atskirtume, kas yra etiškas elgesys ir kas yra profesinis elgesys,

pirmiausia turime apsibrėžti etikos terminus ir juos susieti su informacinių sistemų profesijomis.

Viskas, kas yra neetiška, yra ir neprofesionalu, bet ne atvirkščiai. Profesionalumas yra platesnė

tema negu etiškas elgesys. Anksčiau etikos kodeksai vadinosi profesinio elgesio kodeksai.

Temos apie etiką daugiausiai susijusios su vartotojais ir labiausiai akivaizdžios duomenų

surinkimo veiklose.

Taigi, kas yra etika? Etika - filosofijos šaka, studijuojanti moralinius sprendimus ir jų

pagrindimus. Dilema - situacija, reikalaujanti rinktis tarp dviejų alternatyvų su galimomis

nemaloniomis pasekmėmis. Taigi, etinė dilema yra situacija, kurioje sprendimas reikalauja

moralinio pagrindimo. IT pasirodymas organizacijose pateikia naujas, mažai suprantamas

galimybes neetiškam elgesiui, apie kurias retai diskutuojama.



Etika informacinėse technologijose - problema, kelianti vis didesnį susidomėjimą. IT

vartotojai ir kūrėjai kartais patenka į ypatingas aplinkybes, sukeliančias dilemas, kurio turi būti

gerai apgalvotos pasiekti etišką sprendimą. Viena iš problemų, susijusių su etika, yra ta, kad

etika yra suprantama kaip religinis auklėjimas ir religinių minčių pritaikymas realiam gyvenimui.

Tai nėra tiesa. Etiniai sprendimai ir pagrindimai yra paremti teisingumo ir naudingumo

filosofijomis, tai yra, didžiausiu gėriu didžiausiam skaičiui žmonių. Etika reikalauja alternatyvų

įvertinimo tikint žmonių lygybe ir kilnumu. Toliau aptarsime etiką, susijusią su duomenų

rinkimų ir vartotojo sąveiką su programų kūrimu.

Pagrindiniai etiniai principai

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

skleisite konfidencialią informaciją (“nešite šiukšles iš namų”), jūs ne tik neetiškai elgsitės,

tačiau dėl to gali nukentėti ir 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ų ir kiti. Jam leidus,

konfidencialumo ribos yra pašalinamos, ir 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 laisvai

galite (ir turite) pranešti apie bet kokią nelegalią veiklą vadovams, kompanijos valdžiai ar net

policijai, jei nesiimama jokių priemonių. Pagal įstatymus, jei jūs apie tai nepranešate, tampate

nusikaltimo bendrininku.

Slaptumas. Ekspertai turi teisę žinoti apie jų patirties ir žinių panaudojimą programų

kūrime. Pagrindinė taisyklė - elgtis taip, kaip norėtum, kad būtų elgiamasi su tavimi. Ar

norėtumėte, kad kompanija stebėtų jūsų kompiuterių vartojimą ir kurtų sistemas, paremtas jūsų

patirtimi? Ypač daug etikos problemų dėl ekspertizių nuosavybės iškyla, kuriant ekspertines

sistemas. Be leidimo negali būti jokių tyrimų ir 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 priklauso

kompiuteriai, taip pat priklauso ir darbo su kompiuteriu laikas. Tačiau dažniausiai žmonės linkę

manyti, kad jei resursas neišnaudotas, jis iššvaistytas veltui, ir kad kompiuterių laikas yra kaip

oras, tai yra, laisvas resursas, kuris skirtas tam, kad jį naudotum. Vykdomoji valdžia dažniausiai

nemano taip pat, nežiūrint ar yra kokia nors kompiuterinių resursų naudojimo politika.

Reikėtų sužinoti kompanijos nuostatas apie kompiuterinių resursų naudojimą asmeninėms

reikmėms ir 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 vadovai

apie jiems priklausančių kompiuterinių resursų naudojimą.



Turi būti aiškiai išsakyta, kam priklauso susiję su darbu produktai, kad jei jūs manote, kad

kažkas teisėtai priklauso jums, taip pat mano ir klientas ar kompanija, taigi jūs nepasielgsite

neetiškai tai panaudodami. Painiavos dėl nuosavybės gali kilti dėl tokių dalykų kaip techninė ar

vartotojo dokumentacija, duomenys, programos išeities tekstai. Jei jūs dirbate kokioje nors

firmoje ir kuriate programą pagal užsakymą, jūs neturite teisės jos parduoti kokiai nors kitai

firmai. Ši teisė yra svarstytina ir priklauso tik klientui, jei nėra pabrėžtinai paminėta kontrakte.

Išsiaiškinkite viską ir jums neteks būti atleistam iš darbo ar patrauktam į teismą dėl nuosavybės

teisių pažeidinėjimo.

Patirtis, kurią įgaunate dirbdami, yra intelektualinis turtas. Tai yra jūsų, nebent jūs

pasirašote tai paneigiantį kontraktą. Tačiau neetiška naudoti specifines jūsų kompanijos žinias

asmeniniams, konkurentiniams ar nekonkurentiniams finansiniams tikslams, jei nesate susitarę

su savo darbdaviu dėl tokio panaudojimo. Paprastai darbdaviai reikalauja neskleisti firmos

patentuotos informacijos, tačiau kiekvienas gali skirtingai suprasti, kas būtent priklauso tokiai

informacijai. 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ų atvirai išsiaiškinti tokias problemas, kad

vėliau nekiltų jokių konfliktų.

Politika. Pasistenkite niekada neįsivelti į politines kovas. Tai lengviau nei atrodo, ypač jei

jūs esate programų sistemų inžinierius ar projekto vadovas. Politika - valdžios mokslas,

dažniausiai priklausantis nuo asmeninių motyvų. Organizacijose dauguma žmonių galvoja apie

firmos interesus darydami sprendimus, kiekvienas asmuo bent jau apsvarsto savo asmeninę

situaciją. Kai kurie asmenys pirmiausia siekia asmeninio pagerėjimo, net jei tai daro žalą

kompanijai. Didelis savanaudiškumas nepaisant rezultatų kitiems asmenims ar kompanijai yra

neetiška.

Politinėse kovose kai kurie asmenys stengiasi manipuliuoti projekto rezultatais, siekdami

pagerinti savo padėtį kompanijoje. Politiniai manevrai gali įgyti įvairias formas: melavimas,

dirbtiniai reikalavimai, apgaulingas bendradarbiavimas ar skirtingos viešos ir privačios kalbos.

PS inžinierius arba projekto vadovas turėtų atidžiai stebėti tokius pasireiškimus ir išmokti juos

išsklaidyti.

Informavimas apie problemas. Su klientu reikia aptarinėti susijusias su projekto

vykdymo tvarkaraščiu, biudžetu ar teisingumu bei kitas svarbias problemas, tačiau jo nereikia

jaudinti smulkiomis problemomis, kurias galite išspręsti pats. Sprendžiant, kada informuoti

vartotoją apie problemas, reikėtų vadovautis sveiku protu. Vartotoją apie problemą reikia įspėti

pakankamai anksti, kad žinotų, ir pakankamai vėlai, kad nebūtų jaudinamasi dėl niekų. Niekada

nelaukite paskutinės minutės, kai nebebus nieko galima pataisyti, arba visi projekto dalyviai

praras pasitikėjimą. Visada paprašykite kliento pagalbos problemos sprendime, jei jau juos



informavote. Savaitinių susirinkimų tikslas yra įvertinti projekto būklę ir nustatyti problemas ir

numatyti jų sprendimus. Jei problema egzistuoja kelis mėnesius be jokio jos sprendimo, ji visada

sukels plano ir biudžeto problemas. Jei klientas pastoviai informuojamas apie technines

problemas, jisai taip netiesiogiai paruošiamas potencialiems kainos kilimams ir laiko

užtęsimams. Apie projekto problemas turi būti informuojami ir visi projekto dalyviai.

Asmeniniai metodai ir atsakomybė. Kai žmonės dirba bendrame projekte, jie kartais

praranda 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 ir projekto vadovo uždavinių yra kiekvienam projekto

dalyviui išugdyti atsakomybės jausmą. Kiekvienas asmuo turėtų žinoti savo užduotis, biudžetą,

skirtus resursus ir savo laiką. Kiekvienas turėtų būti atsakingas už savo terminus ir programas be

klaidų. Atskaitomybę bendrame projekte lengva perkelti, ir pasidaro neaišku, kas yra atsakingas.

Vieni sako, kad visada atsakingas projekto vadovas. Kiti - kad analitikai ir PS inžinieriai. Dar

kiti - kad niekas neatsakingas. Trumpas atsakymas yra toks, kad kiekvienas asmuo yra atsakingas

už nuosavą darbą ir jo integravimą į visą projektą.

Nekalbėkite su savo vadovu, klientu ar darbuotojais apie darbo problemas nesusijusias su

projekto užbaigimu. Vadovai ir klientai nori atsakymų ir sprendimų, o ne problemų. Todėl jie

turėtų būti informuojami apie projekto būklę ir problemas, kurios gali juos paveikti, o kitais

atvejais palikite juos ramybėje. Vadovų nedomina, kaip kokia nors spausdintoja ar dar kas nors

žlugdo jūsų darbą. Jūs tai išsiaiškinkite ir pamirškite. Jei yra problemų su kieno nors darbo

kokybe, pirmiausia aiškinkitės su tuo žmogumi, ir tik tada, jei nepasiseka, kalbėkite su jų

vadovu. Kuo mažiau jūs kaltinsite ir kuo konkretesnis būsite, tuo mažiau atrodysite kaip

verkšlentojas ir skundikas. Būkite tikras, kad galite paremti bet kuriuos jūsų pareikštus

kaltinimus.

Neetiška pasakoti klientui ar vadovui apie savo asmenines problemas, jei jūsų nesieja

asmeniniai ryšiai, nes visa kaltė visada gali būti suversta asmeninėms problemoms (“Never

complain, never explain”, Henry Ford). Jūsų pareiga darbe - dirbti, taigi taip ir darykite.

Neužmegzkite asmeninių ryšių su klientu. Jei pradeda megztis emocinis ryšys, tegu tai

palaukia iki projekto pabaigos. Asmeniniai ryšiai lengvai užsimezga, kai esate kartu 10-15

valandų per dieną daug mėnesių iš eilės. Jie taip pat lengvai linkę iširti, kai tik prasideda naujas

projektas ir pradedama su kitais dirbti 10-15 valandų per dieną. Asmeniniai ryšiai temdo

sprendimus ir jiems ne vieta įstaigoje.

Niekada sąmoningai neklaidinkite kitų. Niekada nemeluokite. Nesuteikite vartotojui

klaidingų į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ą



jūs ir vadovai jiems sakote. Nepervertinkite sistemos galimybių. Tačiau, jei sistema kartais yra

nuvertinama, nepalikite klaidingų vilčių žmonėms, kad jų darbo vietos bus išsaugotos, jei žinote,

kad taip nebus. Nekelkite aliarmo, bet ir nesuteikite neteisingų vilčių.

Etinis sprendimų pagrindimas

Jei jūs susiduriate su problema, reikalaujančia etinio pagrindimo, reikia nustatyti visas

suinteresuotas puses (t.y. asmenis, galinčius turėti arba žalos, arba naudos, priklausomai nuo

sprendimo), įvertinti visus galimus veiksmus ir pagrįsti visas alternatyvas. Čia pateikiamas

vienas iš tokių metodų, bandantis atspindėti žmogaus mąstymą, sprendžiant problemas.

Suinteresuotų pusių nustatymas. Pirmiausia reikia nustatyti visus asmenis, galinčius

nukentėti arba pasipelnyti nuo jūsų sprendimo. Tai nelengva užduotis, ypač kai naudojami

kompiuteriai, jūs galite nepažinoti visų tokių žmonių asmeniškai. Tai gali būti kompanijos

akcininkai, kompanija, jūsų viršininkas, jūs, vartotojai, visuomenė ar žmonės, turintys kokį nors

kontaktą su kuriama programa (pvz., ligoninės pacientai, asmenys, gyvenantys šalia gamyklos,

kurioje bus pradėta vykdyti programa, ataskaitų vartotojai, el. pašto adresatai, vyriausybė ir t.t.).

Priimtinų veiksmų kiekvienai suinteresuotai pusei nustatymas. Dabar kiekvienai

suinteresuotai 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 geriausias

sprendimas? Atsakykite į šiuos klausimus nuo kiekvienos suinteresuotų asmenų grupės.

Pabandymas įsivaizduoti save kiekvieno iš jų vietoje reikalauja objektyvumo ir gebėjimo

paž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. Visada

atsižvelkite į šalies, kurioje esate, ir šalies, kurią atstovaujate, įstatymus.

Kompanijų veiklos procedūros ir normos (“procedures and policies”) yra panašūs elgesio

kodeksuose, bet gali skirtis griežtumu, baudžiant už pažeidimus. Už rimtus pažeidimus

daž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 ir 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šą, pateikdami

klausimus, reiškiančius neigiamus pasirinkimo rezultatus. Jei į bent vieną iš tų klausimų

atsakysite “taip” (teigiamai), išbraukite tą alternatyvą iš sąrašo. Pavyzdžiui.: Ar šiuo veiksmu

pažeidžiamos kieno nors teisės? Apsvarstykite teises į asmeninį gyvenimą, turėjimą informacijos

apie kieno nors pirkimo, mokėjimo būdus, pajamas, mokesčius ir panašiai. Apsvarstykite



kompanijos teises į finansinę, klientų, personalo, medicininę ir 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žkirstas.

Ar šiuo veiksmu nesielgiama neteisingai su asmeniu ar grupe? Tarptautinėse kompanijose

neteisingumas 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 kaip

prastesnės kokybės, tai problemos nebuvo. Jei buvo teigiama, kad tai aukščiausios kokybės

daiktai, kompanijos melavo ir 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ščiausios

kokybės, kad būtų mažiausiai rizikuojama žmonių gyvybėmis. Jei yra nukertami kampai

analizuojant, projektuojant ar testuojant, gali būti prarandami žmonės.

Teigiamų rezultatų alternatyvų įvertinimas. Likusioms alternatyvoms pateikite

klausimus apie teigiamus rezultatus ir išsirinkite geriausią. Ar šis veiksmas geriausiai veiks visus

suinteresuotus asmenis? O kas bus, jei nesiimsite jokių veiksmų? Jei yra alternatyvos tik su

neigiamais rezultatais, ar ši alternatyva visiems sukelia mažiausiai žalos? Jei taip, kas nukenčia ir

kaip? Jei asmuo yra įspėjamas, ar gali problema būti pašalinta?

Tinkamiausio veiksmo pasirinkimas. Kai apsvarstyti visi pliusai ir minusai, pasirinkite

alternatyvą, kuri suteikia naudos daugiausiai žmonių, nepažeidžia niekieno teisių ir siūlo

teisingiausią sprendimą.

Teisiniai programų sistemų inžinerijos aspektai

Teisiniai veiksniai turi didelę įtaką ir kuriamai programų sistemai, ir jos kūrimo projektui.

Įstatymai, vyriausybės nutarimai, organizacijų statutai ir kiti normatyviniai dokumentai nustato

funkcijas, kurios gali būti kompiuterizuojamos, ir duomenis, kurie gali būti renkami bei

kaupiami, daro poveikį duomenų rinkimo ir saugojimo technologijai, duomenų bazių struktūrai

bei tų bazių valdymo tvarkai, rezultatų pateikimo formai, techninės įrangos parinkimui, sistemos

diegimui ir projekto valdymui. Galimos teisinės rizikos veiksniai taip pat yra esminiai.

Technologinių procesų valdymo sistemų, bankų kompiuterizavimo sistemų ir daugelio kitų

sistemų padaryta žala gali būti gana didelė. Be to, ji gali būti siejama su baudžiamąja

atsakomybe. Todėl kuriant svarbias programų sistemas, reikia pasitarti su patyrusiu juristu,

nustatyti ir išnagrinėti visus teisinės rizikos veiksnius ir numatyti atitinkamas apsaugos

priemones.



Formuluojant funkcinius programų sistemų reikalavimus, būtina atsižvelgti į konstitucinį

įstatymų leidžiamosios, vykdomosios ir teisminės valdžių atskyrimo principą. Įstatymai nustato

kiekvienos institucijos kompetencijos ribas, t.y. nustato, ką ta institucija gali daryti ir ko ne.

Valstybinės ir savivaldos institucijos turi tik tuos įgaliojimus, kurie joms yra deleguoti. Privačios

institucijos negali užsiimti veikla, nenumatyta jų įstatuose. Institucijose naudojamos programų

sistemos negali tų apribojimų pažeisti. Tai liečia ir renkamus, apdorojamus bei platinamus

duomenis, ir sistemos vykdomas funkcijas. Teismas, nustatęs, kad institucija, naudodama tam

tikrą programų sistemą, viršija savo įgaliojimus, gali sustabdyti tos institucijos veiklą arba

pripažinti tą veiklą nekonstitucine.

Formuluojant funkcinius reikalavimus, būtina atsižvelgti ir į 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. Kitas

pavyzdys - asmens duomenų apsaugos ir mokesčių įstatymai. Dėl jų gali tekti skaidyti į dalis

kuriamas duomenų bazes, kartais net ir pačias sistemas. Asmens duomenų apsaugos reikalavimai

riboja spausdinamų duomenų apimtį ir turinį, reglamentuoja duomenų rinkimo būdus ir 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 susirgimus

ir sužalojimus kompiuterinio apdorojimo būdus.

Mokesčių ir kiti su jais susiję įstatymai nustato pelno kontrolės procedūras ir finansinės bei

buhalterinės apskaitos vedimo taisykles. Tos taisyklės yra privalomos ir 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ą ir saugojimo formatą. Reikalaujama numatyti

sistemoje audito trasas, dokumentuoti sistemą tam tikru nurodytu būdu, archyvuoti tam tikrus

nurodytus duomenis. Teisiniai reikalavimai turi didelę įtaką ir rezultatų pateikimo pavidalui. Kai

kurių dokumentų forma yra griežtai nustatyta, į kitus dokumentus reikalaujama rašyti tik tam

tikrus 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 ir galima patikrinti

dokumento parengimo vietą, laiką ir jam rengti naudotus šaltinius. Tokio dokumento

patikimumas gali priklausyti nuo programų sistemos apsaugos mechanizmo ypatumų ir

veiksmingumo.

Pažymėsime, kad programų sistemos dokumentacija yra svarbi ir baudžiamosios

atsakomybės požiūriu. Jei naudojant programų sistemą padaroma žala, tenka aiškintis, kas yra



kaltas: 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 ir telekomunikacijų bei ryšių įstatymai.

Duomenų perdavimo maršrutai, tarifai ir kiti panašaus pobūdžio veiksniai lemia daugelį

programų sistemos reikalavimų.

Reikia atsižvelgti ir į 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 arba

jų kitimo tendencijas. Niekam negali būti prieinama statistinė ar analitinė informacija, galinti

paveikti kainas.

Čia aptarėme tik pačius bendriausius teisinius aspektus. Kadangi normatyviniai

dokumentai kiekvienai dalykinei sričiai yra kiti, tai teisiniai veiksniai kiekvienai dalykinei sričiai

taip pat skiriasi.


[IEEE99] Software Engineering Code of Ethics and Professional Practice as recommended

by the IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and

Professional Practices. http://seeri.etsu.edu/Codes/TheSECode.htm

[ACM92] ACM Code of Ethics and Professional Conduct, Adopted by ACM Council

10/16/92. http://www.acm.org/about/code-of-ethics

Programų sistemų inžinerija Kontroliniai klausimai


Programų sistemų inžinerijos kontrolinių klausimų pavyzdžiai

1. 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) ir programų sistemų inžineriją

(software engineering).

3. Išvardinkite programinės įrangos gyvavimo ciklo procesų kategorijas, apibrėžtas

ISO/IEC 12207

4. 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 15504

rezultatas?

6. Nurodykite pakopinių ir tolydinių programų kūrimo procesų modelių pliusus ir minusus

7. Organizacija įvertinta 5-u lygiu pagal CMMI pakopinį modelį. Koks bus jos įvertinimas

pagal CMMI tolydinį modelį ir kodėl?

8. Kokias pagrindines (bazines) metrikas naudoja PSP?

9. Kam TSP naudojamas uždirbtos vertės (earned value) metodas? Paaiškinkite jo esmę.

10. Pateikite judriųjų programų sistemų kūrimo metodikų manifeste (Agile Software

Development Manifesto) suformuluotus principus

11. Pateikite XP (eXtreme Programming) praktikas

12. 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 skirtumas tarp baltos dėžės (white box) ir 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 (kokia

gali būti naudojama notacija)?

20. Kokiais kriterijais remiantis prioritetizuojamos rizikos?

Documents

Program ų sistem ų inžinerija - mif.vu.ltragaisis/PSI_mag2007/PSI.pdf · Standartas ISO/IEC 15504 ... Scrum ... t.y. pagal Lietuvoje naudojam ą moksl ų klasifikacij ą ji apima