programŲ sistemŲ Įsigijimas ir prieŽiŪravalund/konspektai/ps isigijimas... · 2010-01-29 ·...
TRANSCRIPT
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ė
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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š
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ę,
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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).
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ę
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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?
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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Į.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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šą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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“.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijim
as ir priežiūra. M
okymo m
edžiaga. Vilnius, 2007
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Į.
Valdas Undzėnas. Programų sistemų įsigijim
as ir priežiūra. M
okymo m
edžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijim
as ir priežiūra. M
okymo m
edžiaga. Vilnius, 2007
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ų.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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?
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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“.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą?
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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)
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
102
15.2 lentelė. Kas nurodoma kiekvieno testo procedūrų aprašuose
Nr. Nurodomas dalykas
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
Nr. Nurodomas dalykas
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
Nr. Nurodomas dalykas
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
103
15.5 lentelė. Kas rašoma testavimo ataskaitoje
Nr. Nurodomas dalykas
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.).
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ė);
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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?
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.),
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ą.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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:
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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:
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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);
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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:
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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“.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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;
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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);
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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ų.
Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. Vilnius, 2007
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.