PROGRAMŲ SISTEMŲ ĮSIGIJIMAS IR PRIEŽIŪRAvalund/KONSPEKTAI/PS isigijimas... · 2010-01-29 · įsigijimo projekte. Dar daugiau, įsigijimų tvarka, tinkanti medžiagų įsigijimo

EUROPOS SĄJUNGA Europos socialinis fondas

KURKIME ATEITĮ DRAUGE!

Valdas UNDZĖNAS

http://www.mif.vu.lt/~valund

PROGRAMŲ SISTEMŲ

ĮSIGIJIMAS IR PRIEŽIŪRA

Mokymo medžiaga

Vilnius 2007

Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007

2

Mokymo medžiaga parengta įgyvendinant 2004-2006 metų bendrojo

programavimo dokumento 2.5 priemonės „Žmogiškųjų išteklių kokybės gerinimas

mokslinių tyrimų ir inovacijų srityje” projektą „Programų sistemų magistrantūros

įsteigimas”. Projektas finansuotas Europos Sąjungos struktūrinių fondų ir Lietuvos

Respublikos bendrojo finansavimo lėšomis.


3

Turinys

I dalis. PROGRAMŲ SISTEMŲ ĮSIGIJIMAS...............................................................5 Įvadas ..............................................................................................................................5 1. Programinės įrangos ( PĮ ) ypatumai ........................................................................8 2. PĮ įsigijimo platesnis kontekstas .............................................................................10 3. Skirtingi požiūriai į PĮ įsigijimo procesą.................................................................12 4. PĮ tipai ......................................................................................................................16 5. PĮ įsigijimo nuostatos...............................................................................................17 6. Įsigijimo veiklų seka ................................................................................................25 7. Darbuotojų grupės PĮ įsigyti sudarymas.................................................................32 8. Įsigijimo projekto planavimas .................................................................................36 9. Įsigyjamos PĮ reikalavimai ......................................................................................39 9.1. Reikalavimų rengimas.................................................................................................. 39

9.2. Reikalavimų valdymas (peržiūra, keitimas)................................................................. 50

10. Kurti naują ar pirkti gatavą PĮ? ..............................................................................62 11. Įsigijimo sandorių sudarymas.................................................................................68 12. PĮ naudojimo aplinkos apibrėžimas ......................................................................79 13. Autorinių ir nuosavybės teisių klausimo sprendimas............................................82 14. PĮ įsigijimo projekto darbų grafiko sudarymas ......................................................87 15. Įsigyjamos PĮ testavimas ........................................................................................94 16. Darbuotojų mokymas, PĮ naudojimas ir priežiūra ...............................................104 17. Įsigijimo projekto valdymas..................................................................................112 18. PĮ konfigūracijos valdymas...................................................................................121 19. PĮ įsigijimo rizikos valdymas................................................................................125 1 priedas. Organizacijų gebėjimas vykdyti PĮ įsigijimo projektus. SA-CMM modelis....130 2 priedas. ISO/IEC standartų nuostatos............................................................................ 134

P2.1. PĮ gyvavimo ciklas......................................................................................134 P2.2. Visas PĮ įsigijimo procesas.........................................................................135 P2.3. PĮ įsigijimo veiklų apibūdinimas ...............................................................136 P2.4. Įsigijimo proceso inicijavimas....................................................................142 P2.5. Rengimasis viešiesiems pirkimams ...........................................................143 P2.6. PĮ tiekėjo išrinkimas ir sandorio sudarymas..............................................144 P2.7. PĮ tiekėjo darbo priežiūra ...........................................................................145 P2.8. PĮ priėmimas ir įsigijimo proceso užbaigimas...........................................145

Santrumpos .................................................................................................................147 Šaltiniai .......................................................................................................................148


4

II dalis. PROGRAMŲ SISTEMŲ PRIEŽIŪRA........................................................150 Įvadas ..........................................................................................................................150 1. PĮ priežiūros pagrindai ...........................................................................................152

1.1. Apibrėžimai ir terminai.................................................................................152 1.2. PĮ priežiūros esmė ........................................................................................152 1.3. Priežiūros poreikis ........................................................................................153 1.4. Pagrindinės priežiūros išlaidos ....................................................................153 1.5. PĮ plėtra.........................................................................................................154 1.6. Priežiūros darbų kategorijos.........................................................................154

2. Pagrindiniai PĮ priežiūros klausimai......................................................................155 2.1. Techniškieji priežiūros klausimai ................................................................155 2.2. Priežiūros valdymo klausimai ......................................................................157 2.3. Išlaidų PĮ priežiūrai įvertinimas...................................................................158 2.4. PĮ priežiūros įvertinimas ..............................................................................158

3. PĮ priežiūros procesas.............................................................................................160 3.1. Priežiūros procesai........................................................................................160 3.2. Priežiūros veiklos ..........................................................................................161

4. Priežiūros gerinimo būdai ......................................................................................164 4.1. Programų suprantamumo gerinimas ...........................................................164 4.2. Reinžinerija ...................................................................................................164 4.3. Atvirkščioji inžinerija ....................................................................................164

Šaltiniai .......................................................................................................................165


5

I dalis. PROGRAMŲ SISTEMŲ ĮSIGIJIMAS

Įvadas

Šios mokymo medžiagos paskirtis supažindinti skaitytojus su veiksmais, kurių

turėtų imtis organizacijos, norėdamos įsigyti programinę įrangą ar programų sistemą

(toliau - PĮ). „Įsigyti“ reiškia, kad gali būti kuriama nauja arba perkama jau gatava,

poreikius atitinkanti PĮ. Žinių apie PĮ įsigijimą gali prireikti įvairių organizacijų

vadovams, projektų vykdytojams, techniniams darbuotojams, siekiantiems pagerinti

savo organizacijos veiklą informacinių technologijų priemonėmis.

Sudėtingos PĮ įsigijimas yra nemenkas rūpestis. Viešojo ir privačiojo sektorių

atstovai dažnai susiduria su įvairiais sunkumais, įsigydami naują arba

eksploatuodami turimą PĮ.

Organizacijoms iškylančių PĮ įsigijimo, naudojimo ir priežiūros klausimų

sprendimus galima rasti knygose apie PĮ inžineriją. Tačiau lietuviškų knygų šia

tema yra labai mažai.

Šioje mokymo medžiagoje visų pirma apibūdinama PĮ, aprašomi jos įsigijimo

pagrindai, problema, taip pat parodoma, kuo PĮ įsigijimas skiriasi nuo kitokių

objektų įsigijimo. Kituose skyriuose aprašomi specifiniai PĮ įsigijimo klausimai.

1 skyriuje „PĮ ypatumai“ parodoma, kad PĮ labai skiriasi nuo kitokio tipo

objektų (pvz., mašinų, pastatų, medžiagų, kt.). Skaitytojų dėmesys atkreipiamas į tai,

kad PĮ atveju reikalingas visai kitoks požiūris į įsigijimo procesą.

2 skyriuje „PĮ įsigijimo platesnis kontekstas“ atkreipiamas dėmesys į tai, kad

PĮ yra sudėtingesnės sistemos dalis. Jei PĮ įsigijimo etapas buvo sėkmingas, visa

sistema tampa veiksminga ir efektyvesnė.

3 skyriuje „Skirtingi požiūriai į PĮ įsigijimo procesą“ parodoma, kad yra

didelis užsakovų ir tiekėjų požiūrių į PĮ įsigijimo procesą skirtumas. Didžioji dalis

nesutarimų tarp šių šalių gali būti pašalinta išsiaiškinus jų argumentus, abejones.

4 skyriuje „PĮ sistemų tipai“ supažindinama su PĮ klasifikacija. PĮ reikalinga

ne tik mūsų kasdieniniuose kompiuteriuose, bet ir kitokioje įrangoje, kaip transporto

priemonės (pvz., automobiliai, lėktuvai, laivai), medicininė įranga (pvz.,

kardiografai, tomografai), vaizdo ir garso aparatūra, kt. Jos tipai priklauso nuo

naudojimo aplinkos, paplitimo, jai keliamų reikalavimų.

5 skyrius „PĮ įsigijimo nuostatos“ supažindinama su nuostatomis, kurios turi

įtakos sėkmingam PĮ įsigijimui. Jos yra aktualios įvairiuose įsigijimo proceso

etapuose.


6

6 skyriuje „Įsigijimo veiklų seka“ apžvelgiamos veiklos ir parodoma, kad

negali būti vieno veiksmų plano visiems įsigijimams.

7 skyriuje „Darbuotojų grupės PĮ įsigyti sudarymas“ aptariamas atitinkamos

darbuotojų grupės sudarymo klausimas. Tai turėtų būti atliekama PĮ įsigijimo

projekto pradžioje, suteikiant šiems darbuotojams atitinkamus įgaliojimus.

8 skyriuje „Įsigijimo proceso planavimas“ nagrinėjamas įsigijimo plano

rengimas. Netgi tos veiklos, kurios bus atliekamos tik PĮ įsigijimo proceso pabaigoje,

turi būti įtrauktos į šį planą. Planas padeda koordinuoti visų įsigijimo grupės narių

veiksmus siekiant tikslo.

9 skyrius „Įsigyjamos PĮ reikalavimai“ yra padalintas į dvi dalis: reikalavimų

rengimą ir reikalavimų valdymą. Reikalavimų rengimas baigiasi atitinkamo

dokumento parengimu. Tačiau tuo dėmesys jiems neturi baigtis. Tvarkyti

reikalavimus tenka viso PĮ įsigijimo proceso eigoje. Nukrypimo nuo reikalavimų turi

būti vengiama, tačiau tuo pačiu metu jie neturėtų būti įšaldyti. Nors PĮ reikalavimų

valdymo klausimai nagrinėjami ir 17-19 skyriuose, metodiniais sumetimais tai

daroma ir šiame skyriuje.

10 skyriuje „Kurti naują ar pirkti gatavą PĮ?“ atkreipiamas dėmesys į gatavos

komercinės PĮ (COTS – Commercial Of The Shelf, komercinė nuo lentynos)

naudojimą vietoje to, kad kurtume savo unikalią PĮ. Tai, žinoma, nėra visų PĮ

įsigijimo problemų sprendimo būdas, tačiau dažnai yra labiau apsimokantis.

11 skyriuje „Įsigijimo sandorių sudarymas“ pristatomos įvairaus tipo sandorių

su tiekėjais (pardavėjais arba kūrėjais) galimybės ir jų tinkamumas PĮ įsigyti.

12 skyriuje „PĮ naudojimo aplinkos apibrėžimas“ nagrinėjama PĮ aparatinė,

programinė, telekomunikacinė ir kitokia aplinka, kuri turi būti apibrėžta sudarant

sandorius su tiekėjais.

13 skyrius „Autorinių ir nuosavybės teisių klausimo sprendimas“ skirtas

klausimams, kas ir kokias teises įgyja į sukurtą PĮ.

14 skyriuje „PĮ įsigijimo projekto darbų grafiko sudarymas“ parodoma, kaip

bendromis užsakovo ir tiekėjo pastangomis įsigijimo proceso planą reikėtų paversti

realiu ir įgyvendinamu darbų grafiku.

15 skyriuje „Įsigyjamos PĮ testavimas“ aiškinama, kaip užsakovas ir tiekėjas

nešališkai turėtų nuspręsti, kad PĮ jau yra tinkamai parengta naudoti.

16 skyriuje „Darbuotojų mokymas, PĮ naudojimas ir priežiūra“ nagrinėjamos

trys svarbios veiklos, kurioms sunaudojama didesnė PĮ gyvavimo ciklo biudžeto

dalis.


7

17 skyriaus „Įsigijimo projekto valdymas“ akcentas yra tas, kaip reikėtų siekti

aiškaus supratimo apie PĮ įsigijimo projektą ir ką reikėtų daryti, jei nukrypstama nuo

darbų grafiko. Taip pat nagrinėjami kokybės užtikrinimo klausimai, kad įsigyta PĮ

būtų patikima ir būtų patogu ją prižiūrėti.

18 skyriuje „PĮ konfigūracijos valdymas“ nagrinėjami PĮ konfigūracijos

valdymo bei PĮ funkcijų ir parametrų nustatymo veiklos. Be šių veiklų įvairios

įsigijimo proceso dalys greitai gali pasidaryti nesuderintos.

19 skyriuje „PĮ įsigijimo rizikos valdymas“ įvardinama PĮ įsigijimo rizika ir

kaip reikėtų valdyti ją, kad būtų išvengta problemų.

Prieduose trumpai supažindinama su organizacijų gebėjimo vykdyti PĮ

įsigijimo projektus vertinimo modeliu [SA-CMM02], pateikiamos tarptautinio

standarto [ISO12207] nuostatos PĮ įsigijimo klausimais.

Mokymo medžiagos I dalis „Programų sistemų įsigijimas“ parengta

vadovaujantis pagrindinai šaltiniais [DoT98a; DoT98b; SMC04], taip pat naudojant

kitus šioje medžiagoje nurodytus šaltinius.


8

1. Programinės įrangos ( PĮ ) ypatumai

Dažnai su PĮ įsigijimo projektais atsitinka taip, kad:

- galutiniai rezultatai gaunami pavėluotai, t.y. pasibaigus projekto terminui;

- viršijamas projekto biudžetas.

Iš interviu su valstybės kontroliere R.Budbergyte: „Nustatyta, kad pasaulyje tik 16 proc. projektų įgyvendinama laiku. Apie 50 proc. jų dėl blogos vadybos pabrangsta 220 proc., o jų įgyvendinimo laikas pailgėja iki 167 proc. Neinvestuojam į kvalifikuotą žmogų, kad jis vadovautų projektui, ir taip padarom nuostolių valstybei. ...“ [„Valstybės tarnybos aktualijos“, 2007 liepa, Nr. 8, „NIEKO NEKEISDAMI, PRIEISIME LIEPTO GALĄ”].

Deja, viso to priežastys projekto pradžioje ne visada būna aiškios. Dažnoje

organizacijoje už PĮ įsigijimą atsakingi asmenys nežino šių problemų priežasčių.

Šiems klausimams skiriamas dėmesys atitinka jų turimą patirtį, kuri dažniausiai

būna įgyta vykdant statybų, transporto, medžiagų įsigijimo ar panašius projektus. PĮ

inžinerija yra palyginus nauja sritis, kurios amžius vos du-trys dešimtmečiai.

Kodėl PĮ įsigijimo projektai dažnai patiria nesėkmę? Tai atsitinka dėl eilės

priežasčių:

- PĮ yra žymiai sudėtingesnis objektas, nei kitokios rūšies objektai (pastatai,

keliai, kt.); kaip ir pastatai ar keliai, PĮ turi statiškas charakteristikas, pvz., sąsajas su

kita PĮ ar sistemomis. Bet PĮ turi dar ir kintančias charakteristikas, kaip įvesties

duomenys ar sąveika su operatoriais, atliekančiais daugybę subtilių, sunkiai

pastebimų veiksmų. PĮ ar sistemų integracija yra sudėtingiausias ir sunkiausias

uždavinys;

- žmogaus ir PĮ sąveikos realizacija – ar tai būtų sąveika, naudojant

popieriuje spausdinamus pranešimus, ar sąveika realiu laiku terminalo priemonėmis

– yra dažnas PĮ naudotojų nusiskundimų taikinys. Netgi jei yra subjektyvūs

naudotojo nusiskundimai, tenka daryti PĮ pakeitimus. Apskritai, PĮ visada

realizuojamos minėtos sąveikos; - PĮ projektavimo išlaidų ir PĮ kainos santykis yra visai kitoks, nei jis yra

aparatinės įrangos įsigijimo ar statybų projektuose. Statybų projektuose architektūrinių sprendimų ar projektų rengimo kaina yra santykinai maža, lyginant su statinio kaina. Tai yra natūrali kliūtis užbaigto objekto pakeitimams daryti. Pvz., gali prireikti daugelio metų, kad nutiestas greitkelis būtų praplatintas nauja eismo juosta, t.y. kad būtų daromi greitkelio pakeitimai. Didelė kaina mažina keitimus norinčių daryti iniciatorių užgaidas. Tuo tarpu PĮ kaina santykinai yra nedidelė


9

(pvz., PĮ kopija diskelyje), lyginant su kūrimo išlaidomis. Tai sudaro iliuziją, kad yra lengva daryti PĮ pakeitimus. Todėl pakeitimai daromi ne vieną kartą;

- valdyti PĮ įsigijimo projektus yra sunku. Būdai, kurie tinka kitokių projektų eigai vertinti, netinka PĮ projektams. Tai nėra tas pat, kaip nustatyti, kiek kilometrų kelio išasfaltuota arba keli namo aukštai pastatyti;

- supratimas apie PĮ įgyjamas sunkiai. Organizacijų vadovai skundžiasi, kad popieriniai dokumentai ir kitų asmenų nuomonės mažai suteikia aiškumo. Sunku suvokti, kokia ta PĮ bus;

- netgi sėkmingai įdiegus PĮ, gali atsirasti neatitikimų, pvz., iškilus naujiems poreikiams. PĮ naudojimo laikas retai kada būna didesnis kaip penkeri metai (PĮ moraliai pasensta), kai tuo tarpu kitokių objektų, pvz., pastatų, kelių, naudojimo laikas gali būti daug dešimtmečių.

Taigi, PĮ yra visiškai kitokio pobūdžio objektas. Kaip turėtų būti vykdomi PĮ įsigijimo projektai, kad būtų atsižvelgta į PĮ

ypatumus? Panagrinėkime palankias ir nepalankias aplinkybes.

Nepalanki aplinkybė: įprastos projektų valdymo veiklos netinka PĮ atveju. Padarykime keletą prielaidų. Tarkime organizacija samdo patyrusį vadovą,

gerai užsirekomendavusį kitokio tipo, nei PĮ įsigijimas, projektuose. Tačiau, vykdant PĮ įsigijimo projektą darbų grafiko ir biudžeto bėdos atsiranda dėl to, kad PĮ turi savo ypatumus, o pasamdytas vadovas yra įgijęs kitokių projektų patirtį. Ta kitokia gera patirtis gali klaidinti vadovą vykdant pirmąjį jo PĮ įsigijimo projektą. Šitokio projekto eigoje jis gali imtis pastangų efektyviam projekto valdymo būdui rasti. Praeityje naudotos valdymo priemonės gali pasirodyti visiškai netinkamos PĮ įsigijimo projekte. Dar daugiau, įsigijimų tvarka, tinkanti medžiagų įsigijimo sandoriuose (pvz., fiksuotos kainos sandoriuose), nebūtinai tinka PĮ. Trumpai tariant, kitokio tipo projektų vadovavimo patirtis ne visada tinka PĮ įsigijimo projektuose.

Kaip yra su nedidelę darbo patirtį PĮ srityje turinčio vadovo samdymu? Tikriausiai tokio, kuris išmano tik kompiuterių programavimą. Iš tikrųjų tai gali atnešti daugiau žalos, nei naudos. Darbo patirtis su mažais PĮ projektais gali nuvesti klaidingu keliu, ir kuriama didesnė PĮ neatitiks visuotinai pripažintų reikalavimų, bus sunkiai suderinama su žinomomis sistemomis. Taigi, greitų ir lengvų sprendimų nebūna.

Palanki aplinkybė: prie PĮ ypatumų galima prisitaikyti. Kadangi PĮ skiriasi nuo kitokio tipo objektų, tai ji kitaip ir turi būti įsigyjama.

Tradiciniuose pastatų, transporto priemonių, medžiagų įsigijimo projektuose sutinkamas požiūris turi būti pakoreguotas ir pritaikytas PĮ. Yra sukurti metodai tam atlikti. Apie kai kuriuos iš jų rašoma šioje mokymo medžiagoje.


10

2. PĮ įsigijimo platesnis kontekstas

Apskritai, PĮ įsigijimas yra tik kažkokios sudėtingesnės sistemos įsigijimo

proceso dalis. 2.1 pav. pavaizduota bendroji įsigijimo konteksto schema.

2.1 pav. Bendrasis PĮ įsigijimo kontekstas

Visas sistemos įsigijimo procesas prasideda nuo poreikių analizės, kurio metu

išryškinami organizacijos poreikiai ir spręstinos problemos. Toliau siūlomi

problemų sprendimo keliai, formuojama sistemos samprata. Turint puoselėjamos

sistemos sampratą, sprendžiamas jos įsigijimo klausimas.

Ankstyvajame įsigijimo etape sistemos samprata gali būti tik vizija iniciatorių

galvose ir suvokimas, ką sistema duos organizacijai. Tai gali būti formalus

dokumentas, apibrėžiantis sistemos tikslus ir siekius. Kokį pavidalą sistemos

samprata beįgautų, ji tarnauja kaip atspirties taškas, kaip kelrodis, kuria linkme

rengiamasi eiti. Neturint vizijos, labai lengva pasimesti vykdant įsigijimo projektą.

Tai gali atvesti prie lyg ir veikiančių komponentų sukūrimo, tačiau neduodančių

norimo rezultato, arba galima visiškai nukrypti į šalį ir negauti jokių rezultatų.

Sistemos įsigijimo procesas įgalina paversti viziją tikrove. PĮ yra vienas iš

sistemos komponentų. Būtent apie PĮ įsigijimą ir bus kalbama toliau. Jei jos įsigijimo

etapas buvo sėkmingas, visa sistema tampa veiksminga.

Grįžtamojo ryšio duomenys apie sistemos kokybę (veiksmingumą) padeda

toliau tikslinti ar plėtoti poreikius. Kai sistema yra eksploatuojama, lygiagrečiai

vyksta ir jos priežiūra. Tai aparatinės įrangos (AĮ) ir PĮ priežiūra. Faktiškai, sistemos

gyvavimo cikle PĮ priežiūros pastangos ir kaina per eilę metų dažnai viršija PĮ

kūrimo išlaidas įsigijimo laikotarpiu.

Organizacijos

poreikių

analizė

Siūlomi

sprendimo

keliai

Sistemos

įsigijimas

Naudojimas ir

priežiūra

Tolesnis

planavimas

Sistemos

samprata


11

Detalizuokime 2.1 pav. parodytą „sistemos įsigijimo“ etapą. 2.2 pav.

schemiškai pavaizduotos šio etapo veiklos, apimančios AĮ ir PĮ. Jame sistemos

projektavimas dalinasi į dvi dalis. Taip atsiranda PĮ reikalavimai, kas savo ruožtu

iššaukia PĮ projektavimo ir kūrimo veiklas.

Kaip parodyta 2.2 pav., AĮ ir PĮ turi būti integruotos dar iki sistemos priėmimo

ir naudojimo.

2.2 pav. Sistemos įsigijimo proceso veiklos

Pastebėkime, kad tai yra tik viena iš sistemos koncepcijų. Ne visuose

projektuose 2.2 pav. parodytos veiklos yra būtinos kaip atskiri žingsniai. Taip pat,

sistemos reikalavimų rengimas, sistemos projektavimas, PĮ reikalavimų rengimas

paprastai nėra viena po kitos nuosekliai atliekamos veiklos, laukiant, kol bus atlikta

ankstesnioji.

Naudojimas

ir priežiūra

Sistemos

reikalavimų

rengimas

Sistemos

projektavimas

PĮ

įsigijimas

AĮ

įsigijimas Sistemos dalių

integracija

Sistemos

priėmimas

Sistemos įsigijimas

Sistemos

samprata


12

3. Skirtingi požiūriai į PĮ įsigijimo procesą

Užsakovai (dažniausiai viešasis sektorius) ir tiekėjai (privatusis sektorius)

skirtingai žiūri į PĮ įsigijimo procesą. Skirtingas požiūris yra susiformavęs dėl

daugelio priežasčių.

Toliau pateikiamos dažniausiai sutinkamos užsakovų ir tiekėjų atstovų

nuomonės PĮ įsigijimo klausimais.

Užsakovų samprotavimas: netapk priklausomas nuo tiekėjo

Netapk priklausomas nuo vieno tiekėjo – tai dažnai sutinkamas PĮ užsakovų

požiūris. Kai prisirišama prie vieno tiekėjo, prarandami įtakos jam svertai ateityje.

Taip užsakovas tampa priklausomas nuo tiekėjo, kuris ima reikalauti lupikiškų

kainų už nesudėtingus PĮ kūrimo ar keitimo darbus. Dar blogiau būna, kai tiekėjas

nutraukia savo veiklą (bankrutuoja) arba sandorį. Tuomet užsakovas lieka be

pagalbos ir su neprižiūrima PĮ. Todėl, baigiantis projektui, užsakovai dažnai

reikalauja pateikti ir pradinius programų tekstus (source code), kad išvengtų

priklausomybės nuo tiekėjų.

Tiekėjų požiūris į užsakovų samprotavimus „netapk priklausomas nuo

tiekėjo“

Tiekėjų nuomone užsakovų reikalavimas pateikti pradinius programų tekstus

nepadeda jiems tapti nepriklausomais nuo tiekėjų. Tai tik didina PĮ kainą.

Papildomai užmokėjęs už pradinio programų teksto licenciją, užsakovas vėliau

pastebi, kad tai neduoda jam naudos. PĮ yra perdaug sudėtingas objektas, kad bet

kas galėtų ją prižiūrėti ar keisti. Iš pirmo žvilgsnio atrodantys paprasti PĮ pakeitimai

gali pareikalauti šimtų eilučių keitimo pradiniame programos tekste. Tai gali būti

sunkiai įgyvendinama. Netgi jei užsakovui pavyksta pasinaudoti pradiniu

programos tekstu darant PĮ keitimus, tai gali sukelti keletą nepageidaujamų

padarinių. Pakeitimai gali turėti neigiamą poveikį PĮ garantijoms. Gatavos PĮ

pirkimo atveju užsakovo atlikti pakeitimai joje nebus perkeliami į tiekėjo leidžiamas

naujas PĮ versijas. Taigi, užsakovas susiduria su dviem nepageidaujamomis

aplinkybėmis:

1) atnaujintoje gatavos PĮ versijoje taip pat reikia daryti pakeitimus;

2) stengiantis išlikti nepriklausomu nuo tiekėjo, turima PĮ versija greitai

pasensta.

Antroji aplinkybė užkerta priežiūros palaikymo galimybę, kadangi tiekėjas

dažniausiai nebeprižiūri visų savo anksčiau išleistų PĮ versijų.


13

Užsakovų samprotavimas: įsigyk individualius poreikius atitinkančią PĮ

PĮ įsigyjantis užsakovas turi keletą priežasčių kelti individualius

reikalavimus.

Pirma, jis nori, kad PĮ geriau atitiktų jo poreikius. Gali būti siekiama, kad PĮ

atitiktų unikalius jo reikalavimus. Užsakovui gali atrodyti, kad tiekėjų siūlomos PĮ

algoritmai nėra optimalūs jo poreikiams.

Antra, yra tam tikros darbo procedūros, su kuriomis užsakovo darbuotojai yra

susipažinę, prie jų įpratę. Darbuotojai gali nenorėti papildomai mokytis naujų

dalykų, taikytis prie naujos PĮ.

Trečia, galimybė įsigyti PĮ pasitaiko ne taip dažnai. Sunku gauti finansavimą.

Taigi, jei jau pasitaikė galimybė, užsakovas siekia didžiausios naudos ir todėl nenori

įsigyti tokios PĮ, kuri gali pasenti per artimiausius keletą metų, nežiūrint jos

teikiamų privalumų.

Ketvirta, kažkokią sudėtingą PĮ užsakovas jau gali būti įsigijęs anksčiau.

Todėl gali būti nepriimtina pirkti jau esančius gatavus PĮ paketus dėl integravimo su

jau turima PĮ sunkumų.

Tiekėjų požiūris į individualių poreikių PĮ

Tiekėjų siūlomos PĮ adaptavimas užsakovo individualiems poreikiams yra

dažnas reikalavimas. Tiekėjai supranta, kad daug kas gali turėti unikalius poreikius.

Tačiau jie mano, kad reikalavimai adaptuoti jų siūlomą PĮ užsakovo individualiems

poreikiams dažnai yra nebūtini. Užsakovas vietoje to, kad imtų kurti naują PĮ, turėtų

kelti kuklesnius reikalavimus ir ieškoti visapusiškai geriausiai jo poreikius

atitinkančios gatavos PĮ. Kuomet užsakovas prašo sukurti naują PĮ, užkertami keliai

įsigyti jau gatavą PĮ. Tiekėjai mano, kad toks elgesys bet kokioje srityje yra

netoleruotinas. Jie mano, kad įsigyjant gatavą produktą pirkėjo poreikiai

patenkinami geriausiai. Kai mes perkame, pvz., automobilį, darome kompromisą

tarp kainos ir prabangos, bet neiname pas gamintoją ir nereikalaujame perdaryti

automobilio. Ar negalima būtų laikytis tokios nuostatos ir PĮ atveju? Imkime dar

vieną pavyzdį. Tarkime, prireikus kavos virdulio, jūs apeinate keletą parduotuvių ir

nusiperkate labiausiai patikusį. Galbūt tai buvo ne pats geriausias virdulys, bet dėl

to jūs nebėgate pas gamintoją ir neprašote perkelti rankenos iš vienos vietos į kitą.

Tačiau PĮ atveju, atrodo, pakeitimai kažkodėl laikomi normaliu dalyku.

Individualūs poreikiai veda prie to, kad kiekvienam užsakovui turėtų būti

kuriama unikali PĮ. Tiekėjo gatava PĮ yra patikimas produktas, gerai ištestuotas ir

veikia įvairioje aplinkoje. Laikui bėgant dauguma išryškėjusių trūkumų buvo


14

pašalinti. Na, o nauja individualių poreikių PĮ niekada neturės tokių garantijų ir

patikimumo.

Pernelyg ambicingi poreikiai sumažina užsakovo galimybę susirasti

kvalifikuotą tiekėją. Pastarasis, pardavimui turėdamas gatavą produktą, nėra

suinteresuotas kurti naują individualių reikalavimų PĮ. Per daug rizikos, ir bet kokiu

atveju toks darbas nėra pelningas. Imantis užsakovo užduoties, yra rizika

nepatenkinti jo norų ir sugadinti savo reputaciją. Todėl konkursus dažnai laimi

mažesnę patirtį turinčios kompanijos. Jų darbas būna prastesnės kokybės, kas toliau

sukelia nepasitikėjimų ciklą.

Tiekėjai mano, kad visiems būtų nauda, jei sukurta PĮ būtų prekiaujama tol,

kol, platinant ją tarp pirkėjų, nebus padengtos PĮ sukūrimo išlaidos. Taip pat jie

mano, kad gatavo produkto didesnis paplitimas daro įtaką konkurencijai ir

inovacijoms. Todėl PĮ tiekėjai (kūrėjai) vis tik skiria savo resursus įvairių pirkėjų

individualiems poreikiams tenkinti, nežiūrint, kad ateityje dalies tų poreikių gali ir

nelikti. Didėjant PĮ paplitimui ir užsakovams (pirkėjams) reikia mokėti mažiau, jie

gauna daugiau naudos iš PĮ, nes naujovės sudaro galimybę žengti į priekį.

Užsakovų siekiama nauda

Užsakovai jaučia, kad tiekėjai stengiasi išpešti naudą iš įvairių sandorio

aplinkybių. Jie įtaria, kad aukštų kainų prašoma už paprastus PĮ patobulinimus, ir

tai daroma įvairiausiais būdais. Todėl užsakovai įrodinėja, kad jeigu patobulinimai

nebuvo aiškiai įvardinti sandoryje, jie neprivalo mokėti visos jų atlikimo kainos,

kadangi tiekėjas gali parduoti tuos patobulinimus keletą kartų kitiems užsakovams.

Taip pat pasitaiko, kad, priėmus PĮ arba pasibaigus formaliam sandoriui, PĮ nustoja

veikti, ir užsakovas neturi kito pasirinkimo, kaip kreiptis pagalbos į tiekėją. Todėl

užsakovai siekia tiekėjo garantijų PĮ sutrikimų atvejais, netgi jei tai nebuvo

numatyta sandoryje.

Tiekėjų siekiama nauda

Tiekėjai taip pat jaučia, kad užsakovai įvairias sandorio aplinkybes stengiasi

išnaudoti savo naudai. Tiekėjai mano, kad užsakovai neturi paskatų priimti PĮ,

kadangi tai gali būti suprasta kaip susitarimo prižiūrėti PĮ pabaiga. Tiekėjai tvirtina,

kad jie netampa turtingesni dėl kuriamos PĮ. Faktiškai gaunamus pinigus jie leidžia

sandorio reikmėms. Pasitaiko, kad užsakovai reikalauja nemažai pakeitimų iki PĮ

priėmimo, nesuteikdami šiems darbams papildomo finansavimo. Tiekėjai sako, kad

jie neturėtų būti kreditoriai. Užsakovai turėtų suprasti, kad privati firma yra pelno

siekiantis subjektas, o ne viešųjų paslaugų tiekėjas. Tiekėjai skundžiasi, kad PĮ

atveju jie negauna viršpelnio; šiaip tai jie nutyli (slepia) kainą, nuosavas išlaidas. Iš


15

tikro pradinės nuosavos tiekėjo investicijos į PĮ (pvz., įsigyjančiosios organizacijos

darbo analizė, pradinė PĮ diegimo studija) pasiteisina ir atsiperka. Tiekėjai taip pat

skundžiasi, kad, netgi priėmus PĮ, užsakovai kreipiasi ir tikisi papildomos pagalbos

jai prižiūrėti. Tiekėjai, netgi neturėdami sutartinių įsipareigojimų teikti tokią

pagalbą, teikia ją, stengiasi palaikyti gerus santykius su užsakovu.

Ką turėtų daryti užsakovas?

Skirtingi užsakovų ir tiekėjų požiūriai į PĮ įsigijimo procesą nėra geras

dalykas. Kiekviena pusė gali pateikti pavyzdžių, kaip ji nukentėjo nuo kitos. Šioje

mokymo medžiagoje pateikiamos kai kurių problemų sprendimo rekomendacijos,

kad būtų gaunama abipusė nauda. Užsakovams ypač rekomenduojama:

- pirkti gatavą PĮ, o ne kurti naują, individualių poreikių PĮ, jei tai įmanoma.

Taip mažėja rizika ir nepasitikėjimas. Tokiu atveju labai praverčia įsigijimo

tikslams sudaryta darbo grupė;

- palaikyti atvirus užsakovo ir tiekėjo ryšius. Tai padeda tiekėjui geriau

suprasti užsakovo poreikius, o užsakovui pamatyti, kad ne visi jo

individualūs reikalavimai yra būtini. Užsakovas ima geriau suprasti, kokių

pastangų gali prireikti jo keliamiems reikalavimams įgyvendinti, ir kiek

įmanoma sumažina juos;

- parengti formalų testavimo planą PĮ priimti, išryškinti priėmimo kriterijus.

Tai padeda sklandžiau užbaigti sandorius ir atsiskaityti su tiekėjais. Tuo

pačiu tai suteikia užsakovui didesnį tikrumą, kad PĮ atitiks reikalavimus ir

bus pakankamai patikima;

- pasirūpinti PĮ priežiūra ir užsakovo darbuotojų mokymu įsigijimo projekto

bėgyje. Tiekėjui patikėjus priežiūrą, lengviau pastebimos PĮ klaidos. PĮ

administravimo funkcijas ir žmogaus sąveiką su PĮ aprašantys dokumentai

gali sumažinti užsakovo priklausomybę nuo tiekėjo, kuris, pasibaigus

sandoriui, gali nebenorėti būti trukdomas;

- užsakovo ir tiekėjo sandorio punktuose, susijusiuose su intelektine

nuosavybe, vengti reikalavimo tiekėjui pateikti pradinius programų tekstus

pasibaigus sandoriui.


16

4. PĮ tipai

Įsigijimo projektų vadovai retai kada domisi PĮ atskiros darbo vietos siauriems

poreikiams tenkinti. Dažniausiai jiems tenka rūpintis PĮ, kuri yra kažkokios

sudėtingos sistemos komponentas, įsigijimu. Jei kaina nėra pagrindinis sistemos

įsigijimą sąlygojantis rodiklis, PĮ dažnai apsprendžia sistemos kūrimo kalendorinį

darbų planą ir yra pagrindinis sistemos funkcionalumą, patogumą ir patikimumą

nulemiantis veiksnys. PĮ yra „rišamoji medžiaga“, kuri sujungia sistemos

komponentus ir daro sistemą veiksmingą.

Yra įvairi PĮ, kurios rangą apsprendžia sukūrimo rizika. Bendras tokios PĮ

bruožas yra „realaus laiko“ reikalavimai. Priklausomai nuo atliekamų funkcijų, PĮ

turi būti pajėgi duoti atsakymą per minutes ar net sekundės dalis po duomenų

įvedimo (pvz., lėktuvuose, raketose). Ji turi veikti nepertraukiamai ir būti patikima.

Tarp šio tipo PĮ ir stalinio kompiuterio PĮ, kurios sutrikimai nėra retas reiškinys ir

kurios veikimą tenka atstatyti kelis kartus per dieną, yra didelis kontrastas. „Realaus

laiko“ reikalavimams įgyvendinti reikalinga sudėtingesnė ir brangesnė PĮ

(atitinkamai reikia ir geresnės aparatinės įrangos). Tuo ir paaiškinama, kodėl tokia

PĮ sutinkama retai.

PĮ rangas yra nustatinėjamas ir pagal technologinį lygį, įdiegimo vietų kiekį,

esamų gatavų produktų (komponentų) tinkamumą joms. Kartais tokiai PĮ sukurti

tinka keleto pardavėjų siūlomi gatavi produktai. Tačiau yra PĮ, kuriai tinkamų

gatavų komponentų, galinčių padėti sumažinti PĮ sukūrimo riziką, yra mažai arba

nėra iš viso. Tokiais atvejais užsakovas turėtų pasvarstyti, ar jis turi pakankamai

patirties tokios PĮ įsigijimo projektams vykdyti.

Kai prireikia PĮ vienokio tipo sistemai sujungti (integruoti) su kitokia, ji turi

būti kuriama pagal individualų užsakymą. Tai, žinoma, įneša tam tikrą riziką.


17

5. PĮ įsigijimo nuostatos

Šiame skyriuje aptariamos PĮ įsigijimo nuostatos (požiūriai). Jomis reikėtų

grįsti PĮ įsigijimo procesą, turint omenyje, kad PĮ iš esmės skiriasi nuo kitokių

objektų. Žinoma, šios nuostatos nėra naujos ar unikalios. Tačiau kai kurios iš jų yra

būtinos PĮ projektuose, nors kitokiuose projektuose gali būti nepriimtinos. Dalis PĮ

įsigijimo nuostatų skiriasi nuo kitokių objektų įsigijimo nuostatų ne savo esme, o

tikslumu, griežtumu.

5.1 lentelėje išvardintos PĮ įsigijimo nuostatos. Išnagrinėkime jas.

5.1 lentelė. PĮ įsigijimo nuostatos

Nuostatų grupė Nuostatos pavadinimas

Nekurkime naujos PĮ, jei galima nusipirkti gatavą

PĮ nuostatos

Imkimės kurti įveikiamos apimties PĮ

Lankstumas

Nėra visa apimančių sprendimų

Valdymo nuostatos

Išankstinis planavimas

Bendradarbiavimas

Grupės PĮ įsigyti sudarymas

Atviri užsakovo ir tiekėjo ryšiai

Žmogiškųjų santykių nuostatos

Aktyvus užsakovo dalyvavimas PĮ įsigijimo projekte

Žmogiškųjų santykių nuostatos

Bendradarbiavimas. PĮ įsigijimas yra kolektyvinis procesas. Projekto vadovas

negali to padaryti vienas arba priiminėti vienašališkus sprendimus. Priešingai, turi

būti glaudžiai bendradarbiaujama su kitais įsigyjančiosios organizacijos

darbuotojais. Pvz., tiesioginiai PĮ naudotojai turi būti pasitelkiami į pagalbą priimant

sprendimus, ką sistema turės daryti, apibrėžiant naudotojų sąveikos su PĮ būdus,

darant kompromisus tarp kainos ir sistemos funkcionalumo. Būtina bendradarbiauti

ir su kitų organizacijų atstovais, ypač su PĮ tiekėjais. Tik tiekėjas yra pajėgus

apibrėžti galimas projekto variacijas arba nurodyti galbūt netikusius reikalavimus.

Tiekėjo patirtis gali padėti užsakovui suformuluoti savo poreikius.


18

Bendradarbiavimas neįmanomas, kai nėra su kuo bendradarbiauti. Todėl

reikia suburti darbo grupę PĮ įsigyti.

Grupės PĮ įsigyti sudarymas. Reikalingi įvairūs įgūdžiai, norint įsigyti PĮ. Nė

vienas individas ar organizacija, tikriausiai, neturi visų įgūdžių. Todėl reikalinga

profesionalų grupė. Joje turi būti aparatinės įrangos, PĮ, sistemų inžinerijos

specialistai, sandorių rengėjai, naudotojai, prižiūrėtojai (projektų vadovai),

teisininkai. Grupėje turint sandorių specialistus, atsiranda galimybė rinktis įvairius

įsigijimo būdus, geriausiai tinkančius PĮ atveju. Įvairūs grupės nariai turi ne tik

skirtingus įgūdžius, bet ir skirtingą požiūrį į problemą. Pvz., tiesioginiai PĮ

naudotojai grupėje rūpinsis klausimais, turinčiais įtakos PĮ naudojimo patogumui.

Grupė gali būti ir kitų organizacijos padalinių arba net ir kitų organizacijų atstovai.

Tokio paties rango organizacijos atstovai gali būti kviečiami patarėjais. Svarbus

grupės narys yra PĮ tiekėjas. Netgi rizikos valdymas yra grupinė veikla, ir tai nėra

vien tik užsakovo reikalas. Užsakovas ir tiekėjas negali turėti prieštaraujančių tikslų;

labai svarbu, kad jie dirbtų kartu ir siektų bendro tikslo. Jeigu užsakovas laikosi

griežtos pozicijos tiekėjo atžvilgiu ir spaudžia jį dėl smulkmenų, tai nėra gera

praktika ir gali atnešti abipusius nuostolius. Turi būti stengiamasi sudaryti abiem

pusėm priimtiną aplinką.

Grupė yra geriau negu įvairią patirtį turinčių darbuotojų rinkinys. Kad

darbuotojus galima būtų vadinti grupe, jie turi dirbti kartu ir siekti to paties tikslo.

Potencialios biurokratinės PĮ įsigijimo kliūtys, sukeltos tiesioginių naudotojų,

sandorių sudarymo pareigūnų ar dar kurių nors, turi būti įveiktos, ir visi dalyviai turi

būti pasinėrę į PĮ įsigijimo procesą. Tokiai grupei suformuoti organizacijos vadovybė

maksimaliai turi išnaudoti savo politinius ir vadybinius sugebėjimus. Tikslas

pasiekiamas savitarpišku pasitikėjimu.

Grupės sudarymas reikalauja nuolatinio auklėjamojo ir švietėjiško darbo.

Pagrindinė nuostata, padedanti greičiau sudaryti grupę, yra nuolatinis atvirų ryšių

palaikymas.

Atviri užsakovo ir tiekėjo ryšiai. Viso PĮ įsigijimo proceso metu būtina

palaikyti atvirus (glaudžius, draugiškus) ryšius tarp užsakovo ir tiekėjo. Tai padeda

išvengti nesusipratimų, nes užsakovo ir tiekėjo požiūriai į PĮ gali būti labai skirtingi.

Ryšiai turėtų būti užmegzti dar iki sandorio pasirašymo, kad būtų aptartos įvairios

sąlygos, ypač intelektinės nuosavybės klausimai. Atviri ryšiai turi būti palaikomi

pradedant nuo PĮ reikalavimų svarstymo ir tęstis PĮ priėmimo bei priežiūros

laikotarpiu. Įsigijimo proceso eigoje kiekviena pusė turėtų nesivaržydama dėstyti

nemalonias žinias kitai pusei, nebijoti priešiškos reakcijos.


19

Pasirašytas sandoris turi leisti atvirus ryšius net tais atvejais, kai PĮ kuria

subrangovas. Reikalaujami formalūs ryšiai tarp užsakovo ir tiekėjo tik trukdo

efektyviam bendravimui. Netgi formalių tikrinimų metu atviri ryšiai yra skatintini.

Apie PĮ įsigijimo sandoryje iškilusias problemas būtina kaip galima greičiau

informuoti kitą pusę ir dirbti drauge. Dažniausiai taip ir daroma. Tačiau užsakovai

turėtų įspėti, jeigu tiekėjas dels pranešti apie iškilusias problemas, tai atsakomybę

už viršytas išlaidas teks prisiimti tiekėjui.

Aktyvus užsakovo dalyvavimas PĮ įsigijimo projekte. Bendradarbiavimas,

grupės sudarymas, atviri ryšiai reikalauja nuolatinio aktyvaus užsakovo dalyvavimo

PĮ įsigijimo procese. Galima būtų viską pavesti projekto vadovui arba tiekėjui. Jei

kitokio tipo projektuose užsakovas gali apsiriboti, pvz., tik tiekėjų darbų

patikrinimais, tai PĮ įsigijimo projektuose beveik pusę PĮ reikalavimų formulavimo ir

projekto (eskizo) rengimo darbų turi atlikti užsakovas ir tiesioginiai PĮ naudotojai,

netgi kai sandoris su tiekėju jau būna pasirašytas. Žinoma, toks užsakovo

įsijungimas į įsigijimo projektą turi būti paremtas atitinkamais resursais. Aktyvus

užsakovo dalyvavimas taip pat reiškia jo pasiryžimą spręsti iškylančias problemas ir

prisiimti atsakomybę (pageidautina raštu) už specifinius veiksmus, atvirų ryšių su

tiekėju metu išklausius įvairias projekto įgyvendinimo galimybes.

Valdymo nuostatos

Lankstumas. Statybų projektai sėkmingai vykdomi pagal nekeičiamus

brėžinius ir už sutartą kainą. PĮ atveju reikalingas kur kas didesnis lankstumas. Jis

būtinas viso įsigijimo proceso eigoje: formuluojant reikalavimus, darbo santykiuose,

pasirenkant sandorio tipą. Bet labiausiai reikalingas yra požiūrio į minėtus dalykus

lankstumas. Reikalingas nusiteikimas (supratimas), kad PĮ įsigijimo projekto eigoje

gali tekti daryti įvairius pakeitimus. Lankstus požiūris projekto pradžioje įgalina

geriau pasirinkti sandorio tipą, netgi tokį, kuris anksčiau dar nebuvo išbandytas.

Rengiant PĮ reikalavimus, reikėtų lanksčiai žiūrėti į tai, kad naudotojai negali gauti

visko, ko jie norėtų; turi būti kompromisas tarp įsigyjamos PĮ funkcionalumo, kainos

ir darbų grafiko.

PĮ reikalavimai įgyvendinami bėgant laikui. Tipiškas atvejis, kai du procentai

reikalavimų keičiama kas mėnesį. Mintis, kad kartą parengti PĮ reikalavimai

nebeturėtų būti keičiami, dažniausiai nepasiteisina. Kai kurių reikalavimų prasmė

pradžioje gali būti nevisiškai aiški. Tik pradėjus įsigijimo projektą, gali išryškėti, kad

jie turi nepriimtiną poveikį PĮ darbingumui. Kartais iš pažiūros nekaltas ir mažai

reikšmingas reikalavimas daro didelį poveikį projektui, įneša tam tikrą techninę,


20

kainos padidėjimo ir įvykdymo laiku riziką. Įsigijimo procesas turi būti lankstus, kad

išliktų galimybė keisti arba šalinti abejotinus reikalavimus (tokiems reikalavimams

įvardinti būtini atviri ryšiai tarp užsakovo ir tiekėjo). Tai ypač taikytina aparatinės

įrangos ir PĮ reikalavimams, kurie gali moraliai pasenti per projekto trukmę.

Kadangi daromi kainos, darbų grafiko, PĮ funkcionalumo kompromisai, tai daliniai

sprendimai yra tinkamiausias tokių reikalavimų tvarkymo būdas. Gali būti taip, kad

PĮ nedarys visko, ko norėta, ypač pirmoje iteracijoje. Realiausia, kad iš karto PĮ

atitiks 80-90 procentų užsakovo poreikių, ir tai yra priimtinas rezultatas PĮ kainos-

efektyvumo prasme. Atkakliai reikalaujant daugiau, vargu ar galima pasiekti

geresnių rezultatų, nes atsiranda pavojus įsivelti į ilgai trunkantį ir rizikingą PĮ

kūrimo procesą. Nelankstūs reikalavimai beveik be išimčių veda prie sprendimo

kurti naują PĮ priėmimo, atsisakant įsigyti didžiumą reikalavimų atitinkančią jau

esančią gatavą PĮ.

Lankstumas techniškaisiais klausimais įmanomas tik esant atitinkamo tipo

sandoriams, kurie leidžia daryti korekcijas (turi būti sudaryta įsigijimo grupė, į kurią

yra įtraukti tiekėjo atstovai, ir palaikomi atviri ryšiai). Pvz., pažangūs pasiūlymai gali

būti remiami, leidžiant sandorio pusėms koreguoti reikalavimus. Didelės vertės

įsigijimo projektuose galimybė siūlyti PĮ reikalavimų korekcijas įtraukiama į sandorį.

Derantis dėl kainos, taip pat reikalingas lankstumas. Projekto pradžioje,

apskritai, neįmanoma tiksliai ir patikimai įvertinti PĮ kainą. Įsigijimo proceso eigoje,

iškilus problemoms, būtinas lankstumas darant kompromisus dėl kainos,

kalendorinio darbų grafiko ir funkcionalumo. Tai gali pareikalauti papildomų

resursų (didinama kaina, išsaugant tokį patį PĮ funkcionalumą) arba perskirstyti

resursus (kaina nekeičiama, bet mažinamas PĮ funkcionalumas). Požiūris į projekto

tikslus kiekviename įsigijimo proceso etape gali būti atnaujinamas. Turėtų būti

lanksčiai elgiamasi su netiksliai apibrėžtomis sandorio sąlygomis, kurias tiksliau

apibrėžti galima tik projekto eigoje.

Tačiau per didelis lankstumas taip pat nėra geras dalykas. Reikėtų vengti

reikalavimų kaitos, naujų reikalavimų kėlimo arba projekto apimties didinimo.

Reikalavimų pastovumas yra pirmas sėkmingo PĮ įsigijimo veiksnys. Antras veiksnys

yra realus kalendorinis darbų grafikas.

Nėra visa apimančių sprendimų. Kai tik PĮ įsigijimo projektai patenka į bėdą,

natūralu, kad ieškoma būdų iškilusioms problemoms išspręsti. Galbūt tai galėtų būti

ypatingas projekto valdymas, nauji PĮ kūrimo instrumentai, programavimo kalba ar

kūrimo metodologija. Vaisto nuo visų ligų, t.y. visa apimančių sprendimų, deja,

nėra. Kai kas sako, kad PĮ atveju reikalingi nauji sandorių tipai. Gal tai ir gera


21

mintis, kadangi tradiciniai sandorių tipai buvo sukurti neatsižvelgiant į PĮ

egzistavimą. Tačiau netgi jei atsirastų nauji sandorių tipai, tai nepadėtų. PĮ

reikalavimų rengimo, kainos nustatymo, testavimo, kokybės kontrolės klausimai vis

tiek reikalaus savo sprendimo. Sėkmingas PĮ įsigijimas įmanomas tik turint didelę

valdymo ir techninio darbo patirtį.

Išankstinis planavimas. Daugelis PĮ įsigijimo proceso veiklų, kaip

reikalavimų rengimas, projekto peržiūra, testavimas, priežiūra, nėra atliekami tol,

kol nepasirašomas sandoris su išrinktu tiekėju. Faktiškai, kai kurios iš jų

nepradedamos iki galutinės įsigijimo proceso stadijos. Nepaisant to, veiklos turi būti

planuojamos iš anksto dar iki prašymo teikti pasiūlymus (RFP – Request For

Proposal) paskelbimo. Tai įgalina paskirstyti įvairias PĮ įsigijimo projekto veiklas

kalendoriniame darbų grafike ir numatyti jų trukmes. Taip pat atsiranda galimybė

išdėstyti prašyme teikti pasiūlymus (RFP) ir rengiamame sandoryje PĮ naudojimo ir

priežiūros koncepciją, priėmimo kriterijus, intelektinės nuosavybės teises.

Techniškojoje srityje išankstinis planavimas turi apimti PĮ saugumą, atvirųjų

sistemų klausimus (OSI modelį), patikimumą. Šioms savybėms dėmesys turi būti

skiriamas nuo pat PĮ sumanymo pradžios, to negalima atidėlioti, blogiausiu atveju

bent jau turi būti numatytos galimos pasekmės. PĮ suderinamumas su kitomis

sistemomis yra kita pusė, į ką turi būti kreipiamas dėmesys išankstinio planavimo

metu.

Išankstinio planavimo koncepcijos esmė yra ta, kad geriau yra numatyti

problemas iš anksto, nei ieškoti sprendimų vėliau, kai problemos iškyla. Tai gali

žymiai padidinti projekto kainą, ypač jei problemos nuslepiamos arba jų sprendimas

nukeliamas vėlesniam laikui. Problemas atskleisti kiek galima anksčiau gali padėti

sudaryta įsigijimo grupė, tarp užsakovo ir tiekėjo palaikomi atviri ryšiai.

PĮ nuostatos

Nekurkime naujos PĮ, jei galima nusipirkti gatavą. Kai tik įmanoma, reikėtų

pirkti gatavus PĮ produktus, o ne kurti naujus pagal užsakymą nuo pat pradžios.

Įvairių tipų sistemoms galima rasti tinkamus gatavus PĮ produktus (COTS –

Commercial Of The Shelf), kuriuos galima būtų integruoti į kuriamą sistemą. Naujos,

individualių poreikių PĮ kūrimas turi didesnę riziką. Taip pat tai gali pareikalauti

didesnių išlaidų. Nusipirkti gatavą PĮ yra pigiau, nes jos sukūrimo išlaidos

pasiskirsto tarp daugelio pirkėjų. Gatavai PĮ pirkti reikalingas lankstumas,

švelninant reikalavimus ir pasirenkant geriausiai tinkančią. Reikalingas

nusiteikimas, kad esanti gatava PĮ tikriausiai niekada neatitiks jūsų idealios vizijos.


22

Bet jei PĮ atitinka 80% jūsų reikalavimų, tai sprendimas įsigyti tokią gali būt

pateisinamas. Nereikėtų siekti tobulybės bet kuria kaina.

Tiekėjai remia gatavos PĮ įsigijimus. Tačiau šis įsigijimo būdas nėra visa

apimantis ir todėl ne visada jį reikėtų naudoti. Pirkime gatavą PĮ, jei tą diktuoja

sveikas protas. Jeigu gatava PĮ neatitinka jūsų reikalavimų, peržiūrėkime savo

reikalavimus, įvertinkime jų svarbą ir įgyvendinimo kainą. Jei reikalinga iš tikro

unikalių reikalavimų, moderni PĮ, tai būtina ją kurti. Bet nepamirškime gatavos PĮ

pirkimo gerųjų savybių. Jei vėliau nutariama tobulinti PĮ, tai poreikis pritaikyti ją

individualiems poreikiams jau bus grindžiamas patirtimi, sukaupta naudojant PĮ, o

ne spėlionėmis. Žinoma, bet koks tobulinimas yra grupinė veikla drauge su

anksčiau pasirinktu tiekėju, įvertinant, ką įmanoma padaryti ir ko ne. Tik tada

imamasi įveikiamų per nustatytą laiką darbų.

Imkimės kurti įveikiamos apimties PĮ. Dažna PĮ įsigijimo problema yra noras

padaryti pernelyg daug iš karto. Daug kas kuria ambicingas ilgalaikes vizijas.

Tačiau tai yra tik geri norai tam tikru momentu. Vėliau kiekviename žingsnyje

susiduriama su noru mažinti reikalavimus ir darbų apimtis.

Pradinių reikalavimų apibrėžimas, netgi jei pirktumėme gatavą PĮ, yra

pirmasis įsigijimo proceso etapas. Parengiamas planas, įgalinantis lanksčiai plėtoti

PĮ ateityje. Aukšti pradiniai reikalavimai yra pagrindas, leidžiantis vėlesniuose PĮ

įsigijimo proceso etapuose diegti naujas funkcijas. Taip sudėtinga PĮ gali būti

daloma į smulkesnes dalis.

Yra eilė privalumų, skaidant sudėtingą įsigijimo projektą į mažesnes dalis:

- lengviau valdyti PĮ įsigijimo procesą. Dideli projektai gali atrodyti

įvykdomi, tačiau jie gali žlugti ne dėl technologinių priežasčių, o dėl to, kad

buvo peržengtos šiuolaikinės PĮ projektų valdymo galimybės;

- didėjant PĮ apimčiai, didėja klaidų tikimybė, mažėja nesutrinkamo veikimo

trukmė. Įrodyta, kad pridėjus naujų reikalavimų jų poveikis yra daug

didesnis nei manoma, PĮ sudėtingumas auga, o patikimumas mažėja

kvadratiniu dėsniu priklausomai nuo PĮ dydžio. Taigi, PĮ apimties

sumažinimas gali duoti ryškią naudą;

- PĮ sukurti reikalingos pastangos didėja žymiai greičiau nei jos apimties

padidėjimas. Mažesnės apimties PĮ sukuriama žymiai greičiau. Manoma,

kad perpus sumažinus PĮ apimtį, bendros jai sukurti reikalingos pastangos

sumažėja apytikriai dviem trečdaliais;

- su mažesnėmis dalimis tvarkomasi žymiai lengviau. Pastebėta, kad, įdiegus

naują PĮ, ji pradedama naudoti nenumatytais būdais. Reali PĮ naudojimo


23

patirtis gali būti naudinga vėliau, padėti atskleisti anksčiau nenumatytus

naudotojo poreikius. Tai geriau nei įsigyti PĮ, atitinkančią visus iš anksto

apibrėžtus poreikius, ir pamatyti, kad didelė dalis pastangų buvo iššvaistyta

nenaudojamoms funkcijoms projektuoti. Be to, turint apčiuopiamą

produktą, yra lengviau gauti vadovybės paramą ilgalaikiams tikslams

pasiekti. Matomi darbo vaisiai pagerina programuotojų ir vadovų darbinę

dvasią;

- mažesnė įsigijamos PĮ apimtis ir trumpesni projektų terminai sudaro

geresnes prielaidas išsaugoti daugumą tų pačių įsigijimo grupės narių.

Personalo kaita yra didelės apimties PĮ įsigijimų bėda, kai iki projekto

pabaigos išlieka tik nedaug jį pradėjusių darbuotojų. Tai liečia užsakovus ir

tiekėjus. Personalo kaita vienoje pusėje neigiamai veikia ir kitą, nes

prarandama “įstaigos atmintis”. Nauji grupės nariai gali nesutikti su

pradiniais reikalavimais, ir nors PĮ yra baigta (pagal pradinius

reikalavimus), gali prireikti papildomo darbo naujų dalyvių reikalavimams

patenkinti. Kuo trumpesnis įsigijimo procesas, tuo mažesnė ši problema;

- ilgai trunkančius įsigijimo projektus persekioja nuolatinė informacinių

technologijų pažanga. Kol įgyvendinama viena naujovė, pasirodo kita.

Venkime nukrypimų nuo PĮ reikalavimų ir apimties. Kaip reikėtų išvengti

nukrypimų nuo PĮ reikalavimų ir apimties, vykdant įsigijimo projektą nedideliais

žingsniais, kad pernelyg nenutoltume nuo savo vizijos, užsibrėžtų galutinių tikslų.

Vienas iš kelių yra apsibrėžti tokį PĮ funkcionalumą, kurį būtų galima realizuoti per

santykinai trumpą laiką. Žinoma, reikia būti atsargiems, kad pernelyg

nesutrumpintumėme darbų grafiko. Terminai turi būti grindžiami realiomis

galimybėmis, o ne svajonėmis. Jei įsigijimo projektui realizuoti reikia daugiau kaip

vienerių metų, dalinkime jį į dar smulkesnes dalis. Dideli projektai yra pavojingi.

Sėkmingai įvykdytų PĮ įsigijimo projektų analizė rodo, kad projekto trukmė nuo

reikalavimų suformulavimo iki rezultatų pateikimo turi būti ne didesnė kaip devyni

mėnesiai.

PĮ kūrimas laikantis darbų grafiko arba vadovaujantis patirtomis išlaidomis

(kaina) turi glaudų ryšį. Reikėtų parengti privalomų ir neprivalomų PĮ savybių

sąrašą ir užsiimti tik svarbiausiomis, kurios gali būti realizuotos už turimas lėšas.

Kitokio požiūrio laikomasi konkrečių užduočių (task-order) sandoriuose, kai

nustatoma tik pirmoji arba keleta pirmųjų užduočių. Į kiekvieną užduotį gali įeiti

kitos užduoties plano parengimas. Kartais iškeliamos ir papildomos užduotys. Taip

didelis įsigijimo projektas pakeičiamas smulkesnių įsigijimų serija. Tokio projekto


24

sandoryje turi būti numatyta lanksti galimybė rinktis ar keisti tolesnį kursą PĮ

įsigijimo eigoje.

Ko nederėtų daryti

Žemiau pateikiame keletą pasitaikančių samprotavimų PĮ įsigijimo

klausimais, kurie prieštarauja aukščiau išdėstytoms nuostatoms ir yra nepriimtini:

- užsakovui griežtai reikalauti iš tiekėjo laikytis nustatytų reikalavimų ir

terminų;

- stengtis kiek galima sutrumpinti darbų grafiką;

- kurti sudėtingą PĮ vienu užsimojimu, o ne dalimis;

- stengtis gauti iš tiekėjo daugiau, nei numatyta sandoryje;

- pasirinkus tiekėją palikti jį dirbti vieną;

- būti optimistais netgi jei siekiai nerealūs;

- tiekėjui nesistengti atlikti viską tiksliai, siekti užsitikrinti darbo ateičiai,

tikėtis reikalavimų sušvelninimo.


25

6. Įsigijimo veiklų seka

Toliau šioje mokymo medžiagoje (6-16 skyriuose) nagrinėjamos veiklos,

kurios turi įtakos PĮ savybėms ir galutiniam įsigijimo rezultatui.

Dvi pagrindinės veiklos

Laikoma, kad PĮ įsigijimo proceso pagrindinės veiklos yra šios:

1) PĮ reikalavimų rengimas;

2) tiekėjo išrinkimas.

Savo esme jos nėra svarbesnės už kitas veiklas, tačiau joms reikalingas

ypatingas dėmesys, kad įsigijimo procesas vyktų sklandžiai. Jų išskirtinumas slypi

tame, kad jos yra pagrindinis kitų įsigijimo veiklų variklis. Plačiąja prasme santykis

tarp PĮ reikalavimų rengimo ir tiekėjo išrinkimo yra toks:

- pirma parengus PĮ reikalavimus, darbo grupei atsiranda galimybė rinktis

optimalų įsigijimo būdą (kurti naują ar pirkti gatavą PĮ);

- pirma pasirinkus įsigijimo būdą, sprendžiama, ar PĮ reikalavimai turi būti

parengti iki tiekėjo išrinkimo, ar gali būti rengiami bendradarbiaujant su

jau išrinktu tiekėju.

Tarkime, reikia įsigyti nedidelę PĮ. PĮ samprata ir pradiniai reikalavimai gali

būti pakankamas pagrindas sprendimui dėl gatavos PĮ pirkimo, kuriai nereikia jokių

adaptacijų, priimti. Turint pradinius reikalavimus, gali būti priimtas sprendimas dėl

gatavos PĮ įsigijimo būdo. PĮ savybių sąrašo, paimto iš pradinių reikalavimų, visiškai

gali pakakti tiekėjui išrinkti. Tokiu būdu užsakovui atpuola reikalas rengti išsamius

PĮ reikalavimus.

Individualių savybių PĮ kūrimo atvejis yra sudėtingesnis. Pasirinktas įsigijimo

būdas gali turėti įtakos kitoms veikloms. Jei pasirenkamas laiko ir medžiagų

apmokėjimo tipo sandoris, PĮ reikalavimus geriau būtų rengti drauge su išrinktu

tiekėju. Jei turi būti naudojamas fiksuotos kainos sandoris, reikalingi gerai apibrėžti

PĮ reikalavimai, kad galima būtų priimti išankstinius sprendimus dėl įvairių PĮ dalių

kūrimo ar gatavų pirkimo. Tokiu atveju kuriamoms PĮ dalims išsamius reikalavimus

turi parengti užsakovas iki tiekėjo išrinkimo. Faktiškai, šie PĮ reikalavimai tampa

prašymo teikti pasiūlymus (RFP – Request For Proposal) dalimi. Perkamiems

gataviems komponentams gali pakakti tik bendrųjų reikalavimų (savybių sąrašo).


26

Veiklų eiliškumas ir pažintis su jomis

Idealiu atveju turėtų būti viena žingsnis po žingsnio vykdomų PĮ įsigijimo

proceso veiklų seka. Deja, įsigijimo procesas nėra tiesinis. Jis nėra aiškus iš anksto.

Kai kurios veiklos turi būti atliekamos pirmiausiai, siekiant išaiškinti mažiau

suprantamus dalykus.

Kad įsigijimo procesas geriau atitiktų organizacijos poreikius, o nebūtų

mechaniškas nustatyto proceso vykdymas, reikalingas lankstumas.

Visais atvejais toliau nagrinėjamos veiklos bus persidengiančios, nežiūrint jas

skatinančių ir ribojančių veiksnių. PĮ įsigijimo procesai, tikriausiai, vystosi

spirališkai, o ne tiesiškai. Kiekviena veikla pakyla į aukštesnį lygį, pasistūmėjus

pirmyn kitose veiklose. Laikui bėgant veiklos padeda geriau išryškinti projekto

esmę. Pradžioje juk gali būti tik miglotas supratimas apie projektą. Taip pat įsigijimo

procesas atskleidžia užsakovo sugebėjimą vykdyti veiklas lygiagrečiai.

Kaip pavyzdį panagrinėkime PĮ reikalavimų rengimo eigą. Pradiniai

reikalavimai dažniausiai atspindi tik užsakovo poreikius arba sampratą, ką PĮ turėtų

daryti. Su tokiomis mintimis gali būti dairomasi kitose organizacijose arba lankomos

pardavėjų rengiamos prezentacijos pasižiūrėti, ką jums rūpimais klausimais jie turi.

Derinant poreikius su pamatytais produktais, reikalavimai yra detalizuojami ir

tikslinami. Parengus detalius reikalavimus, daromi nauji sprendimai. Kas geriau -

kurti individualių reikalavimų PĮ, ar pirkti gatavą PĮ. Kokį įsigijimo būdą geriausia

rinktis? Kokios patirties trūksta ir ką pagalbai kviestis į darbo grupę? Kai

išsiaiškinami šie klausimai, rengiamas įsigijimo projekto planas, kuriame

numatomos kitos veiklos. Svarstant naujas veiklas, gali būti koreguojami anksčiau

parengti PĮ reikalavimai. Kai viskas išsiaiškinama, toliau, pvz., gali būti svarstomi PĮ

intelektinės nuosavybės teisių klausimai. Pastarųjų sprendimas gali turėti įtakos

parengtiems dokumentams, būsimai PĮ priežiūrai. Taigi, įvairios veiklos atsiranda

ankstesniųjų pagrindu ir tampa pagrindu kitoms. PĮ įsigijimas yra iteratyvinis

procesas.

Nagrinėdami įsigijimo proceso veiklas, jų seką, dažniausiai laikysime, kad PĮ

reikalavimai rengiami prieš sandorio su tiekėju sudarymą ir jie tampa prašymo teikti

pasiūlymus (RFP) dalimi.

Nežiūrint to, kad PĮ įsigijimo procese veiklų eilės tvarka gali varijuoti, yra

keletas pastovių išskirtinių veiklų:

- grupės sudarymas. Pradėjus projektą, įsigijimo grupė turi būti sudaryta

kaip galima greičiau. Kai kuriais atvejais grupės nariai gali būti

neformaliai paskirti dar iki oficialios projekto pradžios;


27

- išankstinis planavimas. Netgi tos veiklos, kurios bus atliekamos projekto

pabaigoje (PĮ testavimas priėmimo metu, darbuotojų mokymas, PĮ

priežiūra), turi būti planuojamos iš anksto;

- kalendorinio darbų grafiko rengimas. Daugumos nesėkmingų projektų

kalendorinis darbų grafikas buvo sudarytas neatsižvelgiant į PĮ

reikalavimus. Nežiūrint natūralaus reikalavimų augimo, grafike dažnai

neskiriama laiko nenumatytoms veikloms atlikti;

- PĮ reikalavimų rengimas ir sandorio su tiekėju sudarymas. Šios veiklos

sąlygoja daugelį kitų veiklų. Jos turi būti svarstomos kartu.

6.1 pav. pavaizduotos PĮ įsigijimo veiklos ir apytikris jų atlikimo grafikas. Tai

tik bendras darbų grafikas, kuris gali žymiai skirtis įvairiuose įsigijimo projektuose.

Viskas pradedama nuo darbo grupės sudarymo, kas yra visų kitų veiklų būtina

sąlyga. Kai kurios veiklos yra nenutrūkstamos, kurios paveikslėlyje vaizduojamos

stačiakampiu be vienos kraštinės ir su rodykle. Tikslus eiliškumas ir įvairių veiklų

trukmė priklauso nuo konkretaus įsigijimo projekto, o paveikslėlyje jos yra išdėstytos

prisilaikant viršuje parodytų įsigijimo fazių: išankstinės veiklos, PĮ kūrimo, PĮ

naudojimo. Trikampiais pažymėti įsigijimo projekto kontroliniai taškai.

Pastebėkime, kad 6.1 pav. nėra veiklų, susijusių su tiekėjo išrinkimu ir

sandorio sudarymu. Jos parodytos 6.2 pav. Pastarajame paveikslėlyje dar kartą

parodyta grupės sudarymo veikla, nes ji yra visa ko pradžia. Sprendimai kurti naują

ar pirkti gatavą PĮ ir kokį sandorio tipą rinktis atspindimi prašyme teikti pasiūlymus

(RFP) ir galutiniame sandoryje. Viešojo sektoriaus institucijoms tiekėjo išrinkimas

yra būtinas formalus procesas. Netgi perkant gatavą PĮ, turi būti parengtas prašymas

teikti pasiūlymus (RFP).

6.2 pav. parodyta, kad intelektinės nuosavybės teisių klausimai turi būti

aptarti iki sandorio pasirašymo (plačiau žiūr. 13 skyriuje). Tuo tarpu PĮ reikalavimų

peržiūros laikas priklauso nuo sandorio. Jei pasirenkamas santykinai nelankstus

įsigijimo sandorio tipas, reikalavimai turi būti peržiūrėti iki sandorio sudarymo.

Lankstesnio sandorio atveju reikalavimų peržiūra gali būti atliekama po sandorio

sudarymo. Todėl PĮ reikalavimų peržiūrą vaizduojantis stačiakampis nupieštas

punktyrine linija.

Išankstinė veikla

PĮ kūrimas

PĮ naudojimas ir priežiūra

Grupės

sudarymas

Plano

rengim

as

Pro

jekto planas

Projekto sam

prata

PĮ reikalavim

ų

rengim

as

PĮ reikalavim

ų

peržiūra

Galutiniai

reikalavim

ai

PĮ reikalavim

ų valdymas

PĮ naudojimo aplinkos

apibrėžimas

Pro

jekto darb

ų gra

fikas

Tikrinim

as ir priėm

imas

Mokymas

Priežiūra

Projekto valdymas

PĮ konfigūracijos valdymas

Rizikos valdymas

6.1 pav. Apytikslis PĮ įsigijimo proceso veiklų grafikas

Priėm

imo testų ir priežiūros planavim

as

PĮ priėm

imas

Grupės

sudarymas

Sprendim

o

kurti naują ar

pirkti gatavą PĮ

priėm

imas

Sandorio tipo

pasirinkim

as

Prašymo

teikti pasiūlymus

(RFP) rengim

as

Tiekėjo

išrinkim

as

Intelektinės

nuosavybės

teisių klausimų

sprendim

as

PĮ reikalavim

ų

peržiūra

Sandorio

sudarymas

6.2 pav. Apytikslis tiekėjo išrinkimo veiklų grafikas


30

Su PĮ savybėmis susijusios veiklos ir tiekėjo išrinkimo veiklos pavaizduotos

skirtinguose paveikslėliuose todėl, kad išvengtume neaiškumų dėl jų laiko

grafikų. Šių dviejų veiklos aibių laikų santykis priklauso nuo įvairių veiksnių,

ypač nuo pasirinkto įsigijimo būdo:

- rekomenduojama rinktis tokį įsigijimo būdą, kuris sudaro sąlygas

daugumą 6.1 pav. pavaizduotų veiklų, įskaitant PĮ reikalavimų rengimą

ir priėmimo testavimo planavimą, atlikti užsakovui bendradarbiaujant

su tiekėju. Tokiu atveju ką tik paminėtos veiklos turėtų būti atliekamos

po tiekėjo išrinkimo;

- įsigijimo projektuose, kur nusprendžiama pirkti gatavą PĮ, reikalavimų

rengimo procesas gali būti žymiai supaprastintas, pateikiant tik būtinus

pirkimams atlikti bendruosius reikalavimus, t.y. PĮ savybių sąrašą (jame

taip pat turi būti PĮ priėmimo proceso reikalavimai bei formalus

prašymas teikti pasiūlymus). Tai pavaizduota 6.3 pav. Pradžioje

užsakovas gali nenorėti užsiimti išsamių reikalavimų rengimu, ir tai

nėra tik nenorėjimo reikalas. Gatavos PĮ pirkimo atveju jie tokie nėra

reikalingi, netgi gali trukdyti sprendimo pirkti gatavą PĮ, kuri atitinka

didžiumą užsakovo poreikių, priėmimui.

Pastebėkime, kad 6.3 paveikslėlio kairės pusės šakoje „pirkti“ nėra

išsamių reikalavimų rengimo veiklos. Taip pat atkreiptinas dėmesys į

tai, kad paveikslėlio dešinės pusės šakoje „kurti“ išsamūs reikalavimai

gali būti rengiami iki tiekėjo išrinkimo, priklausomai nuo pasirinkto

sandorio tipo. Tai dar kartą patvirtina, kodėl tarp 6.1 ir 6.2

paveikslėliuose pavaizduotų veiklų galimi poslinkiai.

Dar viena pastaba dėl 6.3 pav. pavaizduotų veiklų yra ta, kad darbo

grupė turi bendradarbiauti ne tik su naujos PĮ kūrėju, bet ir su gatavos

PĮ tiekėju, jei įsigytas produktas dar turi būti adaptuojamas

individualiems užsakovo poreikiams. Tik tiekėjas žino, kuris užsakovo

pageidavimas daryti gatavos PĮ pakeitimus yra nesudėtingas, o kuris

pareikalaus sudėtingo pertvarkymo ir rizikos. Pasikliauti užsakovo

intuicija negalima;

- tiekėjo (kūrėjo) atliekama PĮ konfigūracijos valdymo veikla dažniausiai

nedomina užsakovo ir galėtų būti pašalinta iš 6.1 paveikslėlio;

- fiksuotos kainos ar kitokiuose santykinai nelanksčiuose sandoriuose PĮ

reikalavimai rengiami dar iki sandorio sudarymo (6.2 pav.).

Reikalavimai peržiūrimi taip pat iki sandorio sudarymo.


31

Trumpai tariant, du veiklų atlikimo grafikai (6.1 ir 6.2 pav.) priklausomai

nuo aplinkybių gali būti horizontaliai paslinkti vienas kito atžvilgiu. Veiklų

atlikimo eiliškumas šiuose paveikslėliuose taip pat gali kažkiek varijuoti.

Bendrieji PĮ

reikalavimai

Kurti

ar

pirkti?

PĮ savybių

sąrašo

sudarymas

Produkto

išrinkimas

Sandorio

tipo

pasirinkimas

Išsamių PĮ

reikalavimų

rengimas

Užsakymo

vykdymas

Tiekėjo

išrinkimas

pirkti kurti

6.3 pav. Išsamūs PĮ reikalavimai iš anksto rengiami ne visada


32

7. Darbuotojų grupės PĮ įsigyti sudarymas

Grupė – tai nedidelis būrelis įvairius sugebėjimus turinčių žmonių,

siekiančių ir dirbančių bendram tikslui bei atsakingų už tai, kas juos vienija.

Transporto, statybų ar kitokių sričių inžinieriai ir planuotojai yra gerai

pasirengę vykdyti savo srities darbus. Tačiau PĮ įsigijimo klausimams spręsti

būtina kitokia patirtis, kuri skiriasi nuo anksčiau sukauptos pagal organizacijų

veiklos profilį. Geriems rezultatams pasiekti būtina sudaryti profesionalių,

įvairiapusę patirtį turinčių darbuotojų grupę. Nebandykime daryti to vieni.

Apskritai paėmus, tai nėra vien tik tam tikrus įgūdžius turinčių žmonių

surinkimas, o yra pasišventusių bendram tikslui žmonių grupės sudarymas.

Galimas biurokratinis pasipriešinimas turi būti nugalėtas. Tam dažnai prireikia

gero vadybininko ir derybininko sugebėjimų. Asmeninės ambicijos turi būti

atmestos; reikalingas geras iškalbingumas. Tik taip galima pasiekti gerų

rezultatų.

Ką reikėtų įtraukti į grupę?

Šių sričių specialistai reikalingi PĮ įsigijimo grupėje:

- PĮ techniniai ekspertai. Jie reikalingi PĮ reikalavimų pagrįstumui

įvertinti, PĮ apimčiai ir kainai įvertinti, techniniams dokumentams

peržiūrėti, kaip pagalbininkai ryšiui su PĮ tiekėjais palaikyti, padėti

įsigijimo projekto vadovui prižiūrėti įsigijimo proceso veiklų atlikimą.

Gali atrodyti, kad ekspertai turi turėti kompiuterių programavimo

patirties. Iš tikro pageidautina PĮ inžinerijos, sistemų inžinerijos arba PĮ

vadybininko patirtis. Tokius specialistus sunku rasti, pasamdyti ir

išlaikyti, ypač viešojo sektoriaus institucijoms. Tai skatina glaudžiai

bendradarbiauti su tiekėju;

- tiesioginiai PĮ naudotojai (angl. end users). Jie turi dalyvauti rengiant

naudotojo reikalavimus ir įtraukiami į greitą prototipų (PĮ sąsajų, kt.)

rengimo veiklą. Jie bendrauja su PĮ tiekėjais, vertina PĮ patogumo

naudoti požiūriu. Tiesioginių naudotojų ir inžinierių požiūriai į PĮ

skiriasi. Inžinieriai dažniausiai turi didelę darbo kompiuteriais patirtį, o

tiesioginiai naudotojai – ne. Kas atrodo lengva ar paprasta inžinieriui,

tas gali būti visai nesuprantama tiesioginiam naudotojui. Turi būti

suformuota bendra projektuotojų, užsakovo ir naudotojų terminologija

atviriems ir aiškiems ryšiams (kontaktams, bendravimui) palaikyti.

Vienas arba keli tiesioginiai PĮ naudotojai turi būti įtraukti į įsigijimo


33

projekto grupę nuo pat pradžios, nors jie vėliau gal ir nebus įsigyjamos

PĮ naudotojai. Įsigijimo vertė bus didesnė, nes naudotojai jaučia, kuo jie

galėtų prisidėti prie PĮ sukūrimo. PĮ tampa bendras tikslas, o ne

grėsmė, ir naudotojai suvokia priimamų sprendimų ar kompromisų

pagrindą. PĮ tampa jų nuosavas kūrinys, o ne kažkas primesta. Taigi,

nuomonė, kad tiesioginiai naudotojai yra svarbiausi grupės nariai ir

nuo jų žymia dalimi priklauso projekto sėkmė, yra teisinga;

- PĮ prižiūrėtojai ir administratoriai. Šie asmenys nėra tiesioginiai PĮ

naudotojai, o tik atsako už PĮ veikimą ir atnaujinimą. Jie turi gerą

supratimą apie PĮ priežiūrą, žinių apie įvairių PĮ ar sistemų sąsajas, kas

turi būti tinkamai atspindėta prašyme teikti pasiūlymus (RFP) bei

sandoryje su tiekėju. Dėl savo unikalaus vaidmens prižiūrėtojai ir

administratoriai jie turi kitokį požiūrį į PĮ, nei techniniai ekspertai ir

tiesioginiai naudotojai. Jie gali siūlyti į PĮ įtraukti priemones,

įgalinančias greičiau rasti ir pašalinti gedimus. Jie gali būti geri

pagalbininkai rengiant PĮ dokumentų reikalavimus ir peržiūrint tiekėjo

pateiktus dokumentus, ar juose yra PĮ priežiūrai atlikti reikalinga

informacija;

- PĮ naudojimo ekspertai (angl. domain experts). Pagal savo kompetenciją

pradžioje jie išdėsto savo poreikius, o vėliau įvertina, ar PĮ atitinka

puoselėtas viltis. Šie ekspertai gali būti labai naudingi pravedant PĮ

naudotojų mokymus, padeda naudotojams geriau išnaudoti PĮ

galimybes.

- sandorių sudarymo ir viešųjų pirkimų pareigūnai gali padėti parinkti

geriausią įsigijimo būdą. Šie pareigūnai įsigijimo pradžioje padeda

išsiaiškinti neįprastus PĮ įsigijimo aspektus. Pvz., gali būti svarbus

sudaromo sandorio lankstumas tokiais klausimais, kaip PĮ reikalavimų

valdymas, nuosekli projektavimo (kūrimo) eiga arba sąsajų prototipų

greitas rengimas. Tačiau šie klausimai sandorių sudarymo ir viešųjų

pirkimų pareigūnams gali būti mažai žinomi. Jie įpratę daugiau

rūpintis alternatyviais įsigijimo būdais, tiekėjo išrinkimo procedūromis,

kas dažniausiai svarbu įvairiuose įsigijimo, pvz., statybų, projektuose.

Todėl darbo grupei gali tekti spręsti, ar reikia kviestis pagalbos iš kitur,

jei šie užsakovo pareigūnai neturi patirties PĮ įsigijimo klausimais.

Įsigijimo projekto pradžioje įtraukus sandorių sudarymo ir viešųjų

pirkimų pareigūnus į darbo grupę, reikia duoti jiems laiko adaptuotis

prie PĮ įsigijimo niuansų. Įtraukus juos į PĮ įsigijimo procesą paskutinę


34

minutę ir reikalaujant veiksmų, su kuriais jie nėra gerai susipažinę,

tikriausiai, rezultatai bus prasti;

- PĮ srities teisininkai reikalingi intelektinės nuosavybės teisių

klausimams spręsti. Jų rūpestis yra sunkių licencijavimo, garantijų,

nuosavybės teisių ir autorystės klausimų nagrinėjimas. Kadangi PĮ

teisiniai klausimai sprendžiami labai sunkiai, dažnai tenka kviestis

pagalbą iš kitur;

- vertėjai. Į darbo grupę dažnai įtraukiami asmenys, turintys įvairių sričių

žinių ir galintys išversti techninius tekstus, žargoną ir sprendžiamos

problemos sąvokas. Pvz., tai gali būti asmuo, išmanantis PĮ ir turintis

žinių sveikatos apsaugos srities informacijos tvarkymo klausimais.

Visiems suprantamos kalbos naudojimas padeda gerinti bendravimo

kokybę.

Kur reikėtų ieškoti žmonių sudarant darbo grupę?

Įsigijimo grupei reikalingų žmonių geriausia ieškoti savo institucijos

įvairiuose padaliniuose. Už institucijos informacijos resursų tvarkymą atsakingi

asmenys gali turėti patirties geografinių informacinių sistemų (GIS) ir duomenų

bazių valdymo sistemų (DBVS) srityje. Todėl jie galėtų būti įtraukiami į grupę. Ši

rekomendacija yra daugiau bendro pobūdžio, nes ne visada šių specialistų gali

reikėti. Tokie specialistai galėtų peržiūrėti projektą, maloniai atitrūkdami nuo

tiesioginių pareigų savo darbo vietoje. Reikia tik rasti skatinimo priemones, kad

jie įsijungtų į sudaromą grupę.

Atkreiptinas dėmesys į riziką, kai asmens kompetencijos ir patirties

panaudojimas PĮ įsigijimo projekte gali būti neaiškus. Netgi jei asmuo turi įgijęs

patirtį ankstesniuose PĮ pirkimuose, ji nebūtinai tiks jūsų projekte. Pvz.,

organizacijos įsigyta standartinė DBVS, gerai tinkanti įrašams apie asmenis

tvarkyti, gali būti visiškai netinkama sudėtingose realaus laiko reikalavimų

sistemose.

Jeigu asmens su reikiama patirtimi nėra jūsų organizacijoje, galima

samdyti specialistą iš šalies. Tačiau kartais tai gali sukelti tam tikrų problemų.

Tiekėjai skundžiasi dėl įsigijimo projektų, kuriuose techniniai ekspertai samdomi

PĮ reikalavimams parengti ir jiems vėliau leidžiama dalyvauti konkursuose dėl PĮ

kūrimo. Tokie ekspertai, rengdami prašymą teikti pasiūlymus (RFP), laimi laiko ir

į reikalavimus įtraukia savo gaminamų produktų savybes. Tai gali turėti įtakos

tiekėjo išrinkimui ir būti interesų derinimą reglamentuojančių teisės aktų

pažeidimo priežastimi. Kita vertus, visa tai išryškina potencialią ekspertų

samdymo problemą, kai viešojo sektoriaus institucijoms prireikia PĮ ekspertų


35

pagalbos, tvarkant reikalus su PĮ tiekėjais. PĮ tiekėjai skundžiasi, kad ekspertus

samdančios organizacijos ryšiai su tiekėjais darosi neaiškūs: ekspertai išreiškia

organizacijos nuomonę ar savo?

Kai kuriais atvejais PĮ įsigyjančioje organizacijoje žmonės galėjo neturėti

jokių sąlygų reikiamai patirčiai PĮ srityje įgyti. Tokiais atvejais kitokių pareigybių

darbuotojai gali atstovauti tiesioginiams PĮ naudotojams. Prireikus šito, turėtų

būti kviečiami asmenys, kurių išsilavinimas yra panašus, kaip ir būsimų

tiesioginių PĮ naudotojų. Apskritai, sudarant grupę, pagrindinis interesas yra

geros PĮ įsigijimas.

Paskiausiai įtraukiamas grupės narys

Įsigijimo grupės sudarymo etape pasigendama dar vieno svarbaus nario -

PĮ tiekėjo. Kai sudaromas sandoris su tiekėju, būtina išplėsti darbo grupę,

įtraukiant į ją PĮ tiekėją. Tai labai svarbus narys, nežiūrint ar kuriama nauja, ar

perkama gatava PĮ.

Nors tiekėjo traktavimas kaip grupės nario gali atrodyti neįprastai, tačiau

priešingų pusių sutartiniai santykiai turėtų būti draugiški ir keliantys

pasitenkinimą. Jei tas pavyksta, tai yra dar vienas pavyzdys, kad PĮ skiriasi nuo

kitokių objektų ir jos įsigijimo procesas yra kitoks. Tiekėjo įtraukimas į PĮ

įsigijimo grupę yra draugiškumo gestas, kaip ir partnerystė, pvz., statybiniuose

projektuose. Partnerystė – tai bendradarbiavimas ir glaudūs santykiai, kurie

būtini sprendžiant neišvengiamus projekto apimties, kainos ir kalendorinio darbų

plano klausimus.

Kai po sandorio sudarymo tiekėjas įsijungia į darbo grupę, iki sandorio

sudarymo buvę nariai turi išlikti grupėje. Tiesioginiai PĮ naudotojai ir toliau turi

tęsti savo svarbų vaidmenį. Sandorių sudarymo ir viešųjų pirkimų pareigūnų bei

PĮ srities teisininkų vaidmuo sudarius sandorį gali pasidaryti ir mažesnis.


36

8. Įsigijimo projekto planavimas

Kiekvienas PĮ įsigijimo projektas turi būti pradedamas plano – glausto ir

dalykiško dokumento - rengimu. Jame turi būti atspindėti projekto bendrieji

tikslai ir sprendimai. Pradžioje užsakovo sudaryta įsigijimo grupė gali neturėti

visų atsakymų. Tai nieko blogo. Paliekami tušti skyriai plane, prie kurių bus

grįžtama vėliau.

Skirtingose organizacijose toks planas gali būti vadinamas įvairiai:

„įsigijimo strategija“, „projekto valdymo planas“, „PĮ kūrimo valdymo planas“, kt.

Kartais planas dalinamas į dvi arba daugiau dalių, kaip valdymo planas, įsigijimo

planas, kt. Tačiau kaip jį bevadintume ar dalintume, planas turi būti sudarytas.

Vienas žymiausių pasaulyje vadybos mąstytojų Tom Peters teigia, kad

įmonės teoriškai žino, bet dažniausiai nesilaiko svarbiausių verslo principų, tokių

kaip aiški strategija, paprasta organizacinė stuktūra, minimalus darbuotojų kiekis

(lean staff), autonomijos suteikimas, mažiau planavimo – daugiau veiksmo

principo [DELFI, 2009 01 25, Prieš krizę padeda kovoti konkretūs veiksmai ir

profesionalų patarimai]. ??? – V. Undz.

Kada rengti planą?

PĮ įsigijimo projekto planas rengiamas tuoj po grupės sudarymo. Praktiškai

du žingsniai yra iteraciniai. Iniciatorius (pirmas grupės narys) gali parengti

pirmąją plano versiją. Ši versija gali padėti įvardinti kitus asmenis, kuriuos

reikėtų įtraukti į grupę, ir gali pasitarnaut kaip pradinės sampratos apie įsigijimo

tikslus aiškinimo priemonė potencialiems grupės nariams. Kai grupė

suformuojama, kiti jos nariai gali prisidėti prie tikslesnės plano versijos rengimo.

Jų dalyvavimas PĮ įsigijimo planavime nuo pat pradžios gali turėti didelę įtaką

projekto sėkmei.

Į projekto pradžioje parašytą pradinį planą turi būti žiūrima kaip į

gyvybingą dokumentą. Periodiškai jis turi būti peržiūrimas, kad atitiktų

einamuosius projekto tikslus ir pasiekimus.

Plano nauda

Projekto planas yra gera įsigijimo grupės narius vienijanti priemonė.

Planas yra reikšmingas politinis dokumentas, palaikant ryšį su projekto

įgyvendinime tiesiogiai nedalyvaujančiais asmenimis, ypač organizacijos

vadovybe. Kai sprendimus priimantys vadovai ir finansų analitikai paprašo

projekto aprašo, grupės parengtas planas yra kaip tik tai, ką reikėtų jiems


37

pateikti. Tai sukelia pasitikėjimą, kas vėliau yra labai svarbu įvairiose projekto

biudžeto peržiūrose. Planas gali labai praversti ir tada, kai kažkam prireikia tik

bendrosios projekto informacijos. Labai patogu, kai plano dalis gali kopijuoti ir

perkelti į kitus dokumentus, nes frazės ir mintys jau yra suderintos.

Kas turėtų būti plane?

Nėra universalių taisyklių, ką reikėtų nurodyti plane. 8.1 lentelėje

pateikiami tik kai kurie pasiūlymai. Kadangi dauguma šios lentelės punktų tinka

įvairių tipų projektams, pasvirusiu šriftu (italic) pažymėti tie, kurie yra daugiau

svarbūs PĮ įsigijimo projektams. Apskritai, kiekviena organizacija gali turėti savo

nuostatas, ką reikėtų traukti į planą.

Kai kurių 8.1 lentelėje nurodytų veiklų tam tikrais laiko etapais gali ir

neprireikti. Pvz., PĮ priėmimo, naudotojų mokymo, priežiūros veiklų nereikės tol,

kol PĮ nebus sukurta. Nepaisant to, jos turi būti suplanuotos iš anksto ir joms turi

būti numatytas biudžetas. Įsigijimo grupei gali trūkti informacijos, ir todėl

pradinėje plano versijoje šios veiklos gali būti neatspindėtos. Po pirmosios plano

versijos paskelbimo planavimas nenutraukiamas. Visi plano klausimai turi būti

apsvarstyti iki sandorio su tiekėju sudarymo.

Pradėdama rengti planą, grupė tikriausiai nežinos atsakymo nė į vieną 8.1

lentelės klausimą. Todėl rekomenduojama jame palikti tuščias vietas, kurios

užpildomos atsiradus mintims.

8.1 lentelė. Įsigijimo projekto plano dalys

Nr. Plano dalis Plano dalies turinys

1. Projekto aprašas Trumpa projekto esmė, jo tikslai ir apimtis.

2. Pagrindimas Kodėl reikia įsigyti PĮ: organizacijos lėšų taupymas, darbuotojų krūvio mažinimas, esamų paslaugų kokybės gerinimas, našumo didinimas.

3. Projekto darbų grafikas

Bendrasis darbų grafikas, nurodant pagrindinius įsigijimo projekto kontrolinius taškus.

4. Projekto dalyviai, jų pareigos

Kas bus projekto vadovas? Įsigijimo grupės sudėtis ir dydis. Kokios organizacijos bus įtrauktos į projektą? Kiekvienos organizacijos kontaktiniai asmenys, jų vaidmuo. Kas bus atsakingas už naudotojų mokymus, PĮ priežiūrą? Įsigyjančiosios organizacijos schema.

5. Sąmata ir finansavimo šaltiniai

Sudaryta sąmata ir finansavimo šaltiniai peržiūrimi atsižvelgiant į projekto etapus ir įsigyjančiosios organizacijos galimybes.


38

6. Darbo sąlygos Kur bus atliekami projekto darbai? Kur bus diegiama PĮ baigus projektą? Ar reikės kokios nors specialios įrangos ar priemonių?

7. Įsigijimo strategija Ar visa PĮ bus kuriama nauja? Kokių gatavų komponentų reikės ieškoti ir pirkti? Kaip tokie komponentai bus integruojami į kuriamą PĮ? Ar negalima būtų panaudoti kitų projektų PĮ dalių? Ar PĮ bus kuriama laipsniškai keliais etapais, kiekviename formuojant kito etapo uždavinius? Ar bus kuriamas prototipas? Kaip įsigyti gatavi komponentai bus integruojami vienas su kitu?

8. Aplinka Su kokiomis kitomis anksčiau turėtomis sistemomis įsigyjama PĮ turės sąveikoti? Su kokiomis kitomis organizacijomis reikės palaikyti ryšius ir kokia tų ryšių (santykių) jurisdikcija?

9. Standartai Kokių techninių standartų turi būti laikomasi?

10. Pagrindinė rizika ir jos valdymas

Kokia yra pagrindinė rizika? Kaip bus valdoma rizika?

11. Sandorių strategija

Kokie darbai bus atliekami pačioje įsigyjančiojoje organizacijoje? Kokiems darbams reikės sandorių su tiekėjais? Ar bus samdomi konsultantai?

12. Sandorių tipas Kokie galimi variantai: fiksuotos kainos, išlaidas padengiantysis, laiko ir medžiagų apmokėjimo sandoris? Projektavimo, kūrimo ar PĮ priežiūros sandoris? Kiek sandorių reikės?

13. Sandorių valdymas

Kaip bus prižiūrimas sandorių vykdymas? Kaip bus vertinama ir valdoma projekto eiga?

14. Tiesioginiai naudotojai

Kas betarpiškai naudos PĮ? Kas administruos ir prižiūrės PĮ? Kokie yra žmogiškieji ir apmokėjimo už jų darbą resursai?

15. Priėmimo strategija Koks bus PĮ priėmimo pagrindas?

16. Mokymas Kaip bus mokomi PĮ naudotojai?

17. Priežiūra Kaip PĮ bus prižiūrima po jos priėmimo?

18. Apribojimai Kokia yra tikrovė, su kuria privaloma skaitytis?


39

9. Įsigyjamos PĮ reikalavimai

Sunkiausia įsigijimo proceso dalis yra preciziško sprendimo, kokią PĮ

norime įsigyti, priėmimas. Nė vienos kitos įsigijimo proceso dalies klaidos taip

smarkiai neiškraipo puoselėjamos galutinės PĮ, kaip PĮ reikalavimų klaidos. Tai

įsigijimo proceso dalis, kurios klaidas vėliau sunkiausia ištaisyti.

9.1. Reikalavimų rengimas

Reikalavimų svarba

Gerų reikalavimų rinkinys yra svarbiausia, ką įsigyjančioji organizacija

turėtų parengti PĮ įsigijimo procese. Tai yra svarbu ir viešajame, ir privačiajame

sektoriuje. Realių projektų tyrinėjimais įrodyta, kad atsakingas dėmesys

reikalavimams turi teigiamą poveikį PĮ kokybei ir našumui. Projektų bėdos

dažniausiai atsiranda dėl nepakankamai gerai parengtų PĮ reikalavimų. Pastebėti

trys pagrindiniai reikalavimų trūkumai: naudotojų pastangų (indėlio) rengiant

juos nebuvimas, reikalavimų nepakankamumas, reikalavimų kaita. Tai

pagrindinės priežastys, dėl ko PĮ įsigijimo projektai vėluoja, viršijamas biudžetas

arba PĮ funkcionalumas būna mažesnis.

Reikalavimų svarba pasireiškia tuo, kad jie padeda suvienodinti užsakovo

ir tiekėjo sampratą apie PĮ ir tampa įsigijimo projekto planavimo ir valdymo

pagrindu. Jie yra:

- įsigijimo projekto apimties, darbų grafiko ir sąmatos pagrindas;

- sprendimo kurti naują ar pirkti gatavą PĮ pagrindas;

- projektavimo, kūrimo ir sukurtos PĮ testavimo priėmimo metu veiklų

pagrindas.

Gerai parengti reikalavimai yra svarbūs ir projekto kainos požiūriu.

Reikalavimų trūkumai gali sukelti problemas vėlesnėse projekto stadijose. Kuo

vėliau šie trūkumai išryškėja, tuo daugiau kainuoja jų pašalinimas. Įprasta

laikyti, kad einant nuo vienos PĮ gyvavimo ciklo fazės prie kitos, reikalavimų

klaidos ištaisymo kaina išauga dešimt kartų. Šis daugiklis taikytinas ir

reikalavimų koregavimo atveju – kuo vėliau tai daroma, tuo brangiau atsieina.

Kas rengia reikalavimus

Labai svarbu, kad įvairią patirtį turintys užsakovo žmonės aktyviai

įsijungtų į PĮ reikalavimų rengimą. Įsigijimo grupės narių vaidmenys rengiant PĮ

reikalavimus pateikti 9.1 lentelėje.


40

9.1 lentelė. Grupės narių vaidmenys rengiant PĮ reikalavimus

Nr. Grupės nario patirtis Grupės nario vaidmuo

1. PĮ naudojimo ekspertas

Rūpinasi, kad PĮ atitiktų naudotojų darbinius poreikius.

2. PĮ techninis ekspertas

Padeda rengti reikalavimus, peržiūri, ar jie yra pakankami, aiškūs, neprieštaringi, patikrinami ir įgyvendinami. Šie ekspertai gali užsiimti greitu prototipų rengimu dar iki tiekėjo išrinkimo, vietoje to, kad tai vėliau darytų išrinktas tiekėjas.

3. Tiesioginis PĮ naudotojas

Rūpinasi, kad reikalavimai atitiktų tiesioginių naudotojų poreikius (naudotojai dažniausiai turi kitokį supratimą ir požiūrį į PĮ, nei jos kūrėjai).

4. Prižiūrėtojas, PĮ administratorius

Jų uždavinys yra kelti tokius reikalavimus, kurie turi įtakos greitesnei PĮ sutrikimų diagnostikai ar jos dalių priežiūrai vietiniu arba nuotoliniu metodu. Inžinieriai ar tiesioginiai naudotojai į tai dažnai žiūri tik kaip į tolimą perspektyvą.

Reikalavimai yra rengiami kolektyviai, grupės nariams tariantis

tarpusavyje. Būtina išklausyti tiesioginių naudotojų kartais netgi perdėtus

reikalavimus, tačiau nebūtina priimti juos iš karto. Patartina siūlyti kompromisą,

pvz., „šiandien nesame pajėgūs įsigyti PĮ, atitinkančios visus poreikius, tačiau

trūkstamas funkcijas įdiegsime kaip galima greičiau“.

Reikalavimų rengimo pradžia

PĮ reikalavimų rengimo pradžioje visų pirma reikia išsiaiškinti, ko ir kodėl

jūs norite. Visi grupės nariai turi būti įtraukti į reikalavimų rengimą.

Kolektyviniai naujų idėjų svarstymai, naudotojų apklausos yra pagrindiniai būdai

reikalingai informacijai gauti.

Reikalavimų rengimas gali susidėti iš keleto iteracijų. Pirmieji grupės

susirinkimai gali būti reikalingi sutarimui (konsensusui), kokią problemą norima

išspręsti ir kokia PĮ tam reikalinga, pasiekti. Būtina nustatyti šaukiamų

susirinkimų ar naudotojų apklausų temas ir fiksuoti tai dokumentuose. Šie

dokumentai peržiūrimi vėlesniuose grupės susirinkimuose. Kiekvieną kartą

reikėtų nustatyti reikalavimų prioritetą.

PĮ samprata yra reikalavimų rengimo pagrindas. Su PĮ vizija savo galvoje

jūs galite lankyti kitas organizacijas, kur panaši PĮ yra įdiegta, arba prekiautojų

parodas. Tai suteikia galimybę susipažinti su kitur įdiegtos PĮ savybėmis, su jų

atitikimu jūsų poreikiams. Kartais tai padeda atskleisti naujas PĮ panaudojimo


41

galimybes arba, priešingai, pastebėti trūkumai sumažina norą pirkti gatavą PĮ.

Tokie apsilankymai gali sumažinti riziką arba beprasmiškų reikalavimų priėmimo

tikimybę. Tačiau tiems užsakovams, kurie neturi savo vizijos, kitose

organizacijose pamatytos PĮ geros savybės gali sukelti susižavėjimą. Jie gali

nuspręsti reikalauti kažkokių PĮ savybių diegimo ne todėl, kad jų reikia, o todėl,

kad jos yra įspūdingos.

Užsakovas gali prašyti pardavėjų pademonstruoti (dažniausiai užsakovo

organizacijoje) gatavą PĮ ir supažindinti su jos dokumentais. Tokiu būdu

sužinoma, kas yra siūloma rinkoje. Tai skatina formuluoti aukštesnius

reikalavimus, bet daro kliūtis sprendimo pirkti gatavą PĮ priėmimui. Kartais

nedideli, iš pažiūros smulkūs reikalavimai gali būti pernelyg varžantys. Tokie

reikalavimai gali būti supaprastinami arba atmetami. Kitaip tariant, grupės

tikslas yra parengti minimalių reikalavimų rinkinį, kuris atitiktų užsakovo

poreikius ir kad kiek galima daugiau gatavų produktų atitiktų juos.

Dėmesys gataviems produktams ir kompromisų dėl produkto

funkcionalumo, kainos ir darbų grafiko darymas – tai rekomenduojama

komercinė praktika.

Nors žvalgymasis kitose organizacijose ir gatavos PĮ demonstravimų

lankymas kai kuriais įsigijimo atvejais yra rekomenduojami, tačiau tai nėra

sėkmės garantas. Jie taip pat turi trūkumų. Kai kas domėjimąsi, kaip yra kitose

organizacijose, laiko labai naudingu. Tačiau yra tam tikra rizika, nes užsakovui

tai gali sužadinti norą perimti vienus reikalavimus iš vienos pamatytos PĮ, kitus –

iš kitos. Technologijos gali užhipnotizuoti užsakovą taip, kad bus parengti

mišriūs ar hibridiniai PĮ reikalavimai, atspindintys „viską po truputį“. Tai tampa

kliūtimi priimti sprendimą pirkti gatavą PĮ. Tokie reikalavimai bus vieninteliai ir,

kažin, ar priimtini. Tai tik dar kartą patvirtina bendrųjų poreikių ir PĮ sampratos

turėjimo visų pirma svarbą. Tik turint savo PĮ viziją derėtų žvalgytis po kitas

organizacijas ar lankyti PĮ pardavėjų demonstracinius renginius ir po to

formuluoti savo specifinius reikalavimus.

Taip pat reikėtų nepamiršti, kad užsakovui, norint įsidiegti pas save kitur

matytą PĮ, reikės nemažų jos pakeitimų. Idealiu atveju tai būtų tik PĮ kopijos

perkėlimas, jei aplinka yra identiška. Tačiau, priklausomai nuo PĮ, galimos

didelės išlaidos ir rizika, jei bus bandoma diegti kitos organizacijos PĮ be

pakeitimų.

Reikalavimai – tai dokumentas

Kadangi PĮ reikalavimai yra labai svarbi įsigijimo projekto dalis, būtina

juos užrašyti formaliame dokumente ir atidžiai kontroliuoti daromus pakeitimus

(žiūr. 18 skyrių „PĮ konfigūracijos valdymas“). Projektų vykdytojai pabrėžia, kad


42

reikalavimų rašymas yra pats sunkiausias, didelių pastangų reikalaujantis etapas.

Patartina šiai PĮ įsigijimo veiklai skirti tiek laiko ir pastangų, kiek reikia.

Gerų reikalavimų charakteristikos

Reikalavimuose turi būti nurodymai „ką reikia daryti“, o ne „kaip reikia

daryti“. Tai labai skiriasi, pvz., nuo daug kam įprastos projekto specifikacijos.

Projektiniai sprendimai neturi būti traukiami į reikalavimus.

Nors požiūris „kas, o ne kaip“ ir yra teisingas (logiškas), kartais praktikoje

būna sunku jo laikytis. Vieno žmogaus „kas“ (kas turėtų būti daroma) kitam

žmogui gali atrodyti „kaip“ (kaip turėtų būti daroma). Reikalavimų dokumente

turėtų būti dėstomi reikalaujami atlikti darbai, o ne technologiniai reikalavimai.

Tiekėjai dažnai skundžiasi, kad užsakovai reikalauja kurti PĮ pagal pernelyg

griežtų apribojimų techninę specifikaciją. Tai gali padidinti PĮ kainą ir sumažinti

jos efektyvumą. Dėl to taip pat gali būti nepagrįstai atsisakoma pirkti

perspektyvią gatavą PĮ.

Užsakovo norai (siūlomas modelis) gali labai varžyti tiekėją ir versti jį

ribotis nuo naujovių. Tai ypač pavojinga fiksuotos kainos sandoriuose arba kai

tiekėjas verčiamas griežtai laikytis nustatytų reikalavimų. Šią problemą galima

įveikti, leidžiant tiekėjams siūlyti dokumentiškai apipavidalintas reikalavimų

alternatyvas. Užsakovas tuomet turi galimybę lanksčiai reaguoti į pasiūlymus ir

priimti geriausią sprendimą. Jei užsakovas nustato, kad siūloma alternatyva yra

ekonomiškai priimtina, tuomet leidžiamos PĮ reikalavimų korekcijos. Laikantis

tokios lanksčios taktikos, reikėtų nepamiršti užfiksuoti korekcijų sandorio

vykdymo dokumentuose. Priešingu atveju yra tam tikra rizika, kad į pasiūlytas

korekcijas vėliau nebus atsižvelgta, nes nebus griežto jų atitikimo dokumentiškai

patvirtintiems pradiniams reikalavimams.

PĮ reikalavimai turi būti aiškiai suformuluoti, nedviprasmiški, patikrinami,

įmanomi įdiegti, tarpusavyje suderinti. Apskritai, reikalavimai formuluojami

tariamąja nuosaka (pvz., PĮ turėtų daryti ... ). Rekomenduotina dokumente

kiekvieną reikalavimą rašyti iš naujos eilutės ir numeruoti juos.

Kas turi būti PĮ reikalavimų dokumente?

9.2 lentelėje parodyta, kas turėtų būti PĮ reikalavimų dokumente. Joje

reikalavimai skirstomi į keletą kategorijų: funkcinius, eksploatacinių savybių

(performance) ir sąsajos. Tačiau jie gali būti skirstomi ir kitaip. Todėl reikalavimų

eilės tvarka parengtame dokumente gali būti ir kitokia, nei parodyta 9.2 lentelėje.

PĮ reikalavimai - tai ne įsigijimo projekto specifikacija, todėl patartina

juose dar nenurodyti techninės platformos (computing platform) ir operacinės

sistemos. Tačiau yra viena šios nuostatos išimtis: reikalavimuose reikia nurodyti


43

sąsajas su užsakovo organizacijoje jau esamomis sistemomis, su kuriomis

įsigyjama PĮ turės palaikyti ryšį. Netgi jei PĮ reikalavimų rengimas atidedamas

iki tol, kol bus išrinktas tiekėjas, esamas sistemas, su kuriomis įsigyjama PĮ turės

palaikyti ryšį, ir kitus aplinkos aspektus reikėtų nurodyti prašyme teikti

pasiūlymus (RFP).

9.2 lentelė. Kas turėtų būti PĮ reikalavimų dokumente

Nr. Reikalavimai

Funkciniai reikalavimai

1. Ką turi gebėti PĮ. Akcentuojamos funkcijos, o ne aprašinėjami sprendimai, kaip jas reikėtų realizuoti.

2. Reikalavimai funkcijoms. Jie rašomi tariamąja nuosaka ir turėtų būti galimybė patikrinti jų įgyvendinimą (pvz., PĮ turėtų išvesti į monitorių perspėjimus apie neteisingus įvestus duomenis ...).

3. Nurodymai, ar funkcijos turėtų būti atliekamos rankiniu būdu, ar pusiau automatizuotai, ar visiškai automatizuotai (pvz., PĮ turėtų parinkti pranešimą ir išvesti jį į monitorių; operatorius turėtų įvesti pranešimą, kuris būtų išvedinėjamas į monitorių; operatorius turėtų parinkti vieną iš keleto anksčiau parengtų pranešimų, kuris būtų išvedamas į monitorių).

4. Bendrieji žmogaus ir PĮ sąsajos reikalavimai. Gali būti ir detalūs sąsajos reikalavimai, tačiau greitas prototipų regimo ir nuomonių derinimo būdas yra labiau priimtinas šiems reikalavimams parengti.

5. Algoritmai arba matematiniai reiškiniai.

6. Atitiktis teisės aktams, standartams.

Eksploatacinių savybių reikalavimai

7. Vidutinis PĮ reakcijos į kreipinius laikas, leistini reakcijos laiko nukrypimai, kt. (pvz., vidutinis sistemos reakcijos laikas turėtų būti 30 sekundžių, o 90 proc. atvejų reakcijos laikas neturėtų viršyti 40 sekundžių).

8. Įvesties (loading) reikalavimai (pvz., turėtų būti galimybė vienu metu įvesti informaciją nurodyto kiekio ryšio kanalais), šie reikalavimai esant blogiausioms aplinkybėms, kt.

9. Informacijos perdavimo sparta (pvz., transakcijų kiekis per valandą).

10. Sistemos talpa (pvz., turėtų būti galimybė kaupti ir išsaugoti visus 30 dienų laikotarpio įvykių duomenis).

11. Klaidingų pavojaus paskelbimų dažnis (false alarm rates), įskaitant dažnio gavimo algoritmą.


44

12. PĮ tikslumas, nurodant algoritmus.

13. Patikimumas ir priežiūros patogumas (pvz., vidutinis laikas tarp dviejų sutrikimų; vidutinis gedimų pašalinimo laikas).

14. Duomenų saugumas (duomenų apsauga, vientisumas, autentiškumas, kt.).

15. PĮ saugumas (ar PĮ apsaugota nuo sugadinimo, nesankcionuotų pakeitimų, kt.).

Sąsajos: vidinės ir išorinės, duomenų perdavimo sąsajomis kontrolė

16. Sąsaja su išorės įrenginiais, jutikliais, kt. (field devices).

17. Sąsaja su monitoriais.

18. Sąsaja su naudotojais.

19. Sąsaja su kitomis užsakovo organizacijos sistemomis, įskaitant jau veikiančias.

20. Sąsaja su kitų organizacijų sistemomis.

21. Sąsaja su užsakovo organizacijos svarbiausiais padaliniais.

22. Sąsaja tarp PĮ komponentų (pvz., tarp incidentų fiksavimo algoritmo ir duomenų surinkimo).

Įvestis

23. Įvesties duomenų šaltiniai (automatai ar žmonės).

24. Duomenų įvesties dažnis.

25. Įvesties duomenų leistini dydžiai ir matavimo vienetai.

26. Unikalaus identifikatoriaus suteikimo įvesties duomenims reikalavimas.

Išvestis

27. Esamojo išvesties laiko (pvz., išvedant perspėjimus į monitorių) arba kitokio laiko nurodymo būtinumas (pvz., spausdinant suvestines).

28. Išvesties duomenų adresatai (automatai ar žmonės).

29. Duomenų išvesties dažnis.

30. Išvesties duomenų leistini dydžiai ir matavimo vienetai.

31. Unikalaus identifikatoriaus suteikimo išvesties duomenims reikalavimas.

Nereikalaukime pernelyg daug

Viena iš įsigijimo problemų yra ta, kad reikalaujama iš karto sukurti

didelių galimybių PĮ. Užsakovui dažnai kyla noras pridėti dar ir dar vieną

reikalavimą samprotaujant, kad tai bus tik nedidelis PĮ praplėtimas. Patyrę PĮ

kūrimo specialistai sako, kad norai pagerinti jau įdiegtos PĮ savybes yra


45

suprantami ir sveikintini. Tačiau papildomų reikalavimų kėlimas PĮ kūrimo

eigoje, gali sužlugdyti visą įsigijimo procesą.

Ne veltui sakoma, kad „geriau mažiau, negu nieko“: jei prašysime nedaug,

gausime tai; jei reikalausime pernelyg daug, rizikuosime išleisti daug pinigų ir

gauti mažiau arba nieko. Gerai yra turėti ambicingus planus ateičiai, tačiau

nereikėtų siekti jų įgyvendinimo vienu užmoju.

Sukūrus pirmąją PĮ versiją, jos naudotojai pradeda kaupti patirtį.

Rezultatai būna labai įvairūs. Kartais PĮ trūkumų gal ir nepastebima, tačiau laikui

bėgant atsiranda nauji reikalavimai. Kitais atvejais, esant informacinių

technologijų poveikiui, naudotojų samprata apie PĮ ir poreikiai netikėtai

pasikeičia. Nežiūrint įsigijimo projekto pradžioje numatytų vienokių reikalavimų,

gali atsirasti nauji. Dažniausiai tai būna esminiai, o ne ankstesnių reikalavimų

patobulinimas. Nežiūrint to, kad dalis naujų reikalavimų gali būti mažiau

svarbūs, būtina juos visus išsiaiškinti kaip galima anksčiau. Tai yra geriausia, ką

galima padaryti valdant reikalavimus.

Grupės atliekama reikalavimų peržiūra yra vienas iš būdų atsisakyti

neesminių reikalavimų. Atsisakius kažkurio reikalavimo, sutaupoma lėšų ir laiko.

Kaip jau buvo minėta, sumažinus reikalavimus PĮ kūrimo pastangos, projekto

sudėtingumas, darbų trukmė sumažėja žymiai didesniu laipsniu; taip pat žymiai

padidėja PĮ patikimumas. Priklausomi nuo pasirinkto sandorio su tiekėju tipo,

užsakovui mažiausiai du kartus gali kilti noras peržiūrėti PĮ reikalavimus: prieš

skelbiant prašymą teikti pasiūlymus (RFP) ir išrinkus PĮ tiekėją.

Neatitikimams tarp užsakovo poreikių ir PĮ reikalavimų išvengti taip pat

reikėtų periodiškai peržiūrėti PĮ sampratą įsigijimo projekto plane (žiūr. 8 skyrių

„Įsigijimo projekto planavimas“). Turėtų būti stebima:

- ar reikalavimai atitinka PĮ sampratą ir ar nenukrypta nuo pagrindinio

tikslo;

- ar PĮ atsarginiai reikalavimai „būtų gerai, jei būtų“ iš tikro reikalingi.

Kiek išsamus turi būti PĮ reikalavimų dokumentas?

Vienareikšmiško atsakymo į šį klausimą, matyt, nėra. Bendra

rekomendacija yra tokia: reikalavimai turi būti užbaigti, suformuluoti aiškiai

(tiksliai) ir išsamūs. Tai padeda išvengti dviprasmybių tolesniuose įsigijimo

projekto etapuose. Tačiau PĮ tiekėjai laikosi kitokio požiūrio. Jie mano, kad

išsamūs reikalavimai trukdo užsakovams priimti sprendimą dėl gatavos PĮ

pirkimo.

Pardavėjams labiau priimtini yra trumpi bendrieji PĮ reikalavimai, nei

išsamus reikalavimų dokumentas. Jie norėtų, kad vadovaujantis bendraisiais

reikalavimais būtų renkama geriausiai tinkanti gatava PĮ.


46

Bendrųjų PĮ reikalavimų rengimas gali būti priimtinas abiem šalims tuo

atveju, kai jie naudojami kaip prašymo teikti pasiūlymus (RFP) dalis. Tiekėjams

tai yra pagrindas pasiūlymams rengti, o užsakovams – pagrindas priimti

sprendimus kurti naują ar pirkti gatavą PĮ. Jei nutariama kurti visą PĮ ar

kažkurias jos dalis, bendradarbiaujant su išrinktu tiekėju (kūrėju) bendrojo

pobūdžio PĮ reikalavimai sukonkretinami ir parengiami išsamūs reikalavimai.

PĮ kokybės rodikliai

PĮ kokybės klausimai, t.y. kokiu laipsniu PĮ atitinka reikalavimus, taip pat

turėtų būti atspindėti reikalavimų dokumente. Įvertinti kokybę yra žymiai

sunkiau, nei patikrinti PĮ funkcionalumą ar eksploatacines savybes. Dažnai

formalus testavimas PĮ priėmimo metu gali būti neįgyvendinamas (netinkamas).

Todėl vietoje jo gali būti naudojamos mažiau griežtos procedūros, kaip PĮ

tikrinimas ar analizė jos kūrimo eigoje. Nežiūrint to, yra ar nėra galimybių

adekvačiai išmatuoti ar įvertinti kokybės rodiklius, jie turi įtakos į PĮ kūrimo

procesą. Išvardinkime pagrindinius PĮ kokybės rodiklius:

- patikimumas (angl. reliability). Tai rodiklis, atspindintis PĮ gebėjimą

veikti be sutrikimų apibrėžtą laiko tarpą. Dažniausiai jis išreiškiamas

sutrikimų kiekiu per laiko vienetą, bet kartais gali būti matuojamas ir PĮ

trūkumų kiekiu. Tačiau trūkumai gali ir neiššaukti veikimo sutrikimų,

pvz., klaidos dokumentuose ar funkcionavimas nepakankamu lygiu, dėl

ko nestabdomas PĮ darbas. Taigi, patikimumas reikalauja tikslaus

sutrikimų apibrėžimo. Jei užsakovui daugiau rūpi, kad tik PĮ veiktų, tai

jos kokybei atspindėti geriau tiktų veiksnumo rodiklis;

- veiksnumas (angl. availability). Tai rodiklis, kaip ilgai PĮ gali veikti be

pertrūkių. Jis išreiškiamas procentais ir reiškia santykį tarp nesutrinkamo

PĮ darbo laiko su visu jos veikimo laiku. Pvz., jei sistemos veiksnumas yra

95 proc., tai reiškia, kad per 100 valandų ji gali neveikti 5 valandas. Kam

išnaudojamas PĮ neveiksnumo laikas, mes turėtume žinoti. Ar visą laiką

PĮ turi būti veiksni, ar leistini jos sustabdymai (profilaktikai, audito

darbams, kt.);

- priežiūros patogumas (angl. maintainability). Tai pastangų dydžio PĮ

gedimams ar su ja susijusioms problemoms išspręsti per apibrėžtą laiką

rodiklis: kiek laiko vidutiniškai reikia gedimams pašalinti ar problemoms

išspręsti;

- patogumas naudoti (angl. usability). Juo atspindimos naudotojų mokymo

ar jų darbo su PĮ santykinės pastangos. Tai ypač svarbus PĮ kokybės


47

rodiklis, turintis ryšį su sunkiai įvertinamu žmogiškuoju faktoriumi. Jis

galėtų būti išreiškiamas, pvz., klavišų paspaudimo kiekiu, reikalingų

operatoriaus veiksmų kiekiu, PĮ reakcijos į užklausą laiku;

- plėtros galimybė (angl. expandability). Šis rodiklis atspindi galimybę

plėtoti ar gerinti PĮ. Galimybė ateityje adaptuoti patobulinimus

dažniausiai būna numatyta pačioje PĮ konstrukcijoje. Paprastai tai būna

susiję su sistemos resursų, atminties plėtra. PĮ plėtros galimybė taip pat

gali reikšti tai, kad PĮ yra sukurta laikantis vidinių ar išorinių sąsajų

standartų, kas leidžia plėtoti ją nedarant didelių architektūros ar diegimo

pakeitimų.

Patikimumo, veiksnumo ir priežiūros patogumo rodikliai turi būti

nustatomi atsižvelgiant į personalo, kuris naudos ir prižiūrės PĮ, kvalifikaciją ir

įgūdžius. Tai labai svarbūs rodikliai, į kuriuos turi būti atsižvelgiama

formuluojant PĮ reikalavimus. Esant reikalui galima naudoti dar ir kitus kokybės

rodiklius, kurie yra sunkiau apibrėžiami, įvertinami, patikrinami. Štai du iš jų:

- perkėlimo galimybė (angl. portability). Tai PĮ perkėlimo į kitokią aplinką

santykinių pastangų rodiklis;

- tinkamumas panaudoti kitur (angl. reusability). Tai PĮ ar jos komponentų

panaudojimo kitose sistemose santykinių pastangų rodiklis. Į šį rodiklį

turėtų atsižvelgti tiekėjai, norintys, kad jų PĮ būtų konkurencinga rinkoje.

Tuo tarpu užsakovas, siekdamas platesnių PĮ galimybių, kažkiek

rizikuoja, ir gali pastatyti į pavojų savo viltis ir visos įsigijimo grupės

darbą.

Lankstumo planavimas

Lankstumas yra dar vienas su PĮ reikalavimais susijęs klausimas. Natūralu,

kad sistemų projektavimo stadijoje PĮ teikia didesnes lankstumo galimybes nei

aparatinė įranga. Keista, bet seniau sukurtos sistemos dažnai būna nelanksčios.

Negalima plėsti jų galimybių, keisti egzistuojančių elementų. Kartais tenka

naudoti senstelėjusius kompiuterius, nes PĮ perkėlimas į naują kompiuterį yra

pernelyg trikdantis ir brangus. Vien kompiuterių ar jų išorinių įrenginių

pakeitimas neatneša greitos naudos.

PĮ lankstumui neskiriant reikiamo dėmesio, ji būna gyvybinga neilgą laiką,

kartais moraliai pasensta dar nebaigus jos kurti.

Lankstumo planavimo esmė yra ta, kad sukurtoje PĮ galima būtų lengvai

daryti pakeitimus. Tai apima PĮ komponentus, jų jungimą ir sąveiką, apribojimus

ir kaip kiekvienas iš jų gali plėtotis laikui bėgant. Atkreipkime dėmesį, kad čia


48

kalbama apie aukštesnį lygmenį nei algoritmai ar duomenų struktūros. Čia

turima galvoje PĮ architektūra.

Pvz., kokie turėtų būti kažkokio objekto apdorojimo algoritmai, PĮ

reikalavimuose tai nėra svarbu. Svarbu, kur tie algoritmai gali būti pritaikyti,

kokie duomenų šaltiniai jiems yra prieinami, kokių duomenų šaltinių gali

papildomai prireikti ateityje, kokie komponentai naudos tų algoritmų išeigą,

kokie tikėtini šių komponentų pokyčiai ateityje.

Vienas iš lankstumo planavimo kelių yra klausimo, kokios PĮ savybės

tikėtina keisis ar plėtosis per artimiausius penkerius metus, kėlimas. Visada turi

kirbėti klausimas „kas, jeigu“. Ar PĮ bus galima adaptuoti, atsiradus pokyčiams

užsakovo organizacijoje? Tikslas yra sukurti tokią PĮ, kurioje pakeitimų darymas

būtų kiek įmanoma neskausmingas.

Apskritai, užsakovas prašyme teikti pasiūlymus (RFP) neturėtų apibrėžti PĮ

architektūros. Tiekėjų kvalifikacija leidžia tai padaryti žymiai geriau.

Yra eilė lankstumo reikalavimų, kurie svarbūs PĮ įsigijimo procese:

- reikia apibrėžti aplinką, kurioje dirbs įsigyjama PĮ. Tai dažnai apima ir

kitą PĮ, kurią taip pat reikia įsigyti arba kuri jau yra. Užsakovas gali

norėti, kad PĮ veiktų pagal žinomus sąveikos ir komunikacijų

standartus, kad lengviau būtų pasirinkti kitų sistemos komponentų

tiekėjus. Tačiau aparatinės įrangos platforma arba operacinė sistema

įsigyjamai PĮ funkcionuoti neturėtų būti nustatoma, jei nėra būtino

reikalo, nes tai įneša tik bereikalingus apribojimus projektuotojams;

- reikia reikalauti iš tiekėjo, su kuriuo pasirašytas sandoris, kad jis kiek

galima anksčiau pateiktų PĮ architektūrą, nesvarbu kuriama nauja ar

perkama gatava PĮ;

- jei kuriama nauja PĮ, sandoryje su paslaugų tiekėju reikia numatyti

sąlygą, leidžiančią užsakovui vertinti ir tvirtinti tiekėjo pasiūlymus. Tai

padės užsakovui spręsti, ar tiekėjas teisingai supranta jo poreikius ir ar

gali įgyvendinti iškeltus reikalavimus. Jei užsakovas numato imtis

įsigyjamos PĮ priežiūros, jis turi įsitikinti tokiomis savo galimybėmis. Jei

PĮ priežiūrą numatoma pavesti užsakovo ir tiekėjo specialistams,

užsakovo specialistai turi būti įtraukti į įsigijimo grupę;

- įsigyjant gatavą PĮ, reikia apibrėžti, kokiu laipsniu ji turi atitikti

užsakovo reikalavimus. Gatava PĮ gali pareikalauti pastangų, kuriant

jos sąsajas su kitais komponentais arba adaptuojant ją prie užsakovo

vietinės aplinkos. Užsakovas turi įsitikinti, ar galės atlikti būtinus

adaptavimo darbus.


49

Kada užbaigiamas reikalavimų rengimas?

PĮ reikalavimai turi būti parengti ir patvirtinti įsigijimo projekto pradžioje.

Jei nusprendžiama pirkti gatavą PĮ, tuomet pakanka bendrųjų reikalavimų (PĮ

savybių sąrašo) prieš pradedant ieškoti pardavėjo. Kitu atveju, kai kuriama

visiškai nauja PĮ ir sudaromas laiko ir medžiagų apmokėjimo tipo sandoris,

reikalavimai turėtų būti rengiami bendradarbiaujant su išrinktu tiekėju. Tačiau

išlieka neaiškumas, kada bus pasiektas sutarimas tarp užsakovo ir tiekėjo ir kada

įsigijimo procese turėtų būti parengtas reikalavimų dokumentas. Yra kelios šio

klausimo sprendimo galimybės:

1 galimybė. Užsakovas parengia PĮ reikalavimų dokumentą iš anksto. PĮ

reikalavimai įtraukiami į prašymą teikti pasiūlymus (RFP). Užsakovas PĮ

reikalavimams parengti į darbo grupę gali kviestis ekspertus. Argumentai už:

tiekėjams yra galimybė susipažinti su PĮ reikalavimais; tiekėjai gali geriau

atsižvelgti į specifines reikalavimų ypatybes rengdami savo pasiūlymus, kas

padeda užsakovui parinkti geresnį tiekėją. Argumentai prieš: tiekėjų tarpe yra

nuostata, kad užsakovo apibrėžti reikalavimai be reikalo varžo PĮ projektus;

beveik garantuojama, kad reikės realizuoti individualius užsakovo poreikius ir

bus atsisakyta pirkti gatavą PĮ; gali būti neapgalvotai parinktos technologijos,

kurios diegiant PĮ pasens arba bus kliūtis; yra pavojus, kad užsakovas

reikalavimus laikys galutiniais ir neleis jų koreguoti.

2 galimybė. Užsakovas parengia tik preliminarią PĮ reikalavimų

dokumento versiją. Ji įtraukiama į prašymą teikti pasiūlymus (RFP). Kai tik

išrenkamas tiekėjas, bendradarbiaujant užsakovui ir tiekėjui, parengiama

patikslinta PĮ reikalavimų versija. Argumentai už: tiekėjams yra galimybė

susipažinti su PĮ tiek, kad galėtų priimti sprendimą dėl bendradarbiavimo su

užsakovu rengiant patikslintus PĮ reikalavimus. Argumentai prieš: šie

argumentai yra tokie patys kaip ir 1-oje galimybėje, išskyrus tai, kad PĮ

reikalavimai nėra laikomi galutiniais.

3 galimybė. Išrinktas tiekėjas rengia detalius PĮ reikalavimus, kai tik su

juo pasirašomas sandoris. Į prašymą teikti pasiūlymus (RFP) dedamai tik

bendrieji PĮ reikalavimai. Pastaruosiuose gali būti tik PĮ savybių sąrašas,

poreikis, samprata, aplinkos dalykai, sąsajos su esamomis sistemomis. Laiko ir

medžiagų apmokėjimo tipo bei išlaidas padengiančiojo tipo sandoriai (apie

sandorių tipus plačiau žiūr. 11 skyriuje) yra ypač tinkami šios galimybės atveju.

Sudarant išlaidas padengiančiojo tipo sandorį, pradžioje tik PĮ reikalavimams

parengti gali būti nurodomas finansavimas. Kai ši užduotis atliekama

patenkinamai, užsakovas ir tiekėjas PĮ reikalavimus supranta vienodai. Po to


50

numatomas finansavimas kitoms PĮ kūrimo veikloms (projektavimui,

programavimui, testavimui, kt.). Šios galimybės atveju prašyme teikti pasiūlymus

(RFP) turi būti reikalavimas nurodyti tiekėjo darbo perspektyvas, bendrasis

dokumentas potencialių tiekėjų siūlomoms kainoms nurodyti. Argumentai už:

sudaroma galimybė PĮ projektų patirtį ir kompetenciją turintiems asmenims

rengti PĮ reikalavimus; kai užsakovas ir tiekėjas vienodai supranta PĮ

reikalavimus, yra tvirtas pagrindas imtis tolesnių darbų. Argumentai prieš:

nesudaromas tvirtas pagrindas tiekėjams apsispręsti dėl kainos siūlymo; turi būti

kruopščiai parengtas sandoris, įgalinantis derintis prie neapibrėžtumų; griežti ar

fiksuotos kainos tipo sandoriai netinka visam PĮ kūrimo procesui.

4 galimybė. Parengiamas prašymas teikti pasiūlymus (RFP), pagal kurį

tiekėjai turėtų parengti PĮ reikalavimus. Vėliau parengti PĮ reikalavimai dedami

į kitą prašymą teikti pasiūlymus (RFP) PĮ sukurti. Argumentai už: apeinamas

užsakovo patirties PĮ srityje trūkumas, nes jam nereikia rengti PĮ reikalavimų;

kaip ir 1-os galimybės atveju, jau parengtus PĮ reikalavimus įdėjus į prašymą

teikti pasiūlymus (RFP), tiekėjai turi galimybę susipažinti su PĮ reikalavimais

rengdami savo pasiūlymus. Argumentai prieš: jei tiekėjui, kuris parengė PĮ

reikalavimus, vėliau leidžiama teikti pasiūlymą kurti PĮ, iškyla interesų

suderinamumo konfliktas. Toks tiekėjas gali parengti PĮ reikalavimus taip, kad jo

siūloma PĮ geriausiai atitiktų tuos reikalavimus, arba tai įneš neobjektyvumo

antrame tiekėjų atrankos etape. Kita vertus, jei PĮ reikalavimus rengusiam

tiekėjui neleidžiama dalyvauti PĮ kūrėjų atrankoje (arba jei išrenkamas kitas

tiekėjas PĮ kurti), tuomet gali būti įvairių interpretacijų, ką gi tie PĮ reikalavimai

reiškia. Taip pat yra pavojus, kad užsakovo organizacijos veiklos specifiką

išmanantiems, bet PĮ srities gerai nežinantiems asmenims bus pavesta rengti PĮ

reikalavimus.

Taigi, pasirinktas PĮ reikalavimų rengimo kelias turi didelę įtaką

sudaromiems sandoriams. Nėra lengva rasti teisingą atsakymą. Tai viršija

užsakovo galimybes įvertinti situaciją viso PĮ įsigijimo projekto požiūriu.

Nežiūrint pasirinkto sprendimo, užsakovas turi aktyviai dalyvauti PĮ

reikalavimų valdyme viso įsigijimo projekto metu.

9.2. Reikalavimų valdymas (peržiūra, keitimas)

PĮ kūrimo pradžioje visi reikalavimai dar nėra žinomi. Tikslus PĮ

reikalavimų dokumentas iš anksto negali būti parengtas. Geriausia jį plėtoti

analizuojant atliktus projekto darbus.


51

Reikalavimų valdymo būtinumas

Esminė PĮ įsigyjančiųjų klaida yra manymas, kad kažkas vienas gali iš

anksto gerai apibrėžti PĮ, gauti lėšas jai kurti, sukurti ir įdiegti ją.

Įsigijimo proceso pradžioje parengti užbaigtą, gerai dokumentuotų PĮ

reikalavimų rinkinį būtų labai gerai. Tačiau tai vargu ar įmanoma. Kažkada buvo

manoma, kad PĮ įsigijimo projekto sėkmė priklauso nuo:

1) kruopštaus reikalavimų rinkinio parengimo;

2) griežto šių reikalavimų laikymosi viso projekto metu;

3) vertimo tiekėją realizuoti visus užsakovo norus.

Tačiau tokie idealūs veiksmai neatitinka pasaulinės projektų vykdymo patirties.

Kai kas mano, kad projekto eigoje būtina išlaikyti nekintančius PĮ reikalavimus.

Tačiau pradiniai reikalavimai dažniausiai nenumato visko ir būtina juos tikslinti.

Kodėl taip yra?

Gali būti, kad kalba (lietuvių, anglų, rusų, kt.) nėra visiškai tinkama PĮ

reikalavimams dokumentuoti. Dažnai sakoma, reikalavimų dokumentas yra

neaiškus, turintis prieštaravimų, dviprasmiškas, nepilnas, nepatikrintas ar tiesiog

neteisingas. Reikalavimų rengėjai ir jų skaitytojai nuoširdžiai gali suprasti juos

skirtingai. Todėl būtinas daugkartinis reikalavimų aiškinimasis. Reikalavimus,

kurių prasmė juos rašiusiam užsakovui atrodo aiški, kitaip suprasti gali PĮ

kūrėjas. Jei nuomonių skirtumas nepašalinamas PĮ įsigijimo projekto pradžioje,

anksčiau ar vėliau tai tampa nesusišnekėjimo tarp šalių priežastimi. Netgi jei

galima būtų parengti visiškai aiškius, visų vienodai suprantamus reikalavimus,

projekto eigoje jie gali keistis. Įsigijimo proceso eigoje atsiranda naujas

supratimas apie PĮ, todėl reikalavimų koregavimas yra būtinas.

Toliau aptariami PĮ reikalavimų valdymo klausimai projekto eigoje.

Prašykime tiekėjo pastabų

Parengus reikalavimus, patartina formaliai ar neformaliai supažindinti su

jais potencialius tiekėjus ir paprašyti pastabų ar rekomendacijų (tam reikėtų

pasitarti su PĮ įsigijimo grupės sandorių sudarymo specialistais ir teisininkais,

kad toks supažindinimas būtų teisėtas ir nebūtų suprastas kaip palankumo tam

tikriems tiekėjams rodymas). Gavus pastabas, reikalavimai peržiūrimi. Taip

parengiami geriau pagrįsti reikalavimai. Jei pastebima, kad nėra jūsų

reikalavimus atitinkančios gatavos PĮ, reikėtų pasvarstyti, ar iš tikro tokie

reikalavimai būtini ir kokia rizika sukurti visiškai naują PĮ pagal keliamus

reikalavimus. Tikriausiai yra priežastis, kodėl nė vienoje gatavoje PĮ nėra įdiegti

visi jūsų keliami reikalavimai. Taip pat galima kreiptis į kitas, panašią PĮ

anksčiau įsigijusias organizacijas, kad peržiūrėtų jūsų reikalavimus.


52

Tiekėjai gali nenorėti duoti sąžiningo jūsų reikalavimų įvertinimo. Jų

atsakymus galima suprasti kaip pasiūlymą papildyti ar pakoreguoti reikalavimus,

kad jie atitiktų tiekėjų turimus produktus. Tiekėjai gali bijoti, kad, davus

sąžiningus atsakymus, jiems nebus leidžiama dalyvauti pirkimo procese. Tačiau

duodant anonimiškus atsakymus, to galima išvengti. Pastebėta, kad taip elgiantis

tiekėjų atsakymai būna vertingesni.

Konferencijų rengimas dar iki PĮ pirkimo paskelbimo yra kitas būdas

reikalavimams pagerinti. Konferencija šaukiama paviešinus bendruosius PĮ

reikalavimus, bet anksčiau nei paskelbiamas prašymas teikti pasiūlymus (RFP).

Šiuo atveju tiekėjai noriai teikia pastabas ar pasiūlymus, kadangi jie

neatskleidžia savo pasiūlymų konkurentams. Be to užsakovas turi galimybę

daryti pakeitimus, kol galutiniai reikalavimai nėra parengti. Tačiau, kai prašymas

teikti pasiūlymus (RFP) paskelbiamas, kontaktai tarp šalių apribojami.

Reikalavimų valdymo procesas nesibaigia pastabų ir pasiūlymų gavimu iš

tiekėjų bei reikalavimų gerinimu tokiu būdu.

Reikalavimų dokumentas yra geras pradinis pagrindas užsakovo ryšiams

su PĮ kūrėjais ar pardavėjais užmegzti. Tačiau tai nėra kitų bendravimo būdų,

kaip žmonių pokalbiai susirinkimuose, darbo grupės, PĮ prototipai, PĮ

demonstravimai, sistemų testavimas, pakaitalas. Žinios ir naujas supratimas

įgyjamas projekto eigoje. Tai turi būti kaupiama, o ne draudžiama laikantis

statiško reikalavimų dokumento. Užsakovas turi pastoviai bendradarbiauti su

tiekėju ir nuolatos peržiūrėti reikalavimus likusiai projekto daliai. Reikalavimų

pakeitimai turi būti rūpestingai kontroliuojami. Užsakovas neturėtų tik perduoti

reikalavimus tiekėjui ir pamiršti juos.

Laikas nuo laiko peržiūrėkime PĮ reikalavimus

PĮ reikalavimų dokumentas turi būti peržiūrimas drauge su išrinktu

tiekėju. Peržiūros sėkmė priklauso nuo to, ar tinkami specialistai tą atlieka.

Svarbu, kad peržiūroje dalyvautų ne tik už projekto valdymą atsakingi tiekėjo

atstovai, bet ir programuotojai. Dėmesio centre turi būti darbų grafikas, prašymas

teikti pasiūlymus (RFP), sandorio sudarymas. Šie klausimai turi būti svarstomi

kiek galima anksčiau, dar iki PĮ kūrimo pradžios. PĮ reikalavimai gali būti

peržiūrimi netgi iki sandorio pasirašymo. Priklausomai nuo pasirinkto sandorio

tipo, gali būti per vėlu peržiūrėti reikalavimus po sandorio pasirašymo.

PĮ reikalavimai turi būti peržiūrimi eilutė po eilutės, nes užsakovas ir

tiekėjas į juos žiūri iš skirtingų pozicijų, o požiūrių skirtumas yra neišvengiamas.

Būtina aptarti kiekvieną reikalavimų punktą, išsakyti savo nuomones ir pašalinti

nesutarimus, aptarti kiekvieno iš jų poveikį projektui. Tai yra vienas iš atvirų

ryšių tarp užsakovo ir tiekėjo pavyzdžių, kad būtinas bendradarbiavimas.


53

Peržiūros metu neturi būti žiūrima į reikalavimus kaip į nekeičiamus, netgi

jei jie yra jau pasirašyto sandorio dalis. 9.3 lentelėje yra išvardinti darbai, kuriuos

reikėtų atlikti kiekvieną kartą peržiūrint PĮ reikalavimus. Žinoma, į ją gali būti

įtraukiami ir kiti punktai.

PĮ reikalavimų peržiūra gali būti išnaudota neaiškumams pašalinti. Kai tik

reikalavimai išgryninami, patartina drauge su tiekėju optimizuoti juos kainos ir

įgyvendinimui reikalingų pastangų prasmėmis.

9.3 lentelė. Rekomenduojama PĮ reikalavimų peržiūros darbotvarkė

Nr. PĮ reikalavimų peržiūros punkto pavadinimas

1. Dviprasmiškų arba neaiškių reikalavimų suradimas

2. Reikalavimų nesuderinamumo šalinimas

3. Trūkstamų reikalavimų įtraukimas

4. Egzistuojančių reikalavimų keitimas atsiradusiais geresniais alternatyviais reikalavimais

5. Nebūtinų arba sunkiai įgyvendinamų reikalavimų šalinimas arba jų prioriteto mažinimas

6. Likusių reikalavimų surikiavimas pagal prioritetą. Žemesnio prioriteto reikalavimų realizavimo atidėjimas vėlesnėse PĮ versijose

Reikalavimų peržiūra ir ginčytinų klausimų išsiaiškinimas reikalingas tiek

naujos PĮ kūrimo, tiek gatavos pirkimo atvejais. Perkant gatavą PĮ, peržiūra

padeda įvertinti, kokias PĮ modifikacijas bus lengva atlikti, o kokias sunku.

Pardavėjas tai gali padaryti geriau nei kas nors kitas. Ne specialistų nuomonė

dažniausiai būna klaidinga: iš pažiūros nežymų PĮ pakeitimą gali būti sunku

atlikti, o reikšmingą pakeitimą gali būti nesudėtinga atlikti.

Laikantis laipsniško PĮ „auginimo“ požiūrio ir nedideliais laiko tarpais

diegiant nedideles projekto dalis, užsakovai lengviau sutinka atidėti kai kurių

galimybių realizavimą iki kitos PĮ versijos išleidimo. Kai jie mato, kad PĮ kūrimo

ciklas bus ilgas, todėl reikalauja realizuoti kaip galima daugiau galimybių

pirmojoje PĮ versijoje. Tokiu atveju problema tik pasunkėja.

Gali kilti ginčų dėl to, kad PĮ reikalavimų peržiūra atima nemažai laiko. Iš

tikro taip ir yra. Tačiau tai daryti yra daug geriau, nei taisyti projekto klaidas

vėliau. Visuotinai pripažinta, kad uždelsus reikalavimų problemos sprendimą

viena PĮ gyvavimo ciklo faze, vėliau projekto korekcijos kaina atsieina

dešimteriopai. O jeigu lauksime kol prasidės sukurtos PĮ diegimas, tai gali

prireikti šimtus kartų didesnių išlaidų, nei jų būtų reikėję PĮ reikalavimų

korekcijoms atlikti savo laiku.


54

Įsivaizduokime, kad PĮ reikalavimai nėra peržiūrimi. Kas atsitinka, kai dėl

jų užsakovas ir tiekėjas ima nesutarti? Pradžioje, matyt, neatsitinka nieko. Bet

vėliau nepašalinti nesutarimai atveda prie to, kad sukurta PĮ eile aspektų yra

netikusi. PĮ neatitinka užsakovo lūkesčių, jis lieka nusivylęs. Ateityje projekto

dalyviams, įskaitant ir tiekėją, tai gali atsiliepti neigiamai.

Pasirašykime PĮ reikalavimus ir perduokime juos PĮ konfigūracijos

valdytojams

PĮ reikalavimų peržiūros metu visi užsakovo ir tiekėjo susitarimai turi būti

fiksuojami dokumente. Susitarimams užfiksuoti dažniausiai surašomi tik aktai-

atmintinės (savitarpio supratimo memorandumai). Kai kuriais atvejais gali tekti

keisti reikalavimų dokumentą.

Kai tik dėl visų PĮ reikalavimų sutariama, užsakovas ir tiekėjas turi

pasirašyti reikalavimų dokumentą ir tarpusavio susitarimą. Pageidautina, kad

pasirašant PĮ reikalavimų dokumentą įsigijimo grupėje būtų bent vienas

tiesioginis naudotojas. Pasirašius susitarimą, pradedamas pirkimo procesas. Tuo

baigiasi reikalavimų rengimas. Nuo šio momento reikalavimų pakeitimai bus

daromi tik formaliu, užsakovo ir tiekėjo sutartu būdu. Reikalavimai perduodami

PĮ konfigūracijos valdymui.

Tačiau galutinių reikalavimų dokumento parengimas nėra visos šios

istorijos pabaiga. PĮ reikalavimus tenka tvarkyti dar ne kartą.

Du prieštaringi norai: spręsti reikalavimų koregavimo klausimą, kai tik jis

iškyla, ir nustatyti nekeičiamą reikalavimų dalį

Iš vienos pusės, užsakovas turi būti lankstus, sprendžiant neišvengiamai

iškylančius reikalavimų koregavimo klausimus. Kita vertus, yra svarbu turėti

pastovius reikalavimus ir dirbti pagal juos. Balansuojant tarp šių dviejų

aplinkybių, su kažkuo nesutinkant, pagrindinis projekto sėkmės veiksnys turi

būti jūsų poreikiai.

Spręskime PĮ reikalavimų klausimus neatidėliodami

Netgi po formalaus PĮ reikalavimų pasirašymo (patvirtinimo), jie netampa

nekeičiami. Kai kurie keitimai yra neišvengiami. Netgi jei PĮ reikalavimų

dokumentas yra pasirašyto sandorio tarp užsakovo ir tiekėjo dalis, būtina išlaikyti

tam tikrą lankstumą. Natūralu ir protinga išnaudoti projekto eigoje įgyjamą

patirtį. Be to gali kilti noras išnaudoti atsiradusias technologijų naujoves. Su PĮ

reikalavimais susijusius klausimus reikia spręsti neatidėliojant. Dauguma iš jų

būna tik aiškinimaisi ar susitarimai, kas fiksuojama aktuose-atmintinėse

(memorandumuose). Tačiau kai kuriais atvejais gali prireikti ir PĮ reikalavimų


55

pakeitimų. Tokie pakeitimai, ar juos siūlytų tiekėjas, ar jų reikalautų užsakovas,

yra normalus reiškinys ir turi būti svarstomi.

Vertimas tiekėją laikyti pradinius PĮ reikalavimus, kaip galinčius turėti

papildymus, ir vertimas jį laikytis įsigijimo projekto pradinio darbų grafiko ir

biudžeto, nėra tinkamas reikalų tvarkymo būdas. Tai griauna tarpusavio

pasitikėjimą ir sukelia priešiškumą projekto eigoje. Geriau yra kaupti

atsirandančius papildomus reikalavimus ir panaudoti juos papildomoms PĮ

dalims apibrėžti ir kurti vėliau. Žinoma, tos papildomos projekto dalys turi būti

nedidelės ir suvaldomos.

Jei PĮ reikalavimų peržiūra yra vienkartinis darbų grafike numatytas

veiksmas, tai naujai atsirandančių reikalavimų klausimus vėliau tenka spręsti

dažnai. PĮ kūrimo eigoje užsakovas ir tiekėjas (kūrėjas) reikalavimams turi skirti

nuolatinį dėmesį. Užsakovas turi būti ypač atidus PĮ kūrėjo siūlomiems

reikalavimų pakeitimams. Tai neturėtų būti aklas PĮ reikalavimų švelninimas ar

siūlomų pakeitimų priėmimas, o turėtų būti atvira ir garbinga diskusija.

Kai tiekėjas pasiūlo aptarti reikalavimus, užsakovas neturėtų į tai žiūrėti

priekaištaujančiai, girdi, reikalavimų klausimas jau seniai išspręstas. Šiais

klausimais jis turėtų būti dalykiškas ir sudaryti palankią atmosferą, padedančią

žengti į priekį.

Tarkime, kad tiekėjas pasiūlė naują reikalavimą. Turėtų būti atitinkamas

užsakovo lankstumas, įgalinantis papildyti pradinį reikalavimų sąrašą nauju

reikalavimu. Papildomi reikalavimai turėtų būti įtraukiami tik bendru užsakovo ir

tiekėjo sutarimu. Nuolaidų darymas ir alternatyvių sprendimų priėmimas turi būti

daromas kartu. Drauge gali būti prieinama nuomonės šalinti iš ankstesnio

reikalavimų sąrašo žemo prioriteto reikalavimus. Atitinkamai turi būti

koreguojamas darbų grafikas ir kaina, pavyzdžiui, sutariama paslinkti grafiką.

Gali būti ir taip, kad užsakovas sakys: dėl reikalavimų pakeitimų buvo sutarta

ankstesnėje projekto stadijoje ir todėl darbų grafiko ir kainos nekeisime. Tokiose

diskusijose turėtų dalyvauti atitinkami užsakovo įsigijimo projekto grupės nariai.

Kartais tiekėjas pastebi, kad kai kurie reikalavimai yra pernelyg sunkiai

įgyvendinami, nei anksčiau buvo tikėtasi. Tokios žinios užsakovas neturėtų

sutikti su nepasitenkinimu. Naujienos gali būti blogos, ir kuo anksčiau jos

sužinomos, tuo yra geriau. Tokiu atveju reikalavimai gali būti švelninami, kartu

įnešant pataisas į darbų grafiką. O jeigu reikalavimai yra esminiai, jų

įgyvendinimas gali būti paankstintas. Kai sprendimas priimamas, visko, ko

norėtume, nebegausime: atkaklus visko reikalavimas gali žymiai padidinti

kuriamos PĮ kainą ir pakeisti darbų grafiką arba atmesti gatavos PĮ rinkimosi


56

galimybę. Atsiminkime, kad tikslas yra išspręsti problemas ir sukurti PĮ, o ne

nustatyti kaltąjį.

Sandorio mechanizmas turi būti lankstus ir, esant būtinumui, reikalavimai

turi būti koreguojami. Nesvarbu kokiu būdu reikalavimai yra valdomi, turi būti

pakankamas lankstumas pakeitimams daryti. Be to, iškilę klausimai turi būti

sprendžiami nedelsiant, laikantis pakeitimų darymo susitarimo, kuris užfiksuotas

sandorio dokumente.

Užsakovas turi reaguoti į tiekėjo pateiktus klausimus dėl PĮ reikalavimų.

Tam yra keletas priežasčių. Viena, kad pasamdytas tiekėjas yra labiau patyręs PĮ

kūrimo srityje. Kita, užsakovo sudarytos įsigijimo projekto grupės nariai

dažniausiai geriau gali įvertinti reikalavimų keitimo poveikį PĮ naudojimui.

Užsakovo vietiniai ekspertai geriausiai supranta PĮ reikalavimus ir gali juos

paaiškinti. Be jų tik tiekėjo programuotojai gali priimti sprendimus darbo eigoje.

Tačiau programuotojas, nežiūrint jo kompiuterinio išprusimo, gali nežinoti

duomenų perdavimo niuansų (perspektyvų), kurie reikalingi reikalavimų keitimo

poveikiui į PĮ naudojimo patogumą įvertinti. Programuotojas gali turėti įtakos tik

vidiniam PĮ darbui. Todėl PĮ reikalavimų keitimo klausimai turi būti aptariami

diskusijose. Tačiau tai neturėtų būti vienintelis sprendimų dėl PĮ reikalavimų

keitimo priėmimo būdas.

PĮ reikalavimų keitimas yra tas atvejis, kur gali būti išnaudotos vietinių

užsakovo ekspertų teisės. Tiesioginiai PĮ naudotojai ir vietiniai užsakovo

ekspertai dažniausiai geriau pajėgia įvertinti siūlomus PĮ reikalavimų

pakeitimus. Tai jų kasdienis darbas PĮ įsigijimo procese. Jie geriau suvokia PĮ

naudojimo darbe perspektyvą, kurio gali stokoti tiekėjas. Užsakovas geriau jausis

naudodamas būsimą PĮ, jei žinos, kad prisidėjo prie jos formavimo.

Apibrėžkime nekeičiamą PĮ reikalavimų dalį

Nežiūrint lankstumo nuostatų, PĮ reikalavimų papildymams ar keitimams

yra priešinamasi ir stengiamasi juos kiek įmanoma sumažinti. Nekeičiami

reikalavimai yra esminis PĮ sukūrimo sėkmės veiksnys. Todėl, pasirašant sutartis

tarp užsakovo ir tiekėjo, rekomenduojama turėti nekeičiamą PĮ reikalavimų dalį.

Tai suteikia įsigijimo procesui tam tikrą stabilumą. Visada PĮ reikalavimų

keitimas iššaukia įsigijimo projekto kainos ir darbų grafiko viršijimus, nes

kiekvienas pakeitimas yra susijęs su perdarymais. Įsigyjančiosios institucijos

vadovybės nuolatiniai reikalavimų keitimai PĮ kūrimo eigoje yra viena iš projekto

kainos ar darbų grafiko viršijimo priežasčių. Reikalavimų keitimams reikėtų

priešintis visada. Todėl pasirašant užsakovo ir tiekėjo sandorį rekomenduojama

PĮ reikalavimuose išlaikyti tam tikrą pastovią dalį. PĮ reikalavimų papildymai ar

pakeitimai gali būti daromi tik išlaikant viso projekto sampratą.


57

Apibendrinant ankstesnius svarstymus, nekeičiamų PĮ reikalavimų dalis

neturėtų tapti užsakovo griežtumo pateisinimu.

Geri ir blogi PĮ reikalavimų keitimai

Kaip reikėtų derinti priešingus PĮ reikalavimų koregavimo ir jų stabilumo

išlaikymo klausimus? Vienas iš būdų yra kelti sau ir spręsti klausimą, ar siūlomi

PĮ reikalavimų pakeitimai yra geri ar blogi, priimti ar atmesti juos.

Geri keitimai Blogi keitimai

šalinantys nevienareikšmiškumus didinantys sistemos funkcionalumą

padedantys supaprastinti PĮ įnešantys naujus reikalavimus

žemesnio lygmens reikalavimų įtraukimas aukštesnio lygmens reikalavimams paremti

didinantys projekto apimtį

Kitas būdas, padedantis įvertinti norėjimo laipsnį daryti pakeitimus, yra

slenksčio pakeitimams daryti didinimas laikui bėgant. Projekto pradžioje tai

daugiau gali būti kompromiso reikalas. Bet jeigu reikalavimuose yra nustatyti PĮ

kūrimo kontroliniai taškai, tai artėjant prie kontrolinio taško PĮ reikalavimų

keitimo slenkstis turi būti aukštas. Netgi nesilaikant ypatingo griežtumo,

kontrolinių taškų laikymasis turi būti rūpestingai kontroliuojamas. PĮ reikalavimų

keitimų reikalingumas, jų įtaka siekiams, kainai ir darbų grafikui turi būti

nagrinėjami kruopščiai. Įsigijimo projekto darbo grupėje esantys PĮ kūrimo

ekspertai gali padėti priimti tokius sprendimus.

Laikykimės formalių procedūrų ir pasirašykime jas

Užsakovas ir tiekėjas turi susitarti iš anksto, kaip jie, dirbdami drauge,

darys ir priims PĮ reikalavimų pakeitimus. Reikėtų samprotauti taip: „kaip

susitarimai dėl reikalavimų pakeitimų turėtų būti formaliai dokumentuoti“, „kaip

greitai užsakovas turi duoti atsakymus į tiekėjo iškeltus klausimus“.

Nesant susitarimų, yra pavojus, kad kolektyviai svarstomos naujos idėjos

gali būti klaidingai suprastos kaip formalūs pasižadėjimai. Tarkime, kad

užsakovo ir tiekėjo susirinkime aptariami galimi PĮ reikalavimų keitimai. Tiekėjui

tai gali atrodyti tik kaip kolektyvinis idėjų pasvarstymas, ir jis visa tai greitai

pamiršta. Tačiau užsakovui gali atrodyti kitaip, kad tiekėjas, neišreikšdamas to

žodžiais, sutiko daryti pakeitimus. Taip užsakovas gali susidaryti klaidingą

nuomonę, kad pakeitimai bus atlikti. Vėliau, žinoma, jis susidurs su

neįgyvendintais lūkesčiais: sistema nedirbs taip, kaip buvo svarstyta. Seks

kaltinimai dėl susitarimų nevykdymo, o tiekėjas aiškinsis, kad užsakovas nori


58

gauti daugiau už dyką. Tai veda prie nepasitikėjimo ir gali pažeisti gerus

tarpusavio santykius ilgam laikui.

Keletas susitarimų vykdymo taisyklių:

- PĮ reikalavimų pakeitimai neturi būti realizuojami tol, kol jų, formaliai

dokumentuotų, nepasirašys abi šalys. Žodiniai susitarimai nėra

pakankamas pagrindas daryti keitimus. Žinoma, dėl kiekvieno PĮ

reikalavimų keitimo viso sandorio tarp užsakovo ir tiekėjo

persvarstymas, dalyvaujant sandorių specialistams, yra nepriimtinas

(plačiau žiūr 18 skyrių, PĮ konfigūracijos valdymas);

- visi siūlomi pakeitimai turi būti svarstomi, atsižvelgiant į jų poveikį

įsigyjamos PĮ apimčiai, kainai ir darbų grafikui. Šių svarstymų metu

turi būti ieškoma galimų kompromisų;

- turi būti siekiama susitarimo, kaip ilgai PĮ reikalavimų dokumentas bus

laikomas galiojančiu. Projekto eigoje PĮ reikalavimų dokumentas gali

pasidaryti atgyvenęs. Tačiau neturėtų būti iš anksto numatytas

biurokratinis reikalavimų keitimo laikas, kol niekas to nepareikalaus.

Kita vertus, jeigu nutariama, kad reikalavimų dokumentu ateityje bus

remiamasi eksploatuojant ir prižiūrint sistemą, būtina įtraukti į jį visus

pakeitimus. Kai kuriais atvejais reikalavimų dokumentas gali

pasitarnauti kaip pagrindas būsimiems keitimams arba papildymams

atlikti. Todėl rekomenduojama reikalavimų dokumentą laikyti

galiojančiu visą sistemos gyvavimo laikotarpį.

Kad PĮ reikalavimų valdymo procesas būtų veiksmingas, užsakovas ir

tiekėjas turi prisiimti tam tikrą atsakomybę. 9.4 lentelėje jų atsakomybės

parodytos greta. Kiekvienoje eilutėje pateikiama užsakovo atsakomybė ir

atitinkama tiekėjo atsakomybė. Pavyzdžiui, užsakovas gali prieštarauti

siūlomiems PĮ reikalavimų keitimams, tačiau kita šalis gali nesutikti su tuo.

Lentelėje išvardintos atsakomybės gali būti naudingos formuluojant šalių

įsipareigojimus. Jas užsakovas ir tiekėjas turėtų aptarti, kad būtų vienodas

lūkesčių ir įsipareigojimų supratimas.

9.4 lentelė. Užsakovo ir tiekėjo atsakomybės už PĮ reikalavimų valdymą

Užsakovo atsakomybė Tiekėjo atsakomybė

Palaikyti atvirus ryšius su tiekėju, dirbti drauge kaip viena komanda.

Palaikyti atvirus ryšius su užsakovu, dirbti drauge kaip viena komanda.

Svarstyti PĮ reikalavimus su tiekėju, negrasinant ir nekaltinant jo. Suprasti, kad kitokia tiekėjo nuomonė gali būti nuoširdi.

Svarstyti PĮ reikalavimus su užsakovu, negrasinant ir nekaltinant jo. Suprasti, kad kitokia užsakovo nuomonė gali būti nuoširdi.


59

Pasirašyti PĮ reikalavimus, kai tik su tiekėju prieinama vieningos nuomonės.

Pasirašyti PĮ reikalavimus, kai tik su užsakovu prieinama vieningos nuomonės.

Laikytis nuostatos, kad pasiūlyti PĮ reikalavimų pakeitimai negalioja tol, kol jų nepasirašo užsakovas ir tiekėjas.

Laikytis PĮ reikalavimų keitimo procedūrų. Nerealizuoti pakeitimų tol, kol jų nepasirašys užsakovas ir tiekėjas.

Suprasti, kad ne viskas yra įmanoma. Kai kurie PĮ reikalavimai gali būti neįvykdomi arba atidedami.

Nelaikyti PĮ reikalavimų kaip teisinio pagrindo užsakovo lūkesčiams susiaurinti. Vengti požiūrio: užsakovas neprašė, todėl aš nepateikiau. Stengtis įgyvendinti reikalavimų tikslus ir patenkinti užsakovo lūkesčius.

Priešintis pagundai daryti PĮ reikalavimų keitimus arba įvesti naujus reikalavimus, vengti nevienareikšmių reikalavimų.

Lanksčiai vertinti užsakovo siūlomus PĮ reikalavimų keitimus. Ne visi pakeitimų siūlymai yra netikę, kai kurie pakeitimai yra neišvengiami.

Kurti atmosferą, kuri ne tik leistų bet ir skatintų tiekėją kelti PĮ reikalavimų tobulinimo klausimus. Atsižvelgti į tiekėjų arba užsakovo įsigijimo projekto darbo grupės iškeltus PĮ reikalavimų valdymo klausimus.

Kelti PĮ reikalavimų valdymo klausimus. Supažindinti užsakovą su iškilusiomis problemomis, neslėpti jų. Įvardinti reikalavimus, kurie kelia ypatingus rūpesčius. Tai gali būti didelės rizikos, sunkiai įgyvendinami reikalavimai, nuo kurių priklauso visos PĮ sudėtingumas, kaina arba darbų grafikas. Naudojant savo ekspertus, šviesti užsakovą klausimais, ko galima tikėtis iš PĮ. Paaiškinti užsakovui, kurie reikalavimai turi įtakos rizikai, PĮ naudojimo patogumui, funkcionalumui, kt.

Atvirai reikšti nuomonę. Būti ryžtingam ir lanksčiam. Nesitaikstyti su blogomis idėjomis. Dirbti su tiekėju ieškant alternatyvų.

Siūlyti PĮ reikalavimų alternatyvas, kurios geriau atitiktų užsakovo poreikius ar padėtų taupyti lėšas. Dirbti su užsakovu ieškant alternatyvų.

Reaguoti į tiekėjo užklausas laiku. Sutarus dėl PĮ reikalavimų pakeitimų, priimti juos laiku ir tinkamu būdu.

Suprasti, kad užsakovo žodis yra lemiamas priimant ar atmetant PĮ reikalavimų keitimo pasiūlymą.


60

Kai PĮ reikalavimai keičiami arba papildomi naujais, nebandyti versti tiekėją įgyvendinti pakeitimus, laikantis senojo darbų grafiko ar biudžeto. Suprasti, kad tiekėjas siekia pelno, o ne atlieka viešąją paslaugą. Jei reikalavimų keitimas ar papildymas yra būtinas, aptarti jų įdiegimo būdą. Kartais tai gali būti tik reikalavimo prioriteto keitimas žemesniu, o kitais kartais gali būti būtinumas keisti darbų grafiką ar biudžetą.

Nebandyti apgauti užsakovo teisinant PĮ reikalavimų keitimą, jog padaryti gerai galima tik už didesnę kainą. Kai kurie reikalavimų keitimai gali būti lengvai įtraukiami į PĮ projektą ir priimami nekeičiant darbų grafiko ar kainos. Kiti reikalavimų keitimai gali turėti teigiamą poveikį, iš esmės mažindami kainą bei trumpindami darbų grafiką.

Kurkime žmogaus ir PĮ sąsajos reikalavimus greitojo prototipų rengimo būdu

Ankstesniuose aiškinimuose akcentavome, kad užsakovas ir tiekėjas

nuomonių dėl PĮ reikalavimų skirtumus pašalina reikalavimų peržiūros metu.

Buvo daroma prielaida, kad užsakovas žino, kokios PĮ jis nori. Tačiau dažniausiai

taip nėra. Reikalavimų dokumento rengimo sunkumas yra tas, kad užsakovas

nesugeba suformuluoti savo norų. Tai viena iš priežasčių, kodėl projekto eigoje

būtina užsakovui betarpiškai dalyvavauti reikalavimų peržiūrose.

Ši problema yra ypač ryški, kai kalbama apie žmogaus ir PĮ sąsają.

Naudotojui labai sunku suformuluoti tikslius reikalavimus, kol jis neišbando

keleto versijų. Rašytinio dokumento rengimas yra netikęs būdas PĮ interaktyviajai

prigimčiai atspindėti. Sunku rašytinius reikalavimus perteikti vizualiai arba

numatyti, kokią įtaką sąsaja turės naudotojui. Todėl šios srities reikalavimų

nereikėtų labai detalizuoti. Geriausias kelias žmogaus ir PĮ sąsajos

reikalavimams parengti yra greitai rengiami prototipai. Tiesioginiai naudotojai

turėtų glaudžiai bendradarbiauti su PĮ kūrėjais. Iš esmės, PĮ kūrėjai turi siūlyti ir

leisti išbandyti naudotojui skirtingas sąsajas, kol nebus pasiektas priimtinas

sprendimas.

Sandoryje būtina numatyti lėšas greitiems sąsajos prototipų rengimams.

Užsakovas neturi tikėtis, kad tiekėjas padengs šias išlaidas.

Pastebėkime, kad aukščiau išvardinti darbai yra susiję su keliomis

pagrindinėmis PĮ įsigijimo nuostatomis (žiūr. 5 skyrių). Pirma, greitasis prototipų

rengimas reikalauja atviro ir geranoriško užsakovo ir tiekėjo bendradarbiavimo.

Antra, spręsdami PĮ reikalavimų klausimus, jiedu turi dirbti kaip viena komanda

(grupė). Trečia, turi būti pakankamas lankstumas, kad greitai rengiamų prototipų

būdu nustatyti reikalavimai būtų įtraukiami į PĮ reikalavimų sąrašą.


61

Greitai rengiamų prototipų metodo naudojimas nereiškia, kad žmogaus ir

PĮ sąsajos klausimai gali būti visiškai ignoruojami PĮ reikalavimų dokumente.

Reikėtų apibrėžti bendruosius sąsajos reikalavimus, tolesnį jų detalizavimą

atidedant atlikti užsakovo/tiekėjo grupei. Pvz., reikalavimų dokumente galima

nurodyti tik naudotojų tipus ir kiekius. Kruopštesnė analizė leis konkrečiai

įvardinti naudotojus: sistemos administratorius, kompiuteriais parengtų ataskaitų

naudotojus, sistemą remontuojančius technikus, kt.

PĮ reikalavimų dokumente taip pat turėtų būti nurodomos bendrosios

sąsajų galimybės. Pvz., galima būtų nurodyti funkcinį reikalavimą, kad PĮ turėtų

priimti operatoriaus pranešimus apie incidentus. Tačiau nebūtina nurodyti, kiek

eilučių ekrane tam turi būti skirta ar kurioje ekrano vietoje tai turi būti atliekama.

PĮ reikalavimų dokumente turėtų būti nuoroda, kad detalūs reikalavimai bus

gauti greitai rengiamų prototipų būdu (čia darome prielaidą, kad sudarytame

sandoryje yra numatyta lanksti reikalavimų plėtros galimybė). Taigi, PĮ

reikalavimų dokumente nurodoma „ką reikėtų daryti“, o ne „kaip reikėtų daryti“.


62

10. Kurti naują ar pirkti gatavą PĮ?

Vienas iš svarbiausių sprendimų, kurį turi priimti PĮ įsigyjančioji

organizacija, yra kurti naują ar pirkti gatavą PĮ. Privalomos griežtos ribos tokiame

pasirinkime, žinoma, nėra. Netgi jei PĮ yra skirta grynai individualiems

organizacijos poreikiams, kuriant ją gali būti naudojami pirkti gatavi

komponentai. Gatavos PĮ pavyzdžiais gali būti kompiliatoriai, kurių reikia PĮ

kurti, ir mažiau į akis krentantys žemesnio lygmens komponentai, kaip

komunikacijų protokolų realizavimo priemonės (TCP/IP tvarkylės, kt.).

Dažniausiai PĮ yra hibridinė, naudojanti pirktus gatavus komponentus,

komerciškai platinamą ir specialiai jai sukurtą įrangą. Tai tik klausimas, kokiu

laipsniu kiekviena iš minėtų dalių yra panaudojama įsigyjamoje PĮ.

Gatavos PĮ rūšys

Sąvoka „gatava PĮ“ (COTS) yra naudojama apibūdinti PĮ, kuri yra sukurta

kitur ir kurią įsigyjančiajai organizacijai geriau yra nusipirkti, nei kurti pačiai.

Gatava PĮ yra labai įvairi. Dažniausiai reikalingą PĮ, pvz., tekstų rengykles yra

sukūrusios stambios komercinės firmos. Daugelyje organizacijų yra paplitusi

tokia PĮ, kaip duomenų bazių valdymo sistemos, komunikacijų protokolų

tvarkyklės, PĮ kūrimo instrumentai (kompiliatoriai), kt. Todėl ypač apdairiems

reikia būti iškilus tokių PĮ komponentų kūrimo klausimui, nes dažniausiai jie yra

perkami. Jeigu ir iškyla toks klausimas, būtina kruopščiai išsiaiškinti tokių PĮ

komponentų kūrimo priežastis ir reikalavimus. Galų gale, jei be tokios PĮ kūrimo

negalima apsieiti, reikėtų samdyti atitinkamoje srityje patyrusius specialistus.

Gatava PĮ dažniausiai prekiauja daugiau nei vienas pardavėjas.

Sprendimo kurti naują ar pirkti gatavą PĮ priėmimo veiksniai

Sprendimui kurti naują ar pirkti gatavą PĮ priimti įtakos turi eilė veiksnių:

- vietinės aplinkybės organizacijoje gali kelti unikalius reikalavimus

įsigyjamai PĮ (pvz., nacionalinės kalbos problema). Tai gali būti

įgyvendinama įvairiai: adaptuojant nupirktą gatavą PĮ arba kuriant

naują, individualių poreikių PĮ. Tačiau būtina atidžiai peržiūrėti tokius

reikalavimus ir įsitikinti poreikių būtinumu;

- parduodamos gatavos PĮ modifikavimo, adaptavimo ir integravimo su

kita PĮ reikalingumas;

- gatavos PĮ veikimo perkančiosios organizacijos aplinkoje galimybės.

Tačiau reikėtų vengti pirma laiko apibrėžti arba labai detalizuoti

aplinką, kadangi tai gali trukdyti sprendimo pirkti gatavą PĮ priėmimui;


63

- sąsajos galimybės su oganizacijoje jau turima PĮ ar posistemiais. Ar

informacija apie gatavos PĮ sąsajas yra atvirai prieinama ir

dokumentuota, ar sąsajos yra uždaros (yra privati nuosavybė ir

nedokumentuota)?

- ar gatava PĮ atitinka organizacijos finansines, modifikavimo ir

integravimo, licencijų pratęsimo, priežiūros galimybes;

- vietinių ir išorinių PĮ kūrėjų, išmanančių perkančiosios organizacijos

funkcijas ir poreikius, buvimas ir jų kaina;

- gatavos PĮ dokumentacijos, atitinkančios jūsų poreikius, buvimas;

- perkančiosios organizacijos planai ir galimybės prižiūrėti ir tobulinti PĮ;

- laiko tarpas, per kurį PĮ turi būti įdiegta;

- perkančiosios organizacijos gebėjimas diegti ir plėtoti gatavą PĮ.

Gatavos PĮ pirkimo rizika

Apskritai, gatavos PĮ ar komponentų pirkimas mažina riziką. PĮ pirkimas

yra patrauklus dar ir dėl to, kad galima išvengti su PĮ kūrimu susijusių vargų.

Neabejotina tiesa, kad sutaupoma laiko ir pastangų, įdiegus kažkieno kito jau

sukurtą PĮ savo organizacijos aplinkoje.

Nežiūrint aukščiau minėtų privalumų, gatavos PĮ pirkimas turi riziką,

tačiau ji gali būti valdoma. Pardavėjams ir pirkėjams įgyjant daugiau patirties,

formuojantis standartams, tobulėjant technologijoms, gatavos PĮ pirkimo rizika

mažėja. 10.1 lentelėje yra išvardinta kai kuri rizika ir pateikiami pasiūlymai jai

sumažinti.

Čia derėtų prisiminti nuostatą (žiūr. 5 skyrių „PĮ įsigijimo nuostatos“), kad

nėra visa apimančių sprendimų.

10.1 lentelė. Gatavos PĮ pirkimo rizika ir kaip ją sumažinti

Rizikos sritis Kaip sumažinti riziką

Gatava PĮ negali idealiai atitikti pirkėjo individualių reikalavimų.

Jei gatava PĮ atitinka 80 proc. pirkėjo reikalavimų, sprendimas pirkti ją yra pateisinamas.

PĮ neatitikimas pardavėjo tvirtinimams; tikrovės ir reklamos neatitikimas.

Reikalaukime akivaizdaus PĮ veikimo pademonstravimo arba, dar geriau, padirbėkime su demonstracine arba skolinta PĮ versija, nustatykime jos vertę ir tik po to pirkime.

PĮ yra prastai suderinta, ištestuota. Dėl to ji gali būti netinkama naudoti ar netgi diegti.

Reikliai žiūrėkime į naujas arba 1.0 numerį turinčias PĮ versijas; reikalaukime PĮ kopijos įvertinimams atlikti.

Gatavos PĮ integravimo su kita PĮ Patikrinkime visų produktų tarpusavio


64

ir to patikrinimo rizika. Perkamos PĮ sąsajos gali būti uždaros, nedokumentuotos ir būti privačia nuosavybe.

sąveiką, gavę jų kopijas. Tik po to priimkime galutinį sprendimą pirkti gatavus produktus. Gaukime sąsajas aprašančius dokumentus. Pernelyg nedetalizuokime PĮ veikimo aplinkos.

PĮ dokumentai yra prasti arba jų iš viso nėra.

Sužinokime, kokio tipo dokumentai yra PĮ licencijoje. Išnagrinėkime dokumentus prieš pirkdami PĮ.

Gatavos PĮ uždarumas (individualių poreikų PĮ kūrimo atveju taip pat yra rizika dėl jos uždarumo)

Naudokime standartais paremtą atvirojo tipo PĮ. Naudokime atvirųjų formatų duomenis, kad juos būtų galima apdoroti ir kitur esančiomis priemonėmis.

Tikimybė, kad pardavėjas nutrauks prekybą gatava PĮ arba bankrutuos (šitokia rizika yra ir kuriant individualių poreikių PĮ)

Įvertinkime pardavėjo finansinį stabilumą ir jo parduodamos PĮ skverbtį (paplitimą) rinkoje. Reikalaukime raštiškų pardavėjo pasižadėjimų (dauguma mano, jog tai nevykęs sprendimas).

Pristatymo terminai. Atidžiai sudarykime PĮ pristatymo grafiką, kad jame būtų realios PĮ pristatymo datos; pasitikrinkime, ar produktas jau yra leidžiamas.

Parduodama gatava PĮ gali greitai pasikeisti. Naujų funkcijų įdiegimas viename produkte gali versti atnaujinti ir kitus produktus.

Planuokime keitimus. Parenkime naujos laidos produktų diegimo strategiją. Planuokime licencijų atnaujinimus, PĮ priežiūrą ir administracines išlaidas.

Gali būti verčiama pirkti tokio funkcijų paketo PĮ, kurioje šalia jums reikalingų funkcijų yra ir nepageidaujamų. Gali būti verčiama diegti ir naudoti nepageidaujamas funkcijas.

Peržiūrėkime PĮ modulinę struktūrą, atskirų modulių kainas, įvertinkime nebūtinas PĮ savybes ir plėtros galimybes.

Kaip pirkti PĮ?

Kai norime išsinagrinėti gatavos PĮ tinkamumo jums klausimus, visų pirma

reikia atlikti rinkos analizę, pažiūrėti, ar yra funkcinių, sisteminių, finansinių

reikalavimų ir galimybių požiūriais jums tinkanti PĮ. Peržiūrėkime produktų

aprašus, aptarkime savo sampratą ir poreikius su pardavėju, įsitikinkime, ar jo


65

parduodamas produktas gerai atitinka jūsų sampratą. Jūs galite pasitarti ir su

kitomis organizacijomis, kurios jau turi įsigiję ir naudoja tokią PĮ.

Kai kuriais atvejais gatavos PĮ įsigijimo ir integravimo klausimai gali būti

sprendžiami lengviau, jei yra galimybė tai daryti apsijungus kelioms

organizacijoms. Tokiais atvejais, žinoma, pasirinkta PĮ turi atitikti visų šių

organizacijų poreikius.

Nutarus pirkti gatavą PĮ, pagrindiniai jos įsigijimo žingsniai ir

samprotavimai yra šie:

- rengiant PĮ reikalavimus įvardijama, kurie iš jų yra privalomi, o kurie

papildomi. Kiek įmanoma reikalavimuose reikia atspindėti

funkcionalumą ir lankstumą, pagrindinį dėmesį skiriant poreikiams, o

ne kaip visa tai turėtų būti padaryta;

- sudaroma grupė gatavai PĮ vertinti ir parengiamas darbo grafikas;

- įvardinami vertinimo kriterijai, pasirinkimo veiksniai ir prioritetai.

Nurodoma, kokiu laipsniu perkama gatava PĮ turi atitikti reikalavimus,

ir santykinė PĮ funkcijų svarba biudžeto ir darbų grafiko prasmėmis.

Gali būti specifiniai pačios PĮ kriterijai arba bendrieji, kaip PĮ atitikimas

standartams ar pardavėjo taisyklės (policy) dėl jos atnaujinimo;

- sudaroma matrica, kurioje nurodoma, kokia gatava PĮ ir kokius jūsų

reikalavimus atitinka (žiūr. 10.2 lentelę). Į ją įtraukiami PĮ funkciniai ir

veikimo reikalavimai. Veikimo reikalavimo pavyzdžiu gali būti, kiek

klientų vienu metu arba kaip greitai juos gali aptarnauti PĮ.

Priklausomai nuo reikalavimo, įvertinimas matricoje gali būti

išreiškiamas žodeliu Taip/Ne arba skaičiumi, pvz., balu nuo 1 iki 10.

Informacijos šaltiniai tokiems įvertinimams padaryti yra literatūra apie

produktus, pardavėjų teikiama informacija, produktų demonstracijos,

galimybė gauti PĮ kopiją vertinimams atlikti;

- atsisakoma tos PĮ, kuri neatitinka jūsų nustatytų privalomų reikalavimų.

Tokiais atvejais reikia būti ypatingai atidiems, nes PĮ gali būti nauja,

moderni;

- likusi PĮ, t.y. ta, kuri atitiko privalomus reikalavimus, vertinama

kruopščiau. Vertinimo būdas išbandant yra priimtinausias. PĮ reikėtų

tikrinti aplinkoje, kiek įmanoma artimesnėje jūsų organizacijos

aplinkai. Vertinimo kriterijais turi būti PĮ lankstumas, kokiu laipsniu

naudotojas gali pritaikyti PĮ savo poreikiams, reikiamų pakeitimų kiekis

ir dydis, integravimo paprastumas, kiekvieno veiksmo rizika. Vertinimo


66

kriterijumi gali būti ir pardavėjo kreditavimo galimybės, jo finansinis

gyvybingumas;

- PĮ nupirkusiųjų sąrašo gavimas iš pardavėjo ir pokalbis su jais.

Pastarųjų klausiama apie PĮ kokybę, pardavėjo teikiamą pagalbą

(paramą);

- išrenkama PĮ, geriausiai atitinkanti pirkėjo poreikius;

- pasirašomas PĮ pirkimo sandoris; jame numatomi punktai, leidžiantys

daryti pakeitimus (pvz., reikalavimų, funkcionalumo, kainos); sutariama

dėl kainos, lanksčių licencijavimo sąlygų, įvertinančių geografinius

veiksnius, naudotojų kiekį ir PĮ atnaujinimus;

- kuriama speciali PĮ nupirktai gatavai PĮ integruoti į bendrąją jūsų

sistemą (integruoti su anksčiau esama sistema arba kitais posistemiais);

- įgijus darbo su nupirkta gatava PĮ patirtį, teikiami pageidavimai

tobulinti ją. Prieš imantis kokio nors tobulinimo, drauge su pardavėju

išnagrinėjama, kuriuos pakeitimus lengva padaryti, o kokius sunku;

- jei organizacijos specifiniams poreikiams tenkinti sukurta PĮ derinama

su nupirkta gatava PĮ, aptariami intelektinės nuosavybės teisių

klausimai. Netgi turint neribotas teises naudoti specifinę PĮ, gali tekti

papildomai pirkti gatavos PĮ naudojimo licencijas kiekvienai darbo

vietai (workstation). Bendroji intelektinės nuosavybės teisė į visą

sistemą gali būti netaikoma joje panaudotiems komponentams.

10.2 lentelėje, priklausomai nuo įsigijimo projekto, kai kurios eilutės iš

„Kitų kriterijų“ gali būti perkeltos į „Privalomus reikalavimus“.

Atkreiptinas dėmesys į tai, kad dauguma organizacijų aukščiau aprašytus

gatavos PĮ įsigijimo žingsnius naudoja formaliame tiekėjo išrinkimo procese.

Apskritai, gatavos PĮ pirkimo sėkmė labiausiai priklauso nuo

įsigyjančiosios organizacijos supratimo ko siekiama ir ko reikės nupirktai PĮ

integruoti į organizacijos aplinką.


67

10.2 lentelė. Gatavos PĮ vertinimo matricos pavyzdys

A produktas B produktas C produktas

Privalomi reikalavimai

1 reikalavimas

2 reikalavimas

- - - - -

Kiti kriterijai

Kaina

Naudotojo sąsaja

Duomenų teisingumas

Licencijavimas

Atnaujinimas (upgrade)

Saugumas

Darbuotojų mokymas

Pardavėjo stabilumas


68

11. Įsigijimo sandorių sudarymas

PĮ įsigijimo sandorių sudarymas yra daug ginčų keliantis klausimas. Nėra

aišku, koks sandorio tipas yra geriausias PĮ įsigijimo atveju.

Sandorių tipai, kurie naudojami kitose srityse, gali būti naudojami ir PĮ

įsigijimo atveju. Kai kurie iš jų tinka netgi laikantis PĮ įsigijimo nuostatų (žiūr. 5

skyrių). Sandorių problemos atsiranda dėl kitų, daug svarbesnių priežasčių, kaip,

pvz., užsakovo ir tiekėjo nesugebėjimo palaikyti atvirus ryšius. Netgi idealus

sandoris gali žlugti, jei įsigijimo procesas nebus tinkamai valdomas.

Nors ir nėra visiškai aišku, koks turėtų būti PĮ įsigijimo sandoris, tačiau ko

nereikėtų daryti yra aišku. Prieš dėstydami rekomendacijas, visų pirma

apžvelkime PĮ įsigijimo sandorių alternatyvas.

Tinkamam sandoriui sudaryti reikia gerai žinoti jų tipus, pobūdžius ir

skirtumus.

Sandorių tipai

PĮ įsigijimo projektuose paprastai nadojami trys sandorių tipai, turintys eilę

variacijų. Jie skirstomi pagal tai, kaip yra atsiskaitoma su tiekėju:

- fiksuotos kainos sandoriai, kurie dar vadinami mažiausios kainos

sandoriais;

- išlaidas padengiantieji sandoriai;

- laiko ir medžiagų apmokėjimo sandoriai, kai tiekėjas turi atlikti įvardintus

darbus per nustatytus terminus, taip pat apmokant jam už sunaudotas

medžiagas.

Sandorių pobūdis

Sandorio pobūdis atspindi vieno sandorio arba kelių sandorių kombinacijos

vykdymo būdą, aplinkybes įsigijimo projekte. Įvardinkime sandorių pobūdžius

taip:

- darbų prižiūrėtojo/tiekėjo sandoris. Toks paprastai būna statybiniuose

sandoriuose. Sandoriui prižiūrėti visų pirma parenkamas ekspertas -

darbų prižiūrėtojas, o darbus vykdo parinktas tiekėjas;

- sistemų vadovo sandoris. Šiuo atveju parenkamas vadovas (firma), kuris

yra atsakingas už visos sistemos sukūrimą ir įdiegimą;

- projektavimo/kūrimo sandoris. Inovaciniai (individualių poreikių)

sandoriai dažniausiai būna šitokio pobūdžio;

- projektavimo už nustatytą kainą ir nustatytu laiko grafiku sandoris;

- kūrimo pagal sąmatą sandoris.


69

11.1 lentelėje pateikiami įvairaus pobūdžio sandorių pliusai ir minusai.

Viena bendra visų jų problema yra ta, kad PĮ įsigyjima atskirai nuo likusios

sistemos dalies. Aparatinės įrangos pirkimas mažiausia kaina, neatsižvelgiant į

PĮ, gali pareikalauti nemažų PĮ pertvarkymo sąnaudų. Taip gali atsirasti nemaža

kainos padidėjimo ir PĮ sukūrimo rizika. Kitaip tariant, aparatinė įranga ir su ja

susijusi PĮ turi būti įsigyjamos kartu.

Kokio tipo sandorį reikėtų rinktis?

Laiko ir medžiagų apmokėjimo sandoriai gerai tinka individualių poreikių PĮ

kurti, ypač kai projektas skaidomas į atskiras užduotis (etapus). Jie suteikia

lankstumo galimybę. Vietoje to, kad viską turėtume būti numatę iš anksto, toks

sandoris leidžia kurti PĮ palaipsniui, planavimą tęsiant projekto eigoje. Jei

ankstesnio etapo eigoje išryškėja nauji poreikiai ar galimybės, tiekėjas gali tęsti

darbus jiems įgyvendinti. Derybos dėl atsiskaitymo už atskiras užduotis vyksta

sandorio vykdymo eigoje. Kai prireikia daryti pakeitimus ir dėl jų sutariama,

tiekėjas gali pasakyti, kad pakeitimams atlikti reikės kažkiek darbo valandų ir tai

kainuos tam tikrą sumą. Kiekvienu tokiu atveju nereikia grįžti į sandorio pradžią

ir iš naujo derėtis dėl viso projekto kainos.

Įvairiose valstybėse teisės aktų nuostatos dėl šio sandorių tipo gali skirtis.

Laiko ir medžiagų apmokėjimo sandoriai gali būti nepriimtini, ypač kai PĮ kūrimo

rizika yra maža ir jai sukurti naudojami nupirkti gatavi komponentai.

Fiksuotos kainos sandoriai užsakovams gali atrodyti kaip patys geriausi. Jie

kuria PĮ už garantuotas lėšas. Iš pažiūros visa rizika tenka tiekėjui. Tačiau

faktiškai dauguma užsakovų yra aktyvūs dalyviai sprendžiant naudos/nuostolių

klausimus: derantis su tiekėju dėl projekto įgyvendinimo kainos, parenkant

mažiausios kainos tiekėją, spaudžiant tiekėją įvairiais požiūriais.

Užsakovo ir tiekėjo grupinio darbo santykiuose paprastai tvyro „laimėjimo-

pralaimėjimo“ atmosfera, kas įsigijimo procese yra labai svarbu. Praktikoje,

iškilus nenumatytiems atvejams, dažniausiai pralaimi abi pusės. Sudarant

fiksuotos kainos sandorį daroma prielaida, kad visi reikalavimai yra žinomi iš

anksto, ir todėl jie nėra dėmesio centre. Užsakovas patiria nuostolius, kai reikia

daryti pakeitimus. PĮ įsigijimo atveju keitimai yra neišvengiami, nes parengti

pastovius reikalavimus iš anksto yra labai sunku. Todėl realiai įsigijimo projekto

mažiausios kainos nustatyti neįmanoma.

Dėl minėtos priežasties eilė organizacijų atsisako fiksuotos kainos tipo

sandorių. Todėl vietoje jų naudojami išlaidas padengiančiojo tipo sandoriai.

Protingai parengti išlaidas padengiantieji sandoriai yra lankstesni. Pvz., tiekėjas

galėtų būti daugiau sukalbamas sprendžiant reikalavimų keitimo klausimus, jei

už tai jam būtų mokama. Išlaidas padengiančiuosiuose sandoriuose užsakovui

Valdas Undzėnas. Programų sistemų įsigijim

as ir priežiūra. M

okymo m

edžiaga. Vilnius, 2007

70

11.1 lentelė. Požiūrių į sandorius pliusai ir minusai

Sandorio pobūdis

Pobūdžio aprašas

Pobūdžio pliusai

Pobūdžio minusai

Darbų

prižiūrėtojo/

tiekėjo

Užsakovas įprastu paslaugų pirkimo

būdu parenka ekspertą – darbų

prižiūrėtoją, remdamasis

kvalifikacijos ir gebėjimo atlikti

darbą kriterijais. Darbų prižiūrėtojas

rengia objekto pirkimo dokumentus

(planus, specifikacijas). Po to

potencialūs tiekėjai prašomi teikti

pasiūlymus pagal objekto pirkimo

dokumentų (RFP) reikalavimus. Kai

išrenkamas laimėjęs tiekėjas,

projektas vykdomas laikantis

pasiūlymo dokumentų. Parinktasis

darbų prižiūrėtojas gali tikrinti

tiekėjo pasiūlymo dokumentus.

Atsakingas asmuo yra užsakovo

organizacija.

- seniai sutinkamas požiūris;

- gerai apibrėžti vaidmenys;

- teisiniai ginčų sprendimo

būdai yra įprasti;

- galutinis objektas gerai

apibrėžiamas jau

ankstyvojoje stadijoje;

- tiekėjas valdo subrangovus.

- nelankstus ryšys tarp objekto

projekto ir paties objekto;

- netinka PĮ kūrimo darbams:

sunku apibrėžti reikalavimus,

užsakovas gali nemokėti

išreikšti savo norų;

- PĮ integravimą ne visada

atlieka pirmasis (pagrindinis)

tiekėjas;

- tiekėjas turi finansinį stimulą

ieškoti trūkumų pirkimo

dokumentuose (RFP) ir

pasikeitusių aplinkybių, taip

siekti projekto pakeitimų;

- apriboja užsakovo ir tiekėjo

bendravimą, kai objektą kuria

subrangovas.



okymo m


71

Sistemų vad

ovo

Įprastu paslaugų pirkimo būdu

parenkamas visos sistemos kūrimo

vadovas (remiamasi kvalifikacija;

atranka vykdoma konkurencinių

derybų būdu). Sistemos vadovas yra

atsakingas už įsigijamos PĮ projekto

(planų, specifikacijų) parengimą, PĮ

kūrimą, aparatinės įrangos įsigijimą,

integraciją, mokymus ir bendrąją

kokybės kontrolę. Aparatūra,

el.energijos tiekimo ir kompiuterių

tinklų įrengimo paslaugos perkamos

mažiausios kainos principu.

- visos sistemos projektą, PĮ

kūrimą, integravimą ir

bandymus kontroliuoja

vienas asmuo;

- PĮ kūrėjas paprastai būna

pirmasis (pagrindinis)

tiekėjas;

- minimali galimybė išsiginti

kaltės;

- didesnis lankstumas

prireikus daryti keitimus;

- galimybė atmesti

mažiausios kainos

pasiūlymus;

- užsakovui yra lengviau

palaikyti ryšį su sistemos

vadovu.

- yra mažai reikiamus

gebėjimus turinčių sistemų

vadovų (firmų);

- sistemų vadovas gali būti

nežinomas užsakovo

specialistams ar pirkimų

pareigūnams;

- didelė priklausomybė nuo

sistemų vadovo;

- galutinis produktas ne taip

gerai apibrėžiamas nei

da

rbų prižiūrėtojo/tiekėjo

sandorio atveju;

- reikalavimas viešojo

sektoriaus įstaigoms laikytis

mažiausios kainos principo

parenkant tiekėją;

- reikalavimas pirkti aparatinę

įrangą laikantis mažiausios

kainos principo,

neatsižvelgiant į susijusią PĮ.



okymo m


72

Projektavimo/kūrimo Užsakovas pats rengia bendrąjį

įsigijimo planą. Toks planas

paprastai jau sudaro 15-30 proc.

įsigijamo objekto projekto. Vėliau

parenkamas tiekėjas. Šio pobūdžio

sandoryje ir už objekto projektavimą,

ir už jo kūrimą atsakinga viena

firma . Užsakovo pareiga yra

prižiūrėti projektavimo/kūrimo

darbus. Projektavimo/kūrimo

sandorius paprastai naudoja

valstybinės įstaigos, vykdydamos

viešuosius pirkimus.

- visa atsakomybė tenka

projektuotojų/kūrėjų grupei;

- atkrenta sunkumai, susiję su

projektuotojo žinių

perdavimu kūrėjui

(gamintojui);

- galimybė greičiau įvykdyti

projektą;

- galimybė geriau organizuoti

pirkimus;

- problemoms išspręsti reikia

bendrauti tik su viena firma;

- finansinis stimulas greičiau

užbaigti darbus;

- yra tam tikros darbų

atlikimo garantijos.

- užsakovui tenka didesnė

atsakomybė už tikrinimo ir

patvirtinimo procesus;

- projektavimo/kūrimo sandoris

gali būti sunkiai skiriamas

nuo da

rbų prižiūrėtojo/tiekėjo

sandorio, jei darbų

prižiūrėtojas rengia detalų

planą;

- galima projekto kainos

padidėjimo rizika dėl tiekėjo ir

aukštos pasiūlymų kainos

(objekto projektas dar nebūna

parengtas);

- galimybė pažeisti įstatymus;

- didelė užsakovo atsakomybė

už kokybės kontrolę.

Projektavimo už

nustatytą kainą ir

nustatytu laiko

grafiku

Sudaromas prioritetinių reikalavimų

sąrašas. Tiekėjas parengia visus

privalomus projektus ir kiek

įmanoma papildomų, jei tą leidžia

kainos ir laiko apribojimai.

- mažiau kaitaliojami

reikalavimai;

mažesnė kainos viršijimo ir

nukrypimo nuo darbų grafiko

rizika.

- tiekėjas gali nesistengti

pateikti alternatyvių projektų;

- per daug optimistiški

pasiūlymai gali būti išrinkti

laimėjusiais.



okymo m


73

Kūrimo paga

l

sąmatą

Kitaip nei projektavim

o/kūrimo

sandorio atveju, užsakovas pateikia

tik PĮ funkcinius reikalavimus, o ne

detalų projektą. Tiekėjas,

remdamasis savo ankstesniais

geriausiais sprendimais ir

naudodamas tinkančius gatavus

elementus, kuria funkcinius

reikalavimus atitinkančią PĮ.

- leidžia tiekėjams

maksimaliai lanksčiai

išnaudoti efektyviausius

kainos požiūriu sprendimus;

- mažesnė rizika, nes tiekėjai

naudojasi anksčiau sukaupta

patirtimi ir sukurta PĮ;

- galimybė išplėsti PĮ

funkcijas už turimas lėšas.

- užsakovai retai naudoja šitokio

pobūdžio sandorius;

- rizika dėl PĮ įsigijimo plano

nebuvimo;

- tiekėjo parengtas detalus PĮ

įsigijimo planas gali kelti daug

ginčų, dėl ko gali vėluoti

projektas.

Kurti, pačiam turėti,

naudoti įdiegus

kitur, nuomoti.

Tai ilgalaikiai sandoriai apimantys finansavimą, projektavimą, kūrimą, eksploatavimą ir pajamų

rinkimą

iš aptarnaujamų asmenų. Sistemos diegimo

fazėje šitokio

pobūdžio sandoriai yra

ekvivalentiški projektavimo/kūrimo arba kūrimo

paga

l sąmatą sandoriams. Skirtumai atsiranda

sistemos naudojimo ir priežiūros fazėse. Tai tipiški sandoriai, nes jie nereikalauja iš sistemos užsakovo

pradinių (išankstinių) kapitalo įnvesticijų.


74

yra prieinamos bet kokių sugebėjimų reikalaujančios paslaugos, jei padengiamos

tiekėjo išlaidos. Fiksuotos kainos sandoriuose yra priešingai: tiekėjai nenori daryti

keitimų, jei tam reikia papildomų išlaidų. Išlaidas padengiančiuosiuose

sandoriuose lengviau sprendžiamos įsigijimo procese sutinkamos nenumatytos

problemos ir nereikia iš naujo derėtis dėl viso sandorio.

Išlaidas padengiantieji sandoriai turi ir tam tikrų trūkumų. Užsakovas ir

tiekėjas yra verčiami tvarkyti papildomus „popierius“, nes tiekėjo išlaidos turi

būti perduotos kontrolei (auditui). Fiksuotos kainos sandoriuose užsakovas gali

skirti mažesnį dėmesį tiekėjo patirčiai; apibrėžta PĮ turi būti sukurta už sutartą

kainą. Kokiu būdu tiekėjas tą darys, užsakovui nerūpi. Tačiau išlaidas

padengiančiajame sandoryje turi būti kaupiami ir audito duomenys, kam tos

išlaidos buvo panaudotos. Tai yra papildomų išlaidų priežastis.

Užsakovai, kurie PĮ įsigyti renkasi išlaidas padengiančiuosius sandorius,

turėtų žinoti keletą patarimų. Jei jų nepaisoma arba nėra galimybių į juos

atsižvelgti (pvz., dėl organizacijos vidaus taisyklių pirkimų klausimais), tuomet

geriau rinktis fiksuotos kainos tipo sandorius. Patarimai yra tokie:

1 patarimas. Nenaudokime lėšų stokos kaip pateisinimo išlaidas

padengiančiojo sandorio sąlygoms nevykdyti. Kartais sakoma, kad kiekvienas

išlaidas padengiantysis sandoris yra ne kas kita, kaip fiksuotos kainos sandoris su

apatine kainos riba. Kai visas projektas neturi lėšų atsargos, jis yra nelankstus.

Todėl potencialios išlaidas padengiančiųjų sandorių galimybės neišnaudojamos.

Be to juose reikia papildomų lėšų išlaidoms administruoti. Tiekėjai taip pat

patiria išlaidas. Teoriškai tiekėjas gali atsisakyti išlaidas padengiančiojo sandorio,

jei užsakovas nepadengia šių papildomų išlaidų. Bet praktikoje tas nedaroma,

nes stengiamasi išlaikyti gerus santykius su užsakovu ir išsaugoti savo dalykinę

reputaciją.

Apskritai, turint riboto dydžio lėšas, išlaidas padengiantieji sandoriai nėra

patogūs, nes užsakovai ir tiekėjai verčiami daryti papildomas išlaidas, netgi kai

šio tipo sandorių privalumų nepavyksta realizuoti. Taip pat tai reikalauja

didesnių tiekėjo pastangų, norint gauti maksimalų pelną.

2 patarimas. Nenaudokime viename projekte išlaidas padengiančiojo

sandorio PĮ įsigyti, o fiksuotos kainos sandorių - aparatinei įrangai įsigyti. Dažnai

PĮ kūrimas gali būti pagreitintas panaudojus geresnius kompiuterius, nusipirkus

didesnės talpos atmintinę arba įjungus į tinklą dar vieną kompiuterį. Tačiau

fiksuotos kainos sandoriuose tiekėjas nėra pajėgus įsigyti papildomą įrangą. Tai

neskatina jo savo darbe naudoti geresnę aparatinę įrangą. Tuo tarpu išlaidas

padengiančiuosiuose sandoriuose PĮ įsigyti tiekėjui atlyginama už pastangas,

netgi jei jų priežastis yra nepakankamas jo turimos aparatinės įrangos lygis.


75

Todėl tiekėjas, stengdamasis sukurti užsakovui geresnę, pvz., greičiau veikiančią

ar mažiau atminties naudojančią PĮ, gali išleisti žymią užsakovo lėšų dalį savo

darbo instrumentams pagerinti. Kita vertus, tiekėjo pastangos „įsprausti“ kuriamą

PĮ į nepagrįstai mažą (galbūt, pasenusią) aparatinę įrangą, yra laiko ir pinigų

švaistymas.

Trumpai tariant, aparatinės įrangos ir PĮ įsigijimo sandorių tipai turi atitikti

vienas kitą. Tiekėjas ir užsakovas turi būti lankstūs darydami kompromisus dėl

aparatinės įrangos, PĮ ir jų ryšio.

3 patarimas. Didesnių pertvarkymų nereikalaujančiai gatavai PĮ pirkti

geriausiai tinka fiksuotos kainos sandoriai. Tai yra dar vienas gatavos PĮ įsigijimo

privalumas.

Kokio pobūdžio sandorį reikėtų rinktis?

Darbų prižiūrėtojo/tiekėjo pobūdžio sandoriai grindžiami keliomis

pagrindinėmis prielaidomis. Tačiau jos neteisingos PĮ atveju. Darbų

prižiūrėtojo/tiekėjo sandoriai PĮ įsigijimo atveju yra nepriimtini dėl šių priežasčių:

- darbų prižiūrėtojo/tiekėjo sandoriai naudojami gerai specifikuotoms

sistemoms. PĮ įsigijimo projektas nebus sėkmingas, jei vadovausimės

griežta specifikacija, nes parengti detalius PĮ reikalavimus iš anksto

neįmanoma;

- darbų prižiūrėtojo/tiekėjo sandoriai dažnai supriešina užsakovą ir tiekėją,

kas prieštarauja nuostatai, kad PĮ įsigijimo projektuose būtinas užsakovo

ir tiekėjo bendradarbiavimas;

- darbų prižiūrėtojo/tiekėjo pobūdis apriboja užsakovo galimybes dalyvauti

įsigijimo procese. Tai irgi prieštarauja užsakovo ir tiekėjo

bendradarbiavimo nuostatai;

- darbų prižiūrėtojo/tiekėjo sandoriai geriausiai tinka kuriant sistemas,

kuriose naudojamos gerai žinomos technologijos;

- darbų prižiūrėtojo/tiekėjo pobūdis remiasi tuo, kad objekto (pvz., namo)

projektavimo kaina yra santykinai maža lyginant su pačio objekto kaina.

PĮ atveju yra priešingai: diskelio ar kitokios PĮ laikmenos kaina yra

žymiai mažesnė už PĮ kūrimo kainą;

- mažiausios kainos pricipu parenkamo tiekėjo parinkimo metu faktiškai

įvardijama pradinė PĮ kaina. Tačiau po PĮ įdiegimo jos priežiūrai

reikalingų lėšų dydis yra didesnis nei pradinė PĮ kaina.

Kadangi darbų prižiūrėtojo/tiekėjo sandoriai PĮ įsigyti yra nepriimtini,

panagrinėkime kitus. PĮ atveju ir jie nėra idealūs, tačiau gali būti naudojami

sėkmingai.


76

Sistemų vadovo pobūdžio sandoriai turi tą privalumą, kad užsakovas samdo

įsigijimo projekto vadovą laikotarpiui, kol projektas nebus iki galo užbaigtas.

Vadovas turi visą sistemos vaizdą, supranta įvairių sprendimų priežastis ir gali

valdyti projekto eigą (darbų prižiūrėtojo/tiekėjo pobūdžio sandoriuose

prižiūrėtojas tik padeda parengti PĮ reikalavimus ir nedalyvauja tolesniame

įsigijimo proceso planavime). Vadovas drauge su užsakovu rengia PĮ

reikalavimus. Jis taip pat gali būti atsakingas už PĮ kūrimą arba būti PĮ ekspertų

grupės narys (žiūr. 7 skyrių „Darbuotojų grupės įsigijimams atlikti sudarymas“).

Tačiau tiekėjai, kurie dirba kaip sistemų vadovai, skundžiasi, kad jiems

neleidžiama valdyti viso projekto. Užsakovas gali turėti daug sandorių, ir ne visi

jie yra sistemų vadovo pobūdžio. Užsakovas sprendžia, kada priimti sandorių

metu sukurtas posistemes, kartais atsisakant arba ignoruojant sistemų vadovo

rekomendacijas. Sistemų vadovui gali tekt rengti PĮ darbui su kitomis

sistemomis, kurioms jis nėra pritaręs. Taip sistemų vadovas atsiduria

nepavydėtinoje padėtyje, kai užsakovas nesuteikia jam tinkamų įgaliojimų.

Projektavimo/kūrimo pobūdžio sandoriai suteikia galimybę išspręsti

daugumą problemų, būdingų aukščiau nagrinėtiems požiūriams. Laikantis jo,

visa atsakomybė už sistemą tenka vienam tiekėjui. Tai suteikia lankstumo, pvz.,

priimant kompromisus aparatinės įrangos, PĮ arba ryšio priemonių klausimais.

Projektavimo/kūrimo sandoriuose užsakovui svarbu suvaldyti savo norus

(lūkesčius). Sandoris su vienu tiekėju užsakovui kelia mažiau rūpesčių, nei keli

sandoriai. Tačiau sunku tikėtis, kad tai padėtų sumažinti bendrą sistemos kainą.

Taip yra todėl, kad pagrindinių išlaidų dydžiui įtakos neturi tai, ar jos padaromos

sandoryje su vienu ar keliais tiekėjais.

Fiksuotos kainos tipo sandoriuose projektavimo/kūrimo pobūdis taip pat

sukelia tam tikrų problemų. Jos atsiranda ne vien dėl to, kad užsakovas biudžetą

gauna dar nežinodamas PĮ reikalavimų, bet ir todėl, kad sudaromo sandorio

kaina taip pat nustatoma dar nesant reikalavimų. Gaunasi, kad PĮ kūrimo fazė

būna suspausta iš dviejų pusių: ambicingų reikalavimų ir pernelyg mažo pinigų

kiekio.

Kiti galimi pasirinkimai

Viename įsigijimo projekte gali būti sudaroma daug sandorių atskiroms

konkrečioms užduotims atlikti (konkrečių užduočių sandoriai). Pradžioje

finansuojama tik viena užduotis. Likusios užduotys yra pagalbinės (nebūtinos), ir

užsakovas vėliau nusprendžia, vykdyti jas ar ne. Pirmosios užduoties tikslas yra

inicijuoti visą darbą, t.y. atlikti reikalavimų analizę, parengti detalų projektą, kitų

projekto fazių vykdymo planą. Jei pirmoji užduotis atliekama gerai, tuomet


77

finansuojama kita iš eilės einanti užduotis. Vykdant pastarąją gali būti

planuojama tolesnė užduotis arba bazinis sistemos projektas papildomas

naujomis funkcijomis. Kitos užduotys tvarkomos panašiai, derantis dėl kiekvienos

jų atlikimo kainos.

Šitoks skaidymo į užduotis (fazes) požiūris turi savus privalumus: PĮ

suskaidoma į nedideles dalis; tiekėjas suinteresuotas gerai atlikti darbus, kad

būtų finansuojamos kitos dalys; užsakovui ir tiekėjui sudaroma galimybė kaupti

žinias projekto eigoje. Kuriant dideles sistemas, tokiu būdu gaunamas realus

darbų grafikas, yra mažiau neaiškumo dėl biudžeto, lanksčiau naudojamos lėšos.

Pradžioje suplanuoti pinigai vėlesnių fazių reikmėms gali būti panaudoti

anksčiau iškilusioms užduotims vykdyti. Jūs iš karto galite nepasiekti to, ko

tikėjotės, tačiau galite įgyti darbo patirties. Iš ankstesnių užduočių vykdymo

užsakovas gali pasimokyti, ko tiekėjas nepajėgus atlikti, kokiu atveju atsisakyti jo

paslaugų ir nebefinansuoti kitų užduočių.

Anksčiau nagrinėtų sandorių tipų ar pobūdžių variacijos gali būti gaunamos

pravedant projektų rengimo konkursą tiekėjo atrankos procese. Du arba daugiau

tiekėjų projekto pradžioje gali būti kviečiami dirbti lygiagrečiai. Pagal jų darbo

rezultatus atliekama galutinė atranka. Tokiu būdu sugebėjimas dirbti, o ne rašyti

pasiūlymus, yra pagrindinis veiksnys atrenkant galutinį tiekėją. Tačiau šiuo

atveju būtina pasirūpinti, kad konkurso dalyvių parengti projektai būtų vertinami

vienodai ir nebūtų atskleisti kitiems konkurso dalyviams.

Eilėje valstybių sandorių PĮ kurti sudarymo taisyklės yra griežtos. Iš tokios

padėties gelbstimasi finansuojant kitų organizacijų darbus. Pvz., valstybiniams

universitetams suteikiama teisė sudaryti PĮ įsigijimo sandorius ir vadovauti

tokiems projektams. Rizika tame gali būti tokia, ar tos organizacijos supranta

užsakovo poreikius ir turi reikiamus PĮ kūrimo sugebėjimus.

Nereikėtų pamiršti, kad išvengti PĮ įsigijimo sandorių rizikos galima perkant

gatavą PĮ.

Galų gale, pasverkime ir savo galimybes prieš rinkdamiesi sandorio tipą ar

pobūdį PĮ įsigyti.

Pasirinkto sandorio tipo įtaka įsigijimo projektui

Užsakovo pasirinktas sandorio tipas ar pobūdis gali turėti nemažą įtaką PĮ

įsigijimo proceso įvairių veiklų sekai. Kai kuriuose sandoriuose PĮ reikalavimai

rengiami dar prieš skelbiant prašymą teikti pasiūlymus (RFP). Jie perduodami PĮ

tiekėjams (kūrėjams), kuriais jie vadovaujasi tolesniame darbe. Pasirinkus kitokį

sandorio tipą, PĮ reikalavimai gali būti rengiami drauge su tiekėju po sandorio su

juo pasirašymo. Tuomet tik bendrieji PĮ reikalavimai arba savybių sąrašas


78

rengiami prieš skelbiant prašymą teikti pasiūlymus (žiūr. 6 skyrių „Įsigijimo

veiklų seka“).

Geriau remtis sėkmingų įsigijimo projektų pavyzdžiais, nei sandorių tipais

Nors nė vienas sandorių tipas ar pobūdis nebuvo specialiai kurtas PĮ, visus

juos galima naudoti PĮ įsigijimui. Svarbiausia, kad sandoryje būtų numatytos

visos sąlygos geriausiems PĮ įsigijimo veiksmams atlikti. Užtikrinkime, kad

sandoryje būtų laikomasi įvairių šioje mokymo medžiagoje akcentuotų PĮ

įsigijimo nuostatų. Pavyzdžiui:

- nežiūrint sandorio tipo, turi būti sudarytos sąlygos dažniems ir atviriems

užsakovo ir tiekėjo kontaktams. Tai gali pareikalauti aiškios sandorių

kalbos, ypač jei į PĮ kūrimą įtraukiami subrangovai;

- sandoriuose turi būti numatytas reikiamas lankstumas. Jis turi būti toks,

kad jų metu nebūtų prieinama iki teisinių ginčų.

Tinkamo sandorio tipo parinkimas reikalauja glaudaus bendradarbiavimo su

užsakovo sandorių sudarymo ir teisės specialistais. Nuo projekto pradžios jie

turėtų būti įtraukti į darbo grupę. Kuo anksčiau tai bus padaryta, tuo geriau jie

susipažins su projekto tikslais, supras PĮ ypatumus ir kuo ji skiriasi nuo kitokių

objektų, supras kitokio požiūrio į PĮ įsigijimą reikalingumą. Drauge būtina

išsiaiškinti alternatyvas ir įsitikinti, ar kitokie, anksčiau nenagrinėti sandorių

tipai yra neteisėti ar tik neįprasti. Tai gali pareikalauti gilių „know-how“

vadybininko žinių ir nuovokos. Tai nėra lengva.


79

12. PĮ naudojimo aplinkos apibrėžimas

Svarbi PĮ kūrimo dalis yra aplinkos, kurioje ji turės dirbti, apibrėžimas. Tai

leidžia parengti PĮ projektą, atitinkantį įvairius aplinkos apribojimus, ir realizuoti

visas būtinas sąsajas.

Aplinka suprantama kaip derinys išorinių sąlygų, kuriose turės dirbti

įsigyjama PĮ. Nedidelei tekstų apdorojimo kompiuterinei programai kaip

paprastas aplinkos apibrėžimas galėtų būti turimų kompiuterių, operacinės

sistemos, spausdintuvų sąrašas. Didesnės ir sudėtingesnės PĮ aplinkos

apibrėžimas gali būti panašus į ilgą kompiuterių, spausdintuvų, tvarkyklių,

operacinės sistemos, tinklo aparatinės ir programinės įrangos, duomenų bazių

valdymo sistemos, kitokios PĮ ar taikomųjų programų, su kuriomis turės

komunikuoti įsigyjama PĮ, sąrašą. Jei reikalingos sąsajos ir su organizacijoje nuo

seniau turimomis sistemomis, pastarosios yra svarbi įsigyjamos PĮ aplinkos dalis.

Dažniausiai aplinka apibrėžiama rengiant įsigyjamos PĮ reikalavimus.

Reikalavimai aplinkai gali būti pateikiami dviem būdais: kaip funkciniai

reikalavimai arba kaip techniniai reikalavimai ar apribojimai. Būdo pasirinkimas

priklauso nuo įsigijimo srities ir įsigyjančiojoje organizacijoje jau turimų sistemų

ar nusistovėjusių standartų. Jei kuriant sistemą kartu su PĮ įsigyjami ir kiti

komponentai, tai apibrėžiamos tų komponentų funkcijos. Tačiau jei įsigyjama PĮ

turi veikti specifinėje platformoje (pvz., aparatinėje įrangoje, operacinėje

sistemoje, tinkle, duomenų bazių valdymo sistemoje), reikalavimai aplinkai

turėtų atspindėti tai, ir todėl jie tampa techniniais reikalavimais ar apribojimais.

Nieko keisto, jei abu reikalavimų aplinkai pristatymo būdai naudojami kartu.

Su aplinka susiję PĮ reikalavimai priklauso nuo įsigijimo tikslų ir srities.

Pvz., jei įsigyjama PĮ dirbs atskirame (standalone) kompiuteryje, tinklo ar ryšio

aplinkos apibrėžti nereikia. Jei PĮ dirbs nutolusiame (remote) kompiuteryje,

tikriausiai, reikės apibrėžti ir ryšius bei taikomųjų programų nuotolinio valdymo

aplinką. Jei planuojama įsigyti individualių poreikių PĮ, užsakovo pageidaujamos

programavimo kalbos, duomenų bazių valdymo sistemos, duomenų formatai, kiti

kūrimo standartai turėtų būti apibrėžiami kaip techniniai reikalavimai ar

apribojimai.

Tinkamai apibrėžti aplinką gali būti sunku. Tam gali prireikti aplinkos

komponentus žinančių ekspertų pagalbos. Neapibrėžus aplinkos, rizikuojama

įsigyti potencialiai puikią PĮ, tačiau kuri, pvz., negalės naudotis esamomis ryšio

linijomis, neturės sąsajų su kitomis programomis arba jos darbui reikės pirkti

papildomą atmintį. Rengiant aplinkos reikalavimus gali padėti užsakovo


80

organizacijoje esamas informacinių sistemų personalas; jis gali pateikti turimų

sistemų ir tinklo aprašą. Šie patirtį ir kompetenciją turintys žmonės gali būti

pajėgūs apibrėžti rekomenduojamas platformas, gali pateikti samprotavimus apie

savo galimybes palaikyti ir prižiūrėti įvairias platformas ir komponentus, nurodyti

naudotinas platformas ir instrumentus, suteikti informacijos apie tinkančias

informacines sistemas, PĮ standartus. Kitas potencialus pagalbos šaltinis aplinkos

reikalavimams parengti yra kitų organizacijų informacinių sistemų personalas.

Pernelyg detalūs aplinkos reikalavimai, deja, gali įnešti tam tikrą riziką. Jie

gali smarkiai sumažinti potencialių tiekėjų ratą ir žymiai padidinti PĮ kūrimo

laiką ir kainą. Pernelyg smulkiai apibrėžta aplinka gatavos PĮ pirkimo atveju

įneša tokią riziką:

- gali būti bereikalinga kliūtis priimti sprendimą dėl gatavos PĮ pirkimo;

- gali pareikalauti žymių išlaidų nupirktai gatavai PĮ pertvarkyti, kad ji

galėtų dirbti jūsų pasirinktoje operacinėje sistemoje arba su konkrečiais

išoriniais įrenginiais;

- pertvarkyta gatava PĮ gali pasidaryti mažiau patikima;

- galimybė ateityje netekti gatavos PĮ atnaujinimo ir naujų versijų tiekimo

paslaugų.

Aplinkos specifikacijoje turi būti tik būtini reikalavimai. Venkime

skaičiavimo platformos apibrėžimo, kol nėra būtinybės. Nepirkime kitų aplinkos

komponentų atskirai, neišsiaiškinę jų įtakos įsigyjamai PĮ. PĮ veikimui

apibrėžtoje aplinkoje užtikrinti, užsakovo pageidavimams patenkinti, geriausiems

tiekėjo rezultatams gauti už mažiausią kainą būtinas užsakovo ir tiekėjo

lankstumas.

Aplinka apsprendžia, kokius gatavos PĮ pakeitimus reikia atlikti, norint ją

pritaikyti užsakovo poreikiams. Vienoje vietoje veikianti PĮ kitoje gali neveikti,

kol abiejose vietose visa aplinka (išoriniai įrengimai, ryšiai, kompiuteriai,

operacinė sistema ar duomenų bazių valdymo sistema) nebus suvienodinta. PĮ,

veikiančiai su vienokiais išoriniais įrengimais, gali reikėti žymių pakeitimų,

norint pritaikyti ją darbui su kitokiu įrenginių rinkiniu. Užsakovui primygtinai

reikalaujant kažkokios ypatingos įrangos ar duomenų bazių valdymo sistemos,

galimos didesnės išlaidos ir didesnė PĮ sukūrimo rizika. Tai gali atsitikti per

neapsižiūrėjimą, jei aparatinė įranga perkama vadovaujantis mažiausios kainos

principu, neatkreipus dėmesio į jos poveikį PĮ.

12.1 lentelėje yra išvardinti pagrindiniai dalykai, kuriuos reikėtų nurodyti

apibrėžiant aplinką.


81

12.1 lentelė. Ką reikėtų nurodyti, apibrėžiant įsigyjamos PĮ darbo aplinką

Nr. Nurodomi dalykai

1. Sąsajos su užsakovo organizacijoje ir kitur esančiomis reikalingomis

sistemomis bei taikomosiomis programomis.

2. Esami kompiuterių tinklai ir ryšių priemonės, įskaitant protokolus, tinklo

tipą, svarbiausius komponentus, ryšio kanalų tipą ir greitaveiką.

3. Sąsajos su ateityje planuojamomis taikomosiomis programomis ar

sistemomis

4. Naudotojų kiekis ir naudotojų sąsajos (pvz., grafinė sąsaja ar kitokia)

5. Vieta ir/arba fizinė aplinka: įstaiga, kambarys; apšviestumas, erdvės

apribojimai, turintys įtakos darbui su pele ar klaviatūra; nenutrūkstamas

energijos tiekimas, kt.

6. Saugos priemonės nustatytoms taisyklėms ir procedūroms įgyvendinti:

fizinės saugos sistemos (užrakinami kambariai), PĮ apsauga (slaptažodžių

naudojimas), kompiuterinės saugos sistemos (ugniasienės).

7. Veikimo būdas: kiek duomenų ir kaip greitai juos reikia apdoroti, darbo

tikslumas.

8. Standartai.


82

13. Autorinių ir nuosavybės teisių klausimo sprendimas

PĮ licencijų ir nuosavybės teisių klausimai kyla gana dažnai. Vienodai dažni

jie yra viešajame ir privačiajame sektoriuose. Nors šių sektorių atstovai mato

skirtingus minėtų klausimų sprendimo kelius, tačiau visų jų nuomonės sutampa,

kad tai yra labai ginčytina sritis, vedanti prie užsakovų ir tiekėjų konfliktų.

Toliau nagrinėdami šiuos klausimus naudosime kiek platesnę sąvoką

“intelektinės nuosavybės teisės”, apimančią ne tik licencijas, nuosavybės teises,

bet ir autorinių teisių klausimus.

Ginčų dėl teisių priežastis

Tipinis ginčų scenarijus yra toks. Kai pasirašomas sandoris, abi pusės mano,

kad jos susitarė intelektinės nuosavybės teisių klausimu. Taip, sandorių

dokumentuose randame žodžius nuosavybės teisės, licencijos, autorinės teisės,

teisė parduoti ar nuomoti PĮ. Tačiau blogiausia, kad abiem pusėms nežinant, jos

juos supranta nevienodai.

Netgi “programinės įrangos (PĮ)” sąvoka sandorių kalboje dažnai sukelia

ginčus tarp užsakovų ir tiekėjų. Užsakovai ją supranta kaip apimančią ir pradinį

PĮ tekstą (source code), o tiekėjai - tik kaip programos vykdomąjį (executable)

arba objektinį (object) modulį.

Tokie supratimo skirtumai neišaiškėja ilgai, kol nepriartėjama prie sandorio

pabaigos. Tada užsakovas ima reikšti pretenzijas į teises, nes jis jas suprato taip:

“aš galiu prižiūrėti PĮ, parduoti ar daryti kopijas, ...”. Į tai tiekėjas atsako: “jūs

neturite tesės to daryti, jūs galite tik ...”. Taip atsiranda kaltinimai, jog

nesilaikoma sandorio ar susitarimo. Prasideda ilgai trunkančios derybos arba net

teisinis bylinėjimasis.

Nurodykime intelektinės nuosavybės teisių į PĮ reikalingumą užsakovui

Prieš pradedant derybas intelektinės nuosavybės teisių klausimais, reikėtų

apsvarstyti, kodėl užsakovui jų reikia. Taip galima išvengti bereikalingų ginčų.

Užsakovo supratimas apie būsimą PĮ priežiūrą dalinai apsprendžia poreikį

įgyti intelektinės nuosavybės teises. Jeigu manoma, kad įsigytą PĮ galėtų

prižiūrėti užsakovo organizacijoje esantis personalas, reikėtų pasitikrinti, ar verta

imtis tokios atsakomybės. Reikėtų kelti klausimą: jei aš turėsiu pradinius PĮ

tekstus (source code), ar mano organizacijoje yra žmonių, sugebančių naudotis

jais. Gal geriau samdyti prižiūrėtojus, netgi tuos pačius PĮ kūrėjus? Bereikalingų

ginčų dėl intelektinės nuosavybės teisių galima išvengti, išsiaiškinus, kad


83

nepajėgsime naudotis PĮ pradiniu tekstu, ir nereikalaujant intelektinės

nuosavybės teisių.

Užsakovas, imdamasis atsakomybės už įsigytos PĮ priežiūrą, turi:

- turėti kvalifikuotą personalą. Pastebėkime, mokėjimo programuoti

nepakanka, kad galima būtų imtis daug dėmesio reikalaujančios PĮ

tvarkymo. Toks personalas tinka tik trumpalaikiams darbams. Jei įsigytos

PĮ priežiūrai randami tinkami žmonės, tai reikia žiūrėti, ar organizacijos

atlyginimų struktūra leidžia mokėti tiek, kad pritrauktume juos. Jei

mokysim esantį personalą, žiūrėkime, ar tuomet pajėgsime išlaikyti jį;

- supažindinti savo personalą su įsigytos PĮ vidum, palaikymo aplinka ir

priežiūros instrumentais. Tam reikalingas glaudus priežiūros personalo ir

kūrėjo bendradarbiavimas nuo pat PĮ įsigijimo projekto pradžios;

- perimti dokumentų ir PĮ konfigūracijos tvarkymą (žiūr. 18 skyrių „PĮ

konfigūracijos valdymas“), kas normaliai yra pagrindinė tiekėjo

atsakomybė;

- sukurti PĮ palaikymo aplinką;

- turėti prieigą prie:

- pradinių PĮ tekstų kompiliavimui parengtuose kompiuteriniuose

failuose;

- duomenų bazių dokumentų, duomenų struktūros, sąsajų protokolų;

- PĮ kūrimo instrumentų.

Pastebėkime, kad prieiga prie šių priemonių turi savo kainą. Pvz., visos

komercinės duomenų bazės valdymo sistemos (DBVS) palaikymas

kainuoja žymiai daugiau, negu jos vykdomojo (run-time) modulio

licencija. Nėra prasmės mokėti daugiau už papildomas teises, jei jūs

nemokate naudotis tomis priemonėmis.

Viešojo sektoriaus užsakovai kartais primygtinai reikalauja visų teisių į PĮ,

nenorėdami būti pririšti prie konkretaus tiekėjo. Tačiau praktiškai tik PĮ sukūręs

tiekėjas yra pajėgus tvarkyti jos kodą. Visų teisių į PĮ gavimas gali būti bevertis.

Kartais gali kilti noras įgyti teises tik į tam tikras įsigyjamos PĮ dalis. Tačiau

kaip nubrėžti skiriamąją ribą tarp tų dalių. Pvz., galime nuspręsti, kad reikia visų

nuosavybės teisių į visą projekte sukurtą PĮ, bet ne į tiekėjo paimtą iš kitur ir

papildomai panaudotą projekte. Tokią PĮ turėtų saugoti tiekėjas. Bet sukurta PĮ

gali neveikti be tiekėjui priklausančios PĮ. Turėkime galvoje, kad perkant gatavą

PĮ, dažniausiai parduodamas tik jos objektinis kodas.

Kartais viešojo sektoriaus organizacijos stengiasi išlaikyti teises tam, kad

vėliau galėtų platinti įsigytą PĮ kitoms savojo sektoriaus organizacijoms už

nominalią kainą. Kaip grąžą, jos gauna visus PĮ patobulinimus, padarytus tose


84

kitose organizacijose. Toks požiūris buvo teisingas, kol buvo dirbama su

atskiromis (standalone) programomis, skirtomis ofiso aplinkai. Bet ar tai protinga

sudėtingų sistemų atveju? Kaip tokiais atvejais spręsti techninės priežiūros ir

palaikymo klausimus? Jei naudosime kitos organizacijos įsigytą PĮ, neturėsime

dokumentacijos, palaikančių paketų. Sudėtingas sistemas gali reikėti adaptuoti

prie naujos aplinkos, kuri dviejose organizacijose gali būti skirtinga.

Intelektinės nuosavybės teisių klausimus spręskime atvirai

Kad išvengtume su intelektinės nuosavybės teisėmis susijusių problemų,

renkime sandorius taip, kad būtų aiškiai išdėstytos užsakovo ir tiekėjo teisės į PĮ.

13.1 lentelėje yra išvardintos teisės, kurios turėtų būti aptartos sandorio

dokumente. Dar iki sandorio pasirašymo užsakovas ir tiekėjas drauge eilutė po

eilutės turėtų peržiūrėti sandorį, kad būtų išvengta netikėtumų ateityje. Jame turi

būti aiškiai atskirtos kiekvienos pusės teisės į PĮ pradinį tekstą (source code),

objektinį modulį, dokumentaciją. Pusės gali turėti skirtingas teises, tačiau jos gali

būti ir vienodos.

Čia svarstomi klausimai tik patvirtina nuostatą (žiūr. 5 skyrių „PĮ įsigijimo

nuostatos“), kad būtinas užsakovo ir tiekėjo bendradarbiavimas PĮ įsigijimo

projekto metu. Teisių klausimas tik pabrėžia, kad atviros diskusijos būtinos dar

iki sandorio pasirašymo.

Pasitelkime teisininkus

Intelektinės nuosavybės teisė yra teisininkų veiklos sritis. PĮ intelektinės

nuosavybės teisė yra kažkiek siauresnė, santykinai nauja ir besiplėtojanti sritis.

Rasti šią sritį išmanančių teisininkų yra sunku. Nežiūrint to, formuodami PĮ

įsigijimo projekto darbo grupę, reikalaukime, kad į ją būtų įtraukti patirtį šioje

srityje turintys teisininkai.

13.1 lentelė. Intelektinės nuosavybės teisių klausimai sandoriuose

Nr. Teisės klausimai

Bendrosios teisės

1. Kieno nuosavybė bus PĮ? Kokias teises tai apima?

2. Kam priklausys PĮ autorinės teisės? Kokias teises tai apima?

3. Ar autorinių teisių nuoroda kaip komentaras turės būti įtraukiama į PĮ pradinį tekstą (source code)? Kas bus įrašytas į PĮ registrą kaip autorinių teisių turėtojas?


85

Užsakovo teisės

4. Ar užsakovas galės daryti papildomas darbinės PĮ kopijas vidiniam naudojimui?

5. Ar užsakovas galės platinti darbinės PĮ kopijas kitoms giminingoms organizacijoms ar departamentams?

6. Ar užsakovas galės platinti darbinės PĮ kopijas ir išduoti licencijas kitiems? Ar tokios licencijos suteiks teisę kitiems daryti PĮ pakeitimus ir patobulinimus, ar tik suteiks teisę naudotis PĮ?

7. Ar užsakovas galės dalinti darbinės PĮ kopijas už dyką arba už tam tikrą mokestį?

8. Ar užsakovas galės daryti darbinės PĮ pakeitimus arba kitokius su ja susijusius darbus?

9. Ar užsakovas galės atskleisti darbinės PĮ pradinį tekstą kitiems tiekėjams arba leisti jiems daryti PĮ pakeitimus?

10. Kokios darbinės PĮ dalys (taikoma 4-9 šios lentelės punktams) galės būti kopijuojamos ar platinamos: pradinis tekstas, objektinis kodas ir/ar dokumentacija? Kiek kopijų gali būti daroma?

11. Ar užsakovas turės teisę į tiekėjo vėliau padarytus PĮ atnaujinimus?

12. Ar PĮ sudėtyje bus dalys, kurioms naudoti reikės atskirai pirkti licencijas? Tai gali būti operacinė sistema (pvz., Windows, UNIX), komercinė duomenų bazių valdymo sistema, kt. Gali būti daromas skirtingas šių sistemų kopijų kiekis, norint leisti, platinti ar daryti kažką kitą su likusia PĮ dalimi.

13. Ar užsakovas turės prieigą prie PĮ pradinių tekstų? Jei taip, tai ar pradiniai tekstai bus kompiliavimui tinkančiuose failuose, ar tik atspausdinti popieriuje.

14. Ar užsakovas turės prieigą prie palaikymo instrumentų ir kūrimo aplinkos, kuri buvo naudota kompiliuojant PĮ, tvarkant PĮ konfigūraciją, testuojant ją, kt.

15. Ar užsakovas turės teisę į visą mokymo medžiagą?

16. Ar užsakovas turės teisę į vykdomąją aplinką, reikalingą PĮ leisti, ar jis privalės ją atskirai įsigyti iš kito tiekėjo?

17. Ar užsakovas turės prieigą prie duomenų bazių formatų ir sąsajų protokolų dokumentacijos?

18. Keliuose kompiuteriuose galės būti saugomos PĮ kopijos? Keliuose kompiuteriuose PĮ galės būti leidžiama (run)? Šie kiekiai gali skirtis, nes, pvz., atstatomosios (backup) kopijos gali būti tik kai kuriuose.


86

19. Kiek kompiuterių vienu metu galės dirbti naudojant PĮ ar kreiptis į ją? Tinkle visi kompiuteriai gali turėti galimybę naudoti PĮ arba kreiptis į duomenų bazę, tačiau licencija gali riboti vienu metu dirbančiųjų kiekį.

20. Kiek naudotojų gaus licenciją naudoti PĮ? Kiek galės naudoti PĮ vienu metu?

21. Ar bus leidžiama naudoti PĮ tinkle? Pastebėkime, kad yra dvi galimybės. PĮ gali būti leidžiama nuotoliniu būdu, t.y. kitame kompiuteryje, kur ji laikoma pastoviai, arba PĮ kopija laikinai gali būti įkelta į jūsų vietinį kompiuterį ir leidžiama jame.

Tiekėjo teisės

22. Ar tiekėjas galės platinti PĮ kitiems klientams? Jei taip, ar jie turės mokėti už ją?

23. Ar tiekėjas galės pakartotinai naudoti PĮ dalis kituose sandoriuose?

24. Ar tiekėjas galės patentuoti ar gauti PĮ autorines teises arba patentuoti PĮ dalis? Jei taip, ar užsakovas turės mokėti jam autorinį honorarą (procentus)?

25. Ar tiekėjas turės teises į visus užsakovo padarytus PĮ patobulinimus?

Pastangos tiksliai apibrėžti abiejų pusių teises, pasiekti susitarimams, be

abejo, reikalauja laiko, verčia atidėti sandorio sudarymą. Tačiau tai yra kur kas

geriau, nei sistemos įsigijimas, turint skirtingus įsitikinimus, ir bylinėjimasis

teismuose vėliau. Teisme viena pusė tikrai, o greičiausiai abi, gaus mažiau, nei

buvo susitarusios. Nuosavybės teisės ar licencijas skirtingi žmonės dažnai

supranta nevienodai. Todėl geriausia išsiaiškinti požiūrių skirtumus iš karto, kad

vėliau nereikėtų bylinėtis teismuose.


87

14. PĮ įsigijimo projekto darbų grafiko sudarymas

Kai užsakovas jau turi parengęs įsigijimo projekto planą, PĮ reikalavimų

rinkinį, priėmęs sprendimą kurti naują ar pirkti gatavą PĮ, parinkęs sandorio

tipą, jam belieka parengti visų darbų vykdymo grafiką.

Ką reikėtų nurodyti darbų grafike?

14.1 lentelėje yra išvardintos tik su PĮ įsigijimu susijusios projekto veiklos

ir kontrolės taškai, kurie turėtų būti darbų grafike. Visas darbų grafikas apima ir

kitokias veiklas (ne tik PĮ kūrimo ar pirkimo), kaip vietos, kur bus naudojama PĮ,

parinkimas, aparatinės įrangos instaliavimas, kt. Grafike nurodomi užsakovo

nustatyti pagrindiniai kontrolės taškai. Tai datos, kuomet pateikiama kokia nors

įranga, pastabos dėl parengtų dokumentų, darbų ataskaitos.

14.1 lentelė. PĮ įsigijimo veiklos ir kontrolės taškai projekto darbų grafike

Nr. Veiklos Kontrolės taškai

Sandorio sudarymas

1. Intelektinės nuosavybės teisės klausimų peržiūra.

2. Sandorio pasirašymas kontrolės taškas

3. Datos, iki kada užsakovas pateiks tiekėjui sandoriui

vykdyti reikalingus dalykus (įrangą, patalpas,

paslaugas)

kontrolės taškai

PĮ reikalavimai

4. Reikalavimų peržiūra.

5. Reikalavimų pasirašymas kontrolės taškas

6. Greitas prototipų rengimas

Darbų apimčių vertinimas

7. Tiekėjo atliekamas nepriklausomas darbų apimčių ir grafiko įvertinimas

8. Nesutarimų aiškinimasis ir šalinimas

Valdymo klausimai

9. Rizikos veiksnių peržiūra

10. Projekto peržiūra

11. Tikrinimai


88

12. Dokumentų peržiūra

13. Dokumentų tvirtinimas kontrolės taškas

Testavimas PĮ priėmimo metu

14. Detalių priėmimo testų planavimas

15. Priėmimo testų vykdymas

16. Priėmimo testavimo rezultatų analizė

17. Sistemos priėmimas kontrolės taškas

Mokymas

18. Mokymo rengimas ir planavimas

19. Mokymo vykdymas

Palaikymas

20. Palaikymo infrastruktūros kūrimas

21. Perėjimas prie eksploatacijos ir priežiūros kontrolės taškas

Kontrolės taškų nustatymas

Projektų darbų grafikuose nurodomos veiklos ir kontrolės taškai. PĮ

įsigijimo projektuose nustatant kontrolės taškus labai svarbu, kad:

- kontrolės taškų laikas būtų gerai apgalvotas, o atliekamų darbų prasme

jie būtų vienareikšmiai. Neturėtų likti argumentų pasiteisinimams, kad

etape buvo neįmanoma kažko padaryti;

- kontrolės taškuose darbai turi būti vertinami tik taip: atlikti arba neatlikti.

Neturėtų būti nuolaidų, jei etape atlikta, pvz., 90 proc. numatytų darbų.

Tokiais atvejais geriau etapą dalinti į mažesnius etapus, kiekvieno jų

įvykdymą vertinant „taip“ arba „ne“.

Laikantis šitokio požiūrio, visuose kontrolės taškuose įvardyti darbai turi būti

atlikti 100 proc.

Tipinės darbų grafiko sudarymo klaidos

Dvi dažniausiai pasitaikančios PĮ įsigijimo projektų darbų grafiko sudarymo

klaidos yra šios:

- nesiremiama formaliais dokumentais. Pvz., darbų grafikas rengiamas

neatsižvelgiant į PĮ reikalavimus; projekto užbaigimo data nustatoma

savavališkai, įtakojant politiniams ar kitokiems veiksniams;


89

- sudaromas pernelyg glaustas grafikas. Galutinė darbų atlikimo data dažnai

būna perdaug ankstyva. Kai stokojama laiko, apeinamos arba sutrumpinamos kai

kurios būtinos projektų veiklos.

Panagrinėkime, kaip galima būtų išvengti minėtų klaidų.

Remkimės PĮ reikalavimais rengdami darbų grafiką

Formuokime darbų grafiką remdamiesi PĮ reikalavimais. Reikalaujamas

funkcionalumas yra pagrindas, sprendžiant, kiek laiko reikėtų skirti projektui.

Kaip laikomasi reikalavimų, darbų grafiko, biudžeto, stebėkime visą projekto

laiką. Jei prireikia tikslinti reikalavimus ir papildyti PĮ naujomis funkcijomis,

nepamirškime atitinkamai pakoreguoti ir darbų grafiką.

Kai kuriais atvejais projekto galutinės datos paslinkti negalima. Pvz.,

numatytos olimpinės žaidynės negali būti nukeltos dėl to, kad žaidynes

rengiantis miestas nespėja joms pasirengti. Tokiais atvejais reikalavimai ir darbų

grafikas turi būti peržiūrimi laikas nuo laiko (iteratyviai). Jei trūksta laiko visiems

užplanuotiems darbams atlikti, sumažinkime reikalavimus tiek, kad jiems

įgyvendinti užtektų turimo laiko.

Kitais atvejais darbų grafikas ir reikalavimų įgyvendinimo galimybės

priklauso nuo biudžeto svyravimų. Geriausia, kai pageidaujamos PĮ funkcijos

nėra absoliučiai būtinos. Kaip ir kiekvienas pirkėjas, taip ir PĮ užsakovas nori

daugiau, nei gali įsigyti. Todėl PĮ turi būti apkarpyta tiek, kad atitiktų biudžeto

galimybes. Kad ir kokios būtų projekto aplinkybės, darbų grafikas ir reikalavimai

privalo atitikti vienas kitą.

Skirkime projektui pakankamai laiko

„PĮ įsigijimo atveju darbų grafiko forsavimas pasitelkiant daugiau

darbuotojų, skiriant daugiau lėšų, dirbant viršvalandžius, atrodo, neduoda

teigiamų rezultatų“.

Projektų tyrimo rezultatai rodo, kad realus darbų grafikas yra vienas iš

dviejų pagrindinių PĮ įsigijimo projekto sėkmės veiksnių (kitas veiksnys – tai

reikalavimų pastovumas).

Tačiau praktikoje daugumos projektų pradžioje sudaryti darbų grafikai būna

nerealūs. Jie būna optimistiški. Klaidingai tikimasi, kad viskas vyks gerai,

manoma, kad taip turi būti. Apskritai, kai prašoma žmonių įvertinti darbų grafiką,

geriausi vertinimai atitinka optimistinį variantą, o blogiausi yra artimi tokiam,

koks gaunasi realiai vykdant projektą.

Kai kurie vadybininkai paklaidoms dėl žmogiškųjų savybių ir optimizmo

kompensuoti įvertintą darbų grafiko trukmę daugina iš pasirinkto koeficiento.

Dažnas siūlo šio koeficiento dydį imti lygų 2.


90

Vienas iš efektyviausių būdų sumažinti PĮ įsigijimo projekto kainą yra darbų

grafiko ištiesinimas. Kartais klaidingai samprotaujama, kad darbų trukmės

pailginimas reikalauja didesnių pastangų ir išlaidų, nes žmonės turės dirbti

ilgiau. Tačiau yra priešingai: kai darbų grafikas sutrumpinamas, žymiai padidėja

išlaidos. Tai atsitinka todėl, kad, sutrumpinus darbų grafiką, projektui vykdyti

reikia daugiau žmonių, atsiranda apsirūpinimo žmonėmis ir darbų paskirstymo

jiems problema. Padidėjus bendram darbuotojų kiekiui, padidėja ir išlaidos. Be to,

kitokiuose projektuose (pvz., statybos) sukaupta patirtis netinka PĮ atveju.

Padauginus žmonių kiekį iš projekto trukmės, gaunamas žmogaus-mėnesių

kiekis. Kitokio tipo projektuose personalas ir darbai gali būti kaitaliojami

vietomis, jei tik žmogaus-mėnuo atitinka atliekamo darbo kiekį. PĮ kūrimo atveju

taip nėra. Situaciją apibendrina ši PĮ specialistams žinoma citata: „Žmogaus-

mėnuo yra klaidinanti ir pavojinga sąvoka, nes žmonės ir mėnesiai nėra

lygiaverčiai (sukeičiami) nariai“. Faktiškai priklausomybė tarp darbų grafiko (t.y.

mėnesių) ir kūrimo pastangų (t.y. žmonių) yra toli gražu netiesinė. Mažas darbų

grafiko pailginimas gali žymiai sumažinti projekto kainą.

Patyrę specialistai sako, kad PĮ įsigijimo projektą vykdyti būna lengviau,

reikia mažiau lėšų ir padaroma mažiau klaidų, kai šiek tiek pailginama projekto

trukmė.

Yra du šio iš dalies keisto rezultato aiškinimai. Pirma, kuo daugiau žmonių

įtraukiama į projektą, tuo daugiau darbuotojų, su kuriais projekto vadovas turės

sąveikauti. Sulig kiekvienu naujai pasamdytu darbuotoju ankstesnių darbuotojų

darbo našumas nežymiai krenta. Antra, jei darbo grafikas yra suspaustas,

nuoseklią veiksmų seką reikia keisti lygiagrečia (sulygiagretinti procesus).

Pastaroji seka gali būti ištiesinta (pakeista į nuoseklią) tik didesnio darbo našumo

dėka.

Jei yra neribotas biudžetas arba yra griežti projekto pabaigos terminai ir

nevaržomos išlaidos, galime žymiai suspausti darbų grafiką. Tačiau yra apatinė

riba: projektas tiesiog negali būti padarytas per trumpesnį laiką. Galime mokėti

aukštą kainą, kad priartėtume prie tos ribos, tačiau nėra galimybių peržengti ją.

Deja, praktikoje dar dažnai sudaromi pernelyg trumpi darbų grafikai, t.y.

patenkantys į „neįmanomą zoną“ (žiūr. 14.1 pav.).

Rekomenduojama visų pirma sudaryti realų darbų grafiką, o po to jį kažkiek

patrumpinti.

Darbų grafiko trukmės nustatymas

Dažniausiai tai pradedama nuo PĮ dydžio įvertinimo. Šis įvertinimas gali

būti išreikštas įvairiai: programos pradinio teksto eilučių kiekių ar funkcijų


91

14.1 pav. Darbų grafiko suspaudimo poveikis projekto kainai

kiekiu. Po to, remiantis šiuo įvertinimu, nustatomas laikas ir pastangos

(darbuotojų kiekis), kurių reikės PĮ sukurti.

Tačiau projekto pradžioje gali būti neįmanoma įvardinti galutinę projekto

apimtį; galimos labai plačios įvertinimo ribos. Tai ypač būdinga turintiems mažą

PĮ įsigijimo projektų patirtį, kurie nieko nežino apie galutinį kuriamos PĮ dydį.

Čia kaip tik išryškėja gatavos PĮ įsigijimo privalumas, nes nėra reikalo vertinti PĮ

apimties.

Dažniausiai, PĮ skaidoma į kiek įmanoma didesnį komponentų kiekį,

įvertinamas kiekvieno jų dydis, o susumavus juos gaunamas visos PĮ dydis. Juk

žymiai lengviau yra įvertinti, pvz., konkretaus įvykio apdorojimo komponento

dydį, nei visos įvykių apdorojimo funkcijos dydį.

Keletas praktinių rekomendacijų PĮ dydžiui įvertinti:

- PĮ dydžiui įvertinti naudokime savo darbo grupės PĮ ekspertus;

- gaukime kiek įmanoma daugiau PĮ dydžio įvertinimų iš skirtingų

žmonių; yra matematiniai metodai, įgalinantys gauti vidutinę reikšmę ir

paklaidas (standard deviations). Taip pat yra matematiniai metodai,

įgalinantys iš pesimistinių, optimistinių ir dažniausiai nurodomų

vertinimų gauti tikėtiną PĮ dydį ir jo paklaidą;

- jei tik įmanoma, gaukime nepriklausomų asmenų įvertinimus. Jų

įvertinimai yra geresni nei asmenų, kurie yra susiję su projektu, pvz.,

projekto vadovas;

- peržiūrėjus PĮ reikalavimus, paprašykime tiekėjo parengti PĮ dydžio

įvertinimą. Neabejotinai bus žymus skirtumas tarp tiekėjo ir jūsų, kaip

PĮ įsigijimo

projekto bendra kaina

(Lt)

Neįmanoma

zona

Laikas


92

užsakovo, įvertinimų. Palyginkime juos ir išsiaiškinkime visus

skirtumus;

- PĮ dydį vertinkime skaidydami ją į kiek įmanoma mažesnes dalis ir

vertindami kiekvienos dalies dydį;

- niekada ekspromtu nevertinkime darbų grafiko ar PĮ dydžio.

Kai PĮ dydis yra įvertintas, įvairūs našumo veiksniai gali būti taikomi, kad

nustatytume kiek žmonių ir kiek laiko reikės projektui vykdyti. Yra programinės

priemonės, galinčios padėti rasti kompromisą tarp kainos ir darbų grafiko. Tačiau

našumo veiksnius, kuriuos reikia pateikti toms priemonėms, nėra lengva gauti.

Paprastai jie būna paremti stebėjimais, patirtimi.

Įvertinimų ribos (svyravimai, paklaidos)

Natūralus noras yra turėti patikimą bet kokio projekto dydžio (apimties)

įvertinimą. Tačiau PĮ projekto pradžioje padarytas įvertinimas toli gražu

neatitinka tikrovės. Gauti įvertinimai visada turi paklaidą. Pradėjus vykdyti

projektą, gaunama daugiau informacijos. Todėl laikui bėgant įvertinimai gali būti

tikslinami, mažinamas įvertinimo reikšmių galimas intervalas (žiūr. 14.2 pav.).

Pvz., tuoj po PĮ reikalavimų parengimo jos dydžio įvertinimas yra įmanomas tik

darant didelę paklaidą. Kadangi tiekėjo pareiga yra rūpintis PĮ kūrimo detalėmis,

jis gali duoti tikslesnį įvertinimą.

14.2 pav. Projekto dydžio įvertinimo ribų kitimas laike

Dilema, kurią tenka spęsti projekto vadovui, yra ta, kad kainos ir darbų

grafiko paklaidos (ribos) gali būti nepriimtinos projektą tvirtinančiai organizacijos

Projekto

dydžio

įvertinimo

ribos

Laikas

Projekto

samprata

Reikala-

vimai Projekta-

vimas

Programa-

vimas

Testa-

vimas


93

vadovybei. Pvz., prašymas „leiskite kurti PĮ, kas gali trukti nuo 8 mėnesių iki 2

metų ir gali kainuoti nuo 300 tūkst. Lt iki 1,5 mln. Lt“ vargu ar bus patenkintas.

Kaip projekto vadovas turėtų spręsti tikslaus projekto dydžio įvertinimo

dilemą (tikslios reikšmės reikalauja sprendimus priimanti organizacijos

vadovybė), kai įmanoma nurodyti tik įvertinimo reikšmės intervalą, gero

atsakymo nėra. Tačiau yra keletas pasiūlymų, kurie gali praversti:

- pradėkime projektą nurodydami bendrąjį darbų grafiką ir biudžetą.

Tačiau su tiekėju sudarykime tokį sandorį, kad jis būtų padalintas į

fazes, kuriose bus kuriamos tik nedidelės PĮ dalys. Tikriausiai, pirmoji

fazė bus detalus kažkokio posistemio projektavimas. Šios fazės

rezultatas bus darbų grafiko ir biudžeto šio posistemio PĮ kurti

(programuoti, testuoti, kt.) įvertinimas. Kai tik šios dalies projektas

baigiamas, viso projekto dydžio įvertinimas patikslinamas ir jis turėtų

įgyti siauresnes ribas lyginant su tomis, kurios buvo gautos anksčiau

remiantis PĮ reikalavimais;

- atidžiai stebėkime viso projekto eigą ir išnaudokime tai kaip grįžtamąjį

ryšį būsimiems įvertinimams. Kitų fazių įvertinimai gali būti daugiau

tikroviški, nes jie gaunami remiantis ankstesnėse fazėse įgytu patyrimu.

Netgi jei sandoris neskaidomas į fazes, tikroji įvykių eiga gali būti

suplanuota kažkiek vėliau ir palyginta su numatytąja projekto

pradžioje. Tokiu būdu galima atnaujinti darbų grafike anksčiau

numatytą projekto užbaigimo datą ir gauti daugiau tikrovišką projekto

dydžio įvertinimą. Tai yra kur kas geriau, nei kažkada paslinkti projektą

laike arba nepagrįstai tikėtis kompensuoti (atidirbti) prarastą laiką.


94

15. Įsigyjamos PĮ testavimas

PĮ testavimas įsigijimo projekto priėmimo etape yra formalus patikrinimas,

ar PĮ atitinka nustatytus reikalavimus. Testavimo planavimas, kaip ir darbuotojų

mokymo, PĮ eksploatavimo ir priežiūros planavimas, yra perėjimo nuo PĮ kūrimo

proceso prie jos naudojimo pradžia. Kadangi sukurta PĮ negali 100 proc. išlaikyti

priėmimo testavimo, kyla klausimas, kada PĮ jau yra gera, kad galima būtų

pradėti naudoti ją. Daugumoje įsigijimų PĮ priėmimo metu atsiranda tam tikra

sumaištis, kai, pastebėjus kokį nors trūkumą, tiekėjas kratosi atsakomybės ir

stengiasi perduoti (permesti) ją užsakovui arba vienas tiekėjas atsakomybę

permeta kitam tiekėjui. Kai PĮ išlaiko testavimą (patikrinimą), tiekėjas įgyja teisę

gauti atlyginimą iš užsakovo.

Sėkminga testavimo baigtis dar nereiškia, kad sukurtoje PĮ visiškai nėra

klaidų. Bet kuri PĮ turi įvairaus sunkumo užslėptas klaidas („bugs“), kurios laikas

nuo laiko išlenda. Testavimo metu klaidų galima ir nerasti, nes jos pasireiškia tik

nelauktų duomenų arba neįprastų įvykių sekų atvejais. Kartais išlendančios

klaidos yra natūrali PĮ reakcija į retai sutinkamas situacijas, kurios nebuvo

įvardintos reikalavimuose. Nežiūrint klaidų priežasties, tiekėjas negali visų jų

pašalinti. Užsakovo požiūris į klaidas yra PĮ priežiūros ateityje strategijos dalis.

Rekomenduojama laikytis formalaus, gerai dokumentuojamo PĮ testavimo

jos priėmimo metu požiūrio. Įsigijimo procese tokiu požiūriu reikėtų pradėti

vadovautis kaip galima anksčiau. Jau rengiant įsigijimo planą, dar iki sandorio su

tiekėju sudarymo ar net iki prašymo teikti pasiūlymus (RFP) paskelbimo, turi

rūpėti PĮ testavimo klausimai. Netgi jeigu pasirinktas sandorio tipas leidžia

priėmimo testą rengti drauge su tiekėju, tai turėtų būti suplanuota pradinėje

įsigijimo projekto stadijoje.

Šiame skyriuje nagrinėsime tik formalų PĮ testavimą jos priėmimo metu. Tai

nesusiję su kitais PĮ testavimais, būtinais jos kūrimo eigoje. Pvz., gali būti atskirų

PĮ dalių įvairaus lygio testai darbo eigoje. Didžiąja dalimi atsakomybė už šiuos

neformalius testus tenka tiekėjui ir tiesiogiai neliečia užsakovo.

Testavimo pagrindas - PĮ reikalavimai

Įsigijimo projektuose PĮ testavimas jos priėmimo metu atliekamas

vadovaujantis PĮ reikalavimais. Reikalavimai naudojami:

- apdrausti užsakovą. Kiekvieno reikalavimo įgyvendinimas detaliai

tikrinamas vienu arba daugiau testų. Taip gaunami adekvatūs testavimo

rezultatai;


95

- apdrausti tiekėją. Tam peržiūrimas kiekvienas testas, kaip jis tinka

patikrinti vieną ar kelis reikalavimus. Tokiu būdu įsitikinama, kad

testavimo metu nebus įtraukti papildomi reikalavimai ir iš PĮ nebus

reikalaujama daugiau negu buvo nustatyta.

Viso to išvada yra tokia, kad testai turi būti susiję su PĮ reikalavimais ir turi

būti tikrinami tik nustatyti reikalavimai.

Du požiūriai į PĮ testavimą jos priėmimo metu

Pirmasis požiūris į testavimą siejamas su darbo aplinka, kurioje ir

stengiamasi tikrinti PĮ veikimą. Priėmimo kriterijus yra PĮ veikimas pagal

reikalavimus nustatytą laiko periodą. Antrasis požiūris yra daugiau formalus,

kuriame remiamasi testavimo dokumentais. Vykdomi kiek įmanoma platesni ir

pagrįsti PĮ testai nuo pradžios iki galo. Tokie testai rengiami specialiai PĮ

priėmimui ir leidžiami pagal patvirtintą planą. Šiuo atveju priėmimo kriterijus yra

sėkmingas testų išlaikymas.

Praktikoje PĮ tikrinti naudojamas ir aukščiau minėtų dviejų požiūrių mišinys.

Pvz., po sėkmingos bandomosios PĮ eksploatacijos kažkurį laiką, tarkime, mėnesį,

PĮ gali būti priimama tik praleidus dar ir formalius testus. Taip pat gali būti

naudinga prieš priėmimą išbandyti PĮ, ribotai išskleidus ją (mažesnio kiekio

darbo vietose), ir tik po to siūlyti tiekėjui diegti ją visa apimtimi. Taip PĮ būtų

priimama pirma atlikus formalius testus, o po to atlikus visos PĮ bandomąją

eksploataciją.

Priėmimo testo įtraukimas į projektą

Kokio požiūrio į testavimą besilaikytume, sprendimas dėl jo turi būti

priimamas PĮ įsigijimo projekto pradžioje, ir testavimo klausimai turi būti

įtraukiami į projekto planą, darbų grafiką, prašymą teikti pasiūlymus (RFP) ir

sandorį. Išnagrinėkime kiekvieną iš jų.

Projekto plane (žiūr. 8 skyrių „Įsigijimo projekto planavimas“) yra skyrius,

kuriame trumpai nurodoma bendroji PĮ priėmimo strategija, pasirinktas požiūris į

testavimą. Taip pat gali būti nurodomi ir bendrieji (high-level) testavimo

klausimai:

- kur bus atliekami priėmimo testai? (tiekėjo patalpose ar pas užsakovą, kur

PĮ bus naudojama);

- kas atliks testavimą? (tiekėjo žmonės ar PĮ naudotojai);

- kokie yra bendrieji priėmimo kriterijų reikalavimai, kuriuos turi atitikti PĮ?

Darbų grafike nurodomas laiko periodas, kada bus atliekami priėmimo

testai. Jis apima ir laiką, kurio reikia testavimo rezultatams išanalizuoti.

Pastarasis laikas turi būti pakankamas, kad užsakovas spėtų peržiūrėti testavimo


96

rezultatus ir galėtų priimti sprendimą, ar PĮ atitinka visus priėmimo kriterijus.

Taip pat turėtų būti skiriama laiko pataisymams atlikti ir daliai ar visiems testams

pakartoti, jei pastebimi PĮ trūkumai pirmojo tikrinimo metu.

Darbų grafike turi būti ir testavimo planavimo etapas, nurodant jame kartu

su tiekėju parengto PĮ priėmimo testavimo plano pateikimo laiką. Šiam svarbiam

dokumentui peržiūrėti ir patvirtinti taip pat turi būti skiriama pakankamai laiko.

Sudarius sandorį, testavimo planavimo ir parengiamųjų veiklų darbo grafiko

rengimą pradėkime kaip galima anksčiau. Planas gali plėtotis augant

reikalavimams (pvz., peržiūrint reikalavimus). Testavimą planuokime ir renkimės

jam PĮ kūrimo laikotarpiu, t.y. lygiagrečiai su PĮ kūrimo darbais. Kodėl tai yra

būtina? Viena, kad priėmimo testavimo planavimas reikalauja nemažai laiko ir

resursų; juk negalima laukti iki paskutinės minutės. Turi būti parengti testų

variantai, parašytos testavimo programos, parengta tikrinimo aplinka (įranga,

infrastruktūra). Be to, patirtis rodo, kad projektui baigiantis veikloms numatytas

laikas trumpinamas, kas ypač pastebima testavime. Todėl geriausia nelaukti

projekto pabaigos ir iš anksto parengti testavimo planą ir reikiamus dokumentus.

Kitas išankstinio planavimo privalumas yra tas, kad jis įgalina susikoncentruoti

ties dokumentuotų reikalavimų esme. Taip atsiranda grįžtamasis ryšys

reikalavimų valdymo procese. Geri reikalavimai yra tokie, kuriuos galima

patikrinti. Jeigu taip nėra, reiškia jie apibrėžti neadekvačiai. Keldami sau

klausimą, kaip tikrinsime kažkurį reikalavimą, savaime iškeliame ir kitą

klausimą, ką šis reikalavimas iš tikro reiškia. Kuo anksčiau atsakysime į šiuos

klausimus, tuo geriau bus. Jeigu negalima sugalvoti testo reikalavimui patikrinti,

tikriausiai jį reikėtų pašalinti iš reikalavimų sąrašo. PĮ kokybės rodikliams

įvertinti, kas yra labai sunku, prašykime tiekėjo pasiūlyti vertinimo metodą.

Teisės požiūriu PĮ priėmimo testavimas negali būti vienašališkai primetamas

tiekėjui, sulaukus projekto pabaigos. Šis klausimas jau turi būti keliamas

prašyme teikti pasiūlymus (RFP) ir sudarant sandorį. Juose turi būti aiškiai

įvardinta testavimo planavimo veikla ir testavimo plano parengimo laikas.

Prašyme teikti pasiūlymus (RFP) ir sandoryje turi būti nurodomos užsakovo ir

tiekėjo pareigos bei atsakomybė už PĮ testavimą jos priėmimo metu ir už

testavimo plano parengimą: kas rengs testavimo planą, kas testuos, kas analizuos

testų rezultatus, kas nuspręs, ar testavimo rezultatai atitinka priėmimo kriterijus.

Rekomenduojama, kad užsakovas ir tiekėjas savo parašais patvirtintų testavimo

planą.

Prašyme teikti pasiūlymus (RFP) ir sandoryje taip pat turėtų būti apibrėžti

bendrieji priėmimo kriterijai. Detalūs kriterijai rengiami vėliau bendromis

jėgomis. Bendrojo kriterijaus pavyzdžiu gali būti sistemos gebėjimas išlaikyti


97

kritiškus (svarbiausius) testus ir 80 proc. likusių testų. Detalūs testavimo

rezultatų dokumentai gaunami projekto pabaigoje, juose kiekvienam testui

nurodant, kokius kriterijus PĮ atitiko ar neatitiko.

Priėmimo kriterijų įtraukimas į prašymą teikti pasiūlymus (RFP) ir sandorius

yra užsakovų ir tiekėjų apsaugojimo būdas. Paprastai užsakovai skundžiasi, kad

PĮ veikia prastai ir neatitinka jų lūkesčių. Tuo pačiu metu tiekėjai skundžiasi, kad

nesant formalių priėmimo kriterijų viešojo sektoriaus užsakovai neturi paskatų

priimti PĮ ir nuolatos prašo dar ir dar patobulinti PĮ. Atsiskaitymas su tiekėjais vis

atidedamas.

Dar viena priežastis, dėl ko priėmimo testavimas turėtų būti planuojamas

kaip galima anksčiau, yra ta, kad kai kurie PĮ reikalavimai gali kilti iš testavimo

kriterijų. Pvz., reikia tikrinti kažkokį algoritmą ir pagal testavimo planą rodyti tam

tikrus įvesties ir išvesties duomenis. Tiems duomenims rodyti gali reikėti

papildomos programos, kuri juos išskirtų iš duomenų srauto. Darbų pradžioje

tokios papildomos programos kūrimą lengva įtraukti į projektą kaip vieną iš

reikalavimų, ką vėliau padaryti yra žymiai sunkiau.

Perspėjimas

Labai atsargiai žiūrėkime į PĮ priėmimą atskirai nuo visos likusios sistemos.

Netgi jei PĮ yra tik vienas iš sistemos komponentų, ji gali būti svarbus ryšio su

likusiomis sistemos dalimis elementas. Jei įmanoma, geriausia bandyti PĮ turint

visą sistemos aparatinę įrangą (AĮ). Kita vertus, užsakovas gali nenorėti priimti

AĮ įrangos, neįsitikinęs, ar ji atitinka įsigyjamą PĮ. Rizika yra bet kuriuo atveju.

Pirkti AĮ anksčiau nei įsigyjama PĮ yra rizikinga, nes tai gali padidinti

projekto kainą. Eilėje projektų AĮ laikoma brangiausiu sistemos elementu, todėl

geriausia būtų įsigyti ją kiek galima vėliau. Čia AĮ suprantama kaip išoriniai

įrenginiai, įvairūs jutikliai ir kiti specializuoti prietaisai. Kompiuterinės

platformos AĮ, kurioje „šeimininkauja“ (laikoma) PĮ, nėra brangiausia.

AĮ įsigijimo laiko klausimas darosi ypač aktualus, kai PĮ įsigijimo projektas

vėluoja. Blogiausiu atveju, kai projektas nutraukiamas dėl PĮ problemų, niekas

nenori turėti bėdų dėl įsigytos, bet nebereikalingos AĮ. Be to, AĮ tobulėja labai

greitai. Jos pirkimo atidėjimas PĮ kūrimo laikotarpiui gali duoti kai kuriuos

privalumus.

Kita vertus, jei AĮ įsigijimas atidedamas arba jos komponentai netinka

įsigyjamai PĮ testuoti, PĮ gali būti priimta dar iki jos paleidimo visoje sistemoje.

Akivaizdi rizika yra tame, kad PĮ gali neveikti sujungus visą sistemą: nupirkę

daugiausiai kainuojančią aparatinę sistemos dalį pastebėsime, kad PĮ su ja

neveikia. Kadangi PĮ yra jungiantysis elementas, visa sistema neduos jokios


98

naudos. Kai galų gale priversime PĮ dirbti su nupirkta AĮ, pastebėsime, kad AĮ

paseno, o mes nesame pasirengę techninėms naujovėms.

Geresnis pasirinkimas yra įvairios posistemės, kiekviena su savo PĮ,

aparatine įranga ir ryšio komponentais.

Testavimas yra grupinė veikla

Dauguma įsigijimo grupės narių gali ir turėtų dalyvauti PĮ priėmimo

testavime. Tiesioginiai naudotojai ir PĮ administratorius turėtų įnešti savo indėlį į

rengiamą testavimo planą. Bet kuris PĮ ekspertas užsakovo darbo grupėje gali

padėti rengti ir peržiūrėti testavimo plano dokumentus. Kaip jau buvo minėta,

nesvarbu kas rengė testavimo planą, jį savo parašais turi patvirtinti abi pusės –

užsakovas ir tiekėjas.

Užsakovas ir tiekėjas turi testuoti PĮ drauge. Tiesioginiai naudotojai ir PĮ

administratorius gali dalyvauti testuojant PĮ funkcijas, su kuriomis jie yra

tiesiogiai susiję. Grupės techniniai ekspertai taip pat turi dalyvauti testavimo

darbe. Sudarant sandorį reikėtų numatyti, kad jiems tai bus leidžiama ir kad

reikiamas užsakovo personalas bus apmokytas dar iki testavimo pradžios.

Formalių priėmimo testų tipai

Tarkime, užsakovas nutarė vykdyti formalius testus. Tačiau kokio tipo testai

turėtų būti vykdomi? Priėmimo testas turi būti kruopštus ir griežtas, o ne švelnus

patikrinimus, pvz., kad PĮ gali palaikyti ryšį su išoriniais įrengimais. Tai būtų tik

demonstravimas, o ne testavimas. Priėmimo testavimas turi parodyti, kad PĮ dirba

pagal nustatytus reikalavimus ir su visais išoriniais įrenginiais. Vertimas dirbti PĮ

ekstremaliomis sąlygomis yra geras tikrinimo būdas:

- jei reikalavimuose nurodyta, kad išoriniu įrenginiu turi būti įvedami tik

skaitiniai parametrai, tai tikrinkime PĮ ne vien su nominaliomis parametrų

reikšmėmis, bet ir su ekstremaliomis bei klaidingomis reikšmėmis (jei

leistinos reikšmės yra nuo 1 iki 9, tai įveskime, pvz., ir 11. Bandykime

įvesti raides vietoje skaičių);

- tikrinkime PĮ našumą (pvz., galimybę duoti atsakymą per nustatytą laiką)

esant sunkioms aplinkybėms (didelis naudotojų kiekis, įvedami/išvedami

dideli duomenų kiekiai). Jei yra apkrovimo reikalavimas, įsitikinkime, ar

PĮ atitinka jį:

- taip pat gali būti noras patikrinti, kas atsitinka, kai visa sistema per daug

apkraunama. Ar tik sulėtėja jos darbas, ar įvyksta avarinis išsijungimas?

(jei testuojamas darbo sulėtėjimas, tai įsitikinkime, ar iš tikro buvo toks

reikalavimas). Kitas tikrinimo būdas yra sistemos apkrovimo didinimas, kol

ji „nulūžta“.


99

PĮ tikrinimas darbo aplinkoje įgalina papildomai patikrinti galimybes ją

administruoti. Pvz., kiek laiko reikia PĮ paleisti; kas atsitinka, kai nutrūksta ryšio

linija su išoriniu įrenginiu; kt.

Aukščiau išvardintos priemonės nėra visa apimančios, tačiau gali būti

naudingos formalaus testavimo metu.

PĮ sistemoms gali būti naudojami šių tipų testai:

- funkciniai testai. Tai PĮ gebėjimo transformuoti įvesties duomenis į

norimus išvesties duomenis tikrinimas. Funkciniai testai dažniausiai

sudaro didesnę visų testų dalį. Tai gali būti ir paprastos demonstracijos,

pvz., ryšys su išoriniais įrengimais, ir žymiai griežtesni testai. Jeigu yra

didelis išorinių įrenginių, ryšio linijų, monitorių kiekis, kiekvienas iš jų turi

būti patikrintas ir įsitikinta, kad jie veikia normaliai (tai daugkartinio

testavimo pavyzdys, atliekamo pagal tokią pačią procedūrą). Kitais

funkciniais testais siekiama įsitikinti, kad PĮ įveda, pvz., įvairių sensorių

duomenis, atlieka su jais skaičiavimus, sugeneruoja reikiamus išvesties

duomenis, tinkamai juos išsaugo. Taip pat turi būti tikrinama, ar tinkamus

pranešimus PĮ išveda į monitorių sutrikimų atvejais;

- maksimalių galimybių ir darbo ekstremaliomis aplinkybėmis testai. Kas

darosi, kai PĮ yra maksimaliai apkrauta? Testas turėtų parodyti, kad PĮ

funkcionuoja toliau ir reakcijos laikas į užklausas atitinka reikalavimus.

Dažnai šiuose testuose reikalinga imitacinė PĮ didelės apimties įvesties

duomenims generuoti. Įsigijimo projekte darbo grafikas ir resursai turi būti

numatyti tokiai papildomai PĮ sukurti;

- klaidingų įvesties duomenų testai. Tai PĮ tikrinimas įvedant duomenis,

išeinančius už leistinų ribų;

- stabilumo testai. Tai PĮ gebėjimo nepertraukiamai dirbti ilgą laiką

nereikalaujant įsikišimo tikrinimas. Dažnai jis vadinamas nepertraukiamo

darbo testu. Šiuos testus yra sunkiausia atlikti (sugaištama daug laiko);

- integralumo testai. Šiais testais tikrinamas PĮ gebėjimas užkirsti kelią

nesankcionuotiems veiksmams su ja.

Testavimo kruopštumas

Testų parinkimui įtakos turi bendri įsigijimo projekto tikslai.

Rekomenduojama periodiškai peržiūrėti PĮ sampratą įsigijimo projekto plane, kad

galima būtų patikslinti PĮ tikrinimo reikalavimus. Panašiai, remiantis PĮ

samprata, galima nuspręsti, kokios apimties patikrinimų reikėtų priimant ją.

Ilgalaikiam naudojimui skirtas sistemas reikėtų tikrinti rūpestingai, kai kitokioms

gali pakakti patikrinti jų veikimą.


100

Nustatant PĮ reikalaujamą veikimo atsparumo lygį, nepamirškime sistemoje

naudojamos anksčiau įgytos ar kitokios esamos PĮ galimybių. Beveik visa tokia

PĮ, įskaitant ir perkamą gatavą PĮ, nėra labai atspari avarinėms situacijoms ir gali

neatlaikyti sunkių testų. Pvz., taikomajai programai kelti aukštesnius atsparumo

reikalavimus, nei to galima tikėtis iš operacinės sistemos, yra beprasmiška.

Priėmimo testo dokumentai

Priėmimo testavimo procedūra turi būti aprašyta (dokumentuota), kad tokius

pačius rezultatus galėtume gauti kikvieną kartą, prireikus kartoti testą. Priėmimo

testo dokumentai dalinami į penkias dalis: testavimo planą, procedūras,

variantus, įrašus (test logs) ir ataskaitą. Kaip šios dalys pateikiamos, viename

dokumente ar atskirai, nėra esminis dalykas.

Testavimo plane aprašomas visas PĮ testavimas jos priėmimo metu. Jame

išdėstomi konkretūs testavimo klausimai, kurie buvo paminėti įsigijimo projekto

plane, darbų grafike, prašyme teikti pasiūlymus (RFP), sandoryje. Šį planą

reikėtų pradėti rengti netrukus po tiekėjo išrinkimo. Plano rengimui gali

vadovauti tiek užsakovas, tiek tiekėjas. Bet kuriuo atveju planas rengiamas

bendradarbiaujant, patvirtinamas abiejų pusių parašais, turi tapti formaliu

dokumentu ir būti perduotas PĮ konfigūracijos priežiūrai.

Testavimo procedūros yra detalios instrukcijos, kaip žingsnis-po-žingsnio turi

būti atliekamas PĮ tikrinimas. Tokia pati procedūra gali būti atliekama keletą

kartų su skirtingais įvesties duomenimis. Kiekvienas įvesties duomenų rinkinys

atitinka naują testavimo variantą. Kiekvienu testavimo variantu patikrinamas

vieno arba keleto PĮ reikalavimų įgyvendinimas. Testavimo įrašai yra ne kas kita,

kaip tikrinimų metu užfiksuoti duomenys. Testavimo ataskaitoje pateikiamos

tikrinimo išvados. Bendra išvada, ar PĮ išlaikė testus, gali būti išdėstyta

trumpame atskirame dokumente.

15.1-15.5 lentelėse yra išvardinti klausimai, kuriuos siūloma įtraukti į

priėmimo testo dokumentus.

15.1 lentelė. Kas nurodoma PĮ priėmimo testavimo plane

Nr. Nurodomas dalykas

Organizacijų vaidmuo

1. Kas bus atsakingas už testų leidimą?

2. Kas bus atsakingas už testų duomenų registravimą?

3. Kas bus atsakingas už testų duomenų analizę ir testavimo rezultatų (ataskaitos) parengimą?


101

Kur bus atliekamas testavimas

4. užsakovo vietovėje?

5. kokioje operacinėje aplinkoje?

Testavimo grafikas

6. Kompiuterių testams leisti tikrinimas

7. Išorinių įrengimų tikrinimas

8. Ryšio su kitomis sistemomis (iš anksčiau organizacijoje turimomis ar kitur esančiomis sistemomis, su kuriomis reikia palaikyti ryšį) tikrinimas

Testavimui reikalinga papildoma PĮ

9. Speciali testavimo PĮ (ypatingų situacijų imitatoriai, analizės rezultatų skaičiuoklės, kt.)

Bendrieji PĮ priėmimo kriterijai

10. PĮ neatitikimų reikalavimams priėmimo metu leistinas lygis (pvz., visų kritinių ir 80 % likusių testų išlaikymas)

Kas daroma, jei testas neišlaikomas arba vyko ne pagal planą?

11. Pakartotinio testavimo vaidmuo

Testų sąrašas; kiekvienam testui nurodoma:

12. Testo identifikatorius (pvz., 1A)

13. Testo paskirtis (trumpas jo apibūdinimas)

14. Kokie duomenys turi būti registruojami testo metu?

15. Testo išlaikymo/neišlaikymo kriterijus (priklausomai nuo testo šią informaciją gali būti geriau pateikti apibrėžiant testavimo variantus, žiūr. 15.3 lentelę)

Testų ir PĮ reikalavimų ryšys (atsekamumas)

16. Kiekvienam testui nurodoma, koks PĮ reikalavimas juo yra tikrinamas

(atspindimas testų pagrįstumas; tai gali būti traktuojama kaip tiekėjo

apsaugos priemonė, kad tikrinant neatsirastų nauji reikalavimai)

17. Kiekvienam PĮ reikalavimui nurodoma, kokiais testais jis yra tikrinamas

(atspindimas testų visumos išsamumas; tai gali būti traktuojama kaip

užsakovo apsaugos priemonė, kad visi PĮ reikalavimai būtų patikrinti)


102

15.2 lentelė. Kas nurodoma kiekvieno testo procedūrų aprašuose


1. Išankstiniai veiksmai testui paleisti (pvz., įjungti ar išjungti tam tikrus įrenginius, įdiegti (load) tam tikras PĮ dalis)

2. Procedūros, kaip žingsnis-po-žingsnio turi būti atliekamas testas

3. Duomenų trumpinimo ir analizės procedūros (aiškios lygtys, statistikos formulės, apvalinimo būdai, kt.)

4. Kompiuteriai, reikalingi testams leisti ir rezultatams analizuoti

5. Išoriniai įrengimai, reikalingi testui leisti (pvz., jutikliai, indikatoriai)

6. Kitos sistemos (iš anksčiau organizacijoje turimos ar kitur esančios sistemos), su kuriomis reikia palaikyti ryšį

15.3 lentelė. Kas nurodoma priėmimo testų variantuose


1. Įvesties duomenys

2. Įvesties duomenų šaltinis (rankinis įvedimas; išoriniai įrenginiai, jutikliai);

3. Testo trukmė (pvz., kaupti kažkokio indikatoriaus duomenis vieną valandą)

4. Laukiami išvesties duomenys

5. Testo išlaikymo/neišlaikymo kriterijus (priklausomai nuo testo šią informaciją gali būti geriau pateikti testavimo plane, žiūr. 15.1 lentelę)

6. Testų variantų ir testų ryšiai (atsekamumas), kad žinotume, ar testo variantas taikytinas visiems testams.

15.4 lentelė. Kas turėtų būti testavimo įrašuose


1. Testo pavadinimas ir identifikatorius

2. Testavimo pradžios data ir laikas

3. Testavimo pabaigos data ir laikas (tik tiems testams, kurie trunka ilgesnį laiką; daugumai testų pakanka tik pradžios datos ir laiko)

4. Kas leido testą

5. Bet kokie testavimo procedūrų nukrypimai (pvz., testo vykdytojas netyčia praleido kažkokį žingsnį; testavimo procedūroje aptikta ir ištaisyta klaida)

6. Gauti testavimo duomenys


103

15.5 lentelė. Kas rašoma testavimo ataskaitoje


1. Bendroji informacija (pvz., kada buvo testuojama)

2. Bendroji išvada, ar sistema išlaikė testus, ir tolesni veiksmai

Kiekvieno testo rezultatai

3. Testo identifikatorius, naudota procedūra ir testo variantas

4. Bet kokie testavimo procedūros nukrypimai

5. Gauti testavimo duomenys

6. Apskaičiuoti duomenys

7. Testas išlaikytas ar neišlaikytas (vertinant pagal dokumentuotus kriterijus)

PĮ priėmimo testavimo planas yra formalus dokumentas. Todėl prašyme teikti pasiūlymus (RFP) turi būti įvardinti dokumentai, kuriuos tiekėjas turės pateikti užsakovui vykdydamas sandorį. Taip pat įvairiais laiko momentais gali būti reikalaujama preliminaraus testavimo dokumentų. Jie gali būti naudojami kaip neformali priemonė trūkumams išaiškinti, kai tik sukurtos PĮ dalys sujungiamos į sistemą. Tokio testavimo rezultatus užsakovas gali panaudoti formuodamas atsakomąją reakciją į tiekėjo darbus.

15.1 lentelėje parodyta, kad testavimo plane turi būti punktas, ką reikėtų daryti, jei testas neišlaikomas. Yra keletas alternatyvų: gali būti pakartotas atskiras testas, prieš tai atlikus PĮ pataisymus, arba pakartotas visas testų rinkinys. Pastarasis procesas vadinamas pakartotiniu testavimu. Pataisymai gali turėti netikėtą pašalinį poveikį kitoms sistemos dalims. Vienos problemos šalinimas netyčia gali iššaukti kitas problemas. Pakartotinis testavimas, siekiant parodyti, kad sistema išlaiko visus testus, yra priimtinas dalykas. Tačiau visų testų kartojimas gali pareikalauti nemažų išlaidų. Tik sveikas protas ir turimi resursai gali padėti nuspręsti, kur plataus masto pakartotinis testavimas turėtų būti atliekamas.

Testavimo metu gautas duomuo gali būti skaičius arba tiesiog patvirtinimas, kad kažkas įvyko/neįvyko. Kai kurių testų duomenis registruoti reikiamo pavidalo formose gali būti sunku, bet jie gali būti naudojami kaip papildoma medžiaga (pvz., spausdintuvais išvesti duomenys). Kai kuriais atvejais testo duomenys gali būti gaunami labai greitai. Pvz., būseną indikuojanti lemputė užsidegė arba neužsidegė. Yra atvejai, kai testo duomenys gali būti analizuojami vėliau (pvz., kai reikia apskaičiuoti vidutines reikšmes arba vykdyti statistinius testus), norint sužinoti, ar testas buvo sėkmingas. Kai kurie testo duomenys gali būti užrašomi skirtingu metu nuo kitų duomenų gavimo. Tai administraciniai duomenys, kaip testavimo laikas, testas išlaikytas/neišlaikytas.


104

16. Darbuotojų mokymas, PĮ naudojimas ir priežiūra

Kiekviena įsigyjančioji organizacija laukia tos dienos, kai PĮ bus pristatyta ir

galės pradėti ją naudoti. Tačiau nereikėtų pamiršti, kad PĮ naudojimo metu taip

pat reikės vykdyti eilę kitokių veiklų. Dvi iš jų yra pagrindinės: darbuotojų

mokymas ir PĮ priežiūra. Be jų dar yra PĮ administravimo, asmenų, kurie

administruos ir prižiūrės PĮ, mokymo veiklos.

PĮ naudojimo ir priežiūros veiklos, deja, dažniausiai prisimenamos tik

baigiantis PĮ įsigijimo projektui. Tai turėtų būti daroma dar PĮ kūrimo metu, nes

vėliau pasirengti PĮ naudojimui ir priežiūrai būna sunkiau ir brangiau. Tada šios

veiklos atliekamos skubotai, kad nebūtų pažeistas įsigijimo projekto pabaigos

terminas. Per skubėjimą esminiai klausimai sprendžiami netinkamai arba visai

užmirštami iki PĮ pristatymo.

Šio skyriaus tikslas yra supažindinti skaitytojus su rengimosi prižiūrėti

įsigytą PĮ veiklomis.

Priežiūros veiklų planavimas

PĮ naudojimo ir priežiūros klausimai, kurie turėtų būti nagrinėjami jau

įsigijimo projekto planavimo metu, yra šie:

- kaip įdiegti PĮ, integruojant ją į organizacijoje esančią darbinę

(operacinę) aplinką;

- kaip naudoti PĮ efektyviai;

- darbuotojų, naudosiančių PĮ, komplektavimas;

- darbuotojų mokymas naudoti PĮ ir prižiūrėti ją;

- operatyvios (on-line arba telefonu) pagalbos PĮ naudojimo klausimais

organizavimas;

- atsakinėjimas į PĮ naudotojų klausimus;

- PĮ sudėtyje panaudotų gatavų komponentų (COTS) palaikymas pristačius

PĮ;

- PĮ priežiūra;

- PĮ priežiūros priemonės (instrumentai);

- perkėlimų (migration) planavimas, atnaujinant PĮ.

Kiekvieno iš aukščiau išvardintų klausimų atsakyme turi būti pasakyta, kas

tą darys. Panagrinėkime smulkiau kai kuriuos klausimus.

Mokymas

Mokymai yra kelių tipų. Pirmasis, tai darbuotojų mokymas naudotis PĮ. Juos

reikia mokyti, kaip išsikviesti įvairias PĮ funkcijas, kuriuos mygtukus spausti.


105

Taip pat juos reikia supažindinti su bendrąja PĮ struktūra, kaip elgtis įvairių

situacijų atvejais.

Kitas mokymų tipas yra susijęs su PĮ priežiūra, palaikymu ir administravimu.

Turi būti nuspręsta, kas ves mokymus: PĮ tiekėjas (kūrėjas), išorinis

priežiūros paslaugų tiekėjas ar organizacijos savi darbuotojai. Jei nusprendžiama,

kad mokymus ves savi darbuotojai, tai kelkime sau klausimą, kas apmokys tuos

darbuotojus.

Labai svarbu pasirūpinti teise į visą mokomąją medžiagą.

Gatavų komponentų palaikymas

Gatavų PĮ komponentų (COTS) naudojimas visos įsigyjamos PĮ sudėtyje

sukelia specialius kūrimo/pirkimo ir palaikymo klausimus. Kūrimo/pirkimo

klausimą nagrinėjome 10 skyriuje „Kurti naują ar pirkti gatavą PĮ?“. Čia plačiau

panagrinėkime palaikymo klausimą. Gatavą PĮ paprastai prižiūri tiekėjas. Jis

išduoda tik naudojimo licencijas. Nereikėtų tikėtis gauti intelektinės nuosavybės

teisių, kurios būtinos PĮ priežiūrai organizacijos aplinkoje vykdyti. Tiekėjas gali ir

neteikti periodiškų priežiūros paslaugų (pvz., klaidų išaiškinimo ir šalinimo).

Tiekėjas tikriausiai leis naujas gatavos PĮ versijas, kuriose bus pakeitimų.

Įprastas jos tobulinimo rinkoje būdas gali ir nespręsti jūsų organizacijos

problemų. Netgi jei patobulinimai įgalina spręsti jūsų problemas, jūs turite

nuspręsti, ar imsitės visos savo PĮ atnaujinimo, įsigydami naujas gatavų

komponentų (COTS) versijas.

Argumentai „už“, kodėl reikėtų atnaujinti ir savąją PĮ:

- įgyjamas naujas PĮ funkcionalumas;

- pašalinamos klaidos;

- turėdami senąją savo PĮ, neturėsime atnaujinto produkto teikiamų

galimybių ir neteksime pardavėjo palaikymo paslaugų.

Argumentai „prieš“:

- gatavos PĮ (COTS) naujų versijų galimas nepageidaujamas poveikis visai

jūsų PĮ. Ar naujoji versija sklandžiai derinasi su likusia PĮ dalimi? Kai

kuriais atvejais naujai gatavos PĮ versijai įdiegti gali reikėti naujos

aparatinės įrangos, jei pardavėjas, tobulindamas savo produktą, perima ir

technologijos pažangą;

- naujoji gatavos PĮ versija gali būti nesuderinama su senąja. Kiti jūsų

individualios PĮ komponentai gali priklausyti nuo gatavos PĮ senosios

versijos savybių, kurių nebeliko naujojoje versijoje. Kitaip tariant,

paprastas gatavos PĮ patobulinimas gali sugriauti visą likusią jūsų

sistemą;


106

- poreikis apmokyti darbuotojus naudoti naujos versijos PĮ, atsiradus

naudotojo sąsajos pokyčiams;

- tobulinimų išlaidos.

Nežiūrint argumentų „už“ ir „prieš“, tobulinimai dažniausiai yra nemalonus

faktas. Jei jau ryžtamės patobulinimams, išbandykime savo sistemą su naująja

gatavos PĮ versija prieš pradėdami naudoti ją.

Jei gatava PĮ nėra paplitusi, susitarti su pardavėju dėl jos palaikymo būna

lengviau. Paprastai pagalba būna kelių formų. Viena iš jų yra „karštoji linija“, kai

naudotojas gali kreiptis iškilus problemoms ar darbiniams klausimams. Būtinais

atvejais palaikymo paslauga gali būti teikiama už papildomą kainą. Dažnai

paaiškinimus apie tokios PĮ veikimo anomalijas galima rasti naudotojams

pateikiamose mokymo priemonėse. Jei gatava PĮ yra paplitęs produktas, telieka

nuspręsti, ar atnaujinsime savo sistemą, pasirodžius naujai gatavo produkto

versijai.

Reikėtų tinkamai ir laiku pasirūpinti gatavos PĮ licencijomis, kad tai

netrukdytų visos jūsų sistemos eksploatacijai. Kai kuri gatava PĮ gali būti

reikalinga jūsų sistemai palaikyti (kaip priežiūros instrumentai). Jiems naudoti

taip pat reikalingos licencijos. Štai keletas klausimų, kurie turėtų būti atspindėti

palaikymo licencijoje:

- ar numatyti gatavos PĮ atnaujinimai? Jei taip, tai kiek kartų per metus?

- ar teikiamos konsultacijos telefonu? Jei taip, tai kiek valandų per dieną,

kiek dienų per metus?

- per kiek laiko gatavos PĮ tiekėjas turi atsakyti į jūsų klausimus?

PĮ priežiūra

Kas yra PĮ priežiūra?

Išskyrus paprasčiausius atvejus, PĮ retai kada būna užbaigta galutinai. Ją

tenka prižiūrėti visą laiką. Įvairiuose šaltiniuose rašoma, kad tipiškai 60-80%

visos PĮ gyvavimo ciklo kainos sudaro priežiūros išlaidos, kas viršija kūrimo

išlaidas.

PĮ priežiūra – tai jos modifikavimas po pristatymo. Priežiūra apima PĮ

naudojimo metu rastų klaidų taisymą, PĮ darbo našumo arba funkcionalumo

didinimą, PĮ tinkamumo keičiantis aplinkai palaikymą, PĮ darbingumo palaikymą

[IEEE1062].

Į PĮ priežiūrą reikėtų žiūrėti visos sistemos kontekste, apimant ir aparatinės

įrangos priežiūrą. Ar PĮ funkcionalumas priklauso nuo tam tikro aparatinės

įrangos priežiūros lygio? Juk kartais PĮ labai priklauso nuo išorinių įrenginių

buvimo ir jų darbo (pvz., jutikliai, kt.).


107

Į priežiūros sąvoką reikėtų žiūrėti plačiau. Turėtų rūpėti ne tik PĮ priežiūra,

bet ir kas ją prižiūri, kiek tai kainuoja. Priklausomai nuo sistemos dydžio ir

sudėtingumo, priežiūros samprata gali būti dokumentuota (išdėstyta) sistemos

plane arba įtraukta į įsigijimo projekto valdymo planą. Taigi, PĮ priežiūra apima

tokius klausimus, kaip:

- metodai klaidoms (trūkumams) nustatyti;

- pasiūlymų diegti naujas funkcijas arba plėsti senąsias teikimas;

- keitimų prioritetų nustatymas, taisymų ir tobulinimų grafiko sudarymas

bei jų įgyvendinimo stebėjimas;

- pakeitimų tikrinimas, ar po jų PĮ iš tikro gerai veikia ir ar jie neiššaukė

kokių nors kitų kliūčių;

- naudojant nustatytas PĮ konfigūracijos valdymo procedūras,

registravimas tokių dalykų, kaip :

- problemos ir kaip jos buvo išspręstos, PĮ pakeitimai ir patobulinimai;

- testų vykdymas;

- visų susijusių programų kodai ir dokumentai.

Kas turėtų prižiūrėti PĮ?

PĮ priežiūros procese turi būti nustatyta atsakomybė už įvairių veiklų

atlikimą. Ypač svarbu numatyti, kas rūpinsis:

- PĮ naudojimo sferos plėtra;

- PĮ našumo didinimu;

- PĮ papildymu naujomis funkcijomis ir naudotojų mokymu naudoti jas;

- klaidų ieškojimu ir informavimu apie jas;

- klaidų taisymu;

- PĮ dokumentų keitimu.

Tokie lėtai kintantys veiksniai kaip kaina, erdvė, užsakovo ir tiekėjo

personalo kvalifikacija, personalo buvimas turi įtakos priimant sprendimus. Kai

kuriais atvejais atsakomybė gali būti padalinta, dalį priežiūros veiklų pavedant

tiekėjui, o dalį – užsakovo personalui.

Labiausiai patrauklus variantas yra toks, kai PĮ prižiūri jos tiekėjas (kūrėjas).

Jis geriausiai žino vidinę PĮ struktūrą bei turi reikiamos kvalifikacijos specialistus

ir būtiną įrangą priežiūros darbams atlikti. Jei nutariama PĮ priežiūrą pavesti

tiekėjui, reikėtų tai nurodyti pagrindiniame įsigijimo sandoryje arba atskirame

priežiūros sandoryje. Sudarant priežiūros sandorį, derėtų vadovautis žemiau

dėstoma medžiaga.

Jei užsakovas ketina PĮ priežiūrą pavesti kitam paslaugų tiekėjui (ne PĮ

tiekėjui), paruošiamuosius darbus būtina pradėti kaip galima anksčiau. Priežiūros

sandoris turi būti pasirašytas dar iki PĮ naudojimo pradžios.


108

Jei užsakovas ketina prižiūrėti PĮ savo jėgomis, reikėtų gerai apsvarstyti, ar

verta imtis tokios atsakomybės. Imantis atsakomybės už PĮ priežiūrą, reikia:

- turėti kvalifikuotą personalą. Pastebėkime, kad programuotojo patirties

nepakanka realiai PĮ prižiūrėti. Kvalifikuotų žmonių yra mažai. Jei

užsakovo organizacija ketina įsigyti tokių darbuotojų, reikėtų pagalvoti,

ar ji pajėgs mokėti jiems priimtiną algą. Jeigu ji mokys savo turimą

personalą, tai ar pajėgs vėliau juos išlaikyti (pvz., išeis dirbti kitur, kur

didesnis atlyginimas);

- supažindinti personalą su PĮ vidine struktūra, palaikymo aplinka ir

priežiūros instrumentais. Tai pareikalaus priežiūros personalo ir PĮ

tiekėjo (kūrėjo) glaudaus bendradarbiavimo nuo pat įsigijimo projekto

pradžios;

- imtis dokumentų tvarkymo ir PĮ konfigūracijos valdymo darbų, kuriuos

paprastai atlieka tiekėjas;

- sukurti ir įdiegti priežiūrai reikalingą aplinką;

- turėti prieigą prie:

- PĮ pradinių tekstų (source code) kompiliavimui tinkamuose

kompiuterių failuose; popieriuje atspausdintų tekstų nepakanka;

- duomenų bazių dokumentų, duomenų struktūrų, sąsajų protokolų;

- programų rašymo (pvz., kompiliatorių), PĮ konfigūracijos valdymo,

testavimo, kitokių priemonių.

Pastebėkime, kad prieigos teisės prie šių priemonių turi savo kainą. Pvz.,

komercinės duomenų bazių valdymo sistemos visos aplinkos palaikymas

kainuoja žymiai daugiau, negu jos vykdomojo (run-time) paketo licencija.

Priimant sprendimą dėl PĮ priežiūros, nesvarbu, ar tam užsakovas darys

sandorį su kažkuo, ar pats imsis šių darbų, turi būti numatomos ir

išlaidos.

PĮ priežiūros samprata dalinai apibrėžia užsakovo poreikį į intelektinės

nuosavybės teises. Šis poreikis turi būti aprašytas aiškiai; PĮ kodo (t.y. PĮ

pradinių tekstų) turėjimas skiriasi nuo teisės į kodą. Tačiau užsakovas gali

išvengti bereikalingų ginčų dėl intelektinės nuosavybės teisių, nusprendęs, kad

nėra pajėgus tvarkyti PĮ kodo. Reikėtų kelti sau tokį klausimą: jei sieksiu įgyti PĮ

kodą, ar organizacijoje atsiras žmonių, sugebančių prižiūrėti jį; gal geriau

samdyti PĮ prižiūrėtojus, pvz., PĮ sukūrusį tiekėją.

Spręsdami PĮ priežiūros klausimą, išnagrinėkime dokumentus, ar jie yra

pakankami, kad užsakovo organizacijos aplinkoje savi specialistai arba trečioji

organizacija galėtų prižiūrėti PĮ. Tai gali versti užsakovą PĮ priežiūrai rinktis jos

tiekėją, netgi jei projekto pradžioje jis buvo numatęs kitaip.


109

Dažnai užsakovas PĮ priežiūros klausimu tampa priklausomas nuo tiekėjo,

netgi esant labai paprastiems priežiūros darbams, pvz., iškilus reikalui spausdinti

kitokius duomenis, keisti spausdinamų ataskaitų formą. To išvengti galima

reikalaujant, kad ataskaitų generavimo ir grafinių naudotojo sąsajų kūrimo

priemonės būtų pateikiamos kaip atskiros PĮ dalys. Su tokiomis lengvai

naudojamomis PĮ dalimis, kaip instrumentais, sistemos administratorius galėtų

keisti ekranų formatus naudotojams, prireikus koreguoti ankstesnes ataskaitų

formas arba kurti naujas, kt.

Taip pat būtina nuspręsti, kur bus atliekama PĮ priežiūra. Didelėms

sistemoms prižiūrėti užsakovas gali norėti turėti žmones keliose skirtingose

vietose. Vietos parinkimo klausimai gali būti sprendimo dėl priežiūros priėmimo

veiksniais.

Priežiūros priemonės (instrumentai)

Priežiūros priemonės – tai PĮ priežiūrai naudojama aparatinė ir programinė

įranga, įskaitant testavimui ir rezultatų analizei naudojamą specialiąją įrangą.

Šios priemonės paprastai skiriasi nuo PĮ kūrimo priemonių. Pvz., tiekėjo

naudotos priemonės PĮ kurti gali skirtis nuo PĮ naudoti reikalingų priemonių, o

tiekėjo turėtos licencijos neperduodamos užsakovui PĮ palaikyti. Priežiūros fazėje

reikia priemonių PĮ gedimams diagnozuoti, duomenų ir pranešimų perdavimo

eigai stebėti, specialių testavimo scenarijų. Sudarant sandorį su PĮ tiekėju turi

būti aišku, ar PĮ priežiūros priemonės skirsis nuo PĮ naudojimo arba kūrimo

priemonių. Jei yra reikalingos PĮ priežiūros priemonės, jos turi būti nurodytos

sandoryje ir sukurtos jo metu.

Svarbus yra ir priežiūros priemonių laikymo vietos klausimas. Vienas iš

variantų yra pavesti tiekėjui (kūrėjui) savo turimomis priemonėmis rūpintis

sukurtos PĮ priežiūra. Tačiau jeigu tam reikia naujos specialios įrangos,

priežiūros įrangos sukūrimas turi būti įtrauktas į sandorį. Pridavus PĮ, kūrėjo

priemonės gali sudaryti tam tikrą priežiūros priemonių dalį, suteikiančią

platesnes priežiūros galimybes. Užsakovas turi pasirūpinti teise naudoti tiekėjo

turimas PĮ kūrimo priemones PĮ priežiūrai.

Priežiūros priemonėms funkcionuoti reikia tokių pat bendrųjų sąlygų, kaip ir

įsigytai PĮ, įskaitant patalpas, oro kondicionavimą, elektros energijos tiekimą,

darbų grafiką, biudžetą, personalą.

Priežiūros darbuotojų pareigos

Vienas iš pirmųjų PĮ priežiūros planavimo žingsnių turi būti tam reikalingų

darbuotojų numatymas. Jei PĮ tiesioginių naudotojų pareigos yra akivaizdžios, tai

kitų darbuotojų pareigos pradžioje nėra aiškios. 16.1 lentelėje yra išvardintos kai


110

kurios PĮ priežiūros darbuotojų pareigos. Kai kurios iš jų gali būti apjungiamos.

Pvz., į administratoriaus pareigas gali įeiti problemų diagnozė ir ryšio su

aparatinės įrangos pardavėjais palaikymas gedimų atveju.

16.1 lentelė. PĮ priežiūros darbuotojų pareigos

Nr. Pareigos

1. Vadovavimas tiesioginių PĮ naudotojų pamainai

2. PĮ administravimas, kad ji veiktų normaliai

3. PĮ veikimo ataskaitų rengimas

4. PĮ veikimo ataskaitų peržiūra

5. Naujos aparatinės įrangos instaliavimas

6. PĮ klaidų (bugs) taisymas

7. PĮ tobulinimas (upgrade):

- gatavųjų komponentų (COTS) naujų versijų instaliavimas;

- savosios PĮ funkcionalumo didinimas;

- valdymo algoritmų modifikavimas.

8. Aparatinės įrangos gedimų diagnozavimas ir taisymas

9. Darbuotojų mokymas diegiant sistemą ir įvykus darbuotojų kaitai

Kitas labai svarbus ir reikalaujantis dėmesio klausimas yra kaip įmanoma

tiksliau apibrėžti reikalingas žinias ir patirtį žmonių, kuriems bus pavesti PĮ

priežiūros darbai. Jo metu sprendžiama, kas bus atsakingas už 16.1 lentelėje

išvardintų pareigų atlikimą. Jei priežiūros darbus numatoma pavesti tiekėjui, tai

turi būti atspindėta sudarytame sandoryje PĮ kurti. Jei priežiūros darbus

nusprendžia vykdyti pati PĮ įsigyjančioji organizacija, tam turi būti samdomi

darbuotojai. Jei priežiūros darbams sudaromas atskiras sandoris (ne su PĮ

kūrėjais), tuomet įsigijimo projekto veiklos jam parengti turi būti pradėtos kaip

galima anksčiau, kad priežiūros paslaugų tiekėjas būtų išrinktas dar iki PĮ

kūrimo pabaigos.

Priežiūros organizacija turėtų būti pasirengusi prižiūrėti PĮ, kai tik PĮ

priimama. Gali būti ir perėmimo periodas, kuomet kūrėjas perduoda PĮ

prižiūrinčiai organizacijai. Tačiau tai turi būti numatyta ir įvardinta sandoryje su

PĮ kūrėju.

Priežiūros biudžetas

PĮ priežiūros biudžetas ir kas mokės už priežiūrą turi būti numatyti iš

anksto. Jei organizacija nesirengia pati prižiūrėti įsigytą PĮ, tą ji turi pasakyti


111

aiškiai. Iš anksto turi būti įvardintos kitos organizacijos, kurias numatoma kviesti

priežiūros darbams, numatomas biudžetas ir skiriama tam reikalinga įranga ir

resursai. Bet kuriuo atveju PĮ gyvavimo ciklo kainos įvertinime turi būti

priežiūros išlaidos.

Priežiūros proceso išlaidos susideda iš mokymo, priežiūros priemonių

sukūrimo (jei reikia), licencijų ir priežiūros kainų.

Mokymo kaina. Šiai kainai nustatyti įvertinamas žmonių kiekis, kuriuos

reikės mokyti. Tai tiesioginiai PĮ naudotojai, administratoriai, operatoriai.

Įtraukiamos mokytojų darbo apmokėjimo, sunaudotų medžiagų ir mokinių

išlaikymo išlaidos.

Priežiūros priemonių sukūrimo kaina. Ši kaina dažniausiai nurodoma PĮ

tiekėjo (kūrėjo) kainos pasiūlyme. Į ją nereikėtų pamiršti įtraukti šių priemonių

priežiūros, licencijų atnaujinimo, patalpų, jei šiems tikslams jos nuomojamos,

kainų.

Priežiūros kaina. PĮ kūrimo kaina sudaro tik apie 30% visos PĮ gyvavimo

ciklo kainos, o PĮ priežiūros per eilę metų kaina sudaro likusius 70 %. Priežiūra

nėra vien tik PĮ naudojimo metu pastebėtų klaidų taisymas. Tai ir PĮ tobulinimas,

atsiradus naujiems reikalavimams arba siekiant efektyvesnio jos darbo. Faktiškai,

pastebėtų klaidų taisymas sudaro tik penktadalį visų priežiūros darbų. Yra

keletas būdų priežiūros kainai įvertinti. Štai jie:

- pirmas būdas, imant tam tikrą procentą nuo PĮ kūrėjų kiekio. Visuotinai

pripažinta, kad PĮ priežiūrėtojų kiekis turėtų sudaryti 20-50% PĮ kūrėjų

kiekio. Jei 20 žmonių dalyvavo kuriant PĮ, jai prižiūrėti reikės 4-10

žmonių. Natūralu, tai keičiama pinigine išraiska. Pasirinkus apatinę

kainą, iš darbuotojų galima tikėtis tik minimalaus klaidų taisymo ir

minimalių patobulinimų atlikimo. Viršutinė kaina leistų daryti aukštesnio

lygio patobulinimus ir turėti geresnes priežiūros priemones. Nereikėtų

pamiršti, kad priežiūros priemonėms išlaikyti taip pat reikalingi resursai;

- antras būdas, kai naudojama 30% / 70% taisyklė. Laikant, kad 20 PĮ

kūrusių žmonių atitinka 30% PĮ gyvavimo ciklo kainos, tai 70% ciklo

kainos atitiktų apytikriai 46 žmonės. Jei priežiūros periodas yra 10 metų,

tai tam reikėtų 5 žmonių. Matome, kad šis greitas ir grubus būdas duoda

panašius rezultatus kaip ir pirmas būdas;

- trečias būdas pasikliauja labiau moksliškais vertinimo metodais, kur

priežiūros kaina apskaičiuojama remiantis įvertintu pakeisto PĮ kodo

(pradinio teksto) dydžiu.


112

17. Įsigijimo projekto valdymas

Šiame skyriuje nagrinėjamos veiklos, kurias PĮ įsigyjančioji organizacija

turėtų vykdyti pasirašiusi sandorį su tiekėju. Tiekėjas yra atsakingas už

techniškąsias PĮ kūrimo veiklas, nesvarbu, ar tai būtų naujos PĮ kūrimas, gatavos

PĮ tobulinimas ir pritaikymas naujiems poreikiams, ar įvairios gatavos PĮ

integravimas. Tačiau svarbiausias vaidmuo visada tenka užsakovui. PĮ įsigijimas

yra kolektyvinis procesas, ką jau ne vieną kartą esame akcentavę. Užsakovo

įsigijimo grupės nariai turi glaudžiai bendradarbiauti su tiekėju tokiais

techniškais klausimais, kaip greitas prototipų rengimas ir sprendimų priėmimas

remiantis jais, PĮ reikalavimų peržiūra, PĮ testavimas jos priėmimo metu. Šio

skyriaus akcentas yra su visu tuo susijusi valdymo veikla, kurią turi vykdyti

užsakovas. Valdymo svarba priklauso nuo įsigyjamos PĮ dydžio ir sudėtingumo.

Rizikos valdymas ir sugebėjimas adekvačiai suprasti tiekėjo atliekamus

darbus yra du pagrindiniai sandorio valdymo klausimai. Apie rizikos valdymą

rašoma kitame šios mokymo priemonės skyriuje. Čia plačiau panagrinėkime

klausimą, ką reikėtų daryti norint suprasti tiekėjo atliekamas PĮ kūrimo veiklas.

Kaip buvo minėta 1 skyriuje „PĮ ypatumai“, vienas iš dažniausių PĮ įsigijimo

projektų vadovų nusiskundimų yra tas, kad sunku susigaudyti, kiek projektas

pasistūmėjo į priekį. Šis skyrius, tikimės, padės suprasti šiuos dalykus. Čia taip

pat aptariami PĮ įsigijimo projekto eigos koregavimo veiksmai, kas turėtų būti

daroma iškilus būtinybei perstumti darbų grafiką, keičiant PĮ reikalavimus,

sprendžiant kokybės klausimus, derinant įvairių šalių interesus.

PĮ įsigijimo projekto stebėjimo būdai

Užsakovas gali naudoti trejopas PĮ įsigijimo projektų valdymo priemones:

projekto peržiūras, dokumentų peržiūras ir išmatuojamus dydžius, kaip kaina ir

darbų grafikas.

Projekto peržiūros. Jos atliekamos siekiant įvertinti projekto būseną ir iškelti

problemas (trūkumus), bet ne spręsti jas. Projekto peržiūros turėtų būti

atliekamos bendradarbiaujant, jokiu būdu ne konfrontuojant. Jos gali būti

formalios ir neformalios. Formalios projekto peržiūros yra numatomos sudaromo

sandorio darbų grafike. Jų metu tikrinama, ar projektas yra vykdomas laikantis

sutartų metrikų (žiūr. 17.1 lentelę). Šios peržiūros taip pat gali būti naudojamos

patikrinti, ar PĮ kūrimo procese tiksliai daroma tai, kas buvo siūloma (pvz., tiekėjo

pasiūlyme konkurso metu). Neformalios projekto peržiūros yra periodiškai

šaukiami techniniai pasitarimai. Juose dalyvauja tik tie, kurie yra susiję su

svarstomu klausimu.


113

Užsakovo dalyvavimas projekto peržiūrose turi būti aiškiai išdėstytas

sandoryje. Sandoryje gali būti numatyta galimybė užsakovui dalyvauti tiekėjo

atliekamose vidinėse PĮ reikalavimų, projekto ir rizikos peržiūrose. Tai gali būti

naudinga palaikant kolektyvinio darbo atmosferą. Kitokiu atveju, tiekėjui

rengiant grynai vidinius pasitarimus ir nekviečiant užsakovo, gali būti patiriamos

išlaidos, bet negaunama rezultatų.

Dokumentų peržiūros. Jos taip pat yra dviejų tipų. Formalioji dokumentų

peržiūra gali būti kaip projekto etapo pabaiga. PĮ reikalavimų dokumento

peržiūra yra vienas iš formalios dokumentų peržiūros pavyzdžių. Kitas pavyzdys,

kuris gali būti siejamas su kitu projekto etapu, yra projektavimo dokumentų

peržiūra.

Neformali dokumentų peržiūra – tai tiekėjo atliekama jo vidiniam

naudojimui skirtų dokumentų peržiūra. Tokių dokumentų pristatyti užsakovui

nereikia, ir jie yra tik kaip PĮ kūrimo proceso dalis, pvz., kuriamos PĮ failas. Tai

neformalūs dokumentai, atsirandantys kuriant PĮ. Paprastai juos peržiūri kūrėjas,

kad būtų garantuota PĮ kokybė (kokybės užtikrinimo procesas). Peržiūros

rezultatai užrašomi, ir juos gali tikrinti užsakovas.

Planuojant dokumentų peržiūras, reikėtų turėti galvoje šiuos tris dalykus:

- prieš peržiūrą išplatinkime dokumentą visiems dalyviams, kad jie galėtų

pasirengti peržiūrai;

- formali dokumento peržiūra neturėtų būti pirmoji galimybė užsakovui

pamatyti produktą. Neformalios peržiūros turėtų vykti nuolatos ir būti

grįžtamojo ryšio tarp užsakovo ir tiekėjo priemonė. Jei galutinis produktas

gaunamas bendrų pastangų dėka, tai nebeturėtų būti siurprizų formalių

peržiūrų metu;

- neatidėkime dokumentų peržiūros į projekto pabaigą. Atsitikus taip,

netenkama galimybės ištaisyti klaidas, pastebėtas peržiūrų metu. Tokios

peržiūros yra beprasmės ir beveik visada veda prie darbų grafiko

pratęsimo.

Išmatuojamų dydžių stebėjimas. Kiekybiškai išmatuojami dydžiai (jie dar

vadinami metrikomis ) naudojami apibūdinti projekto padėčiai ir dažnai

nagrinėjami projekto peržiūrų metu. Gali būti daug įvairių metrikų.

Panagrinėkime kai kurias iš jų. Pirmosios dvi iš žemiau pateikiamų yra

naudojamos visuose sandoriuose (ne tik PĮ įsigijimo sandoriuose):

- išlaidos. Tai įprasta tiekėjų finansinių ataskaitų dalis. Užsakovas išlaidų

duomenis paprastai gauna, kai tiekėjas pateikia mokestinį pranešimą;

- darbų grafikas. Jo pavidalas gali varijuoti nuo projekto kontrolės taškų

sąrašo iki sudėtingų schemų;


114

- PĮ specifinės metrikos. 17.1 lentelėje yra išvardintos PĮ įsigijimo

projektuose dažniausiai naudojamos metrikos. Tikėtinų ir tikrųjų jų

reikšmių žymėjimas laiko bėgyje yra naudingas dalykas, ir tai yra kaip

valdymo rodiklis. Vieno valdymo rodiklio pokytis nebūtinai reiškia, kad

reikia imtis kažkokių veiksmų arba kad iškilo problema. Valdymo rodiklio

pavyzdys parodytas 17.1 pav.

Sandoriuose turėtų būti nurodomi išmatuojami dydžiai (metrikos), kurių

reikšmes reikės teikti. Nėra gerai, kai užsakovas tiksliai nurodo metrikas, kurias

turės naudoti tiekėjas. Todėl reikėtų reikalauti iš tiekėjų, kad jie pateiktų savo

naudojamas metrikas. Vieno teisingo atsakymo čia nėra, tačiau tiekėjų išdėstytos

mintys gali suteikti užsakovui žinių apie tiekėjo brandos lygį kurti PĮ. Kiti projektų stebėjimo būdai. Keletas būdų, apie kuriuos ne kartą buvo

užsiminta anksčiau, taip pat gali būti naudojami supratimui apie projekto eigą pagerinti:

- greitasis prototipų rengimas. Nagrinėjant prototipus įgyjamas supratimas, kaip PĮ galutinai atrodys ateityje; - iteracinė plėtra, pateikiant keletą didėjančios apimties PĮ variantų. Gudrybė slypi tame, kad nė viename variante nenurodoma per daug funkcijų; - nuolatinių atvirų ryšių su tiekėju palaikymas. Tai įgalina lengviau atskleisti problemas ir imtis jų sprendimo, kai tik jos atsiranda.

17.1 lentelė. PĮ metrikos (išmatuojami dydžiai)

Metrikos pavadinimas

Paaiškinimai

Kūrimo eiga Sukurtų ir planuotų sukurti PĮ vienetų ar komponentų kiekiai duotu metu. Atskiri planai sudaromi PĮ vienetams ar komponentams projektuoti, realizuoti (koduoti) ir integruoti.

Testavimo eiga Praleistų testų kiekis ir visas testų kiekis, kuris turi būti leidžiamas darbų grafike numatytu laiku. Taip pat gali būti fiksuojami išlaikytų ir neišlaikytų testų kiekiai duotu laiku. Užsilikę duomenys, kad testai vis dar nėra išlaikyti, duoda tam tikrų minčių. Jei praėjo daug laiko po pirmojo nesėkmingo testo leidimo, galima manyti, kad yra keblios problemos, kurių nesiseka išspręsti, arba trūksta būtinų resursų (gali būti, kad problema išspręsta, tik testas pakartotinai nėra leistas)

Personalas Tikrasis ir planuotas PĮ kūrėjų kiekis duotu laiku. Kita šios metrikos išraiška yra pagrindinio personalo krūvis. Tai gali būti aiškiau nei bendras krūvis, nes paprastai projekto vykdymo sklandumas priklauso nuo žmonių su reikiamais įgūdžiais ir reikiamu laiku buvimo.


115

PĮ dydis Sukurtos ir planuotos PĮ dydis duotu laiku. Kai sukurtos PĮ dydis viršija planuotąjį, reiškia, kad yra PĮ įsigijimo projekto kainos ir darbų grafiko viršijimo grėsmė. Dydis paprastai matuojamas programos eilučių kiekiu, nors kartais rekomenduojami ir kiti matavimo vienetai, kaip funkcijos, moduliai ar objektai.

Kompiuterio resursų panaudojimas

Centrinio procesoriaus, atminties įrenginių, įvesties/išvesties resursų panaudojimo procentas, lyginant su planuotais maksimaliais poreikiais. Tai parodo PĮ ir aparatinės įrangos pajėgumų atitikimo lygį. Gali praversti kontroliuojant resursų panaudojimą, kai yra riboti resursai arba yra poreikis turėti tam tikrą resursų rezervą (nenumatytiems atvejams ar plėtrai).

Iškilusios problemos ir išspręstos problemos

Iškilusių ir išspręstų problemų kiekiai duotu laiku. Naudinga žinoti, ar neišspręstų problemų kiekis laikui bėgant didėja ar mažėja (žiūr. 17.1 pav.).

Reikalavimų pastovumas

PĮ reikalavimų keitimų kiekis ir bendras reikalavimų kiekis duotu laiku. Tai patogi priemonė reikalavimų augimui valdyti. Jei naujų reikalavimų atsiranda daugiau kaip 20% bendro reikalavimų kiekio, tai yra rimtas pavojaus ženklas.

Apie subrangovus

Vienas iš sudėtingiausių įsigijimo projekto valdymo aspektų yra subrangovo

veiklų kontroliavimas. Pagrindinis tiekėjas gali sąmoningai izoliuoti užsakovą

nuo subrangovų. Tokia situacija gali būti nesėkmės priežastis, ypač jei

subrangovas yra atsakingas už kritines projekto dalis. Tačiau yra būdai tam

išvengti.

Tarkime, kad projektui valdyti pagrindinis tiekėjas turi žinoti visus galimus

projekto vykdymo subrangovus. Jo sandoriai su subrangovais turi būti sudaromi

iš anksto ir būti projekto plano dalis. Visa tai turi būti atitinkamai atspindėta

užsakovo prašyme teikti pasiūlymus (RFP) ir užsakovo sandoryje su pagrindiniu

tiekėju. Klausimai, į kuriuos prašyme teikti pasiūlymus (RFP) ir sandoryje turėtų

būti atkreiptas dėmesys, yra šie:

- ar subrangovo atstovai turi dalyvauti visose peržiūrose, ypač neformaliuose

techninių klausimų svarstymo susirinkimuose;

- reikalavimas, kad su aukščiau minėtomis metrikomis susiję subrangovo

duomenys būtų pateikiami be pakeitimų;

- reikalavimas, kad užsakovui būtų sudarytos sąlygos susipažinti su

subrangovo galimybėmis;


116

- garantavimas, kad subrangovo atstovai galės tinkamai dalyvauti visuose

testavimuose. Subrangovas turi ištestuoti jo sukurtas posistemes ir

dalyvauti visos sistemos testavimuose;

- garantavimas, kad užsakovas galės kontroliuoti subrangovo atliekamus

testavimus;

- garantavimas, kad užsakovui bus teikiami specifiniai duomenys apie

kritines (subrangovų sukurtas) posistemes, nors jie ir nenumatyti traukti į

pagrindinio tiekėjo ataskaitą.

Pastaba: čia vaizduojamos iškilusių ir išspręstų problemų kiekių kitimo kreivės. Artėjant PĮ pridavimo terminui, atstumas tarp kreivių turėtų išnykti. Deja, praktikoje ne visada taip būna.

17.1 pav. Valdymo rodiklio kaitos pavyzdys

Patrauklus būdas projekto darbų eigai stebėti (vertinti) yra pavedant tai PĮ

kūrėjų ir tiesioginių naudotojų grupėms. Bendradarbiaudamos ir šalindamos

tarpžinybinius barjerus, tokios grupės duoda gerus rezultatus.

Apskritai, subrangovų atveju taip pat reikėtų laikytis atvirų ryšių nuostatos.

Atviri ryšiai įgalina subrangovą lengviau bendrauti su užsakovu, apeinant

formalumus, kai apsikeičiant nuomonėmis reikalingas ir pagrindinio tiekėjo

pritarimas.

Korekcinių veiksmų stebėjimas

Kitas valdymo būdas yra korekcinių veiksmų (problemų šalinimo proceso)

stebėjimas. Kai tik iškyla projekto arba PĮ problemos, jos užfiksuojamos problemų

sąraše. Problemos pagal jų sunkumą (sudėtingumą) gali būti skirstomos, pvz.,

taip:

Problemų būsena ( iškilusi / išspręsta )

Problemos

Laikas

10

20

30

40

Projektavimas Kūrimas Testavimas

PĮ kūrimo eiga

iškilusios

išspręstos


117

aukščiausio sunkumo – problemos, sukeliančios PĮ avarijas;

sunkios – problemos, vedančios prie funkcionalumo sumažėjimo;

nesunkios – PĮ išlieka darbinga, bet veikia ne taip, pvz., lėčiau, nei buvo

planuota;

lengvos – dokumentų klaidos arba nereikšmingos problemos.

Problemai išspręsti turi būti numatyti veiksmai. Visų korekcinių veiksmų

gale problema turi būti išspręsta. Kadangi problemų sąrašas yra pastoviai

stebimas, tai neišspręstų problemų sunkumas ir jų kiekis yra žinomi bet kuriuo

metu.

Problemų sąrašo tvarkymas paprastai yra tiekėjo pareiga. Sandoryje reikėtų

numatyti tai, o apie problemas turėtų būti informuojama projekto peržiūrų metu.

Kaip tvarkytis su nukrypimais nuo darbų grafiko

Tarkime, jūs sėkmingai naudojate aukščiau nagrinėtus valdymo metodus,

tačiau jie rodo nukrypimą nuo darbų grafiko. Panagrinėkime hipotetinį šešių

mėnesių PĮ įsigijimo projektą, kuriame antrojo mėnesio darbus pavyksta užbaigti

tik trečiojo mėnesio gale. Ką daryti?

Yra penkios galimybės. Pirmoji, kuri yra patraukliausia, tikriausiai neduos

efekto. Antroji, matyt, taip pat neduos efekto. Likusios trys, atrodytų, yra mažiau

priimtinos, bet siūlo realius sprendimus [DoT98b]:

- 1 galimybė. Planuokime, kaip kompensuosime prarastą laiką vėliau.

Patirtis rodo, kad tai sunku padaryti; įsiskolinimas nusikelia vis toliau ir

toliau. Tokios nesėkmės priežastis yra ta, kad projekto pradžioje buvo

priimtas pernelyg optimistinis darbų grafikas. Mūsų hipotetinio pavyzdžio

darbų grafike planuotiems dviejų mėnesių darbams prireikė trijų mėnesių.

Bet, panaudojus šią pirmą galimybę, pakoreguotame grafike bus viršytos

darbų apimtys, kurios iš pradžių buvo numatytos likusiai projekto daliai.

Tai reiškia, kad planuotus paskutinių keturių mėnesių darbus reikės atlikti

per tris mėnesius.

Nežiūrint viso to, dažniausiai naudojamasi šia galimybe. Suvokus darbų

grafiko pratęsimo pavojų, natūrali ir tradicinė reakcija būna darbuotojų

kiekio padidinimas. Tuo padėtis tik pabloginama. Darbuotojų kiekio

didinimas atsilikus nuo darbų grafiko veda prie to, kad projektas nebus

užbaigtas laiku. Tai yra vienas iš patvirtinimų, kad PĮ įsigijimo projektai

skiriasi nuo kitokio tipo projektų;

- 2 galimybė. Pailginkime PĮ įsigijimo projektą trūkstamu laiku. Mūsų

hipotetiniame pavyzdyje visų vėlesnių etapų pabaigos terminai turėtų būti

atidedami vienu mėnesiu, o visas projektas turėtų būti užbaigtas po


118

septynių mėnesių (vietoje planuotų šešių). Šios galimybės rinkimosi

klaidingumas slypi tame, kad ji įvertina tik pirmą projekto darbų grafiko

dalį, ir laikoma, kad likusioji dalis yra įvertinta tiksliai. Kai kuriais atvejais

tai gali būti teisinga, bet daugeliu atvejų taip nėra;

- 3 galimybė. Viršytą laiką naudokime kaip atitinkamą daugiklį likusio

darbų grafiko laikui pakoreguoti. PĮ įsigijimo projektų vykdymo patirtis tą

patvirtina. Kadangi mūsų hipotetiniame pavyzdyje pirmiesiems darbams

atlikti vietoje planuotų dviejų mėnesių prireikė trijų mėnesių (50% viršytas

planuotas laikas), tai ir likusiems planuotiems darbams vietoje keturių

mėnesių tikėtina reikės šešių mėnesių. Visam projektui reikės devynių, o

ne šešių mėnesių;

- 4 galimybė. Sumažinkime kai kuriuos PĮ reikalavimus, kad būtų lengviau

juos įgyvendinti;

- 5 galimybė. Sumažinkime planuotą PĮ funkcionalumą. Atsisakius kai kurių

reikalavimų, išnyksta su jų įgyvendinimu susiję darbai, projektas tampa

paprastesnis.

3, 4 ir 5 galimybių naudojimas suteikia lankstumo įsigijimo projektams. 3

galimybėje lankstumas pasireiškia darant kompromisą dėl projekto trukmės, kad

būtų išsaugotas PĮ funkcionalumas. 4 ir 5 galimybėse siekiama išlaikyti

nepakeistą darbų grafiką, darant PĮ funkcionalumo kompromisą.

PĮ reikalavimų valdymas

Svarbi įsigijimo projektų valdymo dalis yra nesibaigiantis PĮ reikalavimų

tvarkymo procesas. Apie tai plačiau rašoma 9.2 skyriuje „Reikalavimų valdymas

(peržiūra, keitimas)”.

Kokybės valdymas

Projekto valdymas ir tiekėjo atliekamų veiksmų supratimas yra tik būdai

geriau pažinti įsigyjamą PĮ. Turima galvoje ne bet kokia PĮ, o naudinga ir

veikianti PĮ, t.y. kokybiškas produktas. 9.1 skyriuje “Reikalavimų rengimas”

nagrinėjome kai kuriuos PĮ kokybės rodiklius. Čia aptarsime kokybės valdymo

žingsnius kokybės rodikliams pasiekti.

Kokybės valdymas apima platų klausimų ratą, kad, laikantis PĮ

funkcionalumo reikalavimų, kainos ir darbų grafiko, būtų sukurtas kokybiškas

produktas. Tam būtina planuoti kokybės reikalavimus ir įtraukti juos į sandorius.

Visi turi dėti pastangas kokybei pasiekti, ne tik PĮ kūrėjai.

Kokybės valdymo sąvoka yra platesnė už kokybės užtikrinimo sąvoką.

Faktiškai ji apima ir kokybės užtikrinimą. Kokybės valdymas kaip toks atsirado


119

ne taip seniai (prieš 15-20 metų). Atsakomybė už produkto kokybę tenka visai

projektavimo organizacijai, o ne vien tik kokybės užtikrinimo padaliniui

(matavimo, kontrolės padaliniui). Kokybės užtikrinimo padalinys yra kaip akys ir

ausys, stebinčios, kad būtų vykdoma projekto kokybės užtikrinimo programa ir

būtų pasiekti šios programos tikslai.

Kokybės valdymas apima:

- produkto kokybę, ir

- produkto gamybos proceso kokybę.

Kaip siekiama produkto kokybės?

Yra trys vienas kitą papildantys požiūriai (metodai), kuriais gali vadovautis

užsakovas, siekdamas įsigyti kokybišką produktą. Priklausomai nuo įsigijimo

projekto, jais gali būti vadovaujamasi atskirai arba drauge.

Pirma, kas yra svarbiausia, kokybės reikalavimai turi būti specifikuoti

(išdėstyti) PĮ reikalavimų dokumente arba darbo užduotyje (žiūr. 9.1 skyriaus

“Reikalavimų rengimas“ poskyrį Kokybės rodikliai). Užsakovo įsigijimo projekto

darbo grupė turi nuspręsti, kas yra svarbiausia, ir nustatyti prioritetus.

Išmatuojamuose kokybės rodikliuose, kaip, pvz., veiksnumas (availability), turi

būti išdėstyti PĮ veikimo reikalavimai. Sunkiau išmatuojamuose rodikliuose, kaip,

pvz., kilnojamumas (portability), darbo grupė gali apibrėžti jų prasmę, prioritetą ir

kaip jie bus vertinami kūrėjo parengtame PĮ projekte.

Antrojo požiūrio esmė yra tokia. Užsakovas turi įsitikinti, kad tiekėjo (kūrėjo)

organizacijoje yra įdiegta kokybės užtikrinimo programa (kitur – kokybės

valdymo sistema), ir nustatyti, kaip ji bus taikoma PĮ įsigijimo projekte. Efektyvus

būdas tą padaryti yra reikalauti darbo užduotyje, kad kūrėjas įsidiegtų PĮ kokybės

užtikrinimo programą ir pateiktų ją peržiūrėti užsakovui. Taip pat reikia

reikalauti iš kūrėjo pažymos, kad jo PĮ kokybės užtikrinimo programa yra

sėkmingai praėjusi atitinkamos profesionalios įstaigos auditą (patikrinimą).

Kūrėjo turimos audito pažymos lygis turi atitikti įsigijimo projekto lygį. PĮ kūrimo

procese užsakovas turi stebėti kokybės užtikrinimo programą, ar ji yra vykdoma,

ir vertinti jos efektyvumą.

Trečias požiūris reikalauja, kad darbo užduotyje būtų numatytas

nepriklausomas PĮ įsigijimo projekto darbų vertinimas (tikrinimas ir

patvirtinimas). Paprastai nepriklausomą vertinimą atlieka nuo kūrėjo (tiekėjo)

aiškiai nepriklausoma ir su juo bendrais interesais nesusaistyta organizacija.

Tačiau nepriklausomą vertinimą gali atlikti ir kūrėjo organizacijos specialistai,

nedalyvaujantys projekte. Paprastai projekto vadovams jie prisistato kaip

nepriklausomi, už projekto vykdymą neatsakingi specialistai.


120

Kaip įsitikinama, kad kūrėjas turi PĮ kokybės užtikrinimo programą, kuri

prisidėtų prie produkto kokybės?

Kokybiškas kūrimo procesas yra pagrindinė sąlyga kokybiškam produktui

gauti. Tai ypač akcentuojama PĮ kūrimo brandos modelyje (SW-CMM - Software

Capability Maturity Model) [SA-CMM02]. Šio modelio naudojimas yra vienas iš

būdų, kaip PĮ kūrimo organizacija gali pasiekti aukštos darbų kokybės.

Tiekėjo organizacija, savo viduje nepertraukiamai vykdanti PĮ kūrimo

procesų tobulinimo programą, yra geriau pasirengusi darbui. Įsigyjančioji

organizacija geriau vertina tuos numatomus kūrėjus (tiekėjus), kurie turi ir

pademonstruoja tokią programą. Tačiau nepertraukiamas procesų tobulinimas

yra brangus dalykas ir reikalauja papildomų išlaidų. Į tokius patobulinimus

investuojantis tiekėjas tikisi susigražinti išlaidas kokiu nors būdu, dėl ko jo

paslaugų kainos būna didesnės. Jei užsakovas nustato neaukštą kainos ribą, tai

gali būti priežastis, kodėl geriausi PĮ kūrėjai ar sistemų integruotojai atsisako

imtis siūlomo darbo. Jei fiksuotos kainos tipo sandoriuose užsakovas ir galėtų

sutikti su tiekėjo darbo našumą didinančių sąnaudų padengimu, tačiau tai

nepriimtina išlaidas padengiančiojo arba laiko ir medžiagų apmokėjimo tipų

sandoriuose. Faktiškai, pagal pastarųjų sandorių tvarką tiekėjas lyg ir būtų

baudžiamas už našesnį darbą, nes už mažesnį darbo valandų kiekį užsakovas

mokėtų mažiau. Tai dar vienas patvirtinimas, kad PĮ įsigijimo projektai skiriasi

nuo kitokio tipo projektų.

Lūkesčių valdymas

PĮ įsigijimo projektų patirtis rodo, kad taip pat svarbu yra valdyti

įsigyjančiosios organizacijos kitų darbuotojų, tiesiogiai nedalyvaujančių įsigijimo

projekte, lūkesčius. Tai taikoma visiems darbuotojams (akcininkams) ir

aukščiausiajai organizacijos vadovybei. Pavojus slypi tame, kad sėkmingai

įvykdytas projektas vis dėlto gali būti laikomas nesėkmingu, nes jis neatitinka

pernelyg optimistinių lūkesčių. Klaidingų lūkesčių tikimybei sumažinti

neduokime nepagrįstų pažadų: nepagrįstai trumpo darbų grafiko bei didelio PĮ

funkcionalumo, kurio negalėtumėte realizuoti.

Nepagrįsti lūkesčiai gali atsirasti ne tik dėl už projekto vykdymą atsakingų

asmenų atvirų veiksmų. Yra natūralus kitų asmenų polinkis susikurti „rožines

iliuzijas“, kad projektas duos daugiau, nei buvo numatyta. Taigi, pastoviai reikia

stebėti, ar neatsiranda tokių apraiškų PĮ įsigyjančiojoje organizacijoje. Jei taip

yra, neatidėliodami imkimės žingsnių kitų asmenų klaidingai sampratai apie

projekto rezultatus ištaisyti.


121

18. PĮ konfigūracijos valdymas

Konfigūracijos valdymo disciplina yra gyvybiškai svarbi bet kuriai PĮ.

Konfigūracijos valdymas – tai kompleksinis procesas, apimantis visų PĮ

pakeitimų įvardinimą, dokumentavimą, valdymą, įvertinimą, kontroliavimą ir

patvirtinimą PĮ gyvavimo ciklo metu. Informacija apie PĮ pakeitimus perduodama

daugiau kaip vienam asmeniui ar organizacijai.

Ekspertai PĮ konfigūracijos valdymą laiko viena iš svarbiausių veiklų, kuri

yra paplitusi ir turi esminį poveikį bet kurios didelės PĮ įsigijimui. Už PĮ

konfigūracijos valdymą visų pirma yra atsakingas PĮ kūrėjas (tiekėjas). Čia mes

daugiau akcentuosime užsakovo vaidmenį.

Kas yra konfigūracijos valdymas?

Prieš aiškindami PĮ konfigūracijos valdymą, visų pirma apibrėžkime projekto

etapo „pradinio taško“ (baseline) sąvoką. Pradinis taškas yra PĮ momentinė būklė

nustatytu laiko momentu. Jis yra būsimų darbų kontrolės pagrindas. Kadangi PĮ

reikalavimai yra labai svarbi įsigijimo projekto dalis, tai jie visų pirma užrašomi

formaliame PĮ konfigūracijos valdymo dokumente. Visi kiti su PĮ susiję dalykai

taip pat yra pradinio taško elementai. Tai pačios programos (jų pradiniai tekstai ir

objektiniai kodai), techniniai dokumentai, testavimo variantai, pranešimai apie

iškilusias problemas ir jų padėtį bei visa kita, kas susiję su PĮ kūrimu. Pradinis

taškas nėra kažkas abstraktaus; mes turime turėti galimybes fiziškai pasinaudoti

visu elementų rinkiniu, sudarančiu bet kurį sutartą pradinį tašką.

Kai kuriuose projekto etapuose nustatomi nauji pradiniai taškai, kurį laiką

išsaugojant ir senuosius. Bet kurie po to sekantys pakeitimai daromi jau naujam

pradiniam taškui, o senieji daugiau nebenaudojami. Tačiau bet kuriuo laiko

momentu yra galimybė grįžti prie buvusio pradinio taško ir atstatyti buvusią

padėtį.

Pradinis taškas atspindi tai, ką turime ir ką žinome apie PĮ duotu laiko

momentu. PĮ reikalavimų analizės fazėje, kai dar neturime nei projekto, nei

programų kodų, PĮ reikalavimai yra pradinis taškas. Kai parengiame PĮ projektą,

jis drauge su PĮ reikalavimais (dabar jau išdėstytais projekte) tampa kitu pradiniu

tašku. Kai sukuriamos programos (jų kodai), tai PĮ reikalavimai, PĮ projektas,

programų kodai ir visa kita, ko reikia PĮ palaikyti, tampa dar kitu pradiniu tašku.

Pradinis taškas savo esme rodo, kad jį sudarantys elementai yra suderinti

vienas su kitu. Pvz., PĮ projektas atitinka pradinį PĮ reikalavimų rinkinį, o

programų kodai atitinka PĮ projektą. Juk vienas iš PĮ projekto peržiūros tikslų yra

patikrinti, ar visi PĮ reikalavimai realizuoti projekte. Pradinio taško bet kurio


122

elemento pakeitimai turi būti atspindėti ir visuose kituose to pradinio taško

elementuose, kad išliktų elementų suderinamumas. Tai yra PĮ konfigūracijos

valdymo esmė.

Kadangi PĮ konfigūracijos valdymas turi glaudų ryšį su pakeitimais

pradiniuose taškuose, todėl jis kartais dar vadinamas PĮ pakeitimų valdymu.

Pakeitimams kontroliuoti jie turi būti fiksuojami dokumentuose, o visi

pradinio taško pakeitimai turi būti patvirtinti. Pakeitimai daromi esant abiejų

šalių - užsakovo ir tiekėjo - sutarimui. Jei dėl keitimo šalys nesutaria, tai priimant

sprendimą lemia užsakovo žodis.

Kas atsitinka, jei PĮ konfigūracija nėra valdoma?

Nesant tinkamo konfigūracijos valdymo, PĮ kūrimas sutrinka greitai,

išsiderina įvairūs dalykai ir darbai. Tipiniai prasto PĮ konfigūracijos valdymo

simptomai yra šie:

- negalima rasti programos pradinio teksto (source code) paskutinės versijos;

- ankstesnėje PĮ versijoje ištaisytos klaidos pasirodo vėl;

- tiekėjo atstovai nežino, iš kurių modulių sudaryta PĮ buvo pateikta

užsakovui;

- programuotojai dirba su sena programos kodo versija;

- testuojama sena programos kodo versija;

- sunku atsekti ryšį arba jo iš viso nebėra tarp reikalavimų, dokumentų ir

programos kodo.

PĮ konfigūracijos valdymo žingsniai

Žemiau supaprastintai pateikiami kai kurie PĮ konfigūracijos valdymo

žingsniai:

- PĮ konfigūracijos valdymo plano rengimas ir tvirtinimas;

- PĮ komponentų, perduodamų konfigūracijos valdymo žiniai, įvardinimas;

- komponentų sunumeravimas ar kitoks pažymėjimas;

- pradinio taško, apimančio visų komponentų visus elementus, padėties

kitimo priežiūra (konfigūracijos valdymas);

- buvusio pradinio taško kopijos priežiūra. Bet kuriuo metu turime turėti

galimybę grįžti atgal ir patikimai atstatyti buvusį PĮ pradinį tašką

(konfigūracijos valdymas);

- patvirtinimų gavimas prieš darant pradinio taško pakeitimus. Darykime

pakeitimus laikydamiesi darbų plano ir registruokime juos dokumente

(pakeitimų kontrolė);


123

- tikrinimas, ar PĮ reikalavimai, projektas, programos kodas, testavimo

variantai, kt. atitinka vienas kitą pagal jų seką, ypač kai ateina PĮ diegimo

laikas (konfigūracijos auditas).

Atsakomybė už PĮ konfigūracijos valdymą

Už PĮ konfigūracijos valdymą, pradinių taškų nustatymą ir šios veiklos

kontrolę visų pirma yra atsakingas kūrėjas (tiekėjas). Tačiau užsakovas taip pat

yra atsakingas už kai kuriuos dalykus. Jis privalo:

- reikalauti iš PĮ kūrėjo, kad jis vykdytų konfigūracijos valdymo procesą ir

aprašytų šį procesą konfigūracijos valdymo plane;

- peržiūrėti ir patvirtinti konfigūracijos valdymo planą;

- tikrinti, ar konfigūracijos valdymo planas yra vykdomas;

- spręsti, kokie pradiniai taškai turi būti nustatyti ir kaip jie turi būti

valdomi. Gali būti sudaryta, pvz., Konfigūracijos kontrolės komisija

konfigūracijos valdymo procesui prižiūrėti;

- kontroliuoti sąsajas tarp skirtingų tiekėjų produktų, kurie privalės

sąveikauti tarpusavyje.

Jei PĮ reikalavimai parengiami iki prašymo teikti pasiūlymus (RFP)

paskelbimo, natūralu, kad užsakovas yra atsakingas už PĮ reikalavimų pradinio

taško nustatymą.

Užduodant tiekėjui 18.1 lentelėje surašytus klausimus, galima sužinoti, ar

tiekėjo PĮ konfigūracijos valdymo procesas yra adekvatus užsakovo įsigyjamai PĮ.

18.1 lentelė. Klausimai, padedantys nustatyti, ar tiekėjo PĮ konfigūracijos

valdymas yra adekvatus užsakovo įsigyjamai PĮ

Nr. Klausimas

1. Ar parengtas projekto konfigūracijos valdymo planas?

2. Ar įšvardinti komponentai (produktai), kurie turi būti perduoti konfigūracijos valdymo žiniai?

3. Ar konfigūracijos valdymo procesas yra įtrauktas į įsigijimo projekto planą ir ar jis yra natūrali šio plano dalis?

4. Ar visos konfigūracijos valdymo objektų versijos yra valdomos?

5. Ar sukurta elektroninė biblioteka pradiniams taškams saugoti ir atstatyti?

6. Ar padėties apskaitai ir konfigūracijos pasikeitimų eigai stebėti naudojami konfigūracijos valdymo instrumentai?

7. Ar visi gauti pasiūlymai ir iškeltos problemos konfigūracijai keisti yra registruojami, patvirtinami ir sekami dokumentais nustatyta tvarka?


124

8. Ar visi pradinių taškų keitimai kontroliuojami laikantis nustatytų procedūrų?

9. Ar visi pradiniai taškai periodiškai peržiūrimi ir tikrinami (audituojami), kad būtų įvertintas konfigūracijos valdymo proceso efektyvumas?

10. Ar visa konfigūracijos valdymo žinioje esanti informacija perduodama kitoms organizacijoms?

Nepersistenkime su konfigūracijos valdymu

Nors PĮ konfigūracijos valdymo stoka gali sukelti aukščiau minėtas

problemas, perdėtas konfigūracijos valdymas taip pat nėra gerai. Jei per anksti

versime tiekėją atlikti konfigūracijos valdymo procedūras, projekto eiga gali

pasidaryti lėtesnė. Pvz., ankstyvi dokumentų projektai, kurie bus dar ne kartą

peržiūrimi, neturėtų būti perduodami konfigūracijos valdymui. Kai

dokumentacija ir kiti PĮ produktai parengiami tinkamu lygiu ir gali būti pradinių

taškų elementais, tik tada gali būti atliekamos konfigūracijos valdymo

procedūros. Panašiai, jei programuotojai atlieka nedidelius testus, kad patikrintų,

kaip pasisekė sukurti kažkokią programą, arba bando duomenų bazės galimybes,

nereikalaukime, kad tokia medžiaga būtų perduota konfigūracijos kontrolei. Vis

dėlto PĮ reikalavimai ir visi nustatyti formalūs pradiniai taškai turi būti

kontroliuojami. Kūrėjas turi kontroliuoti konfigūracijos plėtrą. Kada naudoti

konfigūracijos valdymo procedūras, sprendžiama vadovaujantis sveiku protu,

turima patirtimi.


125

19. PĮ įsigijimo rizikos valdymas

Bet kokio projekto planavimas savo prigimtimi yra optimistinė veikla, nes

daroma prielaida, kad viskas vyks sklandžiai. Tačiau PĮ įsigijimo metu dažnai

iškyla nenumatytos problemos. Todėl būtina valdyti riziką (įvertinti pavojus), kad

išvengtume netikėtumų arba bent jau sumažintume problemas. Rizikos valdymas,

priešingai projekto planavimui, savo prigimtimi yra pesimistinė veikla. Tai

nesibaigiantis mokymasis iš patirties, tai vertinimas, kokie reikalai gali pakrypti

negera linkme ir kaip to galima būtų išvengti.

Rizika turi būti valdoma visą laiką, nuo projekto pradžios iki jo pabaigos.

Viso to tikslas yra įvertinti riziką (pavojus) anksčiau, kad ji nesukeltų problemų.

Tai padeda išvengti krizių, kurioms įveikti reikėtų mažinti PĮ funkcionalumą,

daryti kitokius pakeitimus arba ilginti įsigijimo projekto kalendorinį darbų planą.

Kas yra rizika? Rizika tai ne problema. Problema - tai uždavinys,

reikalaujantis tyrimo, sprendimo. Rizika - tai nepageidaujamas dalykas, kuris gali

atsitikti, bet gali ir neatsitikti. Rizika gali būti įvertinta tokiais dydžiais, kaip PĮ

kai kurių reikalavimų neįgyvendinimas, projekto kalendorinio darbų plano

terminų nukėlimas, kainos padidėjimas.

PĮ įsigijimo projektuose rizikos reikšmingumas yra kur kas didesnis nei

kitokio tipo projektų. Pvz., statybų projektuose išlaidų padidėjimo 50% rizika yra

retas atvejis. PĮ įsigijimo projektuose rizikos poveikis išlaidoms gali siekti net

kelis šimtus procentų.

Ar reikia valdyti riziką PĮ įsigijimo projekte?

Be abejo, reikia. Beveik visi PĮ kūrimo projektai yra susiję su rizika. Tačiau

rizikos valdymas ypač aktualus yra dideliuose PĮ projektuose ir būtinas kuriant

sistemas. Bet koks papildomai kuriamų ar modifikuojamų PĮ komponentų kiekio

didinimas didina ir visos PĮ sukūrimo riziką. Nesėkmei išvengti viso to reikėtų

atsisakyti. Pvz., PĮ sukūrimo rizika laikoma maža, jei joje yra ne daugiau kaip

dešimt svarbiausių komponentų (funkcijų), kurių realizavimas nuolat stebimas.

Efektyviausias rizikos sumažinimo būdas yra gatavos PĮ (COTS) pirkimas.

Šiuo atveju PĮ kūrimo rizikos dalis automatiškai atpuola, lieka tik gatavos PĮ

adaptavimo pirkėjo individualiems poreikiams rizika. Tačiau gatavos PĮ pirkimas

taip pat neapsaugo nuo visų negandų. PĮ, dirbanti su vienokia aparatine įranga ir

išoriniais įrenginiais, gali neveikti esant kitokiam aparatinės įrangos rinkiniui.

Taigi, kiekvienas PĮ įsigijimas turi riziką, ir ji turi būti valdoma kiekvieno PĮ

įsigijimo metu.


126

Rizikos valdymo žingsniai

19.1 paveikslėlyje pavaizduoti žingsniai atspindi rizikos valdymo esmę.

Pirmasis žingsnis yra rizikos įvardinimas, t.y. dalyko, kuris, jaučiama, gali

rutuliotis ne taip, kaip norima, nustatymas. Rizika gali būti dalinama į atskiras

kategorijas: techniškąją ir kalendorinio darbų plano. Jos pasireiškimo sritys

pateikiamos 19.1 lentelėje, kuri gali būti naudinga PĮ įsigijimo projektų

vadovams.

19.1 pav. Rizikos valdymo žingsniai

Rizikos analizės žingsnyje įvardinta rizika charakterizuojama atsiradimo

tikėtinumu ir poveikio svarba. Tai sunku išreikšti kiekybiškai, todėl tikėtinumas ir

poveikis dažniausiai nurodomi taip: aukštas, vidutinis arba žemas. Laikantis

tokio vertinimo, sudaroma rizikos apibūdinimo lentelė. Kaip parodyta 19.2

lentelėje, rizikos apibūdinimas gali suteikti informacijos rizikos prioritetui

nustatyti, t.y. kokiai rizikai bus skiriamas didesnis dėmesys, o kokiai mažesnis.

Tai padeda sukurti projekto rizikos strategiją. Apskritai, aukšto poveikio ir aukšto

tikėtinumo rizikai skiriamas didžiausias dėmesys. PĮ įsigijimo projektuose turi

būti skiriama kažkiek resursų rizikai sušvelninti arba PĮ reikalavimai,

kalendorinis darbų planas ir kaina turi būti atitinkamai suderinti.

Trečio žingsnio - rizikos mažinimo - metu yra nustatoma, kas turi būti

daroma su kiekviena lentelėje įvardinta rizika. Specifiniai rizikos valdymo

veiksmai ir strategijos dažniausiai skirstomi į šias kategorijas:

- rizikos vengimas. Vienas iš būdų tam pasiekti yra riziką keliančių PĮ

reikalavimų mažinimas. Pvz., rizika, kad PĮ nebus priimta, jei ji neatitinka

99% reikalavimų, gali būti pašalinta, sumažinus šį procentą iki 95%;

- pagrindinės rizikos priežasties šalinimas. Pvz., gali būti pasitelkiami

papildomi kompiuteriniai resursai, jei jų trūkumas kelia kalendorinio

darbų plano pažeidimo riziką;

- rizikos valdymas. Tai dažniausiai vyksta kaip kompromiso dėl kainos

didinimo, kalendorinio darbų plano ilginimo ar PĮ galimybių mažinimo

darymas galimos rizikos tikėtinumui sumažinti. Kaip pavyzdys galėtų būti

žinių apie sunkius PĮ veikimo atvejus gavimas, galbūt naudojant tokių

Rizikos

įvardinimas

Rizikos

analizė

Rizikos

mažinimas

Rizikos

stebėsena


127

atvejų atskleidimo algoritmą. Dar iki sandorio sudarymo galime išleisti

kažkiek lėšų PĮ realizavimo galimybėms ištirti. Taip projekto rizikos

valdymas pradedamas anksti. Kai kuriais atvejais galime kontroliuoti riziką

kitomis priemonėmis arba finansuoti alternatyvų PĮ kūrimo kelią,

lygiagretų pagrindiniam. Alternatyva gali būti panaudota kaip atsarga, kai

rizika pasitvirtina. Toks požiūris gali būti priimtinas, kai būtina pateikti

rezultatus kalendoriniame plane nustatytu laiku;

- rizikos prisiėmimas. Paprastai prisiimama žemesnio prioriteto rizika.

Paskutinis rizikos valdymo žingsnis yra rizikos stebėsena. Rizika stebima

tam, kad laikui bėgant galima būtų priimti tikslesnius sprendimus. Periodiškai

peržiūrima rizikos apibūdinimo lentelė. Ši peržiūra gali būti kaip įsigijimo

projekto normalaus peržiūros proceso dalis. Rizika vertinama iš naujo, kad būtų

nustatyta, ar pasikeitė jos atsiradimo tikėtinumas ir poveikio svarba. Ar atidėta

rizika išnyko, o gal priešingai, jos prioritetas išaugo? Ar neatsirado nauja rizika,

kurią reikėtų įtraukti į lentelę? Jei taip, grįžtama į rizikos įvardinimo žingsnį.

Rizika turi būti valdoma viso projekto bėgyje

Su rizikos valdymu tenka susidurti viso projekto bėgyje. Įvardinti riziką

pradinėse projekto fazėse yra naudinga, nes tai įgalina daryti įtaką visai įsigijimo

strategijai. Pvz., jei PĮ eksploatacinių parametrų (pvz., darbo greitaveikos) rizika

yra įvardinta, į ją gali būti atsižvelgta prieš pradedant aparatinės įrangos

pirkimus.

Renkant tiekėją (kūrėją), atkreiptinas dėmesys į tai, koks gi yra jų požiūris į

rizikos valdymą. Prašyme teikti pasiūlymus (RFP) gali būti prašoma jų išdėstyti

savo požiūrį į tai. Tiekėjai gali nenorėti išdėstyti projekto rizikos savo pasiūlyme,

tačiau jie turėtų pateikti savo požiūrį į rizikos valdymą vykdant projektą. (RFP

gali būti išnaudotas kaip priemonė informuoti tiekėjus apie užsakovo numatomą

rizikos valdymo strategiją).

Pasirašius sandorį su parinktu tiekėju, rizikos valdymas gali būti

naudojamas PĮ kūrimo rizikai stebėti ir kontroliuoti. Paprastai tai daroma

periodinėse projekto peržiūrose, kuriose rizikos svarstymas gali būti vienas iš

dienotvarkės klausimų.

Vienas iš geriausių rizikos valdymo metodų yra PĮ kokybės valdymo

programos parengimas ankstyvojoje projekto vykdymo fazėje (žiūr. Kokybės

valdymą 17 skyriuje „Įsigijimo projekto valdymas“). Į šią programą gali būti

įtraukti klausimai, turintys įtakos PĮ veikimui, kainai ir kalendoriniam darbų

planui. Kai kurie iš jų gali būti susiję su kūrimo aplinkos adekvatumu kuriamai

PĮ (įrankių rinkinys, kompiliatoriai, aparatinės įrangos pajėgumai, kt.),


128

pasirinktos programavimo kalbos tinkamumu, PĮ reikalavimų aiškumu, testavimo

ir konfigūracijos valdymo veiklų adekvatumu.

19.1 lentelė. PĮ įsigijimo rizikos sritys

Rizikos sritis

PĮ inžinerija Kūrimo aplinka Projekto apribojimai

1. Reikalavimai: a) pastovumas; b) užbaigtumas; c) aiškumas; d) pagrįstumas; e) galimumas; f) precedentas; g) mastas.

2. Projektas: a) funkcionalumas; b) sunkumas; c) sąsajos; d) našumas; e) patikrinamumas; f) aparatinės įrangos

ribojimai; g) ne kuriama, o

pagalbinė PĮ.

3. Programavimas ir testavimas:

a) galimumas; b) testavimas; c) programavimas.

4. Integravimas ir testavimas:

a) aplinka; b) produkto

integravimas; c) sistemos

integravimas.

5. Techninės detalės: a) priežiūra; b) patikimumas; c) saugumas; d) slaptumas; e) žmogiškieji

veiksniai; f) specifikacijos.

1. Kūrimo procesas: a) formalumas; b) tinkamumas; c) proceso kontrolė; d) susipažinimas; e) produkto kontrolė.

2. Kūrimo sistema: a) pajėgumas; b) tinkamumas; c) naudojimo

patogumas; d) susipažinimas; e) patikimumas; f) sistemos palaikymas; g) pristatymas.

3. Valdymo procesas: a) planavimas; b) projekto

organizavimas; c) valdymo patirtis; d) programos sąsajos.

4. Valdymas: a) stebėsena; b) žmonių valdymas; c) kokybės užtikrinimas; d) konfigūracijos

valdymas.

5. Darbo aplinka: a) dėmesys kokybei; b) bendradarbiavimas; c) ryšiai; d) moralė.

1. Resursai: a) kalendorinis

planas; b) personalas; c) biudžetas; d) patalpos.

2. Sandoris: a) sandorio tipas; b) apribojimai; c) priklausomumas.

3. Projekto sąsajos: a) užsakovas; b) susiję tiekėjai; c) subrangovai; d) pagrindinis

tiekėjas; e) kolektyvinis

valdymas; f) prekiautojai; g) politikai.


129

19.2 lentelė. Rizikos apibūdinimo lentelė

Atsiradimo tikėtinumas

Aukštas Vidutinis Žemas

Aukštas Rizika Nr. 1 Rizika Nr.3

Rizika Nr. 4 ---

Vidutinis Rizika Nr. 6 Rizika Nr. 2 Rizika Nr. 5

Rizika Nr. 7

Poveikis

Žemas Rizika Nr.8 --- ---

Rizikos valdymas – tai grupinė veikla

Geriausia, kai užsakovas ir tiekėjas riziką valdo drauge. Kad taip atsitiktų,

kiekviena pusė nepriklausomai turi sudaryti savo rizikos sąrašą, po to susėsti

drauge ir palyginti juos. Gali pasirodyti, kad pusių požiūriai į projektą yra labai

skirtingi. Tuomet, dirbant drauge, parengiamas vienas pagal prioritetus

išdėstytos rizikos rinkinys, planuojami ir atliekami aukščiau aprašyti rizikos

valdymo žingsniai. Jei laikomasi tokio požiūrio, derėtų tai išdėstyti ir prašyme

teikti pasiūlymus (RFP).

Taigi, rizikos klausimai turėtų būti svarstomi projekto pradžioje, taip darant

įtaką PĮ įsigijimo sampratai. Rizika turėtų būti valdoma viso PĮ įsigijimo projekto

metu. Rizikos valdyme pasikliaujama atvirais ryšiais ir bendradarbiavimu tarp

užsakovo ir tiekėjo. Rizikos valdymo klausimų svarstymas gali padėti lengviau

užmegzti atvirus ryšius, kurie reikalingi likusiuose projekto etapuose.

Rizikos valdymo sėkmės pagrindas yra atviri užsakovo ir tiekėjo ryšiai,

grasinimų vengimas. Taip pat kelkime sau klausimą, ar mūsų organizacijoje

cirkuliuojanti informacija ir vertinimo kriterijai padeda visiems PĮ įsigijimo

projekto dalyviams įvardinti riziką.

Aprašykime savo požiūrį į rizikos valdymą projekto plane ir prašyme teikti

pasiūlymus (RFP). Reikalaukime iš tiekėjų išreikšti savo požiūrį į rizikos

valdymą.


130

Priedai

1 priedas. Organizacijų gebėjimas vykdyti PĮ įsigijimo projektus. SA-CMM modelis

Kiekviena organizacija yra suinteresuota sėkminga PĮ įsigijimo proceso baigtimi. Tam būtina gerai žinoti galutinį tikslą ir kaip to tikslo reikėtų siekti. Be to, kelyje link tikslo daroma pažanga turėtų būti išmatuojama. PĮ įsigijimo proceso modelis SA-CMM (Software Acquisition - Capability Maturity Model) [SA-CMM02] – tai gairės, kaip reikėtų vykdyti ir tobulinti šį procesą. SA-CMM yra skirtas asmenims bei organizacijoms, planuojantiems ir valdantiems įsigijimo projektus. Organizacijos gali naudoti SA-CMM modelį kaip priemonę, vertindamos savo sugebėjimą vykdyti PĮ įsigijimo projektus.

Organizacijos gebėjimas vykdyti PĮ įsigijimo projektus – tai sugebėjimas sklandžiai ir efektyviai valdyti PĮ įsigijimo procesą. Kokybiškas įsigijimo procesas yra toks, kai:

- įsigytos PĮ kokybė atitinka organizacijos poreikius, t.y. kai PĮ yra pajėgi reikalaujamu būdu (pvz., greitai, saugiai) atlikti visas numatytas funkcijas;

- įsigijimui sugaištas laikas neviršija nustatyto laikotarpio; - įsigijimui sunaudotos lėšos neviršija numatytos sumos.

Organizacijos gebėjimų vertinimas grindžiamas trimis procesų valdymo aksiomomis: - kas neapibrėžta, negali būti kontroliuojama; - kas nekontroliuojama, negali būti išmatuota; - kas neišmatuojama, negali būti tobulinama. Remiantis jomis SA-CMM modelyje skiriami penki organizacijų gebėjimo lygiai, kur aukštesnieji yra paremti žemesniaisiais. Dauguma organizacijų pirmuosius savo PĮ įsigijimus atlieka žemiausiu, 1-uoju gebėjimų lygiu. Šie penki gebėjimų (įgūdžių) lygiai SA-CMM modelyje charakterizuojami taip: 1 lygis – pradinis. Šis gebėjimų lygis rodo, kad kiekvienas įsigijimas organizacijoje vykdomas kaip specialus vienkartinis procesas. Dažnai tai daroma chaotiškai, neorganizuotai, neturint jokių formalių planų ar taisyklių. Veiklos yra neapibrėžtos ir nekontroliuojamos. 2 lygis – kartojamasis. Kiekvienam PĮ įsigijimo projektui valdyti organizacija rengia planą, laikantis kurio atliekamos visos įsigijimo veiklos. Šiuo atveju organizacijoje jau yra nusistovėjusi tam tikra PĮ įsigijimų praktika bei tradicijos. Tačiau susiklosčiusios taisyklės nėra aprašytos, todėl pasikeitus darbuotojams jos kuriamos iš naujo, nes PĮ įsigijimo proceso veiklos nėra apibrėžtos.


131

3 lygis – apibrėžtasis. PĮ įsigijimo procesas yra apibrėžtas ir standartizuotas. Visi įsigijimo projektai organizacijoje atliekami nustatyta tvarka (laikantis standarto). Įsigijimo proceso veiklos yra apibrėžtos ir kontroliuojamos. Tačiau informacija apie nustatytos tvarkos ir atliekamų veiklų efektyvumą nėra renkama. 4 lygis – kiekybiškasis. Įsigijimo proceso metu organizacija renka įvairius rodiklius. Įsigijimo procesas yra valdomas stebint kiekybinius ir kokybinius rodiklius. Veiklos yra ne tik apibrėžtos, bet ir jų efektyvumas kontroliuojamas naudojant įvairius rodiklius. 5 lygis – opimizuojantysis. Įsigijimo procesas yra nuolatos tobulinamas, išnaudojant matuojamus kiekybinius rodiklius kaip grįžtamąjį ryšį. P1 lentelėje parodyta kiekvienam SA-CMM modelio lygiui būdingos pagrindinės veiklos. Savo ruožtu kiekviena pagrindinė veikla turi savo tikslus ir veiksmų seką, kuri įgalina pasiekti tuos tikslus. Pvz., 2-ą lygį atitinkanti organizacija turi gebėti atlikti tokias veiklas, kaip „PĮ reikalavimų rengimas ir jų valdymas“ ar „sandorio vykdymo priežiūra“. 2-o lygio veiklos sudaro įsigijimo proceso pagrindą. Šio lygio gebėjimo visiškai pakanka daugeliui organizacijų.

P1 lentelė. Organizacijų gebėjimo vykdyti PĮ įsigijimo projektus modelis (SA-CMM)

Gebėjimo lygis Akcentas (esmė) Pagrindinės veiklos

1 lygis, Pradinis

Kompetentingų ir iniciatyvių žmonių veikla

2 lygis, Kartojamasis

Įsigijimo proceso valdymo pagrindai

- PĮ įsigijimo planavimas; - žvalgymasis, klausinėjimas dėl PĮ; - PĮ reikalavimų rengimas ir valdymas; - projekto valdymas; - sandorio vykdymo priežiūra; - įsigyjamos PĮ įvertinimas, testavimas; - PĮ priežiūros perėmimas.

3 lygis, Apibrėžtasis

Įsigijimo proceso standartizavimas

- proceso apibrėžimas ir priežiūra; - projekto vykdymo valdymas; - sandorio vykdymo valdymas; - įsigijimo projekto rizikos valdymas; - mokymas.

4 lygis, Kiekybiškasis

Įsigijimo proceso valdymas, remiantis kiekybiniais rodikliais

- kiekybinis procesų valdymas; - kiekybinis įsigijimo valdymas.

5 lygis, Optimizuojantysis

Nepertraukiamas įsigijimo proceso tobulinimas

- nepertraukiamas įsigijimo proceso tobulinimas; - įsigijimo inovacijų valdymas.


132

Laikoma, kad organizacija atitinka kažkurį SA-CMM modelio gebėjimo lygį, jei ji sugeba atlikti visas tam lygiui priklausančias veiklas ir visų žemesnių lygių veiklas. Gebėjimo lygis yra siejamas su organizacijos gebėjimu vykdyti PĮ įsigijimo projektus. Apskritai, daugiau sugebančios organizacijos turi geresnes perspektyvas.

Kaip SA-CMM modelis gali būti panaudotas įsigyjant PĮ

Realiam gyvenime dauguma organizacijų savo daugiametėje praktikoje tikriausiai nenaudoja SA-CMM modelio PĮ įsigijimo procesams tobulinti. Aukštesniu lygiu įsigijimus atlieka tos organizacijos, kurioms laikas nuo laiko tenka įsigyti didesnės svarbos ir apimties PĮ. Smulkesnėms organizacijoms, susiduriančioms tik su vienkartiniais įsigijimo projektais labiausiai priimtinas yra 2-asis lygis (kartojamasis). SA-CMM modelį jos visų pirma gali panaudoti savo sugėbėjimams vykdyti PĮ įsigijimo projektus įvertinti, savo silpnosioms ir stipriosioms pusėms įvardinti. Vertinimo rezultatai tuomet gali duoti pagrindą gebėjimams tobulinti. Naudojant SA-CMM modelį minėtu tikslu, reikėtų nepamiršti, kad jis pradžioje buvo sukurtas organizacijoms, dažnai susiduriančioms su didesnės svarbos ir brangios PĮ įsigijimais. Taigi, jis gali būti per daug formalus daugeliui paprastesnių PĮ įsigijimų. Pvz., SA-CMM siūlo PĮ įsigijimo projekte parengti darbuotojų mokymo planą, atitinkantį visas mokymo procedūras. Tai jau gali būti traktuojama kaip perlenkimas. Jeigu išnaudosime SA-CMM modelio esmę, ypač veiklas, bet atsisakysime kai kurių dalykų, pvz., organizacijos gebėjimo vykdyti įsigijimo projektus lygio vertinimo, ir netraktuosime modelio kaip standarto, tai jis gali būti mums labai naudingas. Mažiems įsigijimo projektams SA-CMM modelis gali būti supaprastintas praleidžiant mums nereikalingas dalis, paimant tik tai, kas tinka. Pvz., SA-CMM modelis siūlo rengti eilę valdymo planų ir nurodo veiklas, kurios turėtų būti apibrėžtos tuose planuose. Stambios PĮ įsigijimo projekte toks planas gali užimti daug puslapių, o mažos – tik vieną ar du puslapius. Kai kurioms veikloms, apskritai, gali būti atsisakoma rengti formalius planus. Toks sprendimas priimamas atsižvelgiant į tai, kokias veiklas mes galime atlikti patys savo organizacijoje, kokioms reikalingi sandoriai su paslaugų tiekėjais, kokios mūsų konkrečiame projekte yra nereikalingos. Taip pat pagrindinės SA-CMM modelio veiklos gali būti pertvarkomos taip, kad geriausiai atitiktų mūsų PĮ įsigijimo projektą. Gali būti įterpiamos naujos veiklos, atsisakoma nereikalingų arba jos modifikuojamos taip, kad tiktų geriausiai. SA-CMM modelis gali būti naudojamas kaip gairės įsigijimo procesui tobulinti. Gebėjimo lygiai gali būti kaip siekiamas tikslas. Pvz., norime, kad mūsų organizacija gebėtų vykdyti įsigijimo projektus 3-uoju lygiu. Pagrindinės šio lygio veiklos nurodo tolesnius tikslus, kuriuos norima pasiekti, veiklas (planavimą, apklausas, tiekėjų priežiūrą, kt.), kurias reikėtų tobulinti. Tačiau įsigijimo proceso


133

tobulinimas nėra lengvas reikalas. Teigiamiems rezultatams gauti reikalingos rimtos organizacinės ir vadybinės pastangos. SA-CMM modelis taip pat gali praversti nustatant organizacijų rangą (reitinguojant) pagal jų gebėjimą vykdyti PĮ įsigijimo projektus. Atkreipkime dėmesį į tai, kad SA-CMM modelis tik nurodo, ką reikėtų daryti vykdant pagrindines įsigijimo veiklas, tačiau nenurodo, kaip jos turi būti vykdomos. Modelis tik charakterizuoja veiklas, esant įvairiems gebėjimų lygiams. Kokiu būdu bus pasiektas norimas įsigijimo procesų atlikimo lygis, yra kiekvienos organizacijos reikalas. SA-CMM modelis nėra įsigijimo procesų tobulinimo metodas. Jis tik gali pagrįsti organizacijos PĮ įsigijimo gebėjimų tobulinimo patangas, ir gali būti naudojamas kaip diagnostikos arba tikslų nustatymo priemonė. Jis nenurodo žingsnių, kokius organizacijos turėtų daryti tobulindamos savo sugebėjimus.


134

2 priedas. ISO/IEC standartų nuostatos

P2.1. PĮ gyvavimo ciklas Tarptautinis PĮ gyvavimo ciklo procesų standartas ISO/IEC 12207:1995

[ISO12207] skiria penkis pagrindinius, aštuonis pagalbinius ir keturis organizacinius procesus (žiūr. P2.1 lentelę).

P2.1 lentelė. PĮ gyvavimo ciklo procesai

Pagrindiniai procesai Pagalbiniai procesai Organizaciniai procesai

1. Įsigijimas. 2. Tiekimas. 3. Kūrimas. 4. Eksploatavimas. 5. Priežiūra

1. Dokumentavimas. 2. Valdymo (kontrolės) schemos ir procedūrų nustatymas.

3. Kokybės užtikrinimo būdų ir procedūrų nustatymas.

4. Atitikties reikalavimams, kontrolės būdų, sąlygų tikrinimas.

5. Testavimas, atitikties reikalavimams patvirtinimas.

6. PĮ peržiūra, dalyvaujant užsakovui ir tiekėjui.

7. PĮ atitikimo dokumentams, testavimo rezultatų, dokumentų ir kito tikrinimas.

8. Trūkumų įvardinimas ir šalinimas.

1. Valdymas. 2. Infrastruktūros rengimas.

3. Įrangos tobulinimas. 4. Žmogiškųjų išteklių rengimas.

Pagrindiniai procesai yra sietini su atitinkamomis veikiančiųjų asmenų grupėmis: PĮ įsigyjančiąja organizacija, PĮ kūrėjais, tiekėjais, prekiautojais, eksploatuotojais, prižiūrėtojais.

Pagalbiniai procesai (nebūtinai visi, o tik atitinkantys paskirtį ir poreikį) sutinkami kiekviename pagrindiniame procese.

Organizaciniai procesai yra neišvengiami kiekvienos PĮ gyvavimo cikle. Kiekvieno proceso darbus gerai atlikti įmanoma tik žinant galutinį tikslą ir

ko reikia šiam tikslui pasiekti, o siekiami tikslai turi būti išmatuojami.


135

P2.2. Visas PĮ įsigijimo procesas

ISO/IEC 12207:1995 standarte numatytos tokios pagrindinės veiklos, kurias turėtų atlikti PĮ įsigyjančios organizacijos: 1) įsigijimo proceso inicijavimas;

2) rengimasis viešiesiems pirkimams; 3) tiekėjo išrinkimas ir sandorio sudarymas; 4) tiekėjo darbų priežiūra; 5) PĮ priėmimas ir įsigijimo proceso užbaigimas. ISO/IEC 12207:1995 standarto 2002 metų papildyme Amd.1:2002(H)

aukščiau išvardintos įsigijimo proceso pagrindinės veiklos įvardintos taip: 1) PĮ poreikio, tikslų, priėmimo kriterijų ir įsigijimo plano rengimas; 2) prašymo teikti pasiūlymus (RFP), kuriuose būtų aiškiai išdėstyti laukiami rezultatai bei užsakovo ir tiekėjo įsipareigojimai ir atsakomybė, rengimas;

3) tiekėjo išrinkimas užsakovo reikalavimus atitinkančiai PĮ teikti (kurti); 4) tiekėjo darbų priežiūra, kad būtų laikomasi PĮ kūrimo kainos, terminų ir kokybės reikalavimų;

5) PĮ priėmimas. Detalizuojant įsigijimo procesą, įsigyjančiųjų organizacijų veiklos

(subprocesai) yra šios: 1) įsigijimo bendrųjų tikslų (policy) rengimas; 2) įsigijimo strategijos (plano) rengimas; 3) įsigijimo naudos analizė (benefit analysis); 4) techninių reikalavimų rengimas; 5) teisinių ir organizacinių reikalavimų rengimas; 6) finansinių reikalavimų rengimas; 7) projekto reikalavimų rengimas; 8) kvietimo tiekėjams rengimas ir skelbimas; 9) tiekėjų kvalifikacijos vertinimas; 10) pasiūlymų vertinimas; 11) sandorio su išrinktu tiekėju sudarymas; 12) tiekėjo darbų priežiūra; 13) tiekėjo sukurtos PĮ (suteiktų paslaugų) įvertinimas ir priėmimas; 14) sandorio užbaigimas; 15) santykių su tiekėju palaikymas; 16) santykių su įsigytos PĮ naudotojais palaikymas; 17) finansinių klausimų tvarkymas.


136

P2.3. PĮ įsigijimo veiklų apibūdinimas

Įsigijimo bendrųjų tikslų (policy) rengimas Šio darbo metu formuluojami bendrieji tikslai ir poreikis PĮ įsigyti, numatomas įsigijimo būdas ir veiksmų planas įsigijimo proceso metu. Sėkmingai atlikto darbo rezultatai: 1) suformuluoti poreikiai ir bendrieji įsigijimo tikslai; 2) parinktos tinkamiausios technologijos, procesai, metodai, tiekėjai, standartai ir teisėtos reguliavimo priemonės įsigijimui optimizuoti;

3) suformuota įsigijimo specialistų grupė, turinti konkursų rengimo, sandorių sudarymo, techniškuosius, finansinius ir projektų valdymo įgūdžius;

4) apibrėžti įsigyjamos PĮ kokybės nustatymo standartai, atitinkantys įsigyjančios organizacijos poreikius;

5) nustatyti efektyvūs ir produktyvūs santykiai su PĮ tiekėju ir kitomis susijusiomis grupėmis.

Įsigijimo strategijos (plano) rengimas Įsigijimo strategija rengiama tuo tikslu, kad įsigijimo proceso eigoje jau būtų aišku (nebūtų blaškymosi), kaip turi būti siekiama įsigyjamos įrangos atitikimo organizacijos paskirčiai, tikslams ir siekiams, ir kad strategija būtų atspirties taškas planuojant visus įsigijimo projekto darbus. Šis procesas apima verslo infrastruktūrinius (biudžeto, investicijų), įrangos įsigijimo būdo (pirkti gatavą, kurti pagal užsakymą) ir bendrųjų taisyklių (įsigijimo strategijų, darbų grafiko sudarymo) klausimus. Įsigijimo strategijos kūrimo rezultatas: 1) įsigijimo proceso valdymo planas, atitinkantis įsigijimo taisykles (policy) ir įsigyjančiosios organizacijos verslo poreikius; 2) specifiniai tikslai (finansiniai, sandorio, projekto, techniniai) alternatyvių įsigijimo variantų atvejais; 3) kritiniai faktoriai, lemiantys sėkmingą įsigijimo proceso baigtį; 4) alternatyvūs įsigijimo keliai, kurie galėtų tenkinti įsigyjančiosios organizacijos poreikius ir lūkesčius; 5) verslo rizikos, finansiniai, techniniai ir resursų įverčiai alternatyvių įsigijimo variantų atvejais; 6) reikalavimai PĮ atnaujinimui.

Įsigijimo naudos analizė Šio darbo tikslas yra nepertraukiamai stebėti įsigijimo procesą tinkamumo ir naudingumo požiūriu, augant ar kintant įsigyjančiosios organizacijos reikalavimams ir verslo poreikiams. Veiklos rezultatai:


137

1) įsigijimo proceso eigos rezultatų nukrypimai nuo numatytų tarpinių rodiklių (tikslų); 2) nukrypimų poveikio įsigijimo kainai analizė.

Techninių reikalavimų rengimas Šio darbo metu turėtų būti parengti techniniai įsigyjamos PĮ reikalavimai.

Tai funkcinių ir nefunkcinių reikalavimų, apimančių visą PĮ gyvavimo ciklą, suformulavimas. Darbo rezultatai: 1) techniniai reikalavimai, įvertinantys IT aplinkos poveikį, saugumo klausimus bei atitinkantys įsigyjančiosios organizacijos poreikius ir lūkesčius; 2) esami ir numatomi ateityje įsigijimo poreikiai; 3) reikalavimai ir galimi sprendimai, taikytini kiekvienai susijusių dalyvių grupei;

4) naujų reikalavimų įtraukimo arba reikalavimų keitimo baziniame reikalavimų sąraše mechanizmas;

5) keičiamos technologijos poveikio techniniams reikalavimams įvardinimo ir pakeitimų darymo mechanizmas (tvarka);

6) reikalavimai turi atitikti atitinkamus poveikio mus supančiai aplinkai ir darbo saugos standartus (ekologijos aspektai). Techniniams reikalavimas suformuluoti gali būti naudingas ISO 1296 standartas.

Teisinių ir organizacinių reikalavimų rengimas Šio darbo tikslas yra apibrėžti PĮ įsigijimą pagrindžiančius aspektus – poreikius, teisinius pagrindus, atsakomybę ir kitus klausimus, atitinkančius nacionalinę ir tarptautinę teisę. Darbo rezultatai: 1) apibrėžtas sandorio sudarymu pagrįstas įsigijimo (viešųjų pirkimų) būdas, atitinkantis nacionalinę ir tarptautinę teisę, taisykles, nuostatas; 2) parengtos sandorio (viešųjų pirkimų) sąlygos tiekėjams įsigyjančiosios organizacijos poreikiams ir lūkesčiams įgyvendinti; 3) užsakytos PĮ priėmimo kriterijai ir trūkumų šalinimo mechanizmas sandorio sąlygoms užtikrinti; 4) apibrėžtos įsigyjančiosios organizacijos teisės tiesiogiai ar netiesiogiai įgyti, priimti sprendimus sukurtos PĮ autorinių teisių klausimais; 5) apibrėžtos garantijos ir aptarnavimo paslaugų lygis, kai to reikia; 6) apibrėžtos sąlygos tiekėjams teikti kitus (naujus) reikalavimus (pvz., keisti kokybės užtikrinimo planą, įsipareigojimus); 7) apibrėžtos nuosavybės teisės, teisės valdyti (eksploatuoti, prižiūrėti) PĮ ir kiti atsakomybės klausimai. Galutinai minėti reikalavimai nustatomi sandorio su tiekėju sudarymo metu.


138

Finansinių reikalavimų rengimas Finansinių reikalavimų PĮ įsigyti rengimo tikslas yra sukurti finansinio valdymo infrastruktūrą, užtikrinti efektyvų įsigijimo projekto finansavimą. Šio darbo rezultatai: 1) parengta finansavimo tvarka, įvertinta įsigyjančiosios organizacijos rizika ir išlaidų suma; 2) nustatyti finansavimo terminai ir sumos, turintys lemiamą poveikį įsigijimui; 3) įsigijimo projekto finansavimo tvarka (nuoseklumas) sandorio su tiekėju pasirašymo metu;

4) parengtos paraiškos įgaliotoms finansinėms institucijoms įsigijimo projekto veiklų biudžetui parengti;

5) reikalavimai tiekėjų išlaidų sąmatoms (cost reporting), laikantis sutarto (pasirinkto) išlaidų įvertinimo modelio;

6) reikalavimai mokėjimų paraiškoms, kurios turi būti rengiamos atsižvelgiant (laikantis) į sandorio duomenis ir projekto vykdymo rezultatus;

7) reikalavimų prioritetai, kurie padėtų įsigijimo procese priimti reikalavimų svarbą atitinkančius sprendimus.

Projekto reikalavimų rengimas Projekto reikalavimų rengimo tikslas – išvardinti įsigijimo projekto vykdymo reikalavimus, kad projekto tikslų būtų siekiama ir veiksmai būtų atliekami laikantis numatyto plano, reikalavimų personalui, vadovavimo, organizacinių ir kontrolės procedūrų.

Rezultatai: 1) techninių, finansinių, projekto ir sandorių neprieštaringi reikalavimai; 2) apibrėžti organizaciniai, valdymo, kontrolės ir ataskaitų teikimo

aspektai; 3) reikalavimai projekto vykdytojų grupės narių kvalifikacijai (teisinei,

sandorių, techniškajai), aiškiai apibrėžta jų atsakomybė ir siekiami tikslai; 4) apibrėžta informacija, kuria turėtų būti keičiamasi tarp visų šalių,

susijusių su projekto vykdymu; 5) reikalavimai tarpinių darbų užbaigtumui, jų priėmimui ir

atsiskaitymams už juos; 6) įvardintos su įsigijimo projekto gyvavimo ciklu ir tiekėjais susijusi rizika; 7) nuostatos nuosavybės teisių (turtinių, neturtinių) klausimais; 8) apibrėžtos įsigyjančiosios organizacijos ir tiekėjo teisės PĮ naudojimo ir

platinimo klausimais; 9) PĮ palaikymo ir priežiūros reikalavimai.


139

Kvietimo tiekėjams rengimas ir skelbimas Šio darbo tikslas yra parengti ir paskelbti kvietimą (konkursą) tiekėjams,

kuriame būtų atspindėti įsigijimo techniniai, finansiniai, projekto ir sandorio reikalavimai.

Darbo rezultatai (parengtame kvietime turi būti): 1) tiekėjų pasiūlymų rengimo ir vertinimo taisyklės, atitinkančios įsigijimo

bendrąsias taisykles (policy) ir strategiją; 2) techniniai ir kitokie reikalavimai tiekėjo kvalifikacijai ir pajėgumui,

kurie pridedami prie kvietimo; 3) sandorio užduotis ir sąlygos; 4) kainos ir apmokėjimo tvarkos reikalavimai; 5) projekto reikalavimai; 6) techniniai reikalavimai; 7) parengtas ir paskelbtas kvietimas turi atitikti įsigyjančiosios

organizacijos parengtas bendrąsias įsigijimo taisykles (policy) bei nacionalinius ir tarptautinius tesės aktus ir normas.

Tiekėjų kvalifikacijos vertinimas Šio darbo tikslas yra įvertinti ir nustatyti potencialių (paraiškas dalyvauti konkurse padavusių) tiekėjų kvalifikaciją, kad jų pasiūlymai būtų nagrinėjami toliau. Šio proceso metu vertinami tiekėjo techniniai sugebėjimai, įdiegta kokybės valdymo sistema, paslaugos, siūlomos įrangos palaikymo galimybės, kt.

Rezultatai: 1) tiekėjų kvalifikacijos vertinimo kriterijai; 2) tiekėjų pajėgumo vykdyti įsigijimo užduotį įvertinimai; 3) kvalifikacinius reikalavimus atitikusių tiekėjų, kurių pasiūlymai bus

vertinami, sąrašas; 4) bet kokių trūkumų (tiekėjo neatitikimų reikalavimams) įvertinimas; 5) įsigyjančiosios organizacijos priimtų sprendimų dėl tiekėjų tinkamumo

koregavimas.

Pasiūlymų vertinimas Šiame procese vertinami atrinktų, reikalaujamą kvalifikaciją atitikusių tiekėjų pasiūlymai (sukurti naują ir/arba parduoti gatavą PĮ), kad galima būtų pradėti derybas sandoriui sudaryti. Darbo rezultatai: 1) pasiūlymų įvertinimai, atlikti laikantis kvietime išdėstytų (konkurso) reikalavimų; 2) gatavos PĮ vertinimo kriterijai, jei tokia įranga yra pasiūlymo dalis arba visas pasiūlymas; 3) gatavos PĮ tinkamumo įsigyjančiosios organizacijos poreikiams ir lūkesčiams lygio įvertinimas;


140

4) kvietimas laimėjusio pasiūlymo tiekėjui sudaryti sandorį.

Sandorio su išrinktu tiekėju sudarymas Šio proceso tikslas yra pravesti derybas su išrinktu tiekėju ir pasirašyti sandorį, kuriame aiškiai išdėstomi tiekėjo ir įsigyjančiosios organizacijos lūkesčiai (tikslai), atsakomybė, darbo rezultatai ir įsipareigojimai. Rezultatai: 1) suderėtas, peržiūrėtas ir įsigyjančiosios organizacijos patvirtintas sandorio dokumentas, kuris pateikiamas tiekėjui(ams); 2) tiekėjo pajėgumų ir veiklos valdymo bei įvardintų rizikos faktorių mažinimo mechanizmas, kas įtraukiama į sandorio sąlygas; 3) pasirašytas sandoris.

Tiekėjo darbų priežiūra Tiekėjo darbų priežiūros tikslas yra palengvinti tiekėjo darbų derinimą su įsigijimo projekto reikalais, laikantis sandoryje nustatytų reikalavimų ir bendrųjų nuostatų.

Priežiūros rezultatai: 1) bendri įsigyjančiosios organizacijos ir tiekėjo veiksmai iškilusiems

klausimams spręsti, jei to prireikia; 2) reguliari tiekėjo informacija ir duomenys apie įsigijimo projekto eigą; 3) pakoreguota tiekėjo veikla, kad geriau atitiktų sandorio reikalavimus; 4) nutarimas dėl iškilusių klausimų ir priimti sprendimai.

Tiekėjo sukurtos PĮ įvertinimas ir priėmimas Šio proceso tikslas yra, remiantis sutartais kriterijais, patvirtinti ir priimti sukurtą PĮ. Atliekant šiuos darbus laikomasi nuostatų, padedančių eliminuoti įsigyjančiosios organizacijos ir tiekėjų veiksmų dubliavimą. Proceso rezultatai: 1) vertinimo ir/ar tikrinimo procedūros atliekamos laikantis suplanuotos ir dokumentu patvirtintos priėmimo strategijos; 2) priėmimo procedūra atliekama laikantis įsigijimo strategijos ir sutartų reikalavimų; 3) pateikta įranga vertinama laikantis sutartų reikalavimų; 4) patvirtintos garantijos, kur to reikia.

Sandorio užbaigimas Sandoris užbaigiamas pateikiant išsamią su sandorio vykdymu ir baigimu susijusią informaciją visoms sandoryje dalyvavusioms grupėms. Rezultatai: 1) atsiskaitymų baigimas ir tolesnių atsiskaitymų grafiko nustatymas; 2) konfidencialios tiekėjo ir įsigyjančiosios organizacijos informacijos grąžinimo arba įslaptinimo patvirtinimas;


141

3) apsikeitimas informacija apie įsigijimo rezultatus tarp įsigijimo proceso dalyvių; 4) įsigijimo projekto rezultatų įvertinimas sandorio, projekto, techninių ir finansinių reikalavimų požiūriais, lyginant su originaliais (pradiniais) reikalavimais ir/ar tikslais; 5) visų įsigijimo proceso dalyvių darbo apžvalga; 6) į archyvą atiduota aktuali įsigijimo proceso medžiaga, kurią galima būtų panaudoti kituose įsigijimuose arba įsigijimo procesams tobulinti.

Santykių su tiekėju palaikymas Šio proceso esmė yra gerų santykių tarp įsigyjančiosios organizacijos ir tiekėjo palaikymas paslaugų kokybės ir finansine prasmėmis. Rezultatai: 1) tinkami santykiai su tiekėju projekto metu ir turint galvoje ateities (įrangos palaikymo) poreikius; 2) apibrėžti įsigytos įrangos nuosavybės ir tarpusavio santykių koordinavimo klausimai; 3) aiškus supratimas tų tarpusavio santykių, kurie yra svarbiausi siekiant veiklos tikslų; 4) įvardinta ilgalaikė gerų tarpusavio santykių palaikymo potenciali nauda ir abipuse rizika; 5) reguliari tarpusavio santykių efektyvumo peržiūra ir santykių koregavimas.

Santykių su įsigytos įrangos naudotojais palaikymas Šio proceso esmė yra gerų santykių tarp įsigyjančiosios organizacijos ir įsigytos įrangos naudotojų palaikymas paslaugų kokybės ir finansine prasmėmis. Rezultatai: 1) nustatytos nuosavybės teisės ir tarpusavio santykių koordinavimo taisyklės; 2) aiškus supratimas tų tarpusavio santykių, kurie yra svarbiausi siekiant darbo tikslų; 3) įvardinta ilgalaikė gerų tarpusavio santykių palaikymo potenciali nauda ir abipuse rizika; 4) reguliari tarpusavio santykių efektyvumo peržiūra ir santykių koregavimas.

Finansinių reikalų tvarkymas Šio proceso tikslas yra užtikrinti, kad būtų įvardinta preliminari įsigijimo kaina ir paskirtas jam finansavimas bei išlaidos būtų daromos laikantis sutarto plano ir tikslų.

Šios veiklos rezultatai:


142

1) parengtas finansavimo planas ir tikslai; 2) parengtas ir patvirtintas biudžetas; 3) finansiniai dokumentai, atitinkantys audito reikalavimus; 4) patarimai atsakingiems asmenims realiai įsigijimo projekto kainai

nustatyti; 5) neatitikimų tarp planuotos kainos ir realių išlaidų registravimas ir

analizė; 6) atsakingų asmenų sprendimai finansavimo tikslams pasiekti.

P2.4. Įsigijimo proceso inicijavimas

Organizacijoje atsiradus PĮ poreikiui, inicijuojamas jos įsigijimo procesas. Pagal ISO/IEC 12207 standartą inicijavimo metu turi būti atliekami tokie veiksmai:

1) formuluojama PĮ (programinio produkto, su PĮ susijusios paslaugos) samprata ir pagrindžiamas jos poreikis;

2) rengiami ir nagrinėjami PĮ reikalavimai; 3) įvertinami ir patvirtinami parengti PĮ reikalavimai; 4) nagrinėjami PĮ įsigijimo būdai; 5) rengiami dokumentai ir įsigijimo proceso planas; 6) įsigyjamos įrangos priėmimo strategijos ir sąlygų apibrėžimas bei

dokumentavimas.

PĮ sampratos formulavimas ir poreikio pagrindimas Pagal ISO/IEC 12207:1995 standartą (standarto 5.1.1.4 punktas)

įsigyjančioji organizacija gali pati rengti PĮ sampratą ir poreikio pagrindimą arba samdyti paslaugų tiekėją šiam darbui atlikti.

PĮ reikalavimų rengimas ir nagrinėjimas PĮ reikalavimai turi apimti organizacijos darbinius, organizacinius,

naudotojų saugos, informacijos saugumo ir kitokius kritinius klausimus. Visa tai turi būti daroma laikantis atitinkamų projektavimo ir tikrinimo standartų ir procedūrų, nustatytų valstybės teisės aktais ir reglamentais.

Pagal ISO/IEC 12207:1995 standartą (5.1.1.4 punktas) įsigyjančioji organizacija gali pati rengti PĮ reikalavimus arba samdyti paslaugų tiekėją šiam darbui atlikti.

Parengtų PĮ reikalavimų vertinimas ir tvirtinimas Pagal ISO/ESI 12207:1995 standartą:

- jei įsigyjančioji organizacija samdo paslaugų tiekėją PĮ reikalavimams parengti, ji turi įvertinti ir patvirtinti parengtus reikalavimus (standarto 5.1.1.3 punktas);


143

- įsigyjančioji organizacija gali pati rengti PĮ reikalavimus arba samdyti paslaugų tiekėją šiam darbui atlikti (5.1.1.4 punktas);

- suformuluoti poreikiai ir reikalavimai vėliau įgyvendinami PĮ gyvavimo ciklo pagrindinio proceso „kūrimas“ metu (standarto 5.1.1.5 punktas, žiūr. P2.1 lentelę).

PĮ įsigijimo būdų nagrinėjimas Laikantis ISO/IEC 12207:1995 standarto (5.1.1.6 punkto) šiame įsigijimo

inicijavimo proceso etape nagrinėjami alternatyvūs PĮ įsigijimo būdai, vertinant juos rizikos, kainos ir naudingumo kriterijais. Galimi tokie būdai:

a) pirkimas gatavos PĮ, kuri atitinka organizacijos reikalavimus; b) PĮ (programinio produkto, su PĮ susijusių paslaugų) kūrimas

įsigyjančiosios organizacijos jėgomis; c) PĮ kūrimas įsigyjančiajai organizacijai sudarius sandorį su išrinktu

paslaugų teikėju; d) įsigijimas, derinant a, b ir c papunkčiuose išvardintus variantus; e) įsigyjančiojoje organizacijoje esamos PĮ tobulinimas. Kai nusprendžiama pirkti gatavą PĮ, įsigyjančioji organizacija turi atkreipti

dėmesį į šias sąlygas: - ar PĮ atitinka organizacijos reikalavimus; - ar yra prieinama PĮ dokumentacija; - ar tenkina PĮ nuosavybės, naudojimo, garantinės ir licencijų nuostatos; - ar numatyta PĮ priežiūra ateityje.

PĮ įsigijimo dokumentų ir veiksmų plano rengimas Dokumentuose ir plane turi būti: a) PĮ reikalavimai; b) numatomas PĮ veikimas (panaudojimas); c) sandorio su paslaugų tiekėju tipas; d) į įsigijimo procesą įtrauktų organizacijų atsakomybė; e) nuostatos, kaip bus prižiūrima PĮ; f) galimi rizikos faktoriai ir rizikos valdymo metodai.

Įsigyjamos įrangos priėmimo strategijos ir kriterijų apibrėžimas ir dokumentavimas Įsigyjančioji organizacija rengia PĮ priėmimo strategiją ir kriterijus.

P2.5. Rengimasis viešiesiems pirkimams

Rengiantis pirkimams sprendžiami žemiau išvardinti uždaviniai.

Įsigijimo (pirkimo) dokumentų rengimas Rengiamuose įsigijimo dokumentuose, priklausomai nuo pasirinkto

įsigijimo būdo, turi būti atspindėta:


144

a) įsigyjamos PĮ reikalavimai; b) siekiami tikslai; kokią organizacijos veiklos sritį apims, kam bus

naudojama PĮ c) instrukcijos kainų pasiūlymo tvarkai; d) norimos įsigyti PĮ sąrašas; e) sąlygos; PĮ pateikimo sąlygos, garantijos ir kt. f) santykiai su subrangovais (tiekėjais); g) techniniai apribojimai (pvz., aplinka, kur bus diegiama PĮ).

Tarptautinių standartų reikalavimų parinkimas Įsigyjančioji organizacija turi nurodyti tarptautinių standartų reikalavimus,

kurie taikomi įsigijimo projektams. Ypač svarbu, kad įsigyjančioji organizacija numatytų tinkamus PĮ gyvavimo ciklo pagalbinius procesus (žiūr. P2.1 lentelę), numatytų reikalavimus šiuos procesus palaikančiosioms organizacijoms, pastarųjų atsakomybę (jei PĮ prižiūrės ne jos tiekėjas). To reikia, kad tiekėjai savo rengiamuose pasiūlymuose galėtų išreikšti savo požiūrį į išvardintus pagalbinius procesus.

Kontrolės taškų nustatymas Įsigijimo dokumentuose įsigyjančioji organizacija turi nurodyti kontrolės

taškus, kada bus tikrinami tiekėjo atlikti darbai, atliekamas auditas. Tai yra susiję su atitinkamais PĮ gyvavimo ciklo pagalbiniais procesais: PĮ peržiūra, testavimu, parengtų dokumentų tikrinimu, kt.

Įsigijimo dokumentų perdavimas įsigijimo procedūrų vykdytojui Įsigyjančiosios organizacijos parengti įsigijimo dokumentai perduodami

pasirinktai įsigijimo procedūrų vykdymu besispecializuojančiai organizacijai (pvz., pirkimų agentūrai. Kai kuriose valstybėse tokios agentūros yra).

P2.6. PĮ tiekėjo išrinkimas ir sandorio sudarymas

Tiekėjo parinkimo procedūros nustatymas Įsigyjančioji organizacija turi būti nustačiusi tiekėjo parinkimo procedūrą,

o taip pat pasiūlymų vertinimo kriterijus ir kriterijų svorius.

Tiekėjo išrinkimas Įsigyjančioji organizacija išrenka priimtiniausią tiekėją, remdamasi tiekėjų

pajėgumų ir pasiūlymų įvertinimais bei kitais reikalingais faktoriais.

Kitų šalių pagalba įsigijimo procedūroms atlikti Dar iki tiekėjo išrinkimo įsigyjančioji organizacija gali pasitelkti kitas šalis,

įskaitant potencialius tiekėjus, įsigijimo projekto procedūroms atlikti. Pvz., tai gali būti organizacija, besispecializuojanti atlikti įsigijimo procedūras (pirkimo agentūra). Tačiau galutinius sprendimus turi priimti įsigyjančioji organizacija.


145

Įsigyjančioji organizacija, sudarydama sandorį, turi remtis su įsigijimais susijusių tarptautinių standartų nuostatomis.

Derybos ir sandorio sudarymas Įsigyjančioji organizacija turi pravesti derybas ir su tiekėju sudaryti tokį

sandorį, kuris atitiktų įsigijimo projekto kainos, kalendorinio darbų plano, PĮ pristatymo ar paslaugų suteikimo reikalavimus. Sandoryje turi būti atspindėti nuosavybės, naudojimo, garantijų ir licencijų, jei įsigyjama gatava PĮ, klausimai.

Sandorio sąlygų koregavimas Kai sandoris jau sudarytas, jo sąlygų pakeitimai ar papildymai priimami

derybų keliu, laikantis nustatytos tvarkos. Turi būti išnagrinėta, kokią įtaką sandorio pakeitimai turi įsigijimo tikslams, kainai, kokybei, kalendoriniam darbo planui.

P2.7. PĮ tiekėjo darbo priežiūra

Įsigijimo pagalbiniai procesai tiekėjo darbų priežiūrai Įsigyjančioji organizacija turi prižiūrėti tiekėjo atliekamus darbus

vykdydama PĮ gyvavimo ciklo pagalbinius procesus, kaip „6. PĮ peržiūra, dalyvaujant užsakovui ir tiekėjui“ bei „7. PĮ atitikimo dokumentams, testavimo rezultatų, dokumentų tikrinimas“ (žiūr. P2.1 lentelę). Esant reikalui, priežiūros metu papildomai gali tekti vykdyti pagalbinius procesus „4. Atitikties reikalavimams, kontrolės būdų, sąlygų tikrinimas“ ir „5. Testavimas, atitikties reikalavimams patvirtinimas“.

Įsigyjančiosios organizacijos ir tiekėjo bendradarbiavimas Įsigyjančioji organizacija turi bendradarbiauti su PĮ tiekėju, laiku suteikti

jam visą būtiną informaciją ir išspręsti visus iškylančius klausimus.

P2.8. PĮ priėmimas ir įsigijimo proceso užbaigimas

Pasirengimas tikrinti įsigyjamą PĮ Įsigyjančioji organizacija turi pasirengti įsigyjamos PĮ priėmimui, laikantis nustatytos priėmimo strategijos ir kriterijų. Tai apima tikrinimo objektus, tikrinimo metu reikalingus duomenis, tikrinimo procedūras ir tikrinimo aplinką. Tiekėjo dalyvavimo laipsnis tikrinimo metu turi būti apibrėžtas.

Įsigyjamos PĮ tikrinimas ir priėmimas Įsigyjančioji organizacija turi patikrinti įsigyjamą PĮ, suteiktas paslaugas ir priimti jas, jei išpildytos visos priėmimo sąlygos. Priėmimo procedūra turi būti atliekama pagal apibrėžtą įsigyjamos PĮ priėmimo strategiją ir sąlygas.


146

Atsakomybė už įsigytą PĮ Po PĮ priėmimo įsigyjančioji organizacija yra atsakinga už įsigytos PĮ konfigūracijos valdymą. Tai atitinka PĮ gyvavimo ciklo pagalbinį procesą „2. Valdymo (kontrolės) schemos ir procedūrų nustatymas“ (žiūr. P2.1 lentelę). Pastaba: įsigyjančioji organizacija gali instaliuoti PĮ ar naudoti ją pagal tiekėjo parengtas instrukcijas.


147

Santrumpos

AĮ - Aparatinė įranga;

COTS - Commercial Of The Shelf; komercinė gatava PĮ;

DBVS - Duomenų bazių valdymo sistema;

IEEE - Institute of Electrical and Electronics Engineers; elektros ir

elektronikos inžinierių institutas;

ISO/IEC - International Standardisation Organization / International

Electrotechnical Commission; tarptautinė standartizacijos

organizacija;

PĮ - Programinė įranga arba programų sistema;

RFP - Request For Proposal; prašymas teikti pasiūlymus;

SA-CMM - Software Acquisition – Capacity Maturity Model; PĮ įsigijimo

proceso modelis.


148

Šaltiniai

[DoT98a] US Department of Transportation. Federal Highway Administration.

The road to successful ITS software acquisition. Volume I: Overview and

themes. 1998, p.p. 54.

URL: www.fhwa.dot.gov/tfhrc/safety/pubs/its/architecture/rdsuccessvol1.pdf.

270 KB, 2007-04.

[DoT98b] US Department of Transportation. Federal Highway Administration.

The road to successful ITS software acquisition. Volume II: Software

acquisition process reference guide. 1998, p.p. 214.

URL: www.fhwa.dot.gov/tfhrc/safety/pubs/its/architecture/rdsuccessvol2.pdf.

857 KB, 2007-04.

[IEEE1062] IEEE Recommended Practice for Software Acquisition, IEEE Std

1062-1993. 1993

[ISO12207] ISO/IEC 12207:1995, Information technology – Software life cycle

processes. 1995.

[ISO12207H] ISO/IEC 12207:1995/Amd.1:2002, Annex H (informative),

ISO/IEC TR 15504-2, PDAM1, Reference model Extensions for the

ISO/IEC 12207:1995. 2002.

[ISO12207F] ISO/IEC 12207:1995/Amd.1:2002, Annex F (normative),

Purpose and Outcomes. 2002.

[ISO14598-4] ISO/IEC 14598-4:1999, Software engineering – product

evaluation, Part 4: Process for acquirers. 1999.

[ISO15504-2] ISO/IEC 15504-2:2003, Information technology - Process

assessment - Part 2: Performing an assessment. 2003.

[MO01] B.Craig Meyers, Patricia Oberndorf. Managing Software

Acquisition: open systems and COTS. Addison-Wesley Professional, ISBN

0201704544, 2001, p.p. 288.

[SA-CMM02] Software Acquisition Capability Maturity Model (SA-CMM)

Version 1.03. Technical report CMU/SEI-2002-TR-010, ESC-TR-2002-010.

March 2002, p.p. 134.

URL: http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr010.pdf.

437 KB, 2007-04.

[Sca02] Walt Scacchi, Open Acquisition: Combining Open Source Software

Development with System Acquisition. Final report, Institute of Software

Research University of California, Irvine, 2002.

URL: http://www.ics.uci.edu/~wscacchi/Papers/DAU/OpenAcquisition.pdf

2008 01.


149

[SMC04] Space and Missile Systems Center (SMC). Software acquisition

handbook. SMC/AXE. 2004.

URL: www.splc.net/programs/acquisition-support/publications/handbook1.pdf.

643 KB, 2007-04.

[STSC00] Software Technology Support Center. Guidelines for Successful

Acquisition and Management of Software Intensive Systems, Version 3.0,

May 2000. URL: http://www.stsc.hill.af.mil/resources/tech_docs/gsam3.html.

2007-04.


150

II dalis. PROGRAMŲ SISTEMŲ PRIEŽIŪRA

Įvadas

Programinės įrangos ar programų sistemos (toliau – PĮ) įsigijimo proceso

rezultatas yra naudotojo poreikius atitinkanti PĮ. Tačiau laikui bėgant PĮ

produktai turi būti keičiami ir plėtojamos jų galimybės, nes eksploatacijos metu

gali būti aptinkami defektai, gali keistis darbo aplinka, atsirasti nauji naudotojo

poreikiai. PĮ gyvavimo cikle priežiūros procesas eina po PĮ įdiegimo garantinio

periodo, nors kai kurios priežiūros veiklos pradedamos žymiai anksčiau.

PĮ priežiūra yra neatskiriama PĮ gyvavimo ciklo dalis. Tačiau istoriškai jai

nėra skiriama tiek dėmesio, kiek kitoms PĮ gyvavimo ciklo dalims. Dauguma

organizacijų PĮ įsigijimui skiria žymiai didesnį dėmesį nei PĮ priežiūrai. Šitokia

padėtis jau pradeda keistis, nes organizacijos, siekdamos didesnės naudos iš

įdėtų investicijų į PĮ kūrimą, stengiasi kiek įmanoma pratęsti PĮ naudojimo laiką

ir todėl priežiūrai ima skirti daugiau dėmesio. Aktyviau svarstomi pavyzdžiai, kai

vienų asmenų sukurtą PĮ prižiūri kiti.

PĮ priežiūra apibrėžiama kaip veiklų visuma, reikalinga sąnaudų požiūriu

efektyviam PĮ palaikymui. Dalis veiklų pradedama dar iki PĮ pristatymo, o dalis -

po PĮ pristatymo. Veiklas iki PĮ pristatymo sudaro planavimas šių trijų dalykų:

1) operacijų, kurias reikės vykdyti po PĮ pristatymo;

2) priežiūros patogumo;

3) įrangos pristatymo pereinamaisiais laikotarpiais.

Veiklos po PĮ pristatymo yra jos modifikavimas, darbuotojų mokymas, pagalbos

priemonių (help desk) naudojimas.

Ši mokymo medžiagos dalis parengta pagrindinai remiantis šaltiniais

[SWEBOK; ISO12207; IEEE1219]. PĮ priežiūros klausimų grupės grafiškai

pavaizduotos 1 pav. Laikantis joje nurodytos eilės, toliau dėstoma su PĮ priežiūra

susijusi medžiaga.


151

1 pav. PĮ priežiūros klausimų grupės

PĮ priežiūra

PĮ priežiūros

pagrindai

Pagrindiniai PĮ priežiūros

klausimai

Priežiūros

procesas

Priežiūros gerinimo

būdai

Apibrėžimai ir

terminai

Priežiūros

esmė

Priežiūros

poreikis

Pagrindinės

priežiūros

išlaidos

PĮ plėtotė

Priežiūros

darbų

kategorijos

Techniškieji

klausimai

Valdymo

klausimai

Priežiūros išlaidų

įvertinimas

PĮ priežiūros

įvertinimas

Priežiūros

subprocesai

Priežiūros

veiklos

PĮ

suprantamumo

gerinimas

Reinžinerija

Atvirkščioji

inžinerija


152

1. PĮ priežiūros pagrindai

Šiame skyriuje skaitytojai supažindinami su pagrindinėmis PĮ priežiūros

sąvokomis ir terminologija. Pateikiami apibrėžimai ir akcentuojamas PĮ

priežiūros poreikis. Sąvokoms suprasti didelę įtaką turi PĮ priežiūros kategorijų

suvokimas.

1.1. Apibrėžimai ir terminai

PĮ priežiūra yra apibrėžta IEEE 1219 standarte [IEEE1219]. Ji

apibūdinama kaip PĮ modifikavimas po jos pristatymo pastebėtiems trūkumams

(klaidoms) pašalinti, jos veikimo ar kitų parametrų gerinimas, adaptavimas prie

kintančios aplinkos.

PĮ gyvavimo ciklo procesus aprašančiame standarte [ISO12207] priežiūra

yra vienas iš pagrindinių procesų, kurio metu PĮ modifikuojama bei atitinkamai

koreguojama jos dokumentacija, šalinant pastebėtus trūkumus arba darant PĮ

patobulinimus. Viso to tikslas yra kiek galima ilgiau išsaugoti egzistuojančios PĮ

tinkamą veiksnumą. Tarptautinis ISO/IEC 14764 standartas [ISO14764] PĮ

priežiūrą apibūdina panašiai kaip ir ISO/IEC 12207 standartas, tik jame labiau

išryškinamos su priežiūra susijusios veiklos, kurios vykdomos dar iki PĮ

pristatymo, pvz., planavimai.

1.2. PĮ priežiūros esmė

PĮ priežiūra – tai PĮ darbingumo išlaikymas visą jos naudojimo laikotarpį.

Poreikiai modifikuoti PĮ yra registruojami ir sekami, nustatoma siūlomų

pakeitimų įtaka, keičiamas programos kodas ir kiti su PĮ susiję produktai (pvz.,

dokumentacija), atliekamas testavimas, išleidžiamos naujos PĮ versijos. Taip pat

naudotojai yra mokomi ir jiems teikiama kasdieninė pagalba. Manoma, kad PĮ

priežiūra yra platesnė veiklos sritis nei PĮ kūrimas.

Pagal ISO/IEC 12207 standartą PĮ prižiūrėtojas yra organizacija, atliekanti

PĮ priežiūros darbus. Tam tikrais atvejais juo gali būti ir atskiras asmuo.

ISO/IEC 12207 standarte įvardinamos tokios pagrindinės PĮ priežiūros

veiklos:

- priežiūros proceso įdiegimas (suorganizavimas);

- PĮ problemų (klaidų) ir modifikacijų analizė, modifikacijų atlikimas;

- priežiūros peržiūra (ar tinkamai ji atliekama);

- priežiūros perkėlimas (migracija) ir atsisakymas.

Šios veiklos nagrinėjamos 3.2 skyriuje „Priežiūros veiklos“.


153

Prižiūrėtojai gali pasimokyti iš PĮ kūrėjų. Jų kontaktai su kūrėjais ir kiek

galima ankstesnis įsitraukimas į PĮ įsigijimo projektą gali sumažinti priežiūrai

prireiksiančių pastangų lygį. Kai kuriais atvejais kūrėjo programuotojai neturėtų

būti verčiami vykdyti užduočių, kurios sukeltų papildomus rūpesčius PĮ

prižiūrėtojams. PĮ priežiūrai turi būti sukurti atitinkami produktai, programos ar

dokumentai, ir visa tai taip pat turi būti plėtojama ir prižiūrima PĮ gyvavimo ciklo

bėgyje.

1.3. Priežiūros poreikis

PĮ priežiūra reikalinga tam, kad PĮ kiek įmanoma ilgiau atitiktų naudotojo

poreikius. PĮ priežiūros eigoje turi būti atliekami tokie darbai:

- trūkumų (pastebėtų klaidų) šalinimas;

- PĮ projekto gerinimas;

- patobulinimų diegimas;

- sąsajų su kitomis sistemomis diegimas;

- PĮ pritaikymas darbui su įvairia kompiuterių aparatine ir programine bei

telekomunikacijų įranga;

- organizacijoje anksčiau turėtos PĮ perkėlimas ir naudojimas;

- nereikalingos PĮ šalinimas.

Prižiūrėtojų veikla skirstoma į šias keturias pagrindines grupes:

- kasdienė PĮ priežiūra;

- PĮ modifikavimo priežiūra;

- esamų PĮ funkcijų tobulinimas;

- PĮ atitikimo naudotojų poreikiams sumažėjimo iki nepriimtino lygio

prevencija (pvz., savalaikis naujų funkcijų įdiegimas).

1.4. Pagrindinės priežiūros išlaidos

Priežiūrai sunaudojama didžiuma viso PĮ gyvavimo ciklo finansinių

resursų. Bendrasis požiūris į PĮ priežiūrą yra toks, kad jos metu tik ieškomos ir

taisomos klaidos. Tačiau ilgamečiai stebėjimai rodo, kad apie 80 proc. priežiūros

pastangų tenka ne PĮ klaidų taisymams. Taip pat pastebėta, kad prižiūrėtojai

dažnai PĮ klaidų taisymo ir PĮ tobulinimo klausimus ataskaitose suplaka į vieną

vietą. Tai nėra gerai, nes taip galima susidaryti neteisingą nuomonę, kad klaidų

taisymui sunaudojama didžioji dalis PĮ priežiūrai skiriamų lėšų. PĮ priežiūros

darbų skaidymas į kategorijas padeda geriau suprasti priežiūros išlaidų struktūrą.

Taip pat PĮ priežiūrai įtaką turinčių veiksnių supratimas padeda sulaikyti nuo

kainų didinimo. Dažniausiai pateikiami tokie techniškieji ir netechniškieji PĮ

priežiūros kainą įtakojantys veiksniai:

- PĮ taikymo srities tipas;


154

- PĮ naujumas;

- personalo PĮ priežiūrai turėjimas;

- PĮ gyvavimo trukmė;

- aparatinės įrangos (hardware) charakteristikos;

- PĮ projekto, konstrukcijos, dokumentų, testavimo kokybė.

1.5. PĮ plėtra

Jau seniai pastebėta, kad priežiūra kartu yra ir evoliucinis PĮ kūrimo

procesas. Priežiūros metu priimamiems sprendimams įtakos turi supratimas, kas

atsitinka PĮ laikui bėgant. Kitaip dar sakoma, kad priežiūra yra PĮ kūrimo proceso

tęsinys, atsiradus papildomiems duomenims (ar apribojimams). Didelė

egzistuojanti PĮ niekada nebūna užbaigta, ji visą laiką plėtojama. Taip PĮ darosi

vis sudėtingesnė, kol nesiimama jos supaprastinimo veiksmų.

Kadangi PĮ yra pastoviai naudojama ir turi tendenciją keistis, visa tai turi

būti kažkaip išmatuojama. Mėginimai sukurti prognozės modelius priežiūros

pastangoms įvertinti davė rezultatus – buvo sukurti tam naudingi instrumentai.

1.6. Priežiūros darbų kategorijos

ISO/IEC 14764 standarte [ISO14764] apibrėžiamos keturios PĮ priežiūros

darbų kategorijos:

- klaidų taisymo. Tai PĮ keitimai, siekiant pašalinti pastebėtas klaidas;

- pritaikymo, siekiant išlaikyti PĮ tinkamumą pakitusioje arba

besikeičiančioje aplinkoje;

- tobulinimo, siekiant pagerinti PĮ darbo charakteristikas arba priežiūros

galimybes;

- prevenciniai, siekiant atskleisti nenumatytus atvejus ir atlikti

atitinkamas korekcijas, kol šie atvejai netampa rimta kliūtimi.

ISO/IEC 14764 standarte tobulinimo ir pritaikymo darbai priklauso PĮ

galimybių plėtros kategorijai. Klaidų taisymo ir prevenciniai darbai (žiūr. 1

lentelę) skiriami PĮ koregavimo darbų kategorijai. Prevenciniai darbai yra

naujausia priežiūros darbų kategorija, dažniausiai atliekama tiems PĮ

produktams, kuriems svarbios yra saugumo problemos.

1 lentelė. PĮ priežiūros darbų kategorijos

Koregavimo kategorijos darbai

Galimybių plėtros kategorijos darbai

Inicijuojamieji Prevenciniai Tobulinimo

Reaguojantieji Klaidų taisymo Pritaikymo


155

2. Pagrindiniai PĮ priežiūros klausimai

Efektyvi PĮ priežiūra įmanoma tik atliekant eilę pagrindinių veiklų. Būtina

suprasti, kad priežiūros klausimai reikalauja iš PĮ prižiūrėtojų nemažų kūrybinių

ir vadybinių pastangų. Geras tokių pastangų pavyzdys yra klaidos radimas 500

tūkst. eilučių dydžio programoje. Panašios pastangos yra ir nesibaigianti

prižiūrėtojų kova su PĮ kūrėjais, kad būtų pateiktas PĮ pradinis tekstas (resource).

Būsimų PĮ versijų planavimas, jau nekalbant apie naujos versijos PĮ

programavimą ir skubų einamosios versijos „lopymą“, taip pat kelia rūpesčių.

Šioje mokymo medžiagos dalyje pagrindiniai PĮ priežiūros klausimai grupuojami

į techniškuosius, valdymo, išlaidų vertinimo ir priežiūros vertinimo.

2.1. Techniškieji priežiūros klausimai

Žinių apie PĮ sudėtį ribotumas

Prižiūrėtojo žinios apie PĮ lemia, kaip greitai jis gali nustatyti, kur reikia

daryti PĮ pakeitimus ar pataisymus, kurios kūrime jis nėra dalyvavęs. Tyrimai

rodo, kad nuo 40 iki 60 proc. priežiūros pastangų sunaudojama tam, kol

nustatoma, ką gi reikėtų keisti. Taigi, žinios apie PĮ sudėtį yra svarbios jos

prižiūrėtojams (programuotojams). Sunkiausia yra nagrinėti PĮ pradinį tekstą

(resource). Pvz., yra sunku sekti evoliuciją, einant nuo vienos PĮ versijos prie

kitos, jei pakeitimai nėra dokumentuoti ir ko kūrėjai dažnai nebemoka paaiškinti.

Prižiūrėtojai (programuotojai) pradžioje turi ribotas žinias apie PĮ, tačiau šiam

trūkumui pašalinti būtinos pastangos.

Testavimas, padarius PĮ pakeitimus

Daugumos PĮ produktų visas pakartotinis testavimas gali pareikalauti

nemažų laiko ir lėšų sąnaudų. Tačiau priežiūros procese pakartotinis visos PĮ ar

pasirinktų atskirų jos komponentų testavimas yra būtinas, kad būtų patikrinta, ar

pakeitimai neduoda nepageidaujamo efekto. Rasti laiko testavimams dažnai būna

sunku. Taip pat sunku būna koordinuoti testavimo darbus, nes skirtingi PĮ

priežiūros grupės darbuotojai tuo pačiu metu būna užsiėmę savais rūpesčiais. Kai

PĮ vykdo kritines (svarbias, pavojingas) funkcijas, apskritai gali būti neįmanoma

atitraukti jos testavimui.

Pagal IEEE610.12-90 standartą pakartotinis (iš naujo) testavimas yra

sistemos ar komponento atrankinis (selektyvus) tikrinimas, siekiant išsiaiškinti,

ar pakeitimai nesukėlė nepageidaujamų reiškinių. Praktiškai tuo norima

įsitikinti, kad PĮ, kuri išlaikydavo testą anksčiau, ir toliau išlaiko jį. Bet kokio

testo kartojimu siekiama įsitikinti, kad PĮ veikimas nepakito, išskyrus tai, kokio


156

pakeitimo buvo reikalaujama. Žinoma, tarp testavimo rezultatų po kiekvieno

pakeitimo ir PĮ pradinio teksto, reikalaujančio taip veikti, turi būti atitikimas.

Daromų PĮ pakeitimų poveikio analizė

Egzistuojančios PĮ pakeitimų poveikio analizė turi būti daroma taip, kad

būtų sunaudojama mažiausiai lėšų. Tam prižiūrėtojai turi būti gerai susipažinę su

PĮ sudėtimi ir turiniu. Šios žinios jiems reikalingos analizuojant pageidavimus PĮ

pakeitimams daryti, kad nustatytų, kokioms sistemoms ir produktams tai turės

įtaką, ir įvertintų visas su keitimais susijusias išlaidas. Taip pat turi būti įvertinta

ir pakeitimų rizika. Pageidavimai daryti PĮ pakeitimus, kas kartais vadinama

problemų įvardinimu (iškėlimu), visų pirma turi būti išanalizuoti ir išdėstyti

kompiuterių programų terminais. Pakeitimai daromi tik po to, kai pageidavimai

daryti pakeitimus praeina PĮ konfigūracijos valdymo procesą. PĮ pakeitimų

poveikio analizės tikslai yra:

- apibrėžti pakeitimų apimtį, kad galima būtų suplanuoti ir įvykdyti šiuos

darbus;

- numatyti keitimo darbams atlikti reikalingus resursus;

- išanalizuoti pageidaujamų pakeitimų kainą ir naudą;

- informuoti kitus apie pakeitimus.

Problemos sunkumas slypi tame, kaip ir kada turi būti iškeltas PĮ keitimo

klausimas. Tik po to programuotojai gali nustatyti (įvardinti) PĮ elementus,

kuriuos reikėtų keisti. Siūloma keletas potencialių sprendimų ir

rekomenduojamas geriausias iš jų.

PĮ kūrimas numatant ir jos priežiūrą palengvina vėliau daromų PĮ

pakeitimų poveikio analizę. Daugiau informacijos šiuo klausimu galima rasti PĮ

konfigūracijos valdymą aprašančiuose skyriuose.

PĮ priežiūros patogumas

Koks indėlis PĮ priežiūros patogumui padaromas jos kūrimo metu? IEEE

610.12-90 „PĮ inžinerijos terminų standartas“ PĮ priežiūros patogumą apibrėžia

kaip lengvumą prižiūrėti, tobulinti, adaptuoti ar koreguoti PĮ, įgyvendinant

apibrėžtus reikalavimus. ISO/IEC 126-01 standartas PĮ priežiūros patogumą

traktuoja kaip vieną iš PĮ kokybės charakteristikų.

Priežiūros patogumo charakteristikos turi būti apibrėžtos, peržiūrimos ir

kontroliuojamos PĮ kūrimo metu, kad ateityje reikėtų mažesnių PĮ priežiūros

išlaidų. Jei tai pavyksta, prižiūrėti PĮ būna lengviau. Tačiau pasiekti tai dažnai

būna sunku, nes PĮ kūrimo metu priežiūros patogumas nebūna dėmesio centre.

Kūrėjai būna pasinėrę į daugelį kitų problemų ir nepaiso prižiūrėtojų

reikalavimų. Tai gali pasireikšti nepakankamo lygio PĮ dokumentacijos

parengimu, dėl ko vėliau prižiūrėtojams sunkiau suprasti PĮ ir analizuoti daromų


157

PĮ pakeitimų poveikį. Pastebėta, kad metodiškas ir kokybiškas kūrimo procesas,

tinkamai pasirinkti instrumentai padidina PĮ priežiūros patogumą.

2.2. Priežiūros valdymo klausimai

PĮ priežiūros ir organizacijos tikslų derinimas

Kiekviena organizacija siekia, kad į PĮ priežiūrą įdėtos investicijos

atsipirktų. Įprasta, kad PĮ kūrimas pradedamas pagal projektą, numatytą darbų

grafiką ir biudžetą. Akcentuojamas naudotojų poreikius atitinkančios PĮ

sukūrimas iki numatyto termino ir neviršijant biudžeto. Tačiau PĮ priežiūros

veikla dažniausiai siekiama pratęsti PĮ gyvavimo laiką kiek galima ilgiau. Be to,

laikui bėgant PĮ gali būti keičiama ir tobulinama pagal naudotojo poreikius.

Abiem šiais PĮ priežiūros atvejais investicijų atsipirkimas yra kur kas mažiau

aiškus, todėl aukšto lygmens vadovai, negalėdami įvertinti naudos organizacijai,

vengia skirti žymesnius resursus PĮ priežiūrai.

PĮ priežiūros personalas

PĮ priežiūros darbuotojų grupės suformavimas ir išlaikymas yra svarbus

klausimas. Tačiau PĮ priežiūra dažnai nėra patrauklus darbas. Atliktų apžvalgų

rezultatai rodo, kad PĮ prižiūrėtojai laikomi „antrarūšiais“ darbuotojais, dėl ko jie

patiria moralinį diskomfortą.

PĮ priežiūros procesas

PĮ priežiūros procesas yra veiklų, metodų, tvarkų ir jų transformacijų

rinkinys PĮ ar su ja susijusiems produktams prižiūrėti. PĮ priežiūros procesas ir PĮ

kūrimo procesas turi daug bendro (pvz., PĮ konfigūracijos valdymas yra svarbi

veikla abiem atvejais). Taip pat PĮ priežiūra reikalauja keleto veiklų, kurių

nesutiksime PĮ kūrimo procese. Pastarosios veiklos atspindi PĮ priežiūros

sunkumus.

PĮ priežiūros organizaciniai aspektai

Organizaciniai aspektai atspindi, kokia organizacija ir/ar jos padalinys bus

atsakinga už PĮ priežiūrą. PĮ kūrėjai toli gražu ne visada įpareigojami (imasi)

prižiūrėti PĮ eksploatavimo laikotarpiu. PĮ priežiūros funkcija gali būti perduota

su PĮ kūrėjais nesusijusiai darbuotojų grupei. Dažnai prižiūrėtojai parenkami

tam, kad užtikrintų normalų PĮ veikimą ir plėtotų ją pagal naudotojo poreikius.

Kadangi galimi įvairūs parinkimo variantai, sprendimas priimamas kiekvienu

atveju atskirai. Atsakingos už PĮ priežiūrą grupės ar asmens paskyrimas yra

svarbus organizacinis klausimas, nesvarbu, kokios struktūros organizacijoje PĮ

būtų diegiama.

PĮ prižiūrėtojų samdymas

PĮ priežiūros paslaugos darosi svarbia veiklos sritimi. Didelės organizacijos

nuomoja ištisas PĮ sistemas, įskaitant jų priežiūrą. Dažniausiai prižiūrėtojai


158

samdomi mažiau reikšmingai PĮ, nes organizacijos nenori prarasti svarbiausiems

jų reikalams naudojamos PĮ kontrolės. Kai kurios organizacijos PĮ prižiūrėtojus

samdo tik tokiais atvejais, jei galima rasti rimtus priežiūros kontrolės būdus.

Tačiau kontrolės būdus yra sunku rasti. PĮ priežiūros paslaugų tiekėjams vienas

iš didesnių sunkumų yra priežiūros darbų reikiamos apimties ir sandorio detalių

nustatymas. Manoma, kad apie 50% tiekėjų pasirašo sandorius be aiškaus PĮ

priežiūros paslaugų lygio apibrėžimo. Šių paslaugų tiekėjai iki priežiūros

sandorio sudarymo tipiniu atveju sugaišta keletą mėnesių vertindami PĮ. Kitas

sunkumas yra PĮ perdavimas priežiūros paslaugų tiekėjui.

2.3. Išlaidų PĮ priežiūrai įvertinimas

PĮ specialistai turi suprasti 1.6 skyriuje išvardintas įvairias PĮ priežiūros

darbų kategorijas, kad galėtų įvertinti PĮ priežiūrai reikalingas išlaidas. Rengiant

PĮ priežiūros planus, reikalingų sąnaudų įvertinimas yra svarbus aspektas.

Išlaidų įvertinimas

2.1 skyrelyje buvo minėta, kad, nagrinėjant PĮ pakeitimų poveikį,

įvardinamos sistemos ir PĮ produktai, kuriems įtakos turi daromi pakeitimai.

Kartu įvertinamos išlaidos tiems pakeitimams atlikti.

Pačiam išlaidų vertinimo procesui įtakos turi eilė techniškųjų ir

netechniškųjų veiksnių. ISO/IEC14764 standartas nustato du pagrindinius PĮ

priežiūrai reikalingų resursų vertinimo būdus: paremtą parametriniais modeliais

ir patirtimi. Dažniausiai naudojama šių abiejų būdų kombinacija.

Parametriniai išlaidų vertinimo modeliai

Parametriniam PĮ priežiūros išlaidų vertinimo modeliui ypač svarbu yra tai,

kad naudojant jį reikalingi anksčiau baigtų PĮ priežiūros projektų duomenys. Kai

kuriuose darbuose nagrinėjami visi išlaidų vertinimo aspektai, įskaitant funkcijas,

ir pateikiamas išsamus PĮ priežiūros išlaidų vertinimo aprašas.

Išlaidų vertinimas remiantis patirtimi

Patirtis, išreiškiama kaip ekspertų nuomonė, analogai (panašumai), darbų

organizacinė schema – tai keletas būdų papildomiems duomenims gauti iš

parametrinių modelių. Geriausias PĮ priežiūros išlaidų įvertinimo būdas, kuomet

remiamasi sukauptais empiriniais duomenimis ir patirtimi. Šie duomenys turėtų

būti gaunami kaip matavimų programos rezultatas.

2.4. PĮ priežiūros įvertinimas

PĮ priežiūros vertinimo formos ir tam reikalingi duomenų rinkiniai

nagrinėjami įvairiuose šaltiniuose. Kai kurie PĮ priežiūros matai yra bendri netgi

esant įvairiems siekiams. Tai PĮ dydis, pastangų dydis, darbų grafikas ir kokybė.

Šie matai yra geras pradinis atramos taškas PĮ prižiūrėtojams. Procesų ir


159

produktų matavimo klausimai plačiai nagrinėjami PĮ inžinerijos procesų ir PĮ

inžinerijos valdymo disciplinose.

Specifiniai priežiūros vertinimo rodikliai

Skirtingiems PĮ priežiūros būdams palyginti yra naudojamas bandymų

kelias. Prižiūrėtojas turi išsiaiškinti, kokie PĮ priežiūros vertinimo rodikliai

(measures) geriausiai tinka PĮ eksploatuojančioje organizacijoje. IEEE1219-98,

ISO9126-01 standartuose [IEEE1219; ISO9126] yra siūlomi rodikliai, kurie

daugiau būdingi PĮ priežiūros vertinimo programoms. Yra keturi pagrindiniai PĮ

priežiūros rodikliai:

- analiziškumas. Su šia charakteristika yra susiję tokie rodikliai, kaip

prižiūrėtojo pastangų dydis (darbuotojų kiekis, laikas) ir būtini resursai

(patalpos, įranga, kt.), kurių reikia PĮ trūkumams ar darbo sutrikimų

priežastims diagnozuoti arba įvardinti modifikavimo reikalaujančias PĮ

dalis;

- pakeitimų atlikimo sudėtingumas. Ši charakteristika atspindima

prižiūrėtojo pastangų dydžio, kurių reikia norint atlikti apsibrėžtus PĮ

pakeitimus, rodikliu;

- stabilumas. Jis atspindimas pastangų dydžiu nenumatytiems PĮ

veikimo atvejams išsiaiškinti, įskaitant netikėtumus testavimo metu;

- testavimo galimybės. Tai prižiūrėtojo ir naudotojų pastangų dydis

reikalingas modifikuotai PĮ patikrinti.

Tikrosios PĮ priežiūros vertinimo rodiklių reikšmės gali būti gaunamos

naudojant esamus komercinius PĮ matavimo instrumentus.


160

3. PĮ priežiūros procesas

Šio skyriaus 3.1 poskyryje „Priežiūros procesai“ pateikiamos šaltinių

nuorodos ir standartai, remiantis kuriais turėtų būti atliekama PĮ priežiūra, o 3.2

poskyryje „Priežiūros veiklos“ parodomi skirtumai tarp priežiūros ir kūrimo bei

parodomas priežiūros sąryšis su kitomis PĮ inžinerijos veiklomis. PĮ inžinerijos

procesų reikalingumas yra gerai dokumentuotas. SM-CMMI modelio [SEI01;

AAD03] taikymas PĮ priežiūrai yra panašus į SW-CMMI taikymą PĮ kūrimui ar

SA-CMM PĮ įsigijimui.

3.1. Priežiūros procesai

PĮ priežiūros procesas apima reikiamas veiklas bei šių veiklų įeities/išeities

duomenis. Tai yra aprašyta PĮ priežiūros standartuose [IEEE1219] ir [ISO14764].

IEEE 1219 standarte priežiūros pastangos pristatomos pradedant veiklomis,

kurios vykdomos po PĮ įsigijimo (įdiegimo), bei aptariami priežiūros planavimo

klausimai. Grafiškai tai pavaizduota 2 pav.

ISO/IEC14764-99 standarte PĮ priežiūros procesas yra labiau išplėtotas.

Jame priežiūros procesai yra panašūs kaip ir IEEE12219 standarte, išskyrus tai,

kad procesai yra agreguoti kitaip. Priežiūros proceso veiklos pagal ISO/IEC

standartą pavaizduotos 3 pav.

2 pav. PĮ priežiūros proceso veiklos pagal IEEE1219-98 standartą

Pakeitimų

klasifikavimas ir

identifikavimas

Analizavimas

Projektavimas

Keičiamos PĮ

kūrimas

Testavimas

Testavimo rezultatų

priėmimas

Pakeitimų

diegimas

Reikalavimas keisti


161

3 pav. PĮ priežiūros procesas pagal ISO/IEC14764-99 standartą

ISO/IEC14764-99 standarte pagrindinis PĮ priežiūros procesas dar yra

skaidomas į uždavinius, kaip: įdiegimo procesas; Iškilusių problemų ir

numatomų modifikacijų analizė; Modifikacijų diegimas; Priežiūra, modifikacijų

peržiūra/priėmimas; Perkėlimas; Panaikinimas.

3.2. Priežiūros veiklos

Kaip jau buvo minėta anksčiau, daug PĮ priežiūros veiklų yra panašios į PĮ

kūrimo veiklas. Prižiūrėtojai taip pat susiduria su analizės, projektavimo,

programavimo (kodavimo), testavimo ir dokumentavimo darbais. Jie, kaip ir PĮ

kūrėjai, savo veikloje turi laikytis PĮ reikalavimų, atnaujinti dokumentaciją, kai

tik padaromi kokie nors pakeitimai. ISO/IEC14764-99 standartas rekomenduoja

PĮ prižiūrėtojams savo darbe adaptuoti PĮ kūrimo procesus savo specifiniams

tikslams pasiekti. Tačiau kai kurios PĮ priežiūros veiklos yra unikalios.

Unikalios PĮ priežiūros veiklos

PĮ priežiūroje yra eilė unikalių procesų, veiklų ir darbų. Pavyzdžiui: - PĮ perdavimas prižiūrėtojui. Tai kontroliuojama ir koordinuota veiklų

seka, kurios metu kūrėjas palaipsniui perduoda PĮ prižiūrėtojui; - pageidavimo keisti PĮ priėmimas arba atmetimas. Prižiūrėtojas

pageidavimą keisti PĮ tam tikru požiūriu gali atmesti ir nukreipti PĮ kūrėjui;

Iškilusių problemų ir

numatomų

pakeitimų analizė

Priežiūra, pakeitimų

peržiūra/priėmimas

Pakeitimų

diegimas

PĮ perkėlimas į

kitą aplinką

PĮ

sunaikinimas

Diegimo

procesas


162

- pageidavimo keisti PĮ ir iškilusių problemų perdavimas pagalbos tarnybai. Tai pagalbos tiesioginiams naudotojams funkcija, kuri savo ruožtu iššaukia pakeitimo įvertinimą, prioritetų ir kainos nustatymą;

- pakeitimų poveikio analizė (plačiau žiūr. 2.1 skyriuje, daromų PĮ pakeitimų poveikio analizė);

- PĮ palaikymas. Tai pagalbinės informacijos ir patarimų tiesioginiams naudotojams teikimas, pvz., darbo taisyklių, patvirtinimų, duomenų prasmės, specialių užklausų/pranešimų;

- susitarimų dėl paslaugų lygio ir specializuotos priežiūros sandorių sudarymas, už kuriuos yra atsakingas prižiūrėtojas.

Pagalbinės PĮ priežiūros veiklos PĮ prižiūrėtojams tenka vykdyti ir eilę pagalbinių veiklų, kaip PĮ priežiūros

planavimas, konfigūracijos valdymas, tikrinimas ir tvirtinimas, PĮ kokybės užtikrinimas, peržiūra, auditas, naudotojų mokymas. Taip pat neišvengiama pagalbinė veikla yra prižiūrėtojų mokymas. PĮ priežiūros planavimas PĮ priežiūros planavimas yra svarbi veikla, kuri turi apimti eilę ateityje galimų klausimų:

- įstaigos veiklos, įskaitant PĮ priežiūrą, planavimas (organizacinis lygmuo);

- PĮ priežiūros planavimas (pereinamasis lygmuo); - PĮ naujos versijos išleidimo planavimas (PĮ lygmuo); - individualių pageidavimų keisti PĮ planavimas (pageidavimų lygmuo). PĮ pakeitimai pagal individualius pageidavimus planuojami PĮ pakeitimų

poveikio analizės metu (žiūr. 2.1 skyriuje, daromų PĮ pakeitimų poveikio analizė). Planuodamas leisti naują PĮ versiją, prižiūrėtojas turi:

- surinkti duomenis apie individualių pageidavimų naudingumą; - susitarti su naudotojais dėl būsimos PĮ versijos turinio; - įvardinti galimas konfliktines situacijas ir numatyti alternatyvas joms; - įvertinti naujos PĮ versijos riziką ir parengti problemų sprendimo planą

iškilus joms; - informuoti visus kitus naudotojus (akcininkus).

Kadangi PĮ kūrimo projektų trukmė dažniausiai būna nuo kelių mėnesių iki kelių metų, tai ir priežiūros procesas gali trukti eilę metų. Reikiamų resursų PĮ priežiūrai įvertinimas yra svarbi planavimo dalis. Šie resursai turėtų būti įtraukti į kūrėjų projektą planuojant biudžetą. PĮ priežiūros planavimas turėtų prasidėti sprendimo kurti naują PĮ priėmimu ir turėtų turėti kokybės gerinimo tikslus. Naujas priežiūros pradinių reikalavimų (sampratos) dokumentas turėtų būti rengiamas atsižvelgiant į priežiūros planą. Šiame dokumente turėtų būti nurodyta:

- PĮ priežiūros apimtis (scope);


163

- PĮ priežiūros proceso adaptacija; - PĮ priežiūrą atliekanti organizacija; - PĮ priežiūros kainos įvertinimas.

Turint pradinį priežiūros plano (sampratos) dokumentą, kitas žingsnis yra atitinkamo detalaus priežiūros plano rengimas. Šis planas turėtų būti rengiamas PĮ kūrimo eigoje ir jame turi būti nurodoma, kaip naudotojas galės išreikšti savo pageidavimus dėl PĮ modifikavimo arba informuoti apie iškilusias problemas. PĮ priežiūros planavimo rekomendacijos ir gairės yra aprašytos IEEE1219 ir ISO/IEC 14764 standartuose. Galiausiai, aukščiausiame lygmenyje PĮ priežiūros organizavimas turi apimti finansavimo klausimų ir priežiūrai reikalingų darbuotojų paskyrimo veiklas visuose institucijos padaliniuose. Priežiūrai reikalingas žinias galima rasti atitinkamuose PĮ inžinerijos mokslo skyriuose. PĮ konfigūracijos valdymas IEEE1219 standarte nurodoma, kad PĮ konfigūracijos valdymas yra kritinis PĮ priežiūros elementas. Pastarosios procedūros turi apimti tikrinimą, tvirtinimą ir auditą bei turi būti atliekamos kiekviename PĮ pakeitimų įvardinimo, analizės, kūrimo ir diegimo žingsnyje. Nepakanka vien registruoti pageidavimus keisti PĮ ar pastebėtus trūkumus. PĮ ir bet kokie jos pakeitimai turi būti kontroliuojami. Tokia kontrolė įvedama ir atliekama laikantis institucijos vadovybės patvirtinto PĮ konfigūracijos valdymo proceso. PĮ konfigūracijos valdymo srities mokslas suteikia detalias žinias, kaip turi būti atliekami PĮ keitimo pageidavimų priėmimo, šių pageidavimų įvertinimo ir patvirtinimo procesai. PĮ konfigūracijos valdymas PĮ priežiūros etape skiriasi nuo konfigūracijos valdymo PĮ kūrimo etape. Šis skirtumas pasireiškia eile atliktų nedidelių modifikacijų, kurias reikia kontroliuoti eksploatuojamoje PĮ. PĮ konfigūracijos valdymo procesams įdiegti būtina parengti atitinkamą planą ir apibrėžti priežiūros procedūras. Prižiūrėtojai, dalyvaudami konfigūracijos valdymo grupelėje, rengia naujų planų ir procedūrų versijas. PĮ kokybė Nereikėtų tikėtis, kad PĮ kokybė gerės nuo tinkamos jos priežiūros. Kokybės gerinimas turi būti planuojamas ir tai turi būti atliekama PĮ priežiūros bėgyje. Pasirinktos PĮ kokybės užtikrinimo, vertinimo ir tvirtinimo, peržiūros ir audito veiklos ir būdai turi būti derinami su kitais procesais, kad būtų pasiektas norimas PĮ kokybės lygis. Taip pat rekomenduojama, kad prižiūrėtojai savo darbe pritaikytų PĮ kūrimo procesus, būdus ir formuojamus rezultatus. PĮ kokybės klausimai plačiau nagrinėjami atskiroje šios srities disciplinoje.


164

4. Priežiūros gerinimo būdai

Šiame mokymo medžiagos skyriuje supažindinama su plačiai naudojamais

PĮ priežiūros gerinimo būdais.

4.1. Programų suprantamumo gerinimas

Programuotojai sugaišta daug laiko nagrinėdami pradinius programų

tekstus (kodus), kad galėtų atlikti norimus pakeitimus. Kodų naršyklės yra

pagrindinės programų suprantamumą palengvinančios priemonės. Aiški ir

trumpa dokumentacija taip pat prisideda prie programų suprantamumo.

4.2. Reinžinerija

Reinžinerija - tai PĮ nagrinėjimas ir perdarymas, siekiant suteikti jai naują

pavidalą ir įtraukti tolesnius sumanymus. Vieni mano, kad reinžinerija yra

radikaliausias ir brangiausias PĮ perdarymo būdas. Kiti mano, kad ji gali būti

naudojama ir nežymiems PĮ pakeitimams. Dažnai tai nepalengvina PĮ priežiūros,

bet prailgina jos amžių. Sprendžiant reinžinerijos klausimus tenka susidurti su PĮ

bendrojo supratimo, tvarkymo instrumentų ir būdų, įvairių faktų , rizikos ir

naudos nagrinėjimu.

4.3. Atvirkščioji inžinerija

Atvirkščioji inžinerija (reverse engineering) yra toks PĮ analizavimo

procesas, kurio metu siekiama įvardinti PĮ komponentus, atskleisti jų sąveiką ir

pavaizduoti juos aukštesniu abstrakcijos lygiu. Atvirkščioji inžinerija yra pasyvus

procesas. Ji neatlieka jokių esamos PĮ keitimų. Atvirkščiosios inžinerijos

pastangomis gaunamas kreipimųsi grafas (call graph) ir valdymo veiksmų

(control graph) grafas iš pradinio programos teksto (source code). Vienas iš

atvirkščiosios inžinerijos apraiškos tipų yra dokumentacijos perdarymas. Kitas

tipas – PĮ projekto atstatymas (pvz., dingus, pametus projektą). Pertvarkymas

(refactoring) yra tokia reorganizacija, kai PĮ veikimo būdas nekeičiamas, o tik

siekiama pagerinti jos struktūrą. Dar vienas atvirkščiosios inžinerijos tipas, beje,

atsiradęs visai neseniai, yra toks, kai PĮ loginės schemos atstatomos iš fizinių

duomenų bazių.


165

Šaltiniai

[AAD03] A. April, A. Abran, and R. Dumke, “Software Maintenance

Capability Maturity Model (SM-CMM): Process Performance

Measurement,” presented at 13th International Workshop on

Software Measurement (IWSM 2003). 2003.

URL: http://www.gelog.etsmtl.ca/publications/pdf/781.pdf

[Ben00] K.H. Bennett, Software Maintenance: A Tutorial, Software

Engineering edited by Dorfman and Thayer, IEEE Computer Society

Press. 2000.

[GT05] Penny Grub, Armstrong A.Takang, Software maintenance. Concepts

and practice, Second edition, World Scientific Publishing Co., 2005.

[IEEE1219] IEEE Std 1219-1998, IEEE Standard for Software

Maintenance, IEEE, 1998.

[ISO12207] ISO/IEC 12207:1995, Information technology – Software life cycle

processes. 1995.

[ISO14764] ISO/IEC 14764-1999, Software Engineering-Software Maintenance,

ISO and IEC. 1999.

[ISO9126] ISO/IEC 9126-1:2001, Software Engineering-Product Quality-Part 1:

Quality Model, ISO and IEC. 2001.

[JAR07] Stanislaw Jarzabek, Effective Software Maintenance and Evolution:

A Reuse-Based Approach, Auerbach, 2007.

[SEI01] Software Engineering Institute, “Capability Maturity Model

Integration, v1.1,” CMU/SEI-2002-TR-002, ESC-TR-2002-002,

December 2001.

[SWEBOK] SWEBOK, Guide to the Software Engineering Body of Knowledge,

2004 Version.

URL: http://www.swebok.org/pdfformat.html. 2001 KB, 2007-04.

Documents

PROGRAMŲ SISTEMŲ ĮSIGIJIMAS IR PRIEŽIŪRAvalund/KONSPEKTAI/PS isigijimas... · 2010-01-29 · įsigijimo projekte. Dar daugiau, įsigijimų tvarka, tinkanti medžiagų įsigijimo