VYTAUTO DIDŽIOJO UNIVERSITETAS

INFORMATIKOS FAKULTETAS
TAIKOMOSIOS INFORMATIKOS KATEDRA

Aušra Kentraitė

IS ANALIZĖS PROCESO VYKDYMO TEORIJA IR PRAKTIKA:

KOMUNIKACIJOS PROCESO BEI KYLANČIŲ PROBLEMŲ APŽVALGA

Magistro baigiamasis darbas

Verslo informatikos studijų programa, valstybinis kodas 621I13004

Informatikos studijų kryptis

Vadovas dr. hab. Vladislav V. Fomin _________ __________

(Parašas) (Data)

Apginta doc.dr. Daiva Vitkutė-Adžgauskienė __________ __________

(Parašas) (Data)

Kaunas, 2012
 TURINYS

Turinys ................................................................................................................................................. 2

Santrumpų ir terminų žodynas ............................................................................................................. 4

Santrauka ............................................................................................................................................. 5

Abstract ................................................................................................................................................ 6

Įvadas ................................................................................................................................................... 7

1. Informacinių sistemų projektavimas ir komunikacijos įtaka projektų realizavimui: tyrimo

problemos aprašymas ........................................................................................................................ 10

2. Tyrimo metodas .......................................................................................................................... 15

3. Informacinių sistemų kūrimo procesas – projekto realizavimas ................................................ 18

3.1. IS kūrimo procesas naudojant Agile ............................................................................... 18

3.2. IS kūrimo procesas naudojant RUP ................................................................................ 19

3.3. Apibendrinimas............................................................................................................... 20

4. Empirinė analizės proceso, jo sąvokos ir iškylančių problemų apžvalga .................................. 21

4.1. Informacinės sistemos analizės procesas: praktiniai aspektai ........................................ 21

4.2. Iškylančių problemų apžvalga ........................................................................................ 25

4.2.1. Analitiko, kliento ir komandos komunikacija..................................................... 25

4.2.2. Sistemingas informacijos perdavimas ................................................................ 26
4.2.3. Terminologija...................................................................................................... 27
4.2.4. Supratimo suvienodinimas .................................................................................. 28
4.3. Apibendrinimas............................................................................................................... 31

5. Komunikacijos procesas literatūroje ir jo įtaka analizės procesui.............................................. 32

5.1. Neverbalinis ir verbalinis bendravimas .......................................................................... 34

5.1.1. Neverbalinis bendravimas................................................................................... 35

5.1.2. Verbalinis bendravimas ...................................................................................... 37
5.1.2.1. Bendravimas žodžiu.................................................................................. 37

5.1.2.2. Bendravimas raštu .................................................................................... 38

5.2. Bendravimo įtaka analizei .............................................................................................. 38

2
6. Analizės procesas literatūroje ..................................................................................................... 41

6.1. Technologijų studijos...................................................................................................... 41

6.2. Analizės procesas literatūroje ......................................................................................... 42

6.3. Literatūroje aprašomos analizės problemos.................................................................... 45

6.3.1. Reliatyvizmo empirinė programa ....................................................................... 45

6.3.2. Technologijų socialinė konstrukcija ................................................................... 45
6.3.3. Interpretacijos lankstumas (angl. Interpretative Flexibility) .............................. 46
6.3.4. Retorinis nesutarimų uždarymas (angl. Rhetorical Closure) .............................. 47
6.4. Apibendrinimas............................................................................................................... 47

7. Analizės rezultatas – reikalavimų specifikacija ......................................................................... 48

7.1. Informacinės sistemos reikalavimų specifikacija ........................................................... 48

7.2. Analizės rezultato standartizavimas naudojant UML ..................................................... 49

7.2.1. UML istorija ....................................................................................................... 49

7.2.2. UML diagramų kūrimo įrankiai .......................................................................... 51
7.2.3. Pagrindinės UML diagramos naudojamos analizėje .......................................... 52
7.2.3.1. Aktorių diagrama ...................................................................................... 52

7.2.3.2. Panaudos atvejų diagrama ........................................................................ 53

7.2.3.3. Veiklos diagrama ...................................................................................... 54

7.2.3.4. Klasių diagrama ........................................................................................ 56

7.2.3.5. Kitos diagramos ........................................................................................ 57

7.3. Apibendrinimas............................................................................................................... 58

Išvados ............................................................................................................................................... 59

Literatūros sąrašas ............................................................................................................................. 62

Priedai ................................................................................................................................................ 67

ABSTRACT ................................................................................................................................ 67

Magistro antrojo tiriamojo darbo santrauka .............................................................................. 68

Magistro trečiojo tiriamojo darbo santrauka.............................................................................. 69

Evaluating companies interoperability USING DEXi ............................................................... 70

3
 SANTRUMPŲ IR TERMINŲ ŽODYNAS

Informacinė sistema – sudėtingų funkcijų visuma, kurios susijungdamos viena su kita

perduoda žinias ir taip sukuria informaciją.
IS – informacinė sistema.
Analizė [gr. Analysis – skaidymas] – tai metodas, pagrįstas mintiniu ar faktiniu visumos
skaidymu į dalis. Taip pat gali būti apibrėžiama kaip smulkus, išsamus, atidus ko nors nagrinėjimas,
studijavimas. [1]
Analizės procesas – tai veiksmų seka, kurių metu atliekama analizė – IS analizuojama
dalimis ir skirtingais abstraktumo lygiais. Abstrakti analizė – bendrais bruožais, detali analizė –
analizuojant būsimas funkcijas po vieną, išsamiai išsiaiškinant visas jos detales.
Analitikas – žmogus, kuris vykdo analizės procesą.
Agile – programinės įrangos kūrimo metodas paremtas iteraciniu ir pavieniu
programavimu.
RUP – kartotinio programinės įrangos kūrimo metodika (angl. Rational Unified
Process).[43]
UML – vieninga modeliavimo kalba (angl. Unified Modelling Language) [65].
OMT – objektų modeliavimo technika (angl. Object-modeling technique)
OOA – į objektus orientuota analizė (angl. Object-oriented analysis)
OOD – į objektus orientuotas sistemos projektavimas (angl. Object-oriented design).
MDA – žiniasklaidos vystymosi institucija (angl. Media Development Authority). [72]
RS – reikalavimų specifikacija (angl. Requirement Specification).
UC – panaudos atvejis (angl. Use Case).

4
 SANTRAUKA

Magistro darbo autorius: Aušra Kentraitė

Magistro darbo pavadinimas: IS analizės proceso vykdymo teorija ir praktika:

Komunikacijos proceso bei kylančių problemų apžvalga

Vadovas: dr. hab. Vladislav V. Fomin

Darbas pristatytas: Vytauto Didžiojo Universitetas, Informatikos fakultetas,

Kaunas, 2012 gegužė.

Puslapių skaičius: 66

Lentelių skaičius: 3

Paveikslų skaičius: 16

Šiame tiriamajame darbe nagrinėjamas informacinių sistemų analitiko darbas, analizės

svarba informacinių sistemų kūrimo procesui bei pagrindinės problemos kylančios analizės metu.
Analitikas tai žmogus, kuris bendrauja su informacinės sistemos užsakovu arba būsimu vartotoju
ir renka pradinę arba detalią informaciją apie veiklos procesą. Toliau darbe aprašytas
informacinės sistemos analizės procesas – veiksmų seka, kurių metu atliekama analizė – būsima
ar pradėta kurti informacinė sistema analizuojama dalimis ir skirtingais abstraktumo lygiais.
Analizės veiklos procesas pateikiamas nuo projekto pradžios, kai komanda gauna pirmus
dokumentus iš kliento, iki surinktos informacijos atidavimo projekto komandai bei jos tikslinimo
informacinės sistemos kūrimo metu. Darbe pateikiama teorija apie sociologijos ir technologijų
ryšį, jų svarbą bei jų daromą įtaką analizės procese kylančioms problemoms. Šiame tiriamajame
darbe aprašytos analizės metu kylančios problemos, dėl kurių projekto laikas gali labai išsitęsti
arba projektas gali būti visai neįgyvendintas.
Šio darbo tikslas yra parodyti ir faktais pagrįsti kodėl analitiko darbas yra svarbus, su
kokiomis problemomis dažniausiai susiduria analitikas bendraudamas su klientu ir projekto
vykdymo komanda bei kokią įtaką informacinių sistemų kūrimui daro sociologija.

5
 ABSTRACT

Author of Master Thesis: Aušra Kentraitė

Full title of Master Thesis: IS requirements analysis process in theory and practice:
Overview of communication process and
common problems

Supervisor: dr. hab. Vladislav V. Fomin

Presented at: Vytautas Magnus University, Faculty of Informatics,

Kaunas, May 2012.

Number of pages: 66

Number of tables: 3

Number of pictures: 16

This study provides information about the analyst's job, analysis and problems in the
analysis process. The analyst is someone who communicates with an information system
developer or prospective customer and collects information on the specifics of the business
process to be supported by Information System (IS). Information systems analysis process is part
of Information System Development (ISD) and is also known as requirements discovery process -
a sequence in which the analysis of the IS under development, or a future IS, is carried out at
different levels of abstraction. The analysis of the business process starts from at the beginning of
the ISD project, when the team of developers gets the first documentation from the client and ends
when information on IS requirements is collected and handed over to the project team. IS analysts
engagement is also required when adjustment to the IS (requirements) are made during the
development process. This work presents an uncommon in Lithuania view on ISD process,
namely that of social studies of technology, it’s relevance for the analytical process. The aim of
this work is to provide theoretical and empirical evidence on the importance of the analyst’s job in
determining success or failure of ISD process. Specifically, this work illustrates common
problems in the analyst-customer and analyst-developers communication process – the problems,
which can cause delays to the ISD process or can make it fail altogether.
6
 ĮVADAS

Analizė [gr. Analysis – skaidymas] – tai metodas, pagrįstas mintiniu ar faktiniu visumos
skaidymu į dalis. Taip pat gali būti apibrėžiama kaip smulkus, išsamus, atidus ko nors nagrinėjimas,
studijavimas. [1]
Informacinių sistemų kūrimo procese, analizė atliekama prieš pradedant kurti informacinę
sistemą (IS), t.y. prieš pradedant projektavimo ir programavimo darbus, bei jos kūrimo (IS
projektavimo/ programavimo) metu.
Analizė, kuri atliekama prieš pradedant kurti IS vadinama „Pradine analize”. Pradinė
analizė reikalinga tam, kad būtų teisingai išsiaiškinta kokias funkcijas turės atlikti sistema, t.y.
susidaryti teisingą pradinį vaizdą apie ką bus projektas, kokia bus jo apimtis, kiek laiko užtruks
įgyvendinti esmines sistemos funkcijas. IS kūrimo metu atliekama „Detali analizė“, kuri padeda
plačiau išsiaiškinti užsakovo poreikius. Jos metu detalizuojamas užsakovo veiklos procesas ir jo
automatizavimas, atliekama smulki veiklos proceso analizė ir jos specifikavimas.
Pagrindinis analizės tikslas – suprasti kliento poreikius, kokia turi būti kuriama IS, kokios
pagrindinės kuriamos sistemos funkcijos, kokį procesą automatizuos sistema, kaip ji palengvins
dabartinį žmogaus darbą. Taip pat svarbu surinktą informaciją teisingai dokumentuoti ir suderinti
dokumentavimo standartus su komandos nariais bei klientu, kad būtų suvienodintas visų supratimas
apie būsimą rezultatą – kuriamą sistemą.
Šiame darbe nagrinėjamas analizės procesas, kurio metu interaktyviai bendrauja bent du
žmonės: tas, kuris aiškinasi – sistemos analitikas – ir tas, kuris pasakoja reikiamas detales ir
procesus – klientas arba būsimos sistemos vartotojas. Taip pat nagrinėjama kokios pagrindinės
problemos iškyla atliekant informacinės sistemos analizę.
Aiškinantis būsimos sistemos funkcionalumą, veiklos procesą, vartotojo sąsają ir kitą
svarbią informaciją apie sistemą – projektuojant sistemą – iškyla problemų, tačiau viena svarbiausių
– supratimo nesutapimas. Supratimo nesutapimas yra dažnai pasitaikantis reiškinys kuriant
informacines sistemas, nes IS užsakovas dažniausiai nėra IT srities atstovas ir neturi pradinių žinių
apie tai kaip turi būti kuriama IS ir kokios informacijos reikia IS kūrimo komandai, kad jie galėtų
sėkmingai realizuoti kliento poreikius. Norint suprasti ir pastebėti supratimo nesutapimus
bendraujant su klientu reikalingi komunikacijos įgūdžiai. Supratimo nesutapimą galima palyginti su
dviejų žmonių pokalbiu – gydytojo ir paciento – jie abu supranta, kad pacientui reikia pagalbos, bet
šiuo atveju pacientas neturi reikiamų žinių apie ligą ir kaip ją gydyti, o ne tiksliai apibūdinęs savo
simptomus gali suklaidinti gydytoją ir bus gydoma liga, kuria pacientas neserga. Taip yra ir su
informacinių sistemų kūrimu, jeigu klientas neaiškiai išdėsto savo poreikius ir lūkesčius, galutinis

7
rezultatas – sukurta informacinė sistema – netenkina jo poreikių. Plačiau apie supratimo nesutapimą
parašyta skyriuje 6.3.3 Interpretacijos lankstumas (angl. Interpretative Flexibility), 46 psl.
Informacinių sistemų kūrimo proceso objektas yra pati informacinė sistema. Analitiko ir
kliento „kalbos“ skiriasi, nes skiriasi jų turimos žinios apie objektą. Galima teigti, kad klientas
supranta informacinę sistemą kaip juodą dėžę su patogia vartotojo sąsaja, kuri atliks visus reikiamus
veiksmus už jį. Dažnai klientui trūksta informacijos apie informacines technologijas ir jų kūrimą.
Analitikas IS supranta kaip sudėtingą kompiuterinę sistemą, kuri turi labai tiksliai atlikti visus
kliento veiklos procesus. Dėl skirtingų turimų žinių apie veiklos procesą ir sistemos projektavimą
analitiko darbas tampa labai svarbus – analitikas turi kuo tiksliau išsiaiškinti verslo procesus,
kuriuos IS turi automatizuoti. Gautas žinias turi sistemingai ir aiškiai pateikti kitiems komandos
nariams – architektui bei programuotojams. Taip pat klientui turi paaiškinti kokias verslo proceso
dalis galima automatizuoti ir kokių ne. Dažnu atveju pasitaiko, kad proceso automatizavimas tik
apsunkina darbą, o ne jį palengvina ar pagreitina.
Remiantis išvardintomis priežastimis galima teigti, kad analizės procesas informacinės
sistemos kūrimo procese yra viena iš svarbiausių dalių – „blogai“ atlikta analizė lemia blogai
sukurtą IS, t.y. sukurtos sistemos vykdomas verslo procesas bei vartotojo sąsaja gali netenkinti
kliento poreikių, nors vertinant sistemos kokybę ne pagal kliento poreikius ji veiks gerai. Analizės
procesas būtinas tam, kad būtų patenkinti kliento poreikiai ir teisingai automatizuotas verslo
procesas, priešingu atveju bus sugaišta daug laiko ir iššvaistyti pinigai, o rezultatas neatitiks
poreikių.
Analitikas šiame kūrimo procese turi labai svarbų vaidmenį – tik jis gali tinkamai
išsiaiškinti kliento poreikius, tinkamai juos dokumentuoti/ specifikuoti ir pateikti kitiems komandos
nariams. Taip pat analitikas argumentuotai gali daryti įtaką būsimos sistemos funkcijoms, jų gausai
ar jų įgyvendinimui.
Sistemų analitikas tiria esamas problemas, planuoja galimus sprendimus, rekomenduoja
programinę įrangą ir sistemas, padeda susieti informacinės sistemos kūrimo procesą su verslo
procesais. Analitikas yra susipažinęs su programavimo kalbomis, operacinėmis sistemomis bei
technine kompiuterine įranga, nes aprašant gautą informaciją į techninę specifikaciją šios žinios yra
reikalingos. Sistemų analitikas yra tarpininkas, vertėjas ir informacijos perdavėjas tarp informacinės
sistemos užsakovo ir informacinės sistemos kūrimo profesionalų. [45, 46]
Analizė nagrinėjama analitiko – kliento ir analitiko – komandos atžvilgiu. Apžvelgiami
svarbiausi bendravimo įgūdžiai bei jų įtaka analizės procesui ir komunikacijai su klientu bei
komanda. Aptariama kaip analitikui teisingai išdėstyti mintis, kad klientas teisingai suprastų
pateiktus klausimus ir galutinis produktas tenkintų tiek užsakovą – klientą, tiek produkto gamintoją
– informacinės sistemos kūrimo komandą.
8
 Kiekviena nesusikalbėjimo ir nesiklausymo klaida kuriant informacinę sistemą sukelia
papildomas problemas ir išlaidas. Kliento ir komandos nepasitenkinimas atliktu darbu, reikalavimų
specifikacijos koregavimas, kliento pataisymai ar papildymai, smarkiai apsunkina darbą bei
sumažina galimybes susišnekėti ir taip išspręsti iškilusias problemas.
Teisingai atlikti informacinės sistemos analizę nėra vieno teisingo būdo. Teisingai atlikti
analizę yra labai daug skirtingų būdų. Šiame darbe išdėstyta autorės nuomonė apie svarbiausias
analizės dalis, aspektus, bendravimo būdą, sugebėjimą išgirsti. Autorė turi 2 metų patirtį dirbant
informacinių sistemų analitiko pozicijoje programinės įrangos kūrimo įmonėje. Dirbant šiose
pareigose buvo susidurta su problemomis, kurioms sprendimo yra ieškoma šiame darbe atliekant
literatūros analizę. Taip pat pastebėta, kad praktikoje yra mažai teorinių žinių ir tik maža dalimi
teorijos yra vadovaujamasi kuriant informacines sistemas. Savarankiškai gilinant žinias apie
analizės procesą pastebėta, kad analizės procesas nagrinėjamas tik kaip informacinių technologijų
dalis, nors analizės proceso veiklos didelę dalį sudaro bendravimas, todėl šiame darbe nagrinėjamas
ir komunikacijos procesas bei analizuojama jo daroma įtaka analizės procesui.

Darbo tikslas:
Aprašyti informacinių sistemų analizės procesą bei sistemų analitiko daromą įtaką IS
kūrimo procesui, taip pat pateikti pagrindines problemas kylančias informacinių sistemų analizės
metu ir kokią įtaką šioms problemoms daro socialiniai faktoriai.

Darbo uždaviniai:
1. Išdėstyti tiriamojo darbo problematiką.
2. Aprašyti tyrimo metodus.
3. Apžvelgti informacinių sistemų kūrimo projektų vykdymą ir įgyvendinimo sėkmingumą.
4. Apžvelgti teorines žinias apie analizės procesą ir palyginti su praktinėmis žiniomis.
5. Apibrėžti analizės sąvoką bei procesą remiantis literatūra ir išskirti praktikoje
naudojamas dalis.
6. Apžvelgti literatūroje aprašomas analizės procese kylančias problemas ir jas palyginti su
realiomis problemomis.
7. Pateikti pasiūlymus kaip spręsti kylančias problemas.
8. Paaiškinti kokie faktoriai, ne tik technologiniai, daro tiesioginę įtaką analizės procesui.

9
 1. INFORMACINIŲ SISTEMŲ PROJEKTAVIMAS IR
KOMUNIKACIJOS ĮTAKA PROJEKTŲ REALIZAVIMUI:
TYRIMO PROBLEMOS APRAŠYMAS

Šiuo metu visame pasaulyje kuriamos vis sudėtingesnės informacinės technologijos.

Informacinių technologijų srityje, tiek taikomojoje informatikoje tiek ir verslo informatikoje,
pagrindinis kuriamas produktas yra informacinės sistemos. Tai gali būti nuo nesudėtingos
programėlės naudojamos telefone stebėti duomenims iki sudėtingų informacinių sistemų skirtų
automatizuoti verslo procesus ir juos susisteminti. Visame pasaulyje kiekvienais metais pasirodo
naujos informacinės sistemos, kurios palengvina ir pagreitina tiek verslo procesus, tiek informacijos
surinkimą ir apdorojimą, kas savo ruožtų sukuria pridėtinę vertę verslui.
Informatika (kompiuterija, angl. Informatics, vok. Informatik, pranc. Informatique, angl.
computer science = „kompiuterių mokslas“, JAV - angl. computer science) – mokslas bei technikos
šaka, kuri nagrinėja informacijos apdorojimą, panaudojant kompiuterius [25]. Informatika
(Informacinės technologijos) skatina intensyvų informacijos apsikeitimą tarptautiniu mastu.
Praktikoje informatika apima tiek abstrakčių algoritmų, formalių gramatikų ir panašius tyrimus, tiek
ir konkretesnes sritis – programavimo kalbas, programinę, techninę įrangą bei kompiuterio
sudėtines dalis [26].
Verslo informatika susideda iš informacinių technologijų, informatikos bei valdymo
koncepcijų [68].
Komunikacija ir komunikacijos procesas šiame darbe atlieka svarbų vaidmenį, nes ji
padeda suprasti bendravimo ypatumus bei leidžia teisingai interpretuoti informaciją, kuri reikalinga
kuriant informacines sistemas. Šiuo metu Lietuvos universitetuose informacinės technologijos ir
komunikacijos procesas tarpusavyje visai nesiejami, nors užsienio šalyse ši praktika jau seniai
naudojama ir puikiai pasiteisina. Tiesiogiai komunikacijos proceso negalima išskirti kaip projektų
vykdymo nesėkmės faktoriaus, todėl toliau bus nagrinėjama kas turi įtaką projektų realizavimui.
Informacinių sistemų kūrimas šiuo metu laikomas vien tik techniniu procesu, kuriam
taikomos techninės taisyklės ir įvairūs informacinių technologijų standartai. Šios žinios yra nuolat
tobulinamos ir atnaujinamos, taip tobulinant IS kūrimo procesą. Tačiau kuriant šias technologijas
dirba ne vienas žmogus, o dažnai kūrybinė komanda susideda iš daugiau nei trijų žmonių.
Dažniausiai visų komandos narių pradinės žinios ir supratimas apie kuriamą produktą skiriasi.
Todėl norint, kad komandoje darbas vyktų sklandžiai ir kuriamas produktas atitiktų kliento
poreikius reikalingi komunikacijos įgūdžiai, kurie padėtų susikalbėti komandos nariams tarpusavyje
ir padėtų suprasti kliento poreikius.
10
 Šiame darbe nagrinėjama:
• Informacinės sistemos kūrimo procesas;
• Esminės problemos darančios įtaką projekto realizacijos sėkmei ir nesėkmei;
• Analitiko daroma įtaka sistemos kūrimo procesui;
• Analizės procesas;
• Analizės proceso metu kylančios problemos.
Visi minėti aspektai apžvelgiami iš teorinės (literatūrinės) ir praktinės (patirties) pusės.
Informacijos apie projektų valdymą, analizės procesą, analizės standartizavimą bei kitus techninius
aspektus literatūroje yra be galo daug. Informacinių sistemų kūrimas ir informacinių sistemų
analitiko darbas praktikoje nėra susijęs vien su informacinės technologijomis, jų išmanymu, tam
tikrų standartų žinojimų ir jų taikymu. Analizės metu kylančios problemos visos yra susijusios su
komunikacijos procesu, todėl šiame darbe dėstoma informacija yra skirta komunikacijos proceso
svarbai informacinių sistemų kūrimo procese.
Toliau šiame skyriuje naudojantis Standish Group duomenimis yra pateikiama informacija
apie projektų įgyvendinimą ir jų nesėkmių priežastis. [40, 57]

1 lentelė
Projektų įgyvendinimas procentais [40, 53, 54, 55]
Metai Sėkmingi projektai Problemiški projektai Nutraukti arba
neįgyvendinti projektai
1994 16% 53% 31%
1996 27% 33% 40%
1998 26% 46% 28%
2000 28% 49% 23%
2004 29% 53% 18%
2006 35% 46% 19%
2009 32% 44% 24%

Lentelėje 1 pateikiami bendri duomenys apie projektų įgyvendinimą. Per dešimt metų
matomas akivaizdus sėkmingai gyvendinamų projektų skaičiaus augimas. Tačiau remiantis Standish
Group leidžiama CHAOS Report 2009 duomenimis, tik 32% projektų buvo užbaigti laiku,
neviršijant biudžeto ir pasiekė visus užsibrėžtus tikslus. 44% projektų viršijo skirtą finansavimą
ir/arba realizacija vėlavo. 24% projektų buvo nutraukti realizacijos metu dėl nesėkmingo jų

11
įgyvendinimo, o tai verslui sukuria nuostolį, kurio kaštus turi pasidengti pati įmonė. Tradiciškai
informacinių technologijų kūrimo procesas atrodo kaip pateikta paveiksle 1 šarže.

1 pav. Informacinių technologijų kūrimo šaržas

Augantis procentas sėkmingai įgyvendinamų projektų, žinoma, buvo nulemtas daugelio

faktorių, tokių kaip: sparčiai tobulėjančios technologijos, greitai plintantis interneto tinklas ir daug
kitų, tačiau prie to nemažai prisidėjo ir analizės tobulėjimas. Tai įrodo, kad susikalbėjimas,
interpretacijos lankstumas ir kiti socialiniai faktoriai informacinių sistemų kūrimui yra be galo
svarbūs. Augantis įgyvendinamų projektų procentas nereiškia, kad prieš tai žmonės nemokėjo
programuoti ir dėl to projektai nepasisekdavo, buvo nutraukiami arba buvo neužbaigiami.
Informacinės sistemos buvo kuriamos, jos sėkmingai veikė, tačiau neatitiko klientų poreikių, dėl to
projektai buvo laikomi neįvykdytais arba probleminiais. Informacinių sistemų kūrimas seniau, kaip
ir dabar, kainavo didžiulius pinigus, todėl yra svarbu rasti būdus kaip pagerinti informacinių
technologijų kūrimą, kad projektai būdų sėkmingai įgyvendinami ir sukurtų pridėtinę vertę jų
kūrimo įmonėms.
Toliau apžvelgiamos pagrindinės priežastys kodėl projektai sėkmingai įgyvendinami ir
kokios pagrindinės problemos kyla projektų įgyvendinimo procese. Remiantis pateikiamomis

12
priežastimis toliau darbe ieškomi sprendimai kaip patobulinti IS kūrimo procesą, kad daugiau
projektų būtų užbaigiami laiku ir neviršijant biudžeto.
Projekto sėkmės veiksniai (atsakymai pateikiami procentais) [57]:
1. Naudotojo įtraukimas į procesą 15,9% (analizės proceso dalis)
2. Vadovų pritarimas projekto vykdymui 13,9%
3. Aiškus reikalavimų specifikavimas 13,0% (analizės proceso dalis)
4. Tinkamas planavimas 9.6%
5. Realistiški lūkesčiai 8,2%
6. Projekto skaidymas į smulkesnius etapus 7,7%
7. Kompetentingi darbuotojai 7,2%
8. Nuosavybė 5,3%
9. Aiški vizija ir tikslai 2,9%
10. Darbštus, orientuotas personalas 2,4%
11. Kiti 13,9%
Norint pagerinti įgyvendinamų projektų rodiklius neužtenka vien tobulinti technologijas ir
specialistus, tam būtina atsižvelgti ir į faktorius, kurie nėra technologiniai.
Projekto problemų veiksniai (atsakymai pateikiami procentais) [57]:
1. Nepakankamas naudotojo įtraukimas į procesą 12,8% (analizės proceso dalis)
2. Nepilni reikalavimai ir reikalavimų specifikacijos 12,3% (analizės proceso dalis)
3. Reikalavimai ir reikalavimų specifikacijos keitimas 11,8 % (analizės proceso dalis)
4. Nepakankamas vadovų pritarimas projekto vykdymui 7,5%
5. Technologijų neišmanymas 7,0%
6. Nepakankami resursai 6,4 proc.
7. Per dideli lūkesčiai - 5,9%
8. Neapibrėžti tikslai 5,3%
9. Blogai įvertinta darbų trukmė 4,3%
10. Nauja technologija 3,7%
11. Kiti 23,0%
Iš pateiktų duomenų matoma, kad pagrindiniai trys projekto problemų veiksniai yra
tiesiogiai susiję su analize ir analizės procesu. Plačiau apie IS kūrimo projektus 3 Informacinių
sistemų kūrimo procesas – projekto realizavimas, 18 psl., skyriuje .
Pagrindinės trys projektų nesėkmių priežastys sudaro net 37% projekto įgyvendinimo
sėkmės. Visos trys priežastys yra iš analizės proceso, todėl galima teigti, kad be analizės proceso
sėkmingai įgyvendinti projektą yra neįmanoma arba geriausiu atveju projekto realizacija bus
komplikuota.
13
 Nagrinėjant pateiktus duomenis kyla klausimas kas turėtų būti padaryta, kad projektų
įgyvendinimo rodikliai dar labiau pakiltų. Čia galima kelti hipotezę, kad projektų realizavimo
rodikliai pagerėtų, jeigu į analizės procesą būtų įtraukiama ne tik techninė informacija, bet
informacinių sistemų analitikai būtų supažindinami su komunikacijos procesu, jo daroma įtaka
analizei bei būtų apmokomi panaudoti komunikacijos įgūdžius reikalavimų surinkimui.
Visose mokslo bei darbo šakose yra būtinas bendravimas norint pasiekti maksimaliai gerų
rezultatų. Tiek akademinėje veikloje, tiek visose verslo srityse pirmas svarbus dalykas yra
susikalbėjimas ir minčių bei idėjų supratimas tarp skirtingų socialinių grupių žmonių. Tam, kad
bendravimas būtų produktyvus ir rezultatas būtų akivaizdžiai pastebimas reikalingas daugelio metų
įdirbis bei pagrindinių žinių įgijimas, kaupimas.

14
 2. TYRIMO METODAS

Tiriamiesiems darbams atlikti yra galimi keli metodai. Toliau šiame skyriuje trumpai bus
paminėti visi tyrimo būdai, o labiausiai tinkantys šiai temai nagrinėti bus plačiau aprašyti ir
paaiškinti.
Kiekviena mokslo sritis, o tuo labiau kryptis, turi savus tyrimo metodus, nors, aišku, yra ir
bendrų tyrimo metodų (pavyzdžiui, eksperimentas, matematinė statistika, teorinės analizės,
apibendrinimo ir kt.). Metodais galime pavadinti įvairius būdus, naudojamus moksliniuose
tyrimuose rezultatams gauti. Tradiciškai metodo sąvoka siejama su pozityvistinio modelio
technikomis – reikalingų atsakymų išgavimas, matavimų užrašymas, fenomenų apibūdinimas,
eksperimentų atlikimas. Išplėtę šios sąvokos reikšmę, apimtume ir interpretacinius metodus –
dalyvavimą, vaidmenų žaidimą, interviu, epizodus ir ataskaitas [13].
Metodo reikšmė – didžiulė. Gerai parengtas ar pritaikytas metodas žymiai palengvina
tyrimą. Teigiama, kad nuo metodo priklauso viso tyrimo sėkmė, o remdamasis tinkamai parengtais
tyrimo metodais net ir nelabai gabus žmogus gali daug padaryti, kai tuo tarpu netinkamai parinkti
tyrimo metodai nepadės ir genialiam mokslininkui [30].
Tyrimo metodas – tai mokslo veiksmų seka ir tvarka, kuri ne tik rodo tai, kaip buvo
pasiekti rezultatai, bet ir leidžia kitiems tyrėjams, naudojantis vienomis ar kitomis priemonėmis,
pakartoti tyrimą bei dar kartą patikrinti jo rezultatus.
Kaip tyrimo metodai yra išskiriami kiekybiniai ir kokybiniai tyrimai.
Skirtingiems tyrimo metodams galima taikyti skirtingas duomenų rinkimo strategijas:
1. Stebėjimas;
2. Eksperimentas;
3. Apklausa.
Iš pateiktų tyrimo metodų šiam tiriamajam darbui tinkamas yra stebėjimas bei esamos
literatūros apžvalga.
Toliau apžvelgiami kiekybiniai ir kokybiniai tyrimai.
Kiekybiniam tyrimui labiau būdingas siekis ieškoti išorinių reiškinio požymių, išgaunant
įvairius rodiklius, kurie gali būti išreikšti skaičiais ir matuojami. Todėl kiekybinio tyrimo mokslinę
vertę nusako gauti jo rezultate kiekybiniai rodikliai. Be to, kiekybinis tyrimas yra labiau
struktūrizuotas ir suplanuotas, nes tyrimo metodai bei duomenų matavimo priemonės dažniausiai
būna sukonstruotos dar prieš tyrimą. Tuo tarpu kokybinių tyrimų metodai yra lankstūs, nes
orientuoti į interpretaciją, o ne į matavimus; į procesą, o ne į išvadą; sutelkia dėmesį į situacijos ir

15
elgesio ryšį, kuris daro didžiausią įtaką patirties formavimui. Be to, skirtingai negu kiti, kokybiniai
tyrimo metodai labiau gilinasi į daiktų ir reiškinių kilmę, o ne į skaičius [39].
Pagal pateiktą informaciją matoma, kad šiam tyrimui labiau tinkamas yra kokybinis
tyrimas, todėl toliau apie jį pateikiama daugiau informacijos.
Pasak Kardelio [30] kokybinių tyrimų sampratos analizė yra problemiška daugeliu aspektų.
Taip pat jis teigia, kad kokybiniai tyrimai arba jų elementai yra panaudojami ir tokiose disciplinose:
psichologijoje – pokalbis, pokalbio turinio analizė; istorijoje – dokumentų analizė, faktų
interpretavimas; medicinoje — terapinis pokalbis ir kt. Suprantama, skirtingų tyrimų tradicijų,
mokyklų ir disciplinų atstovai turi savitą pažiūrą į socialinę realybę. Todėl nenuostabu, kad jie turi
ir skirtingą nuomonę apie kokybinių tyrimų galimybes, reikšmingumą bei tai, kokiu būdu
empiriniai tyrimai gali padėti žmogui. [30]
Mokslo metodologinėje literatūroje kokybiniai tyrimai neretai apibūdinami kaip
natūralistiniai [47]. Jie apima ilgalaikį objekto (asmens, grupės, organizacijos) tyrimą, kurio tikslas
– suprasti asmenį, jo elgesį ir jutimus bei fizinės, socialinės ir psichologinės aplinkos poveikį jam.
Kartais kokybinis tyrimas nusakomas kaip etnografinis [12, 52] , kuris gali būti susijęs su individo
ar grupės elgsenos tam tikroje aplinkoje tyrimais. Toje aplinkoje gali būti savi papročiai, vertybės,
bendravimo būdas. Etnografiniai tyrimai paprastai remiasi atitinkamos žmonių veiklos stebėjimu,
neformaliu pokalbiu, o dažnai ir tiesioginiu tyrėjo dalyvavimu toje veikloje. Jais stengiamasi
atskleisti kas atsitiko tam tikroje socialinėje aplinkoje, kaip palaikomi socialiniai ryšiai ir ką tie
įvykiai ir ryšiai reiškia dalyviams. Pavyzdžiui, kaip grupės nariai siekia bendrų tikslų? Ką grupės
nariams reiškia specifiniai žodžiai, kuriuos jie vartoja? Ir t.t. Dėl šių ypatumų šio tipo tyrimas
leidžia pažvelgti į pasaulį realių, jame gyvenančių žmonių akimis. Ir labai dažnai jų požiūriai,
nuomonės skiriasi (arba gali skirtis) nuo visuotinai priimtų stereotipų ar atskiro mokslininko
nuomonės. Todėl tokie tyrimai, kaip teigiama literatūroje gali būti patrauklūs ir įdomūs.
Kokybiniams tyrimams apibūdinti dažnai vartojama sąvoka atvejo tyrimas, kuri akcentuoja,
kad tyrimas remiasi atskirų atvejų studijomis. Dar kitur jie įvardinami kaip interpretaciniai tyrimai,
pabrėžiantys tyrėjų siekį interpretuoti reiškinius tomis prasmėmis, kurias jiems suteikia tiriami
žmonės [21].
Kur kas rečiau nesutarimų kyla vartojant kiekybinių tyrimų sąvokas. R. Stake [52]
nuomone, kiekybiniai tyrimai gali būti vadinami statistiniais arba eksperimentiniais. Šios sąvokos
akcentuoja kiekybinį duomenų analizės pobūdį bei nenatūralią (laboratorinę) tyrimo situaciją. D.
Krathwohl [31] taip pat teigia, jog kiekybiniuose tyrimuose dažniausiai taikomi eksperimentiniai
metodai.
Apžvelgus sąvokų kokybiniams ir kiekybiniams tyrimams nusakyti įvairovę, nesunku
pastebėti, jog kiekvienoje jų yra akcentuojamas vienas ar kitas aspektas. Anot D. Krathwohl [31],
16
šiomis sąvokomis yra nusakomi du skirtingi požiūriai į tyrimą. Kiekybiniu požiūriu tyrime
dažniausiai siekiama patvirtinti hipotezę, o kokybinio požiūrio atveju priimtinesni iš situacijų
analizės kylantys paaiškinimai. Vadinasi, sąvokos kokybinis ir kiekybinis tyrimas yra labiau
priimtinos, nes jomis nusakomi ne atskiri mokslinio tyrimo metodai arba aspektai, o kiekybinis ir
kokybinis požiūris į tyrimą. Šiuo atveju kokybiniam požiūriui būdingas siekimas suprasti, kaip
individai suvokia bei aiškina pasaulį ir kaip individualiai kuriamos prasmės lemia jų elgesį.
Kiekybiniu požiūriu nusakomas siekis ieškoti išorinių požymių, matuoti juos ir skaičiuoti, siekti
vienintelio paaiškinimo, dėsnių, taisyklių, universalumo ir visuotinumo [31].
Kokybiniai tyrimai, nebūdami priklausomi nuo hipotezių, pasižymi lankstumu bei
duomenų indukcine analize, kuri induktyvią tyrėjo logiką priskiria prie kokybinių tyrimų bruožų.
Lankstumas apibūdina kokybinį tyrimą kaip nestruktūrizuotą, neturintį standartinės tyrimo
struktūros, tinkančios bet kuriai tiriamai aplinkai. Struktūrizuotas jis gali būti vėliau, tačiau turi būti
atliekamas sistemingai ir tiksliai [35, 59]. Pastarojo nuomone, kokybinis tyrimas apima tyrėjo
savianalizę ir refleksiją. Psichologijos žodynas refleksiją apibūdina kaip procesą, per kurį žmogus
pažįsta savo paties psichinius veiksmus ir būsenas. Tai individo mąstymas apie tai, kas vyksta jo
paties sąmonėje. Dėl to, kaip teigia M. Gall su bendraautoriais [21], refleksuodamas tyrėjas ne tik
keičiasi pats, bet ir tampa sudėtine tyrinėjamos realybės dalimi.
Kita svarbi kokybinių tyrimų ypatybė, pasak minėtų literatūros šaltinių, yra ta jog šiems
tyrimams netaikomi griežti imties tūrio reikalavimai. Jų reprezentatyvumą lemia ne tiriamųjų
parinkimo būdai, o lankstūs vienokie ar kitokie teoriniai kriterijai. Todėl galima manyti, kad
svarbiausias kokybinių tyrimų elementas – tyrimo duomenų apibendrinimas.
Remiantis pateikta medžiaga apie kiekybinius ir kokybinius tyrimus bei tyrimų metodus,
šiam tiriamajam darbui yra taikomas kokybinis tyrimas paremtas stebėjimu bei literatūros apžvalga.
Informacinių sistemų analitiko darbas yra labai lankstus, jame tenka susidurti su itin skirtingais
žmonėmis, kurių žinių bagažas gali būti visiškai nesuderinamas. Tobulinti sistemų analitiko darbą
galima tik nagrinėjant konkrečius pavyzdžius ir bandant pritaikyti turimas žinias skirtingose
situacijose.
Atliekant literatūros apžvalgą bei pasitelkiant praktines žinias šiame darbe atliekamas
kokybinis tyrimas.

17
 3. INFORMACINIŲ SISTEMŲ KŪRIMO PROCESAS –
PROJEKTO REALIZAVIMAS

Informacinių sistemų analizė yra dalis visos informacinės sistemos kūrimo proceso. Tam,
kad būtų aiškiai ir tinkamai suprasta analizės svarba ir jos įtaka IS kūrimui, šiame skyriuje yra
pateikiamas bendras projekto vykdymo ciklas. Šiame skyriuje yra nagrinėjamos dvi projektų
valdymo metodikos: kartotinio programinės įrangos kūrimo metodika (angl. Rational Unified
Process (RUP))[43] ir programinės įrangos kūrimo metodika paremtas iteraciniu ir pavieniu
programavimu (Agile) [3, 4, 5, 16, 27, 48].

3.1. IS kūrimo procesas naudojant Agile

Informacinių sistemų kūrimo procesas pagal Agile metodiką yra skaidomas į devynis
žingsnius (2 pav.):
1. Projekto planavimas;
2. Projektų darbų planavimas;
3. IS reikalavimų analizė;
4. Analizė;
5. IS projektavimas;
6. IS realizavimas;
7. Realizuoto produkto diegimas;
8. Sukurtos IS testavimas;
9. Sukurto rezultato vertinimas.
Praktikoje gali būti apjungtos kelios dalys į vieną arba vienas žmogus gali būti atsakingas
už kelias dalis. Proceso realizacija praktikoje priklauso nuo įmonės dydžio, darbų pasiskirstymo bei
įmonėje naudojamo projekto valdymo metodo. Tačiau projektų valdymo teorijoje [2, 43]
nerekomenduojama apjungti kelis procesus į vieną.
Antrame paveiksle pateikti procesai yra tiesiogiai vienas nuo kito priklausomi, o jų
vykdymo eiga turi būti išlaikyta tokia kaip pavaizduota – pradedant nuo planavimo ir reikalavimų
rinkimo. Taigi matoma, kad projekto įgyvendinimas prasideda nuo reikalavimų analizės. Tai savo
ruoštu reiškia, kad blogai atlikus arba visai neatlikus analizės kuriamo produkto likimas yra labai
miglotas.

18
 2 pav. Informacinės sistemos kūrimo procesas pagal Agile [3, 4, 5, 16, 27, 48]

Pagrindinės problemos IS įgyvendinimo cikle [57]:

1. Nepakankamas naudotojo įtraukimas į procesą;
2. Nepilni reikalavimai ir reikalavimų specifikacijos;
3. Reikalavimai ir reikalavimų specifikacijos keitimas.
Šios trys problemos iš projekto realizavimo ciklo priklauso analizės segmentui. Tai dar
vienas įrodymas, kad norint pagerinti projektų įgyvendinimo rodiklius reikia tobulinti analizės
procesą.

3.2. IS kūrimo procesas naudojant RUP

Trečiame paveiksle pateikiamas projekto vykdymo procesas pagal RUP metodiką [44, 49].
RUP metodika projekto procesus skaido į septynis žingsnius:
1. Verslo procesų modeliavimas;
2. Reikalavimų išgavimas;
3. Sistemos analizė;
4. Sistemos projektavimas;
5. Sistemos programavimas;
6. Sistemos testavimas;
7. Sistemos diegimas.
Žemiau pateiktas paveikslas dar kartą patvirtiną, kad analizės procesas IS kūrimo procese
turi labai didelę įtaką ir norint pagerinti projektų įgyvendinimo ir realizavimo rodiklius: sumažinti

19
biudžetą ir sutaupyti realizacijai reikalingą laiką, reikia problemų ieškoti analizės procese ir jį
tobulinti.

Verslo proceso modeliavimas

Reikalavimų išgavimas Analizės

procesas

Sistemos analizė

Sistemos projektavimas

Sistemos programavimas

Sistemos testavimas

Sistemos diegimas

3 pav. Informacinės sistemos kūrimo procesas pagal RUP [44, 49]

3.3. Apibendrinimas

Informacinių sistemų kūrimo procesai gali būti skirtingi kiekvienoje kompanijoje, tačiau
bendras veiklos procesas išlieka panašus. Pagal kokį modelį dirba kompanija yra individualus
pasirinkimas ir tai dažniausiai priklauso nuo to kokia veikla užsiima informacinių sistemų kūrimo
kompanija. Praktikoje taip pat pasitaiko atvejų, kai yra naudojamos abiejų kūrimo procesų dalys į
firmos veiklos procesą integruojant tas dalis, kurios yra reikalingos, o ne visas procesas pagal
teorines taisykles.

20
 4. EMPIRINĖ ANALIZĖS PROCESO, JO SĄVOKOS IR
IŠKYLANČIŲ PROBLEMŲ APŽVALGA

Autorė dirbdama sistemų analitike susidūrė su analizės procese kylančiomis problemomis.

Šiame skyriuje pateikiama autorės patirtis ir nuomonė kokios problemos dažniausiai pasitaiko
analizės proceso metu, kodėl jos atsiranda ir kas galėtų padėti išspręsti kylančias problemas.
Žemiau pateiktame 4 paveiksle pavaizduotas praktikoje naudojamas IS kūrimo procesas.
Informacinės sistemos realizavimui yra išskiriamos penkios esminės dalys:
1. Analizė;
2. Projektavimas;
3. Programavimas;
4. Testavimas;
5. Dokumentavimas.

Kliento
Analizė (1) įtraukimas į
procesą

Dokumentavimas (5) Projektavimas (2)

Testavimas (4) Programavimas (3)

4 pav. Praktikoje naudojamas informacinės sistemos kūrimo procesas

4.1. Informacinės sistemos analizės procesas: praktiniai

aspektai

Analizėje turi dalyvauti bent du žmonės: analitikas – tas, kuris aiškinasi poreikius ir
klientas – tas, kuris išsako savo poreikius, pasakoja reikiamas detales ir procesus.
Analizė atliekama prieš pradedant kurti informacinę sistemą (IS). Tai reikalinga tam, kad
būtų teisingai suprasti užsakovo poreikiai, teisingai įgyvendintas veiklos proceso automatizavimas.

21
 Pagrindinis analizės tikslas – suprasti kliento poreikius, kokia turi būti kuriama IS, kokios
pagrindinės kuriamos sistemos funkcijos, kokį procesą automatizuos sistema, kaip ji palengvins ir
automatizuos dabartinį žmogaus darbą.
Taip pat svarbu surinktą informaciją teisingai dokumentuoti ir suderinti dokumentavimo
standartus su komandos nariais bei klientu, kad būtų suvienodintas visų supratimas. Plačiausiai
naudojama standartizuotai aprašyti IS reikalavimus naudojama vieninga modeliavimo kalba
(Unified Modelling Language – UML), apie tai plačiau skyriuje 7.2 Analizės rezultato
standartizavimas naudojant UML, 49 psl.. Tačiau reikalavimų dokumentavimui kaip ir analizei
galima naudoti daug būdų.
Teorijoje pateikiama daug taisyklių ir patarimų kaip vykdyti analizės procesą, kaip
specifikuoti surinktus reikalavimus, kokios problemos kyla analizės metu, tačiau kaip ir visada
teorija nuo praktikos skiriasi. Šiame skyriuje pateikiamos problemos, kurios dažniausiai pasitaiko
praktikoje analizės proceso metu.
Žemiau pateikiamame 5 paveiksle pavaizduotas analizės procesas, nuo pirminių
dokumentų analizės iki parengtos reikalavimų specifikacijos atidavimo komandai – sistemos
realizavimui.
Informacinės sistemos procesas ne visada vykdomas taip kaip pateikiama schemoje.
Pradinė ir detali analizė gali būti vykdomos atskirai ir nepriklausomai viena nuo kitos. Kokią
analizę reikia atlikti priklauso nuo projekto dydžio, projekto vykdymo etapo bei susitarimo. Jeigu
kuriama sistema yra mažos apimties arba kuriamas produktas tik papildo jau esantį funkcionalumą
pradinė analizė gali būti visiškai praleidžiama ir atliekama tik detali analizė. Tačiau, jeigu yra
pradedamas naujas projektas yra rekomenduojama atlikti pradinę analizę tam, kad būtų išsiaiškinta
tolimesnių darbų apimtis. Pradinę analizę galima naudoti ir kaip tolimesnių darbų apimties
skaičiavimo būdą.

22
 Pradinė
analizė

Detali
analizė

5 pav. Analizės veiklos procesas [sudaryta autorės]

Analizė pradedama nuo pradinių dokumentų analizės. Prasidėjus informacinės sistemos

kūrimo procesui iš kliento gaunami dokumentai apie būsimą sistemą. Dažniausiai tai labai
abstrakčiai aprašyti reikalavimai būsimos sistemos funkcijoms. Gavus tokį dokumentą atliekama jo
analizė tam, kad suprasti ko klientas nori iš būsimos sistemos, kokios funkcijos bus sistemoje, kokio
dydžio bus sistema, kokie sunkumai laukia kuriant sistemą ir išsiaiškinti kitą svarbią informaciją,
kuri būtina norint suprasti kliento lūkesčius ir suvienodinti supratimą apie būsimą sistemą.
Analizuojant sistemą pagal pradinius dokumentus yra paruošiamas vizijos dokumentas.
Jame analitikas ir kiti komandos nariai pateikia savo supratimą apie būsimą sistemą pagal pateiktus
dokumentus. Paruošus šį dokumentą jis yra derinamas su klientu, kad būtų vienodai suprantami
poreikiai. Pagrindinės vizijos dokumento dalys:
1. Verslo poreikiai
1.1.Dabartinė situacija
23
 1.2.Galimybės ir poreikiai
1.3.Verslo tikslai ir sėkmės kriterijai
1.4.Vartotojų ar rinkos poreikiai
1.5.Verslo rizikos
2. Sprendimo vizija
2.1.Vizijos apibrėžimas
2.2.Sistemos konteksto diagrama
2.3.Pagrindinis funkcionalumas
2.4.Prielaidos ir priklausomybės
3. Apimtis ir apribojimai
4. Verslo kontekstas
4.1.Suinteresuotų asmenų profiliai
4.2.Projekto prioritetai
4.3.Veikimo aplinka
Užpildžius šį dokumentą turima pirmine informacija, kurią turi komanda, jis yra
pateikiamas klientui. Klientas papildo, pataiso ar visai nesutinka su viskuo arba kai kuriomis
dokumento dalimis. Jeigu pirminiai dokumentai pateikiami pakankamai išsamūs, vizijos
dokumentas užpildomas teisingai ir iš kliento pataisymų nebūna. Tokiu būdu komanda ir klientas
pradeda diskusiją apie būsimą sistemos funkcionalumą.
Pradėjus aiškintis kokie veiklos procesai bus automatizuojami sistemoje pradeda aiškėti
kokia bus projekto apimtis – kiek darbų turės būti padaryta ir kiek laiko tai užtruks. Dažnai
pasitaiko, kad darbų kiekis išauga projekto vykdymo metu, todėl yra svarbu pradžioje tiksliai
susitarti kokios sistemos funkcijos bus įgyvendintos, kiek laiko yra projekto įvykdymui ir išskirti
prioritetus funkcionalumui. Prioritetai padeda suvaldyti projekto apimtį projektui perėjus į antrąją
projekto realizavimo dalį.
Suderinus vizijos dokumentą ir projekto apimtį su klientu analitikas atlieka detalę analizę
jau aptartų funkcijų. Būtent šio proceso metu iškyla daugiausiai nesusikalbėjimo, nesusipratimo ir
nesiklausymo problemų.
Detalios analizės rezultatas pateikiama kaip reikalavimų specifikacija. Teoriniai ir
praktiniai patarimai kaip specifikuoti reikalavimus yra aprašyti skyriuje 7 Analizės rezultatas –
reikalavimų specifika, 48 psl.

24
 4.2. Iškylančių problemų apžvalga

Analizės metu iškyla problemų, kurias būtina spręsti iškarto norint išvengti nesusipratimų
vėlesniame analizės ir IS kūrimo procese. Visos iškilusios problemos tiesiogiai daro labai didelę
įtaką visam IS kūrimo procesui. Šiame skyriuje bus aptartos svarbiausios ir dažniausiai iškylančios
analizės procese problemos.
Šiame skyriuje yra pateiktos kelios itin svarbios problemos kylančios technologijų srityje,
kurios nagrinėjamos technologijų ir sociologijos ryšio teorijoje. Tai interpretacijos lankstumas ir
supratimo-susikalbėjimo problemų sprendimas. Šiame skyriuje atskleidžiama komunikacijos
proceso ir komunikacijos įgūdžių svarba analizės procesui.
Šiame skyriuje pateikiamos analizės procese kylančios problemos iš autorės darbo patirties.

4.2.1. Analitiko, kliento ir komandos komunikacija

6 pav. Analitiko, kliento ir komandos komunikacija

Aukščiau pateiktas paveiksliukas (6 pav.) iliustruoja su kuo sistemų analitikas

komunikuoja kuriant informacinę sistemą:
• Klientas – informacinės sistemos užsakovas.
• Projekto vadovas.
• Programuotojų komanda.
• Testuotojų komanda.
• Dokumentuotojų komanda.

25
 Matome, kad su klientu bendrauja tik projekto vadovas ir sistemų analitikas. Kiti
komandos nariai neturi galimybės bendrauti su klientu. Nesant tiesioginiam kontaktui atsiranda
vienas kito nesupratimas - nesusikalbėjimas. Analitikas, projekto vykdymo komandoje, yra kliento
poreikių atstovas. Jis turi komandai išdėstyti visus kliento poreikius taip, kad likę komandos nariai
suprastų kas, kaip ir kodėl turi būti realizuota.
Šios situacijos problema ta, kad komanda neturėdama tiesioginio kontakto su klientu
sunkiai įsivaizduoja jo poreikius ir dažnu atveju nenori sutikti, kad reikia vienokių ar kitokių kliento
pageidaujamų funkcijų. Geriausiai problema pastebima, kai jau yra atlikta dalis darbo ir ji
pateikiama kliento vertinimui.
Galima įtarti, kad ši problema kyla dėl nepakankamo kliento įtraukimo į analizės procesą
arba netinkamo reikalavimų specifikavimo. Tačiau nereikia atmesti galimybės, jog sistemų
analitikas neteisingai suprato klientą dėl komunikacijos įgūdžių trūkumo.
Kiekvienos funkcijos svarbumą ir būtinumą sistemoje kiekvienas proceso dalyvis vertina
pagal savo turimas žinias bei įsitikinimus, todėl kas reikalinga klientui gali atrodyti visiškai
nereikalinga IS kūrimo komandai. Praktikoje tai dažnai pasitaikantis nesutarimas. Remiantis autorės
darbo patirtimi siūlomas sprendimas būtų kuo ankstesnėje programavimo stadijoje parodyti sistemą
jos užsakovui ir leisti įvertinti esamų funkcijų tikslumą, kad kliento pasitenkinimas sistema pasiektų
ir kitus komandos narius. Nors sistema dar tik pradinėje kūrimo stadijoje, bet to pakanka, kad
klientas susidarytų pirmą įspūdį apie būsimą sistemą ir galėtų įvertinti jos tinkamumą jo poreikiams.

Nr. Analitiko, kliento ir komandos komunikacija - situacijos aprašymas

1. Sistemų analitikas kelias valandas diskutavo su klientu. Buvo aptariami sistemos
reikalavimai, funkcionalumas bei verslo procesai, kurie bus automatizuojami. Gauta
informacija dokumentuojama arba žodžiu pateikiama komandai. Prasideda diskusijos apie
funkcionalumą, galimybes jas realizuoti ir kliento pageidaujamo funkcionalumo
„patobulinimą“. Šios diskusijos baigiasi pakeistu funkcionalumu, t.y. realizuojama jau
kitoks funkcionalumas negu pageidavo klientas.

4.2.2. Sistemingas informacijos perdavimas

Vienas iš svarbiausių analitiko darbų – rinkti informaciją. Tačiau vien surinkti informaciją
iš kliento neužtenka, ją būtina tiksliai ir sistemingai perduoti komandai. Labai dažnai pasitaiko, kad
kliento norai projekto metu kinta. Tai visai suprantamas dalykas, nes diskutuojant apie būsimą
sistemą kliento supratimas, kaip tai veiks, keičiasi ir jam reikia kitokio funkcionalumo.

26
 Keičiantis kliento nuomonei atsiranda informacijos perdavimo problema. Analitikas turi
perduoti naują ar pasikeitusią informaciją visai informacinės sistemos kūrimo komandai.
Pasikeitimus galima rašyti dokumentacijoje, tačiau jei projektas yra didelis dokumentacijos bus ne
dešimt lapų, o šimtas arba daugiau, tai tampa netinkamu būdu perduoti informacijai. Be to yra
sunku atsekti dokumento pasikeitimus po kiekvieno susitikimo su klientu.
Kokiu būdu informacija bus perduodama ir kokiu dažnumu bus perduodami informacinės
sistemos reikalavimų pasikeitimai komandai yra kiekvienos komandos susitarimo reikalas. Tačiau
tai būtina susitarti nuo pat projekto vykdymo pradžios, kol dokumentų apimtis yra nedidelė. Vėliau
projektui įsibėgėjus pakeisti komandos narių įpročius šiuo klausimu yra labai sunku ir problema
tampa nebeišsprendžiama, o tik sukelia begalę papildomų problemų.

Nr. Sistemingas informacijos perdavimas - situacijos aprašymas

1. Kaip taisyklė, klientams visada svarbiau būna grafinė vartotojo sąsaja negu pats sistemos
funkcionalumas. Tai gi klientas ilgai galvoja ir renkasi kokios spalvos turi būti fonas ar
kokio dydžio ir kur sistemoje turi būti išdėlioti mygtukai. Po ilgų apmastymų jis
nusprendžia, kad sistemos fonas turi būti žalias ir nesileidžia į jokias diskusijas, kad kitaip
būtų geriau. Analitikas perduoda visą gautą informaciją programuotojams, kurie realizuoja
kliento pageidavimą. Kai klientas pagaliau pamato kaip atrodo jo „žalia“ sistema jis
persigalvoja ir informacijos perdavimo ciklas kartojasi.

4.2.3. Terminologija

Kiekviena veiklos sritis turi savo specifinius terminus. Pasitaiko atvejų, kai naudojami tie
patys žodžiai ar apibrėžimai visai kitomis ar žymiai platesnėmis prasmėmis. Projekto pradžioje
būtina susidaryti terminų žodyną, kuris leistų suvienodinti supratimą ir atsikratyti stereotipų. Tai
viena iš priežasčių kodėl komandoje ir bendraujant su klientu atsiranda nesusikalbėjimas, vienas
kito nesupratimas.
Neišsklaidžius asociacijų ir stereotipų projektas vykdomas ilgiau, jame atsiranda daugiau
klaidų netinkamame funkcionalume, tiek komanda tiek klientas praranda pasitenkinimą atliktu
darbu, kas savo ruožtu mažina motyvaciją dirbti.
Tinkamai paruoštas terminų žodynas padeda tinkamai apibūdinti artefaktą taip
sumažinamas interpretavimo lankstumas. Tai tik vienas iš būtų sumažinti šią problemą.

27
Nr. Terminologija - situacijos aprašymas.

1. Tarkime kuriama sistema yra susijusi su piniginėmis operacijomis ir jų tvarkymu. Tokioje

sistemoje bus gausu terminų ekonominių terminų, tokiu kaip: balansas, išrašas, finansinė
ataskaita, išlaidos ir kt.
Visi terminai vienokiame ar kitokiame kontekste yra girdėti ir žinomi, tačiau kas iš tikrųjų
slepiasi po šiais terminais būsimoje sistemoje ir kokios taisyklės jiems turės būti taikomos
– paslaptis. Šią paslaptį ir nesusikalbėjimo šaltinį galima pašalinti sudarant terminų žodyną.

4.2.4. Supratimo suvienodinimas

Supratimo suvienodinimas – pagrindinis analitiko darbas.

Nuomonių skirtumas ir supratimo nesutapimas yra labai svarbus nagrinėjant sistemų
analitiko darbo ypatumus. Tai viena iš pagrindinių priežasčių, kodėl analitikas yra toks svarbus
informacinių sistemų kūrimo procese, jis padeda suvienodinti skirtingų socialinių grupių supratimą.
Interpretacija taip pat yra labai svarbi šios nagrinėjamos temos dalis. Dėl skirtingų socialinių grupių
IS užsakovai turi skirtingas interpretacijas apie tuos pačius dalykus, o sėkmingai sukurti nauja IS
galima tik tuo atveju, jeigu bus suvienodintas supratimas – panaikinta interpretacija.
Norint, kad klientas ir komandos nariai būtų patenkinti gautu produktu ar savo darbu, labai
svarbu yra suvienodinti supratimą apie būsimą informacinę sistemą. Tam yra būtini bendravimo
įgūdžiai, analizės įgūdžiai ir kitos asmeninės žmogaus savybės, kurios padeda įsiklausyti į kliento
bei komandos poreikius ir galimybes juos įgyvendinti.
Žemiau pateiktas 7 paveikslas iliustruoja dviprasmiškumą – jauną ir seną moterį viename
paveiksle. Analizės proceso metu dažnai susiduriama su tokia pat problema. Pokalbio metu atrodo,
kad abu pašnekovai šneka apie tuos pačius dalykus, tačiau pateikus rezultatą paaiškėja, kad kalba
buvo apie skirtingus dalykus dėl prieš tai esančiame skyriuje minėtos terminologijos arba šiuo
atveju interpretacijos lankstumo.

28
 7 pav. Dviprasmiškumas – neatsiejama analizės proceso dalis [71]

Norint išvengti papildomų interpretacijų reikia klientui pateikti klausimus, kurie turėtų
konkretų atsakymą. Jeigu klausimas yra labai abstraktus rekomenduojama jį išskaidyti į keletą
smulkesnių klausimų. Taip pat sistemos analitikui būtina susipažinti su dabartine kliento darbo
aplinka, kad susidarytų tinkamą supratimą kam reikalinga sistema, kaip ji bus naudojama, kokias
funkcijas ji pakeis ar patobulins, kas dirbs su sistema.
Ši problema yra susijusi su artefakto aprašymu bei interpretacijos lankstumu. Kuo daugiau
informacijos gaunama iš kliento pirmųjų susitikimų metu, tuo tiksliau galima apibrėžti kliento
poreikius būsimai sistemai.

Nr. Supratimo suvienodinimas - situacijos aprašymas.

1. Blogas klausimas: Kaip turi veikti sistema?
Atsakymas: gerai.
Iš to jokios informacijos nesužinome. Rekomenduojama skaidyti į:
• Kokie procesai bus vykdomi sistemoje?
• Kokius procesus automatizuos sistema, kuriuos dabar atliekate ne skaitmeninėje
erdvėje?
• Kokie duomenys turės būti saugomi sistemoje?
Kiekvieną iš pateiktų klausimų galima dar skaidyti ir gauti dar tikslesnius atsakymus, tačiau
daug kartų klausti to paties nerekomenduojama. Keletą kartų apie tą patį dalyką būtina
klausti tik tuo atveju, kai atsiranda nesusikalbėjimas ar skirtingas supratimas to paties
dalyko. Gavus atsakymą į klausimą rekomenduojama pasitikslinti ar tikrai taip supratote

29
atsakymą.
Kartais pasitaiko, kad suformuoti klausimą taip, kad abi pusės suprastų, yra labai sudėtinga,
tada rekomenduojama pasinaudoti paišymo įrankiais. Tokiu būdu išdėstyti savo
įsivaizdavimą, o klientas arba analitikas, priklauso nuo to, kuris pateikė klausimą, pataisys
ir padės suvienodinti supratimą.
Pvz. Klientas išreiškė norą, kad jam būtų suprojektuotas namas. Jis turi būti medinis,
nedidelės kvadratūros, vieno aukšto. Analitikas interpretavo, kad tai medinis vasarnamis.
Klientas norėjo namo savo šuniui.
Klaidos:
1. Analitiko interpretacija.
2. Netikslūs klausimai – abstraktūs atsakymai.
3. Supratimo nesuvienodinimas.
Patarimas: prieš pradedant interpretuoti kliento poreikius, reikia dar kartą pasiklausti „Ar tai
turi būti vieno aukšto medinis vasarnamis?“. Klientas išgirdęs tokį klausimą tikrai jį
pataisys ir bus išvengta nesusipratimo.
Supratimo suvienodinimą galima išspręsti:
1. Labiau įtraukiant klientą į analizės procesą.
2. Plačiau aprašinėjant surinktus reikalavimus.
3. Pasitelkiant komunikacijos įgūdžius.

30
 4.3. Apibendrinimas

Šiame skyriuje aprašytos keturios dažniausiai analizės procese pasitaikančios problemos:

1. Analitiko, kliento ir komandos komunikacija.
2. Sistemingas informacijos perdavimas.
3. Terminologija.
4. Supratimo suvienodinimas.
Trys iš keturių problemų yra tiesiogiai susijusios su bendravimu ir bendravimo įgūdžiais.
Visas kylančias problemas galima spręsti standartizuojant analizės procesą, apibrėžiant
dokumentus, kuriuos turi pateikti sistemų analitikas, tačiau ar tai pagerins patį analizės procesą?
Autorės nuomone, analizės procesui neužtenka vien techninių žinių. Norint patobulinti analizės
procesą ir gauti geresnį rezultatą, reikia suteikti analitikui ne tik techninių žinių, bet ir supažindinti
jį su komunikacijos procesu, verbaliniu ir neverbaliniu bendravimu bei kitais komunikacijai
svarbiais dalykais. Dėl šių priežasčių kitame skyriuje yra apžvelgiamas komunikacijos procesas ir
kokią informaciją iš jo gali gauti sistemų analitikas.

31
 5. KOMUNIKACIJOS PROCESAS LITERATŪROJE IR JO
ĮTAKA ANALIZĖS PROCESUI

Atliekant analizę svarbiausia yra „tikslus“ bendravimas. Teisingai suformuluoti klausimai

suteikia galimybę gauti tikslius atsakymus ir kiek galima tiksliau iškarto išsiaiškinti kliento
poreikius, taip įvertinant visas galimas informacinės sistemos kūrimo rizikas.
Remiantis informacija, kuri pateikta 3 Informacinių sistemų kūrimo procesas – projekto
realizavimas, 18 psl., skyriuje yra žinoma, kad informacinės sistemos kūrimas pradedamas nuo
analizės proceso. Analizės metu yra bendraujama su klientu bei komandos nariais. Siekiant
užtikrinti būsimos sistemos kokybę bei kliento poreikių išpildymą analitikas turi surinkti visus
informacinei sistemai keliamus reikalavimus, o tai padaryti galima tik komunikuojant.
Toliau šiame skyriuje pateikiamas bendras komunikacijos procesas, komunikacijos būdai,
ką verta žinoti apie savo pašnekovą bei bendravimo daroma įtaka analizės procesui.

Komunikacijos procesas susideda iš tokių pagrindinių dalių [17, 37]:

1. Siuntėjas
2. Užduotis
3. Užduočiai reikalingas laikas
4. Žinutės perdavėjas
5. Gavėjas bei atsakas

32
 8 pav. Komunikacijos procesas

Iš pateikto paveikslo (8 pav.) matoma, kad pirmas žingsnis analizės procese yra sistemų
analitiko. Jis turi gebėti tinkamai bendrauti, pateikti savo mintis visiems suprantamais sakiniais.
Būtina aiškiai pateikti „užduotį“, kad gavėjas galėtų pateikti išsamų atsaką.
Antra svarbi užduotis yra tinkamai suformuoti „užduotį“ – klausimą. Kuo klausimas
abstraktesnis, tuo atsakymas bus abstraktesnis ir realios naudingos informacijos nebus gauta. Tai gi
analitikas turi tiksliai suformuoti klausimą, kad gautų reikiamą tikslią informaciją apie būsimą
sistemą.
Trečias žingsnis, tai laikas užduočiai – klausimui. Pateikiant klausimą svarbu neskubėti ir
aiškiai išreikšti mintis. Stengiantis greičiau išdėstyti mintis dažnai susiduriama su problema, kad
mintys dėstomos padrikai ir neišreiškiama pagrindinė mintis. Dėl šių priežasčių klientas gali
nesuprasti ko iš jo tikimasi ir atsakymas gali būti visai nesusijęs su klausimu.
Ketvirtas dalykas yra žinutės perdavėjas – bendravimo būdas. Bendravimas gali vykti
tiesiogiai – susitikus akis į akį. Susitikimo metu atsiradus nesusikalbėjimui galima pasitelkti ne tik
kalbines priemones, bet ir kitas vaizdines priemones, kurios padeda susikalbėti ir išsiaiškinti bendrą
supratimą apie objektą, kuris bus kuriamas. Tai gali būti įsivaizdavimo paišymas. Bendrauti galima
telefonu ar kita panašia technologija, kuria galima bendrauti balsu, tačiau siuntėjas nemato gavėjo ir
atvirkščiai. Bendraujant šiuo būdu yra sunkiau susikalbėti ir užtikrinti bendravimo tikslumą. Taip
pat klausimus klientui galima pateikti elektroniniu paštu. Tokiu būdu bendraujant yra dar sunkiau
33
užtikrinti, kad klausimai būtų pateikiami klientui suprantamu būdu ir atsakymai būtų į pateiktus
klausimus, o ne kliento įsivaizdavimas, kuris neatitinka klausimų. Bendraujant elektroniniu paštu
yra didelė tikimybė, kad siuntėjas ir gavėjas nesupras vienas kito.
Penktas svarbus dalykas yra gavėjas ir jo atsakas į pateiktą „užduotį“ – klausimą.
Priklausomai nuo bendravimo būdo atsakymai pateikiami žodžiu arba raštu. Kaip buvo paminėta
ankščiau lengviausia bendrauti yra tiesiogiai, bet svarbu nepamiršti, kad klientui reikia laiko
apgalvoti atsakymą, kad jis nebūtų priimtas paskubomis ir kito susitikimo metu atsakymas nebūtų
pakeistas. Todėl rekomenduojama prieš susitikimą klientui pateikti klausimus elektroniniu paštu, o
juos atsakyti ir aptarti nesutarimus tiesioginio susitikimo metu. Taip klientas spės pasiruošti
atsakymus, o analitikas gaus reikiamus atsakymus, o klausimai bus suprasti ir išsiaiškinti teisingai.

5.1. Neverbalinis ir verbalinis bendravimas

Bendravimas - tai prasminga sąveika tarp dviejų ar daugiau žmonių. Bendravimo prigimtis
įžvelgiama žmogaus saviraiškoje, jo sugebėjime perduoti kitiems žmonėms tai, ką galvojame,
jaučiame, kokiais matome save ir mus supančią aplinką. Bendraudami žmonės ne tik sąveikauja, bet
ir pažįsta vienas kitą. Asmuo, bendraujantis su kitu, siekdamas geriau suprasti pašnekovą ir
svarstomą problemą, pats atsiveria. [11]
Norint teisingai atlikti analizę reikia žinoti pagrindinius bendravimo principus ir suprasti
verbalinį bei neverbalinį bendravimą. Dauguma žmonių mano, kad žodžiais pateikiama informacija
yra pagrindinė bendravimo ir informacijos pateikimo priemonė. Deja, žodžiais pateikiama tik apie 7%
visos informacijos. Informacija gaunama iš balso tono sudaro apie 38%. Tai gi žymiai svarbiau yra
ne kas, o kaip buvo pasakyta. Pateikiant informaciją monotonišku balsu auditorija gali ne tik
nesuprasti kas buvo pasakyta, bet gali net gi neišgirsti svarbių dalykų. Likusius 55% informacijos
bendraudamas žmogus gauna iš neverbalinių signalų. [6]
Analizės metu, bendraujant tiesiogiai su klientu, gaunama labai daug informacijos
neverbaliniu būdu. Iš akių galima suprasti ar tinkamai pateikiami ir formuluojami klausimai klientui,
ar klientui suprantama ir įdomu tai apie ką vyksta pokalbis. Tai akivaizdžiai pastebima, kai pokalbis
pakrypsta apie techninius dalykus, o klientą atstovauja verslo srities žmogus. Pašnekovas praranda
susidomėjimą pokalbiu, nusuka akis į šoną, sukryžiuoja rankas ir kojas, taip užsiblokuodamas nuo
aplinkos. Tokiu atveju reikia nutraukti pokalbį apie techninius dalykus, kurių pokalbio dalyviai
neišmano, ir grįžti prie klausimų iš tos srities, nuo ko buvo pradėtas pokalbis. Lygiai tokia pati
situacija, iš kitos pusės, gali susiklostyti, jei bus užduodami klausimai apie verslo procesą žmogui,
kuriam atsakomybė paskirta už techninius sprendimus.

34
 5.1.1. Neverbalinis bendravimas

Akys. Akių kontaktas turi keletą funkcijų. Viena iš jų – pažintinė. Tiesioginis akių
kontaktas rodo susidomėjimą ir norą ką nors sužinoti. Bendraujant klausytojas dažniau naudoja akių
kontaktą negu kalbėtojas. Akių kontaktas gali reguliuoti pašnekovų sąveikavimą. Žvilgsniu galima
nurodyti bendravimo pradžią. Akių išraiška gali parodyti, kaip mes jaučiamės tam tikroje situacijoje.
Akys parodo susidomėjimą asmeniu, su kuriuo kalbamės, ar daiktu, kurį apžiūrinėjame. Nustebimas,
sumaištis, baimė, pyktis, nusiminimas, laimė, linksmumas geriausiai matomas iš akių išraiškos. Kai
žmonės kalba, jie naudoja akių kontaktą tam, kad pamatytų, kokią įtaką jų kalba daro klausytojui.
Kalbėtojas atidžiai žiūrėdamas į klausytoją bando išsiaiškinti ką jis galvoja. Akių kontaktas gali būti
naudojamas bendravimui per nuotolį: jei žmonės bendrauja būdami vienas nuo kito per didelį
atstumą, jie dažniau žiūri vienas kitam į akis negu būdami arti vienas kito. Savo knygoje The Tell-
Tale, Eye Hess’as teigia, kad akių gestai yra bene išsamiausi ir objektyviausi žmogaus neverbaliniai
signalai, nes jos yra nuolatinis mūsų stebėjimo objektas, o vyzdžiai išsiplečia ir susitraukia
nepriklausomai nuo mūsų valios .[19]
Garsinė informacija. Informaciją gali perduoti ir balso išraiška, pavyzdžiui, juokas,
verksmas, šauksmas. Nė vienas iš šių garsų nėra žodžiai, bet iš jų galime labai daug suprasti. Balso
išraiškai priskiriami ir dažnai kalbėtojų vartojami garsai ir pagalbiniai žodeliai: „o“, „a“, „matote“,
„žinote“, „vadinasi“, „taip sakant“, „žodžiu“ ir kt. Jie tarsi papildo tai, ką norima pasakyti. Taip pat
prie balso įtakos priskiriamos ir pauzės, tačiau ne pauzės tarp žodžių ar sakinių, bet apskritai kalbos
pauzės, tai yra tylėjimas.
Apranga bei išvaizda. Drabužiai skirti ne vien tik šilumai palaikyti, kūnui apsaugoti ar
slėpti. Jie beveik visada skirti ir informacijai perteikti. Šią informaciją mums suteikia drabužių
spalva, sukirpimas, nešiojimo stilius, jų buvimas ar nebuvimas. Drabužiai nusako žmogaus
socialinę padėtį, grupinę priklausomybę, agresyvumo laipsnį, lytinę orientaciją ir panašiai. Vien iš
aprangos atskirsime futbolo sirgalių, valstybės tarnautoją arba roko gerbėją ir pagal tai spręsime,
bendrauti su juo ar ne bei koks bus šis bendravimas. Ypač daug ir labai aiškios informacijos apie
bendravimo pobūdį mums suteikia uniforma. Puikiai suprantame, kokio bendravimo stiliaus galime
laukti susitikę uniformuotą policininką, lėktuvo stiuardesę ar sporto komandos narį. Be abejo,
apranga kartais apgauna. Didžiulį aprangos poveikį žino ir patyrę sukčiai bei aferistai, visada daug
dėmesio skiriantys nepriekaištingai pasiūtiems, prabangiems drabužiams. Apie tai, kiek galima
pasiekti pasinaudojus svetima uniforma, liudija filmai apie žvalgus bei bankų plėšikus. Minėtieji
pavyzdžiai rodo apie apranga perduodamos informacijos svarbą bei jos daromą įtaką.

35
 Mus puošia ne tik drabužiai. Moterys pasidabina auskarais, užsimauna žiedus, dažosi veidą
ar lakuoja nagus. Kartkartėmis apsikerpame; vyrai gali užsiauginti arba nusiskusti barzdą. Visi šie
grožio atributai taip pat yra saviti informacijos šaltiniai.
Dauguma minėtų išvaizdos elementų yra laikino pobūdžio: auskarus galima išsisegti,
žiedus nusimauti, plaukus ar barzdą nusikirpti ar vėl užsiauginti. Tačiau kai kurie papuošimai yra
nuolatiniai. Pavyzdžiui, labai įvairiose kultūrose yra paplitusi tatuiruotė. Tai nuolatinė kūno
papuošimo forma. Tatuiruotės paprastai būna labai informatyvios. Jos gali pasakyti apie žmogaus
profesinę priklausomybę (pavyzdžiui, jūrininko tatuiruotė - inkaras), ideologinę orientaciją, kalinio
tatuiruotė - apie padaryto nusikaltimo rūšį.
Daiktų įtaka. Dažnai romane apie žvalgus aprašoma, jog kaip sutartą atpažinimo priemonę
susitikimo metu ryšininkas laiko rankoje kokį nors ženklą, pavyzdžiui, tam tikros dienos laikraščio
numerį arba gėlių puokštę. Tai puiki iliustracija, rodanti, kokią svarbią informacinę reikšmę gali
įgyti su savimi turimi daiktai. Daiktai gali suteikti informaciją apie mūsų fizinę būseną, sakysim,
akiniai rodo silpną regėjimą, o lazda - su vaikščiojimu susijusius sunkumus. Jie taip pat atskleidžia
ir dvasinę būseną: rankoje laikoma gėlių puokštė, simbolizuoja džiaugsmingą susitikimo laukimą,
kumštyje sugniaužta nosinė - sielvarto ašaras, ir panašiai. Neretai daiktai rodo asmens profesinę
priklausomybę, pavyzdžiui, laiškanešio krepšys ar kiemsargio šluota. Pagal turimus daiktus, bei jų
kokybę galima spręsti ir apie žmogaus užimamą padėtį visuomenėje; neatsitiktinai jiems tiek daug
dėmesio skiria tie asmenys, kuriems itin svarbu pabrėžti turimą socialinį statusą. Geros odos
rankinukas, brangus skėtis, įmantri pypkė ar meniškai drožinėta lazda - visa tai yra savotiški
socialinės padėties simboliai.
Gestai. Gestai visada papildo mūsų kalbą, parodo kokios būsenos esame, pvz.: supykę,
susijaudinę. Kai kuriems žmonėms gestai yra neatsiejama gyvenimo dalis. Kurti žmonės susikalba
vien tik gestų pagalba.
Dauguma gestų vartojame nevalingai, kai esame susijaudinę. Dažnai prieš einant į svarbų
pokalbį mes nevalingai sukiojame švarko sagą ar taisome savo šukuoseną kelis kartus, kitus dažnai
apima rankų drebulys, prakaituoja delnai. Tačiau susivaldantis žmogus gali naudoti gestus
tikriesiems jausmams nuslėpti. Jeigu smarkiai gestikuliuosime, pašnekovui atrodys, kad esame
smarkiai susijaudinę, kai iš tiesų galime būti visiškai abejingi tam, kas sakoma. Priešingai, jeigu
žinodami nevalingų gestų reikšmę, sugebėsime juos suvaldyti, mus gali palaikyti labai santūriu
žmogumi, nors tokiu galime ir nebūti. Todėl požiūris, kad gestai, skirtingai nuo žodžių, visada
atskleidžia tiesą, yra gerokai suprastintas. Abiem šiais bendravimo būdais galima pateikti ir teisingą,
ir klaidingą informaciją.

36
 Aplinka. Kai kurie aplinkos efektai gali ypatingai veikti mūsų bendravimą. Įtakos gali
turėti spalva ir kambario dydis. Mėlyna ir žalia spalva padeda atsipalaiduoti, sukuria ramią
atmosferą. Geltona ir oranžinė spalva padidina žmonių energingumą. [69]
Laikas. Bendraujant labai svarbus yra laikas. Prieš atsakydamas į klausimą žmogus padaro
pauzę, kad apmastytų ir geriau suformuluotų atsakymą. Kai kuriuos dalykus kur kas lengviau aptarti
vakare negu iš ryto. Supratus laiko reikšmę, bendravimą galima padaryti žymiai efektyvesni.
Neverbalinių bendravimo būdų yra žymiai daugiau nei čia aprašyta, tačiau paminėtieji yra
patys svarbiausi analizės proceso metu bendraujant su klientu.

5.1.2. Verbalinis bendravimas

Verbalinės bendravimo formos yra dvi: Informacija perduodama žodžiu, informacija

perduodama raštu. Verbalinis bendravimas – tai tarpusavio sąveika naudojant kalbos ženklus tarp
dviejų ar daugiau žmonių. Neverbalinio bendravimo metu informacija perduodama ne kalba, o
kitais ženklais. [23]

5.1.2.1. Bendravimas žodžiu

Kalbėjimas. Kalbėjimo efektyvumas priklauso nuo: balso tono, moduliacijos, greičio,

garso stiprumo ir slopinimo. Nuo šių elementų priklauso informacijos suvokimas, užkodavimas ir
persiuntimas.
Pati kalba. Kalba turi būti sklandi, tiksli ir aiški. Pasitaiko, kad vienas žodis turi kelias
reikšmes ir bendraujant panaudojama netinkama žodžio reikšmė. Netinkamai panaudotas žodis -
pavojingiausias faktorius bendravimo procese. Reikia vengti sunkiai suprantamų, retai naudojamų
žodžių. Tokiu būdu teisingas pranešimas dažniausiai tampa klaidingu. Geri kalbininkai privalo
mokėti kalbėti aiškiai, sklandžiai, tiksliai ir visiems suprantama kalba.
Balso tonas ir moduliacija. Didelį dėmesį kreipiame į tai, kaip žmogus kalba, t. y. į balso
toną. Balso tonas priklauso nuo to, kaip mes kalbame: užtikrintai, nedrąsiai, agresyviai, piktai,
inertiškai, pasyviai, susinervinę ir t.t.. Moduliacija - tai tono pasikeitimas, t. y, - garso pasikeitimas
(pažeminimas ar paaukštinimas) pustoniu arba tonu. Valdytojai bendraujant turi skirti ypatingą
dėmesį į balso toną ir moduliaciją. Tai labai svarbūs bendravimo elementai, užtikrinantys efektyvų
bendravimą.

37
 Greitis ir garso stiprumas. Bendravimo efektyvumas priklauso nuo to, kaip mes kalbame,
greitai ar lėtai. Nervuoti žmonės dažniausiai kalba daug greičiau, negu savimi pasitikintys, ramūs.
Geriausi rezultatai pasiekiami, kai kalbame nei per greitai, nei per lėtai (turi būti pusiausvyra).
Garso stiprumas gali būti streso rezultatas. Tvirtai pasakytas sakinys įrodo, kad jis yra svarbus.
Nereikšminga informacija nėra užtvirtinama ir pabrėžiama. Tokie reiškiniai sąlygoja garso stiprumą.
Garso silpnumas (tyla). Pauzės, nutylėjimai, nustebimai ir žiopsojimai sąlygoja garso
silpnumą arba, kitaip tariant, tylą. Tačiau ne visada pauzės daromos tada, kai neturime ką pasakyti,
kartais pauzė daroma tada, kai ruošiamės užakcentuoti labai svarbią informaciją.
Klausymas. Tai antra labai svarbi žodinio bendravimo proceso dalis. Patarimai, reikalingi,
kad klausymas būtų efektyvus.
1. Kalbėdami nesiblaškykite.
2. Būkite oportunistas. Suraskite bendrų interesų tarp savęs ir pašnekovo.
3. Jokiu būdu nežiovaukite ir nesvajokite, jei pašnekovas kalba lėtai ir neįdomiai.
4. Stenkitės suprasti pašnekovo tikslą.

5.1.2.2. Bendravimas raštu

Balso tono moduliacija, greičio, garso silpnumo ir stiprumo atžvilgiu, bendravimas raštu
yra efektyvesnis, negu žodžiu. Tačiau nėra jokio skirtumo, kaip bendraujame, svarbu, kad
bendravimas būtų efektyvus. Bendraujant raštu svarbiausia, kad raštu perduota informacija būtų
išreikšta aiškiai, tikslai ir suprantamai. [10]

5.2. Bendravimo įtaka analizei

Analizę be bendravimo būtų neįmanoma atlikti, todėl žemiau esančioje 2 lentelėje yra
pateikti ryšiai tarp neverbalinio/verbalinio bendravimo ir analizės proceso. Iš neverbalinio
bendravimo analitikas gauna daug informacijos apie būsimo susitikimo eigos sklandumą, apie
atsakymų aiškumą bei tvirtumą, gali daryti prielaidas ar verta tęsti susitikimą ar geriau atidėti jį kitai
dienai.

2 lentelė
Neverbalinio ir verbalinio bendravimo įtaka analizės procesui
Bendravimo
Aprašymas Daroma įtaka analizei
būdas

38
 Pokalbio metu
matoma ar
pašnekovas yra Analizės metu iš akių galima matyti ar klientas yra
Akys susidomėjęs tikras tuo ką sako ar geriau pasitikslinti vėliau, pvz.
pokalbiu, ar supranta raštu.
apie ką vyksta
pokalbis.
Pokalbio metu Analizės metu iš pašnekovo juoko ar rimto tono galima
Garsinė iliustruoja suprasti ar klausimai yra taktiški, ar vertėtų pakeisti
informacija pašnekovo emocinę bendravimo taktiką, o galbūt net nukelti susitikimą kitai
būklę. dienai.
Drabužiai nusako
Bendraujant su klientu iš jo aprangos galima matyti ar
žmogaus socialinę
pokalbis bus labai oficialus, ar bendravimas bus
Apranga padėtį, grupinę
paprastas, galima laisvai bendrauti. Taip pat apranga
priklausomybę,
leidžia daryti prielaidas apie žmogaus mentalitetą.
agresyvumo laipsnį.
Daiktai atspindi
žmogaus fizinę ir
Daiktai kaip ir apranga leidžia numanyti kokio tipo bus
Daiktų įtaka dvasinę būsenas,
pokalbis, bei koks žmogaus požiūris į aplinką.
profesinę
priklausomybę.
Gestai parodo kokios Analizės metu bendraujant su klientu svarbu atkreipti
būsenos yra žmogus: dėmesį į jo kūno kalbą, dažnai tai gali išduoti
Gestai
piktas, susijaudinęs, nepasitenkinimą arba pritarimą tam tikrais klausimais,
linksmas. kai jo viršininkas (ne)sutinka su pasiūlymu.
Susitikimo metu reikia atidžiai rinktis vietą, kurioje jis
Aplinkos efektai gali vyks. Pvz. šviesiame kambaryje darbas bus žymiai
Aplinka ypatingai veikti efektyvesnis nei tamsioje patalpoje. Taip bendravimas
mūsų bendravimą. bus energingesnis ir bus gauta žymiai daugiau
informacijos ir analizė bus greičiau atlikta.
Bendraujant su klientu yra pateikiami klausimai, ne
Apmąstymo pauzės, visada klientas iš anksto gauna klausimus, kad galėtų
Laikas
susitikimo laikas. pasiruošti atsakymus, todėl būtina nepertraukti jo
apmąstymų – taip atsakymas bus tikslesnis ir

39
 išsamesnis. Susitikimo laikas taip pat labai svarbus, nes
kiekvieno žmogaus produktyvaus darbo laikas paroje
skiriasi, tačiau šį laiką tinkamai parinkti yra labai
sunku, ypač jei vykdomas trumpas projektas.
Bendraujant su klientu mintis reikia dėstyti aiškiai,
Kalbėjimo greitis, žodžius tarti raiškiai, priešingu atveju jis gali nesuprasti
raiškumas, balso ko jo klausiama. Balso tonas taip pat labai svarbu – jis
Bendravimas
tonas, kalbėjimo parodo Jūsų nusiteikimą (piktas, linksmas). Emocingai
žodžiu
garsumas, išsakytas klausimas gali būti suprastas kaip agresyvus ir
klausymasis. klientas gali pateikti neigiamą atsakymą. Tokiu atveju
reikės susitikti dar kartą, kad atlikti analizę.
Bendravimas raštu nėra toks informatyvus kaip
bendravimas susitikus, tačiau tam tikrais atvejais
Bendravimas laiškais
bendravimas raštu yra geresnis sprendimas nei
ar kitokiomis
Bendravimas susitikimas. Pvz. klientas piktas ir nenori leistis į
priemonėmis kur
raštu diskusijas, tokiu atveju geriau savo nuomonę išdėstyti
negalimas
raštu. Taip klientas turės laiko apsvarstyti pasiūlymą,
bendravimas žodžiu.
nebus spaudžiamas greičiau atsakyti, o radus
kompromisą bus raštiškas įrodymas dėl susitarimo.

40
 6. ANALIZĖS PROCESAS LITERATŪROJE

Šiame skyriuje pateikiama literatūros apžvalga, kitų autorių nuomonė bei patirtis apie
informacinių sistemų analizės procesą. Taip pat apžvelgiamos literatūroje nagrinėjamos analizės
procese iškylančios problemos.

6.1. Technologijų studijos

Literatūroje technologijų studijų tema skaidoma į tris pagrindines temas: inovacijų mokslas,
technologijų istorija ir technologijų sociologija.
Daugiausiai inovacijų studijų technologijose atliko ekonomistai ieškodami tinkamų sąlygų
inovacijų pasisekimui. Prieš išskiriant sociologijos svarbą kaip bendravimą, mokslo žinios buvo
traktuojamos kaip „juoda dėžė“. Analizuojant ekonomines inovacijas technologinėse inovacijose
yra įtraukiama viskas kas gali daryti įtaką inovacijoms, išskyrus technologinius sprendimus.
Apibūdinti inovacijų procesą, nesugebėjimas atsižvelgti į technologinių inovacijų rezultatų turinį,
plačiai naudojami paprasti linijiniai modeliai (9 pav.).

Pagrindiniai Taikomieji
Technologijų Produkto
moksliniai moksliniai Gamyba Naudojimas
vystymasis vystymasis
tyrimai tyrimai

9 pav. Inovacijų proceso šešių lygių linijinis modelis [70]

Nors tokie tyrimai, be abejo, daug prisidėjo prie supratimo apie technologinių inovacijų
ekonominės sėkmės sąlygas, bet jie nepaiso technologinio turinio, todėl negali būti naudojami
socialinio konstruktyvizmo požiūriui technologijų pagrindu.
Nagrinėjant technologijų sociologijos (angl. Sociology of technology) tikslą susiduriama
su dviem problemomis. Pirma iškylanti problema yra susijusi su aprašomąja istoriografija. Atrodo
tik nedaugelis mokslininkų buvo pajėgūs apibendrinti istorinius atvejus, dėl to sunku atskirti
bendras tendencijas, kuriomis paremta technologijų teorija.
Antroji problema susijusi su asimetriniu dėmesiu į analizę. Buvo atkreipiamas dėmesys į
tai, kad tik dalis technologinių inovacijų patyrė nesėkmes vietoj to, kad būtų aiškinamasi kodėl tos
nesėkmės įvyko.

41
 Sutelkiant dėmesį į ketinimą sukurti technologijų sociologiją, kuri traktuoja technologines
žinias tuo pačiu simetrišku, nešališku būdu kaip ir moksliniai faktai traktuojami apie sociologijos
mokslo žinias, atrodo, kad istorinės žinios nėra toli pažengusios.
Vienintelis efektyvus būdas tvarkytis su iškylančiomis problemomis, siejant technologijas
su sociologija, tai priimti perspektyvą, kuri bando parodyti, kad technologijos taip pat kaip ir
mokslas gali būti suprantamos kaip socialinė konstrukcija.
Tai gi, nėra dominuojančio ir vieningo požiūrio į technologijų studijas, inovacijų studijas ir
technologijų istoriją. Tačiau tai labai svarbu siekiant sėkmingai vykdyti informacinių sistemų
kūrimo projektus. Jeigu kuriant IS nebus atsižvelgiama į socialinius aspektus ir nebus daromos
išvados kodėl projektai užsitęsia ar lieka visai neįgyvendinti, t.y. nebus pradėta gilintis į
sociologijos daromą įtaką technologijoms, joks progresas nebus pasiektas. [70]

6.2. Analizės procesas literatūroje

Analizės procesas skirtinguose literatūros šaltiniuose apibrėžiamas skirtingu detalumu.

Vienuose šaltiniuose procesas išskaidytas smulkiais žingsniai, kituose pateikiamos tik pagrindinės
gairės kas turėtų būti įtraukti į šį procesą. Šiame skyriuje apžvelgiama literatūra, kuri aprašo
pagrindinius veiksmus analizės procese.
Literatūros apie analizės procesą ar reikalavimų inžineriją lietuvių kalba yra labai mažai,
tai liudija, kad Lietuvoje analizės procesas yra dar tik pradinėje stadijoje. Lietuviškoje literatūroje
analizės procesas nagrinėjamas tik iš techninės pusės. Taip teigti galima remiantis Dariaus Šilingo
straipsniu „Programinės įrangos reikalavimų valdymo principai ir praktika“ [15], Rimanto Butlerio
moksliniu darbu „Funkcinių reikalavimų specifikavimas abstrahuoto ir detalizuoto reikalavimų
modelių pagrindu“ [42], Eglės Zaksaitės moksliniu darbu „Informacinei sistemai keliamų
reikalavimų apibrėžimo metodika naudojant UML IR OCL“ [20]. Šiuose darbuose yra nagrinėjama
reikalavimų inžinerija, jos procesas ir kita svarbi informacija sėkmingam projekto vykdymui, tačiau
visi aspektai nagrinėjami tik iš techninės pusės. Juose nėra atsižvelgiama į komunikacijos svarbą
reikalavimų išgavimo procesui.
Literatūros aprašančios reikalavimų analizę yra gausu. Analizės proceso aprašymas visuose
šaltiniuose šiek tik skiriasi, bet principas visur yra toks pats. Pagrindinės dalys, kurios išskiriamos
visuose šaltiniuose [8, 18, 32, 34]:
• Verslo reikalavimai ir taisyklės.
• Duomenų reikalavimai.
• Funkciniai reikalavimai.

42
 10 pav. Sistemos reikalavimų analizė viso projekto kontekste [36]

Auščiau pateikiamame paveiksle 10 yra pavaizduotas analizės procesas projekto kontekste.

Analizės procese išskiriami tokie žingsniai [36]:
Pasiruošimas sistemos reikalavimų analizei. Šis žingsnis skirtas užtikrinti, kad projekto
aplinka ir projekto komandos nariai yra tinkamai parengti fiksuoti ir analizuoti sistemos
reikalavimus.

43
 Verslo reikalavimų identifikavimas. Identifikuojami verslo reikalavimai kurie įtraukiami į
projekto apimtį ir kurie viršija projekto apimtį. Identifikuojamos ir dokumentuojamos verslo
taisyklės, taip pat aptariama vartotojo sąsaja.
Procesų modelio identifikavimas. Procesų modelis identifikuojamas paišant diagramas (iš
viršaus į apačią), kuriose yra pateikiami pagrindiniai verslo procesai sąveikaujantys su sistema.
Procesai išskaidomi į funkcijas ir jų sudedamąsias funkcijas (angl. sub-functions) iki žemiausio
lygio, kai proceso nebegalima išskaidyti.
Loginio duomenų modelio identifikavimas. Loginis duomenų modelis tenkina procesus ir
verslo taisykles, identifikuoja subjektus ir jų santykius su kitais subjektais, taip pat apibrėžia verslo
atributus.
Verslo reikalavimų suderinimas su procesų modeliu. Projekto komanda užtikrina, kad
proceso ir loginis duomenų modeliai padengtų visus sistemos reikalavimus ir verslo taisykles.
Kuriama funkcinė specifikacija. Funkcinė specifikacija aprašo vartotojo sąsają. Procesai
ir duomenys yra sistemingai apjungti aprašymui: kaip klientas naudosis programa ir kaip duomenys
bus gaunami, apdorojami ir saugomi.
Remiantis Linda Westfall [33] straipsniu „Programinės įrangos reikalavimai: kas, kodėl,
kas, kada ir kaip (angl. Software Requirements Engineering: What, Why, Who, When, and How)“
[34] reikalavimų analizės metu turi būti išskiriama dar viena svarbi dalis – kokybės reikalavimai
(angl. Quality Attributes). Jie apibūdina nefunkcinius sistemai keliamus reikalavimus, pvz. kokioms
operacinėms sistemoms turi būti pritaikyta programinė įranga.
Analizuojant šią literatūrą buvo pastebėta, kad analizės procesas juose, taip pat kaip ir
lietuviškuose šaltiniuose, pateikiamas iš techninės pusės.
Bashar Nuseibeh [9] ir Steve Easterbrook [56] straipsnyje „Reikalavimų inžinerija: gairės
(angl. Requirements Engineering: A Roadmap)“ [8] yra rašoma, kad norint atlikti reikalavimų
specifikavimą ir surinkimą yra būtina turėti socialinių įgūdžių. Šiam procesui, pasak jų, reikalinga:
• Kognityvinė psichologija padeda suprasti kokie sunkumai gali iškilti žmogui
bandančiam apibūdinti savo poreikius.
• Antropologija pateikia metodą kaip stebėti žmogaus veiklą, kuriai patobulinti yra
kuriama informacinė sistema. Kaip kuriama sistema paveiks šį procesą: teigiamai ar
neigiamai.
• Sociologija suteikia supratimą apie veiklos kultūros pasikeitimus atsiradus
informacinei sistemai. Nauja kuriama sistema gali daryti įtaką net gi visai
organizacijos veiklai, dėl to gali pakisti naudotojo poreikiai.

44
 • Lingvistika yra svarbi, nes reikalavimų inžinerija pagrinde yra apie komunikaciją.
Lingvistiniai įrankiai taip pat gali būti naudojami reikalavimų išgavimui, pvz.,
analizuojant bendravimo modelius organizacijos viduje.

6.3. Literatūroje aprašomos analizės problemos

6.3.1. Reliatyvizmo empirinė programa

Reliatyvizmo empirinė programa (angl.The Empirical Programme of Relativism) yra

požiūris, kuris pristato keletą tyrimų įrodančių, kad mokslinių žinių socialinė konstrukcija yra
sudėtingas mokslas. Pasak „Construction of Technological Systems“ knygos autorių [70], ši
mokslinių tyrimų tradicija atsirado neseniai iš mokslo žinių sociologijos. Šiuo metu šios problemos
plačiai žinomos, tačiau jų svarba analizės procesui nesumažėjo.
Reliatyvizmo empirinė programa skaidoma į tris pagrindines veikimo sritis. Pirmojoje
veikimo srityje pateikiamas sistemos reikalavimų interpretavimo lankstumas (angl. interpretative
flexibility), kitaip sakant, tai parodo, kad informacinės sistemos reikalavimai yra atviri daugiau nei
vienai interpretacijai. Socialinis mechanizmas, kuris apriboja interpretacijos lankstumą bei
daugiaprasmiškumą ir tokiu būdu leidžia nutraukti komandos ir kliento nesutarimus, yra aprašomas
antrojoje srityje. Trečioji veiklos sritis, kuri iki šiol dar nebuvo iki galo atskleista jokiose
šiuolaikinio mokslo studijose, yra susijusi su „uždarymo mechanizmu“ (angl. closure mechanism)
tarp analitiko, informacinės sistemos užsakovo bei komandos.

6.3.2. Technologijų socialinė konstrukcija

Technologijų socialinėje konstrukcijoje technologijų artefakto vystymosi procesas yra

apibūdinamas kaip variacijų ir atrankų kaita. Šis rezultatas yra „daugiakryptis“ modelis – tai yra
kontrastas linijiniam modeliui. Jis tiesiogiai naudojamas daugiausiai inovacijų tyrimuose ir
besąlygiškai daugelyje technologijų istorijų.
Sudarant „daugiakryptį“ modelį (11 pav.) pirmiausiai reikia išskirti pagrindinę problemą –
artefaktą, kuri bus nagrinėjama ar analizuojama. Išskyrus pagrindinę problemą būtina aiškiai išskirti
socialines grupes, kurioms ta problema yra svarbi. Taip apsibrėžiama grupė žmonių, kurių
nuomonę reikia analizuoti. Jeigu nerandama nei viena socialinė grupė žmonių, kuriems iškelta
problema yra svarbi, vadinasi, problemos nėra, nes ją išsprendus tai niekam neteiks naudos.
Svarbiausias reikalavimas socialinei grupei yra tai, kad visi jos nariai turėtų vienodą supratimą apie
artefaktą. Kiekvienai socialinei grupei reikalingas išsamus aprašymas tam, kad būtų galima tiksliau

45
identifikuoti reikiamas funkcijas gerbiant kiekvienos socialinės grupės poreikius. Identifikavus
visas socialines grupes dėmesys sutelkiamas į problemas kylančias konkrečioje grupėje – atidžiai
nagrinėjama kokios su artefaktu susijusios problemos kyla konkrečioje socialinėje grupėje.

11 pav. „Daugiakryptis“ modelis [70]

Tokiu būdu nagrinėjant artefaktą bei detaliai aprašant visas procese dalyvaujančias grandis
yra aiškiai iškeliami visų tipų konfliktai: techninių reikalavimų konfliktas kiekvienoje socialinėje
grupėje – ar reikalingos tam tikros funkcijos ir jų prioritetų nustatymas; iškeltų vienodų problemų
konfliktų sprendimas – funkcijų paskirtis, naudojimosi patogumas; moraliniai konfliktai –
naudotojų kalbų skirtumai, naudojimosi įgūdžių skirtumai. Šių konfliktų sprendimai gali būti ne tik
technologiniai, bet ir juridiniai ar net moraliniai.
Tokiu būdu stebint vystymosi procesą yra aiškiai matomas skirtingų artefaktų
stabilizavimo procentų augimas arba mažėjimas. Stabilizavimo procentas yra individualus
kiekvienoje socialinėje grupėje. Šis modelis pabrėžia „daugiakryptes“ savybes, taip pat išryškina
technologinių artefaktų interpretavimo lankstumą ir rolių svarbą artefakto stabilizavimui.

6.3.3. Interpretacijos lankstumas (angl. Interpretative Flexibility)

Technologinių artefaktų interpretacinis lankstumas privalo būti parodytas. Lankstus gali

būti ne tik žmonių mąstymas būdas ar artefakto interpretavimas, bet ir kaip artefaktas yra

46
suprojektuotas. Suprojektuoti artefaktą nėra vieno galimo būdo ar vieno geriausio būdo. Tai gali
būti pademonstruota tokiu pat būdu kaip ir mokslo atveju – apklausiant technologijų specialistus,
kurie užsiima prieštaravimais šiuolaikinėse technologijose. Interpretavimo lankstumo
demonstravimas naudojantis interviu ir istoriniais šaltiniais yra tik vienas iš daugybės galim metodų.
Kitas metodas gali parodyti, kad skirtingos socialinės grupės turi to paties technologinio
artefakto radikaliai skirtingas interpretacijas. Šie skirtumai vadinami „radikaliais“, nes artefakto
apibūdinimas buvo pateiktas visiems vienodas. Pagrindinė problema – socialinių grupių skirtinga
interpretacija, tokio pat turinio artefaktui rodo skirtingų grandinių reikšmę problemoms ir
sprendimams, tolesniems skirtingiems pokyčiams – yra susijusi su paties artefakto turiniu. [70]
Dalis šios problemos yra susijusi su terminologija, kuri iš praktikos pusės nagrinėjama
4.2.3 Terminologija, 27 psl., skyriuje. Taip pat iš praktikos pusės ši problema aprašyta skyriuje
4.2.4 Supratimo suvienodinimas, 28 psl..

6.3.4. Retorinis nesutarimų uždarymas (angl. Rhetorical Closure)

Diskusijų užbaigimas technologiniais klausimais įtraukia artefakto stabilizaciją ir problemų

„išnykimą“. Norint užbaigti technologinius „nesutarimus“ pirmiausia reikia spręsti problemas
bendrąja šio žodžio prasme. Svarbiausias klausimas yra, ar atitinkamos socialinės grupės nariai
mano, kad problema yra išspręsta. Technologijose reklama gali daryti didelę įtaką formuojant
reikšmę, kurią artefaktui gali suteikia tam tikra socialinė grupė. [70]

6.4. Apibendrinimas

Atlikus literatūros apžvalgą pastebėta, kad pateikiama informacija šaltiniuose skiriasi,

tačiau esminiai analizės proceso principai išlieka tie patys. Literatūroje analizės procesas
nagrinėjamas iš techninės pusės: kokias sritis analizuoti, kokias dalis pateikti specifikacijoje ir t.t.
Literatūroje neminimas komunikacijos procesas ir jo svarba analizės procesui, nors tik
komunikacijos dėka yra išgaunami reikalavimai.
Bashar Nuseibeh [9] ir Steve Easterbrook [56] parašė straipsnį „Reikalavimų inžinerija:
gairės (angl. Requirements Engineering: A Roadmap)“ [8], kuriame jie išskyrė sociologijos svarbą
reikalavimų inžinerijai.
Literatūroje aprašytos analizės problemos yra panašios į problemas aprašytas iš praktinės
patirties. Tai liudija, kad teoriniai sprendimai nepasiteisino ir šioms problemoms spręsti reikia
ieškoti kitų būdų.

47
 7. ANALIZĖS REZULTATAS – REIKALAVIMŲ
SPECIFIKACIJA

Šiame skyriuje trumpai apžvelgiama kokias dalis teorija rekomenduoja įtraukti į

informacinės sistemos specifikaciją ir kurios iš nurodytų dalių yra naudojamos praktikoje. Taip pat
pateikiami patarimai, iš teorinių žinių, kaip standartizuotai aprašyti surinktus reikalavimus.
Vieninga modeliavimo kalba (UML) – vienas iš būdų reikalavimų specifikacijos standartizavimui.
Šiame skyriuje pateikiamas UML taikymo aprašymas su pavyzdžiais.

7.1. Informacinės sistemos reikalavimų specifikacija

Reikalavimų specifikacija (RS) klientui pateikiama kaip tekstinis dokumentas arba

spausdinta stora knyga, kurioje surašytos visos detalės apie kuriamą informacinę sistemą, jos
funkcionalumą ir kitus svarbius techninius dalykus. Reikalavimų specifikacija – tai dokumentas
pagal kurį yra kuriama informacinė sistema, o baigus IS kūrimą, pagal tą patį dokumentą sistema
yra priduodama klientui. Taip pat RS naudojama, kai reikia atnaujinti ar papildyti jau esamą sistemą
nauju funkcionalumu. Tokiu atveju tinkamai sudaryta reikalavimų specifikacija leidžia neatlikti
visos sistemos analizės (ji jau atlikta ir specifikuota) ir leidžia atlikti tik naujo funkcionalumo
analizę. Taip sutaupoma daug laiko.
Reikalavimų specifikacija padeda spręsti ankščiau paminėtas problemas, nors kiekviena
problema yra kitokia priklausomai nuo projekto apimties, informacinės sistemos sudėtingumo,
kliento reiklumo ir daugelio kitų faktorių.
Reikalavimų specifikacija gali būti rašoma laisvu tekstu, reikalavimai gali būti grupuojami
pagal funkcionalumą, aprašymai gali būti pateikiami laisvai arba lentelėmis. Taip pat reikalavimų
specifikacijoje galima paišyti diagramas, kurios padėtų geriau įsisavinti sistemos funkcionalumą bei
verslo procesų logiką. Tai gi nei teorijoje, nei praktikoje nėra vieno teisingo būdo kaip specifikuoti
analizės metu surinktus reikalavimus – visa tai kliento, analitiko ir komandos susitarimas tiesiogiai
priklausomas nuo projekto dydžio ir įgūdžių specifikuojant reikalavimus bei skaitant specifikacijas.
[7, 14, 41]
Reikalavimų specifikacijai rekomenduojamos dalys [50]:
1. IS paskirtis – aprašoma kokias verslo ir veiklos problemas spręs kuriama informacinė
sistema nedetalizuojant kaip ji tas problemas spręs;
2. Veiklos proceso apibrėžimas – aprašomas kuriamos sistemos veiklos procesas
nenagrinėjant kaip sistema veiks techniškai.
48
 3. Konceptualus projektavimas – aprašomas pagrindinis sistemos funkcionalumas ir
techniniai reikalavimai, kurie būtini sistemos veiklos procesui, identifikuojami
sistemos komponentai.
4. Programinės įrangos reikalavimų specifikavimas – detalizuojamas veiklos procesas
aprašant identifikuotus komponentus.

7.2. Analizės rezultato standartizavimas naudojant UML

Šiame skyriuje pateikiama UML istorija, įrankių apžvalga, kuriais galima paišyti UML
diagramas, bei analizės procese naudojamų pagrindinių diagramų pavyzdžiai, jų naudojimas bei
paskirtis. Diagramos pateikiamos kaip pavyzdžiai kas yra UML ir kaip diagramos palengvina
analizės specifikavimo procesą, o ne UML taisyklių aprašymui, todėl diagramos nėra detaliai
aprašomas. Diagramų projektavimui naudojama „Magic Draw“ programinė įranga ir projektuojama
„Testavimo sistema“.

7.2.1. UML istorija

1994 metais kompanija „Rational Software“ pasamdė James Rumbaugh [29]. J. Rumbaugh
dirbo su objektų modeliavimo technikomis (angl. Object-modeling technique (OMT)), kurios buvo
labiau tinkamos į objektus orientuotai analizei (angl. object-oriented analysis (OOA)), o Grady
Booch [22] dirbo su „Booch“ metodu, kuris buvo labiau tinkamas į objektus orientuotam sistemos
projektavimui (angl. object-oriented design (OOD)). Taip „Rational Software“ kompanija tapo
dviejų populiariausių į objektus orientuotų modeliavimo kalbų šaltiniu.
1995 metais „Rational Software“ kompanija įdarbino Ivar Jacobson [28]. Netrukus prie J.
Rumbaugh ir G. Booch prisijungė ir Ivar Jacobson, kuris yra į objektus orientuotos programinės
įrangos inžinerijos (angl. object-oriented software engineering (OOSE)) metodo kūrėjas. Šie trys
metodologai draugiškai susijungė į kolektyvą „Trys draugai (angl. Three Amigos)“.
1996 metais „Rational Software“ kompanija padarė išvadą, kad modeliavimo kalbų gausa
lėtino ir apsunkino technologijų, paremtų objektais, kūrimą. Todėl perskirstė darbus vieningos
modeliavimo kalbos kūrimui ir iškėlė uždavinį „Trims draugams“ sukurti vieningą modeliavimo
kalbą (angl. Unified Modelling Language).
1996 metais, vadovaujantis „Trijų draugų“ technologijomis buvo įkurtas tarptautinis
konsorciumas vadinamas „UML partneriai (angl. UML Partners)“, kuris įkurtas tam, kad būtų
užbaigta vieningos modeliavimo kalbos (angl. Unified Modeling Language (UML)) specifikacija, ir
pasiūlyti jį kaip atsakas į objektų valdymo grupės (angl. Object Management Group (OMG))
49
pasiūlymų užklausas (angl. Request For Proposal (RFP)). OMG „UML
UML Partnerių“
Partneri UML versija 1.0
specifikacijos projektas buvo pasiūlytas
pasi 1997 m. sausio mėn.
n. Per tą
t patį mėnesį „UML
Partneriai“ suformavo darbo grupę
grup „Semantika“, kuriai pirmininkavo Cris Kobryn ir buvo
administruojama Ed Eykholt. Grupė
Grup buvo sudaryta tam, kad užbaigtų specifikacijos semantiką ir
integruoti ją suu kitomis standartizacijomis.
standartizacijomis Šio darbo rezultatas UML versija 1.1, kuri buvo pateikta
į OMG 1997 m. rugpjūčio
ūčio mėn.
m ir priimtos pagal OMG 1997 m. lapkričio mėn.
m [24, 51, 62]

12 pav. UML atsiradimas ir raida [61

61]
UML raida [60,
60, 62]:
62
1995: UM 0.8 (pradinis
pradinis bendradarbiavimas)
bendradarbiavimas
1996: UML 0.9 (tiksl
tikslų atnaujinimas)
1997 sausis: 1.0 (pradinis
pradinis OMG standartas)
standartas
1997 rugsėjis:: UML 1.1 (pirma
( versija)
1998: UML 1.2 (vidiniam
vidiniam naudojimui)
1999: UML 1.3 (publikuotas
publikuotas atnaujinimas)
atnaujinimas
2001 rugsėjis:: UML 1.4 (dabartinė
( versija)
2002 spalis:: UML 1.5 (su
( veiksmų semantika)
2003 pirmas ketvirtis:
ketvirtis UML 2.0 (reorganizavimas
reorganizavimas ir derinimas su MDA)
MDA
50
 2005: Formali UML 2.0 versija

7.2.2. UML diagramų kūrimo įrankiai

3 lentelė
Dešimt populiariausių įrankių, kurie tinkami kurti diagramoms pagal UML standartus [63,
64].
Paskutinio
Atviro
Nr. Pavadinimas Kūrėjai Platforma/ OS atnaujinimo
kodo
data
Windows, Linux,
1. RTDS PragmaDev 2012-04-06 Ne
Solaris
2. Modelio Modeliosoft Windows, Linux 2012-04-03 Taip
Software Ideas Windows (.NET),
3. Dusan Rodina 2012-03-19 Ne
Modeler Linux (Mono)
AgileJ
4. AgileJ Cross-platform (Java) 2012-03-11 Ne
StructureViews
5. BOUML Bruno Pagès Cross-platform 2012-02-22 Ne
Alexander
6. Dia Larsson/GNO Cross-platform 2011-12-18 Taip
ME Office
7. ArgoUML Tigris.org Cross-platform (Java) 2011-12-15 Taip
Rational Windows, Linux,
8. IBM 2011-12-13 Ne
Rhapsody MacOS X
Windows (Supports
Enterprise
9. Sparx Systems Linux & Mac 2011-12-01 Ne
Architect
installation)
MagicDraw
10. No Magic Cross-platform (Java) 2010-11-29 Ne
UML

51
 7.2.3. Pagrindinės UML diagramos naudojamos analizėje

Šiame skyriuje pateikiama informacija remiantis tokiais šaltiniais: [38, 58, 66, 67].

7.2.3.1. Aktorių diagrama

Aktorių diagramoje yra išskiriami būsimos (arba esamos) sistemos naudotojai. Ši diagrama
padeda išsiaiškinti ir suprasti kas naudosis arba jau naudojasi kuriama (tobulinama) sistema, t.y.
kam kuriama sistema teiks naudą ir palengvins verslo procesus.

13 pav. Aktorių diagrama

Aukščiau pateiktoje diagramoje (13 pav.) yra pavaizduoti penkti aktoriai:

1. Sistemos naudotojas;
2. Testuotojas;
3. Sistemos administratorius;
4. Išorinė sistema;
5. Išorinės sistemos naudotojas.
Aktoriais gali būti tik sistemos naudotojai arba kitos informacinės sistemos su kuriomis
kuriama sistema bus integruojama. Pati kuriama sistema aktoriumi būti negali.
Informacinėje sistemoje įprastai yra labai daug funkcijų, kurias gali atlikti naudotojas.
Tačiau ne visas funkcijas gali atlikti visi naudotojai, todėl jos yra išskaidomos pagal aktorių tipus.
Taip pat yra funkcijų, kurias gali atlikti visi naudotojai, todėl aktorių diagramoje „testuotojas“ ir
„sistemos administratorius“ yra apjungti į vieną naudotoją – „sistemos naudotoją“.

52
 7.2.3.2. Panaudos atvejų diagrama

Panaudos atvejai (angl. Use Case (UC)) padeda išskirti ir apibrėžti kuriamos informacinės
sistemos apimtį ir funkcionalumą. Panaudos atvejis nurodo kokią vertę sistema sukurs naudotojui,
t.y. „ką naudotojas galės atlikti su sistema – kokį rezultatą gaus“.

14 pav. Panaudos atvejų diagrama

Aukščiau pateiktame paveiksle 14 pavaizduoti informacinės sistemos „Testavimas“

panaudos atvejai. Visi panaudos atvejai turi bent po vieną naudotoją – asmenį, kuriam sistema
sukurs vertę ir kuris galės atlikti veiksmus su sistema. Sisteminės funkcijos panaudos atvejais
neaprašomos. Pvz. sistemose, kurios kaupia dokumentus dažniai būna pageidaujama funkcija
„automatinis failų archyvavimas“. Šiame procese nedalyvauja joks aktorius todėl šis
funkcionalumas negali būti aprašomas panaudos atveju, tam UML taiko kitokius būdus.
Pateiktoje diagramoje visi panaudos atvejai yra sugrupuoti į paketus:
• Testavimo panaudos atvejai;
• Bendri panaudos atvejai;
• Administravimo panaudos atvejai.
Kuriant dideles informacines sistemas panaudos atvejų būna ne dešimt, o šimtai, dėl to
rekomenduojamas panaudos atvejų grupavimas į paketus. Tai padeda lengviau juos tvarkyti,
analizuoti bei aprašinėti.
Aprašant kiekvieną panaudos atvejį rekomenduojama įtraukti tokias dalis:
1. Panaudos atvejo kodas – padeda identifikuoti.
2. Panaudos atvejo pavadinimas – apibūdina ką naudotojas galės atlikti šiuo panaudos
atveju.
53
 3. Panaudos atvejo paskirtis – trumpas aprašymas kam skirtas UC.
4. Panaudos atvejo aprašymas – UC aprašymas, kuriame nurodoma jo paskirtis, taisyklės
ir kt. informacija.
5. Panaudos atvejo naudotojai – pateikiamas sąrašas naudotojų, kurie turės teisę vykdyti
nurodytą UC.
6. Panaudos atvejo autorius – nurodomas panaudos atvejo autorius.
7. Panaudos atvejo vykdymo pradžios sąlyga – aprašoma kokios sąlygos turi būti
sistemoje tenkinamos, kad būtų galima vykdyti panaudos atvejį.
8. Panaudos atvejo pabaigos sąlyga – aprašoma sistemos būsena po UC įvykdymo.
9. Panaudos atvejo vykdymo pagrindinis scenarijus – nurodomi visi veiksmai, kurie turi
būti įvykdyti, kad UC būtų atliktas.
10. Panaudos atvejo vykdymo alternatyvus scenarijus – aprašomas alternatyvus UC
vykdymo scenarijus. Nurodomi tik tie veiksmai, kurie nesutampa su pagrindiniu
scenarijumi.

Pavyzdys – „Kurti testavimo atvejį“:

1. UC-001.
2. Kurti testavimo atvejį.
3. Naudotojas sukuria naują testavimo atvejį.
4. Testavimo atvejo pavadinimas turi būti unikalus.
5. Testuotojas.
6. Vardenis Pavardenis.
7. Naudotojas turi būti prisijungęs prie sistemos.
8. Sistemoje išsaugomas naujas testavimo atvejis.
9. Panaudos atvejo scenarijus aprašytas skyriuje Veiklos diagrama 54 psl.
10. Panaudos atvejo alternatyvus scenarijus aprašytas skyriuje Veiklos diagrama 54 psl.
Kartais panaudos atvejo scenarijai būna labai sudėtingi ir juos sunku suprasti. Šiai
problemai išspręsti yra rekomenduojama paišyti panaudos atvejo vykdymo veiklos diagramą.
Panaudos atvejo „Kurti panaudos atvejį“ scenarijai aprašyti skyriuje Veiklos diagrama 54 psl.

7.2.3.3. Veiklos diagrama

Veiklos diagrama apibūdina verslo proceso logiką, o ne kaip sistema turi atlikti tam tikrus
veiksmus. Tai reiškia, kad veiklos diagramos apibūdina sistemos veiklą iš naudotojo pusės. Taip pat

54
veiklos diagrama dažnai naudojama parodyti kokie veiksmai turi būti atlikti, kad būtų atliktas
panaudos atvejis.
Veiklos diagramų specifikacijoje gali būti labai daug. Veiklos diagramos gali būti
paišomos bendram veiklos procesui, kiekvienam panaudos atvejui atskirai ar keliems panaudos
atvejams iškart. Kiek ir kokių veiklos diagramų bus pateikiama analizės specifikacijoje priklauso
nuo sistemos apimties, sistemos sudėtingumo, analizės detalumo, veiklos diagramų sudėtingumo
bei informacinės sistemos kūrimo komandos vidinių susitarimų.
Žemiau paveiksle 15 pateikiama veiklos diagrama panaudos atvejui „Kurti testavimo
atvejį“.

15 pav. Kurti testavimo atvejį veiklos diagrama

Diagrama išskirta į dvi esmines dalis – „Testuotojas“ ir „Testavimo sistema“. Atliekamų

veiksmų juostose (angl. swimline) yra surašomi veiksmai, kuriuos reikia atlikti tam, kad panaudos

atvejis būtų atliktas teisingai, vadovaujantis verslo logika. Ženklas žymi veiksmų sekos pradžią,

o ženklas žymi veiklos veiksmų pabaigą, kai panaudos atvejis yra įvykdomas. Rodyklės

nurodo vykdomų veiksmų seką (eiliškumą).
Diagramos skaitymas – pagrindinis scenarijus:
55
 1. Testuotojas inicijuoja testavimo atvejo kūrimą.
2. Testavimo sistema pateikiama langą, kuriame reikia suvesti visus duomenis apie
testavimo atvejį.
3. Testuotojas užpildo testavimo atvejo duomenis.
4. Testuotojas inicijuoja testavimo atvejo išsaugojimą sistemoje.
5. Testavimo sistema tikrina ar visi privalomi laukai užpildyti.
5.1. Taip – visi privalomi laukai užpildyti.
6. Testavimo sistema tikrina ar visi laukai yra užpildyti korektiškai.
6.1. Taip – visi laukai užpildyti korektiškai.
7. Testavimo sistema išsaugo naują testavimo atvejį sistemoje.

Diagramos skaitymas – alternatyvus scenarijus 1:

5. Testavimo sistema tikrina ar visi privalomi laukai užpildyti.
5.1. Ne – ne visi privalomi laukai užpildyti.
6. Testavimo sistema pateikia pranešimą su klaidomis naudotojui.
7. Pagrindinis scenarijus vykdomas nuo trečio žingsnio.

Diagramos skaitymas – alternatyvus scenarijus 2:

6. Testavimo sistema tikrina ar visi laukai yra užpildyti korektiškai.
6.1. Ne – ne visi laukai užpildyti korektiškai.
7. Testavimo sistema pateikia pranešimą su klaidomis naudotojui.
8. Pagrindinis scenarijus vykdomas nuo trečio žingsnio.

7.2.3.4. Klasių diagrama

Klasių diagramoje yra išskiriami svarbiausi sistemos objektai.

Testavimo sistemos svarbiausi objektai (sąvokos): testuotojas, išorinės sistemos
naudotojas, sistemos administratorius, testavimo atvejis, testavimas, testavimo rezultatas, naudotojo
nustatymai.
Visi objektai yra susieti ryšiais – asociacijomis. Pvz., testuotojas ir testavimas yra susieti
asociacija „vykdo“. Skaitant diagramą tai skamba taip: „testuotojas vykdo testavimą“.

Asociacijos kryptį galima nurodyti ženklu . Tokia rodyklė padeda intuityviai ir

neklystant skaityti diagramą, nes kai kuriais atvejais pasitaiko dviprasmiškumų. Pvz., jeigu tarp
objektų „testavimas“ ir „testavimo atvejis“ nebūtų nurodyta asociacijos krytis, o asmuo skaitantis
diagramą neturėtų pradinių žinių apie testavimo procesą, šį užrašymą būtų galim interpretuoti
56
dvejopai: „testavimas vykdomas pagal testavimo atvejį“ arba „testavimo atvejis kuriamas pagal
testavimą“.
Ryšių kiekybiškumas nurodomas asociacijos galuose. Pvz., prie objektų „testuotojas“ ir
„testavimas“ asociacijos „vykdo“ yra nurodytas kiekybiškumas „1..*“ ir „1“, tai reiškia, kad „vienas
testuotojas gali vykdyti vieną arba daug testavimų“
Naudojant šią diagramą išskirti objektai vėlesniuose IS kūrimo etapuose gali pasitarnauti
projektuojant duomenų bazę.

16 pav. Testavimo sistemos sąvokų ryšių diagrama (klasių diagrama)

7.2.3.5. Kitos diagramos

Yra daug skirtingų UML diagramų, kurios skirtos ne tik analizės rezultatui standartizuoti.
Vieningomis modeliavimo kalbos diagramomis galima projektuoti informacinę sistemą, kurti
technines veiklos diagramas, standartizuotai aprašyti duomenų srautus kuriamoje IS ir t.t.
Naudojant UML visame informacinės sistemos kūrimo procese klientui pateikiamas
galutinis dokumentas yra tvarkingas, o įgijus UML skaitymo žinias lengvai suprantamas ir
skaitomas – vaizdus žmogui suprasti yra lengviau negu tekstą.

57
 7.3. Apibendrinimas

Reikalavimų specifikacija yra labai svarbus dokumentas kuriant informacinę sistemą. Nėra
vieno teisingo būdo kaip aprašyti sistemos reikalavimus – tai susitarimo reikalas. Naudojantis
teorinėmis žiniomis ir išbandant jas praktikoje galima rasti tinkamiausią būdą kaip specifikuoti
reikalavimus.
Reikalavimų specifikavimui rekomenduojama naudoti UML. Vieninga modeliavimo kalba
padeda ne tik standartizuotai aprašyti analizės rezultatus, bet ir padeda lengviau suprasti kokie
rezultatai buvo gauti. Tai padeda standartizuotai suvienodinti kliento ir analitiko supratimą apie
kuriamą sistemą. Taip pat tai leidžia suvaldyti projekto apimtį ir augančius kliento poreikius.
Skaitant informacinės sistemos aprašymą, kuris padarytas laisvu tekstu yra žymiai sunkiau
suprasti bendrą sistemos veikimo principą, kokią naudą gaus klientas bei kokius procesus
patobulins, palengvins kuriama IS.
Analizės proceso rezultatai pateikiant diagramomis yra lengviau suprantami pačiam
analitikui, taip pat informacinės sistemos kūrimo komandai ir svarbiausia, tai lengviau suprantama
būsimos sistemos užsakovui – naudotojui, kuriam ta sistema ir yra kuriama.
Vieningos modeliavimo kalbos pliusai:
• Lengva išskirti sistemos funkcionalumą;
• Paišant veiklos diagramas lengva išskirti problemines vietas;
• Diagramas skaityti lengviau negu tekstą;
• Paišant diagramas lengviau modeliuoti verslo procesus, nei juos aprašant žodžiais.
Esminis minusas vieningos modeliavimo kalbos yra tas, kad reikia išmokti ją „skaityti“.

58
 IŠVADOS

Analizė yra viena iš penkių dalių kuriant informacinę sistemą, tačiau ji lyginant su kitomis
dalimis yra labai svarbus procesas informacinės sistemos kūrimo procese. Taip yra todėl, kad
netinkamai atlikus arba visai neatlikus analizės bus neišsiaiškinti kliento verslo procesai, kuriems
automatizuoti jam ir reikalinga IS, kuri bus ar yra kuriama.
Pirmojoje šio darbo dalyje aprašoma pagrindinė darbo problematika – kodėl tiek daug
informacinių sistemų projektų nėra sėkmingi ir kas tai lemia.
Remiantis Standish Group duomenimis, kurie pateikiami skyriuje 1 Informacinių sistemų
projektavimas ir komunikacijos įtaka projektų realizavimui: tyrimo problemos aprašymas, 10 psl.,
net 37% informacinių sistemų kūrimo projektų yra komplikuoti arba neįgyvendinami dėl nesančio
arba nekorektiško analizės proceso.
Antrojoje dalyje remiantis šaltiniais pateikiami tyrimo metodai bei išsamiai aprašytas šiam
darbui taikomas metodas.
Trečiojoje dalyje nagrinėjama kaip teorijoje pateikiami projekto vykdymo procesai ir kokią
jų dalį sudaro analizės procesas. Šiame skyriuje dar kartą patvirtinama, kad analizės procesas yra
labai svarbus informacinių sistemų kūrimo etapas – be jo informacinės sistemos dažniausiai
netenkina klientų poreikių.
Ketvirtojoje darbo dalyje nagrinėjamas praktikoje vykdomas IS kūrimo procesas bei
praktikoje kylančios problemos. Analizės metu, bendravimo su klientu bei komanda metu ir
informacinės sistemos kūrimo metu iškyla problemų, kurias būtina spręsti vos tik joms atsiradus.
Taip pat išnagrinėtas analizės procesas, kurio pagalba galima daryti išvadą, kad prasidėjus
informacinės sistemos kūrimo procesui analitikas dirba vienas, tai reiškia, kad jis daro didžiulę įtaką
būsimos sistemos reikalavimams. Taip pat galima daryti išvadą, kad kitame etape analitikas turi
labai intensyviai bendrauti ne tik su klientu, bet ir su komanda, kad aiškiai ir laiku komunikuotų
apie sistemos reikalavimus ar pasikeitimus.
Atlikus praktikoje dažniausiai pasitaikančių problemų apžvalgą pastebėta, kad pagrindinis
analitiko darbo įrankis yra bendravimas. Komunikuodamas su klientu jis išgauna reikalavimus, o
bendraudamas su komanda – perduoda savo įgytas žinias. Informacinių sistemų analitikas
neturėdamas supratimo ir žinių apie komunikacijos procesą bei kaip jį valdyti, net nesuprasdamas
gali klaidingai atlikti analizę.
Penktame šio darbo skyriuje apžvelgiamas komunikacijos procesas. Pateikiama teorija apie
jį bei nagrinėjamas verbalinis ir neverbalinis bendravimas. Taip pat nagrinėjama kokią įtaką turi
komunikacijos procesas analizei ir pateikiama lentelė su duomenimis apibūdinančiais gaunamą

59
informaciją iš komunikacijos proceso – ne žodinė informacija. Taip pat nagrinėjama svarbi
sociologijos ir technologijų sąsajos problema, kuri lemia sėkmingą IS kūrimą, taip sukuriant naudą
ne tik informacinių technologijų kompanijai, bet ir kitų sričių kompanijoms, kurios naudojasi
informacinėmis sistemomis. Pirmoji gauna naudą kurdama IS, antroji gauna naudą, nes nauja IS
palengvina darbą ir sukuria pridėtinę kompanijos vertę. Čia analitiko pagrindinis darbas yra
komunikacija su klientu bei komanda, kylančių problemų sprendimas – greitai ir tiksliai, ir
informacijos rinkimas bei perdavimas žodžiu ir raštu. Kitais žodžiais sakant tai informacinių
technologijų apjungimas su sociologija ir tų žinių realizavimas iš to gaunant realią naudą.
Šeštoje darbo dalyje pateikiama teorija apie sociologijos svarbą technologijoms ir apskritai
visam mokslui. Trumpai paaiškinama kodėl technologijos negali būti tinkamai tobulinamos
nesinaudojant sociologijos pagrindais. Taip pat apžvelgiamas analizės procesas literatūroje ir
apžvelgiamas analizės procesas Lietuvoje – čia informacinių sistemų analizė yra techninis dalykas
ir komunikacijos procesas nėra nagrinėjamas. Priešingai teigia užsienio literatūra, kurioje yra
pabrėžiama, kad norint tinkamai suprasti apie ką kalba klientas reikalingos sociologijos,
antropologijos bei psichologijos žinios.
Septintojoje darbo dalyje remiantis teorija bei praktinėmis žiniomis yra pateikiama
informacija apie reikalavimų specifikaciją, kuri yra analizės proceso rezultatas. Reikalavimų
specifikavimui yra daug skirtingų būdų, tačiau remiantis autorės patirtimi yra nagrinėjama literatūra
ir išskiriamos pagrindinės specifikacijai reikalingos dalys. Taip pat specifikavimui naudojama
vieninga modeliavimo kalba, kuri plačiai naudojama visame pasaulyje. Tačiau UML yra tik vienas
iš būdų specifikacijai ruošti ir ne visiems projektams šis metodas yra tinkamas.
Atlikus praktinę ir teorinę apžvalgą galima teigti, kad didžioji dalis analizės proceso
problemų kyla dėl komunikacijos proceso. Kitaip sakant, dėl žinių apie jį trūkumo. Lietuvoje
informacinės technologijos yra visai nesiejamos su tokiais įgūdžiais. Analizės procesą galima būtų
patobulinti ir gauti geresnį rezultatą, jei informacinių sistemų analitikai turėtų bent pradines žinias
apie komunikaciją ir jos svarbą analizės procesui.
Kuo detaliau bus išspręstos problemos tuo geriau bus atlikta analizė bei tiksliau sukurta IS,
o projekto pabaigoje klientas bus labiau patenkintas gautu produktu. Tai svarbu ne tik tuo metu
atlikto darbo teikiamam pasitenkinimui, bet ir visos informacinių sistemų kūrimo įmonės įvaizdžiui.
Taip pat tinkamai ir detaliai atlikta analizė daro įtaka IS kūrimo įmonės įvykdomų projektų skaičiui
bei jų įgyvendinimo trukmei.
Remiantis šiais faktais galima teigti, kad informacinių sistemų analitiko darbui yra svarbu
geras technologijų bei sociologijos išmanymas, o analitiko darbas tiesiogiai daro įtaką tiek įmonės,
kurioje dirba, įvaizdžiui ir pelnui, tiek ir IS užsakovo kompanijai, bei jos darbuotojams, nes IS

60
analitiko dėka projektas gali būti sėkmingai įgyvendintas ir nauja IS gali akivaizdžiai pagreitinti ir
palengvinti užsakovo kompanijos darbą.

61
 LITERATŪROS SĄRAŠAS

1. A. Bendorienė, V. Bogušienė, E. Dagytė, T. Daržinskaitė ir kiti. Tarptautinių žodžių žodynas.

Alma Littera, Vilnius, 2001. ISBN 9955-08-100-7.
2. Agile aprašymas. http://www.agilemeaning.net/ paskutinį kartą žiūrėta 2012-05-01.
3. Agile modelling. http://www.agilemodeling.com/ Paskutinį kartą žiūrėta 2012-05-07.
4. Agile processes. http://www.agile-process.org/ Paskutinį kartą žiūrėta 2012-05-07.
5. Agile processes. http://www.agile-process.org/proverbs.html Paskutinį kartą žiūrėta 2012-05-
07.
6. Albert Mehrabian's communication study
http://changingminds.org/explanations/behaviors/body_language/mehrabian.htm Paskutinį
kartą žiūrėta 2012-05-10.
7. Analysis and Software requirements. http://www.slideshare.net/craigwbrown/kano-analyiss-
and-software-requrements Paskutinį kartą žiūrėta 2012-05-05.
8. Bashar Nuseibeh, Steve Easterbrook. Requirements Engineering: A Roadmap.
http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf Paskutinį kartą žiūrėta 2012-05-10.
9. Bashar Nuseibeh. http://mcs.open.ac.uk/ban25/ Paskutinį kartą žiūrėta 2012-05-09.
10. Bendravimas raštu. http://www.straipsniai.lt/psichologija/puslapis/5028. 2011. Paskutinį kartą
žiūrėta 2012-04-08.
11. Bendravimas. Tekstas pateikiamas pagal Creative Commons Attribution/Share-Alike
Licenciją. 2011. http://lt.wikipedia.org/wiki/Bendravimas. Paskutinį kartą žiūrėta 2012-04-15.
12. Charles, C. Pedagoginio tyrimo įvadas. Vilnius, 1999.
13. Cohen, L.; MANION, L. Research Methods in Education. London and New York, 1994.
14. Customer requirements. http://www.slideshare.net/littleb1977/understanding-customer-needs-
1912215 Paskutinį kartą žiūrėta 2012-05-06.
15. Darius Šilingas. Reikalavimų valdymas. Programinės įrangos reikalavimų valdymo principai
ir praktika. http://www.nomagic.lt/text.php?lang=1&item=161&arg=119 Paskutinį kartą
žiūrėta 2012-05-08.
16. David Churchville. Agile Thinking: Leading Successful Software Projects and Teams.
ExtremePlanner Software, 2008m. ISBN 9780557015818
17. Davis, Fanning, McKay. The Communication Skill Book. New Harbinger Publications, Inc.
(www.amazon.com). 2009.
18. Denis de Champeaux, Doug Lea, Penelope Faure. Object-Oriented System Development.
http://g.oswego.edu/dl/oosdw3/ Paskutinį kartą žiūrėta 2012-05-08.

62
19. E. Hess: „The Tell-Tale, Eye”, New York: 1975,Van Nostrand Reinhold.
20. Eglė Zaksaitė. Informacinei sistemai keliamų reikalavimų apibrėžimo metodika naudojant
UML IR OCL. http://vddb.library.lt/fedora/get/LT-eLABa-
0001:E.02~2004~D_20040528_163835-62255/DS.005.0.01.ETD Paskutinį kartą žiūrėta
2012-05-08.
21. Gall, M.; Borg, W.; Gall, J. Educational Research. An Introduction. New York, 1996.
22. Grady Booch. http://researcher.ibm.com/view.php?person=us-gbooch Paskutinį kartą žiūrėta
2012-05-08.
23. Gražina Matulienė: „Psichologija studentui” , Kaunas: 2000, Technologija.
24. History of UML: Methods and Notations http://sourcemaking.com/uml/basic-principles-and-
background/history-of-uml-methods-and-notations Paskutinį kartą žiūrėta 2012-05-06.
25. Informacijos technologija. Terminai ir apibrėžimai. 1-oji dalis. Pagrindiniai terminai. Lietuvos
standartizacijos departamentas. 1996. 33 ps. ↑ LST ISO 2382-1: 1996. Paskutinį kartą
peržiūrėta 2012-05-01.
26. Informatika – apibrėžimas. http://lt.wikipedia.org/wiki/Informatika#cite_note-LST2382-0
paskutinį kartą peržiūrėta 2012-05-02.
27. Iterative development. http://en.wikipedia.org/wiki/Iterative_and_incremental_development
Paskutinį kartą žiūrėta 2012-05-09.
28. Ivar Jacobson. http://www.ivarjacobson.com/about/management_team/ Paskutinį kartą žiūrėta
2012-05-08.
29. James Rumbaugh. http://www.informit.com/authors/bio.aspx?a=D3DD9437-09E2-448F-
9EE3-6AAD01752522 Paskutinį kartą žiūrėta 2012-05-08.
30. Kardelis, K. Mokslinių tyrimų metodologija ir metodai. Kaunas, 2002.
31. Krathwohl, D. Methods of Educational and Social Science Research: An Integrated Approach.
N.Y, 1993.
32. Lifecycle Process Model. http://www.informatik.uni-bremen.de/gdpa/vmodel/sd1.htm
Paskutinį kartą žiūrėta 2012-05-08.
33. Linda Westfall. http://www.icsq.org/12ICSQ/Linda_Westfall.htm Paskutinį kartą žiūrėta
2012-05-01.
34. Linda Westfall. Software Requirements Engineering: What, Why, Who, When, and How.
http://www.westfallteam.com/Papers/The_Why_What_Who_When_and_How_Of_Software_
Requirements.pdf Paskutinį kartą žiūrėta 2012-05-01.
35. Mason, J. Qualitative Researching. London, 1996.
36. New York State Office For Technology. System requirements analysis.
http://www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf Paskutinį kartą žiūrėta 2012-05-08.
63
37. Nijolė Petkevičiūtė. Tarpasmeninė ir tarpkultūrinė komunikacija Europos kontekste. VDU,
Kaunas, 2010. ISBN 978-9955-12-586-0.
38. Patrick Grassle, Henriette Baumann, Philippe Baumann “UML 2.0 in Action “. Pact
Publishing Ltd., UK, 2005m. Pirmas leidimas 2004m. ISBN 1-904811-55-8
39. Paulauskaitė, N. Kokybiniai tyrimo metodai vadyboje. Socialiniai mokslai: Vadyba, 1996,
Nr.4(8), p. 35 - 42.
40. Projektų įgyvendinimas procentais.
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.7918&rep=rep1&type=pdf Paskutinį
kartą peržiūrėta 2011-12-18.
41. Requirements management. http://www.slideshare.net/moobe/requirements-management-
presentation Paskutinį kartą žiūrėta 2012-05-05.
42. Rimantas Butleris. Funkcinių reikalavimų specifikavimas abstrahuoto ir detalizuoto
reikalavimų modelio pagrindu.
http://www.leidykla.eu/fileadmin/Informacijos_mokslai/36/168-177.pdf Paskutinį kartą
žiūrėta 2012-05-08.
43. RUP aprašymas. http://lt.wikipedia.org/wiki/RUP paskutinį kartą žiūrėta 2012-05-01.
44. RUP project template.
http://publib.boulder.ibm.com/infocenter/reqpro/v7r1m0/index.jsp?topic=/com.ibm.reqpro.hel
p/administering/projects/creating_modifying/r_rup_proj_template.html Paskutinį kartą žiūrėta
2012-05-09.
45. Shelly, Gary B., Cashman, Thomas J., & Vermaat, Misty E. Discovering Computers 2008,
Complete. Boston: Thomson Course Technology. ISBN 10: 1 -4239-1205-5
46. Sistemų analitikas. http://en.wikipedia.org/wiki/System_analyst Paskutinį kartą peržiūrėta
2012-05-02.
47. Smith, M.; Glass, G. Research and Evaluation in Education and the Social Sciences. New
Jersey, 1987.
48. Software development by Agile. http://en.wikipedia.org/wiki/Agile_software_development
Paskutinį kartą žiūrėta 2012-05-08.
49. Software Project Management -RUP
http://www.ibm.com/developerworks/rational/library/4721.html Paskutinį kartą žiūrėta 2012-
05-09.
50. Software Requirements Specification. http://www.software-
requirements.tuffley.com/sample.pdf Paskutinį kartą žiūrėta 2012-05-06.
51. Specifikacijos rašymas naudojant UML. http://www.omg.org/cgi-bin/doc?ad/97-08-11 "UML
Specification version 1.1 (OMG document ad/97-08-11)". Paskutinį kartą žiūrėta 2012-05-07.
64
52. Stake, R. The Art of Case Study Research. N.Y, 1995.
53. Standish Group ataskaitos analizė. http://www.cs.vu.nl/~x/chaos/chaos.pdf paskutinį kartą
žiūrėta 2012-04-30.
54. Standish Group Chaos Report. http://www.standishgroup.com/newsroom/chaos_2009.php
Paskutinį kartą žiūrėta 2012-05-07.
55. Standish Group duomenų analizė. http://www.projectsmart.co.uk/pdf/the-curious-case-of-the-
chaos-report-2009.pdf Paskutinį kartą peržiūrėta 2012-05-06.
56. Steve Easterbrook. http://www.cs.toronto.edu/~sme/ Paskutinį kartą žiūrėta 2012-05-09.
57. THE STANDISH GROUP REPORT CHAOS.
https://cs.nmt.edu/~cs328/reading/Standish.pdf Paskutinį kartą peržiūrėta 2012-04-11.
58. Thomas A. Pender “UML weekend crash course”. Wiley Publishing, Inc, New York, 2002m.
ISBN 0-7645-4910-3
59. Thomas, J.; Nelson, J. Research Methods in Physical Activity. 3 rd ed. USA: Human Kinetics,
1996.
60. UML 2.0 Notation Update http://www.sa-depot.com/?page_id=645 Paskutinį kartą žiūrėta
2012-05-08.
61. UML history. http://upload.wikimedia.org/wikipedia/commons/3/33/OO-historie-2.svg
Paskutinį kartą žiūrėta 2012-05-08.
62. UML history. http://www.sa-depot.com/?page_id=217 Paskutinį kartą žiūrėta 2012-05-06.
63. UML įrankiai. http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
Paskutinį kartą žiūrėta 2012-05-08.
64. UML įrankiai. http://uml-2.software.informer.com/software/ Paskutinį kartą žiūrėta 2012-05-
08.
65. UML paaiškinimas. http://www.uml-forum.com/FAQ.htm Pasktuinį kartą peržiūrėta 2012-05-
03.
66. UML taisyklės. http://www.slideshare.net/dhirajmusings/software-requirement-analysis-
using-uml Paskutinį kartą žiūrėta 2012-05-08.
67. UML taisyklės. http://www.slideshare.net/parag/uml-5088447 Paskutinį kartą žiūrėta 2012-
05-08.
68. Verslo informatika – apibrėžimas. http://en.wikipedia.org/wiki/Business_informatics
Paskutinį kartą peržiūrėta 2012-05-01.
69. Viktorija Baršauskienė, Birutė Janulevičiūtė: „ Žmogiškieji santykiai”, Kaunas: 1999,
Technologija.
70. Wiebe E. Bijker, Thomas P. Hughes, Trevor Pinch. Construction of Technological Systems.
Maple-Vail, Inc, United States of America, 2001m. Pirmas leidimas 1989m.
65
71. Young girl and old woman illusion. http://mathworld.wolfram.com/YoungGirl-
OldWomanIllusion.html Paskutinį kartą žiūrėta 2012-04-15.
72. Žiniasklaidos vystymosi institucija http://www.mda.gov.sg/Pages/Home.aspx Paskutinį kartą
peržiūrėta 2012-04-29.

66
 PRIEDAI
Priedas Nr.1

ABSTRACT

Author of Bachelor Thesis: Aušra Kentraitė, Julius Slušnys

Full title of Bachelor Thesis: Customer Relationship Management

Supervisor: doc. dr. Lina Pilelienė

Presented at: Vytautas Magnus University,

Faculty of Informatics, Kaunas,
Department of Applied Informatics,
Department of System Analysis

Number of pages: 35
Number of tables: 3
Number of pictures: 6
Number of appendices: 0

This work performed a theoretical analysis of marketing, which dealt with marketing mix and its
macro and micro environment. Also at issue in the software, which is designed with customer
relationship management. This software will directly affect the company's business expansion and
improve customer satisfaction. Learn more about the software described in this second chapter.
Also, an analysis of the product options, as it can sell and advertise to attract the right customers.

67
 Priedas Nr.2

Magistro antrojo tiriamojo darbo santrauka

Magistro darbo autorius: Aušra Kentraitė

Magistro darbo pavadinimas: IS analizės proceso vykdymo teorija ir praktika: komunikacijos

proceso bei kylančių problemų apžvalga

Vadovas: dr. hab. Vladislav V. Fomin

Darbas pristatytas: Vytauto Didžiojo Universitetas, Informatikos fakultetas,

Kaunas, 2011 birželis.

Puslapių skaičius: 25

Lentelių skaičius: 1

Paveikslų skaičius: 5

Šis tiriamasis darbas pateikia informaciją apie analitiko darbą. Analitikas tai žmogus, kuris
bendrauja su informacinės sistemos užsakovu arba būsimu vartotoju ir renka pradinę arba detalią
informaciją apie veiklos procesą. Toliau darbe aprašytas informacinės sistemos analizės procesas
– veiksmų seka, kurių metu atliekama analizė – būsima ar pradėta kurti informacinė sistema
analizuojama dalimis ir skirtingais abstraktumo lygiais. Analizės veiklos procesas pateikiamas
nuo projekto pradžios, kai komanda gauna pirmus dokumentus iš kliento, iki surinktos
informacijos atidavimo projekto komandai bei jos tikslinimo informacinės sistemos kūrimo metu.
Darbe pateikiama teorija apie komunikacijos procesą, bendravimo būdus, jų svarbą bei jų daromą
įtaką analizės procesui. Šiame tiriamajame darbe aprašytos analizės metu kylančios problemos,
dėl kurių projekto laikas gali labai išsitęsti arba projektas gali būti visai neįgyvendintas.
Šio darbo tikslas yra parodyti ir faktais pagrįsti kodėl analitiko darbas yra svarbus, su kokiomis
problemomis dažniausiai susiduria analitikas bendraudamas su klientu ir projekto vykdymo
komanda bei kokią įtaką informacinių sistemų kūrimui daro komunikacijos procesas.

68
 Priedas Nr.3

Magistro trečiojo tiriamojo darbo santrauka

Magistro darbo autorius: Aušra Kentraitė

Magistro darbo pavadinimas: IS analizės proceso vykdymo teorija ir praktika: komunikacijos

proceso bei kylančių problemų apžvalga

Vadovas: dr. hab. Vladislav V. Fomin

Darbas pristatytas: Vytauto Didžiojo Universitetas, Informatikos fakultetas,

Kaunas, 2012 gruodis.
Puslapių skaičius: 25

Lentelių skaičius: 1

Paveikslų skaičius: 5

Šiame tiriamajame darbe nagrinėjamas informacinių sistemų analitiko darbas, analizės svarba
informacinių sistemų kūrimo procesui bei pagrindinės problemos kylančios analizės metu.
Analitikas tai žmogus, kuris bendrauja su informacinės sistemos užsakovu arba būsimu vartotoju
ir renka pradinę arba detalią informaciją apie veiklos procesą. Toliau darbe aprašytas
informacinės sistemos analizės procesas – veiksmų seka, kurių metu atliekama analizė – būsima
ar pradėta kurti informacinė sistema analizuojama dalimis ir skirtingais abstraktumo lygiais.
Analizės veiklos procesas pateikiamas nuo projekto pradžios, kai komanda gauna pirmus
dokumentus iš kliento, iki surinktos informacijos atidavimo projekto komandai bei jos tikslinimo
informacinės sistemos kūrimo metu. Darbe pateikiama teorija apie sociologijos ir technologijų
ryšį, jų svarbą bei jų daromą įtaką analizės procese kylančioms problemoms. Šiame tiriamajame
darbe aprašytos analizės metu kylančios problemos, dėl kurių projekto laikas gali labai išsitęsti
arba projektas gali būti visai neįgyvendintas.
Šio darbo tikslas yra parodyti ir faktais pagrįsti kodėl analitiko darbas yra svarbus, su kokiomis
problemomis dažniausiai susiduria analitikas bendraudamas su klientu ir projekto vykdymo
komanda bei kokią įtaką informacinių sistemų kūrimui daro sociologija.

69
 Priedas Nr.4

Evaluating companies interoperability USING DEXi

Aušra Kentraitė, Arūnas Bareišis
Vytautas Magnus University, Department of Applied Informatics, Vileikos street 8, Kaunas, Lithuania,
e-mail: ausra.kentraite@gmail.com, abareisis@gmail.com
Abstract. In the paper a model to support enterprises in improving interoperability will be presented. The
methodology considers conceptual, organizational and technological maturity of an enterprise regarding business
strategy, processes, services and data. For the evaluation we propose a qualitative hierarchical multi-attribute
model. The model is implemented within a DEX framework and will be illustrated by examples.
Keywords: decision making, decision modelling, interoperability.

Introduction
In the past, most companies created their own applications and designed their own set of services but times
have changed. In the current and networked society, enterprises need to collaborate with other enterprises to meet their
own added values and to exploit the market opportunities. A major issue in global collaboration and cooperation is
development of interoperability. Interoperability is the Ability of two or more systems or components to exchange
information and to use the information that has been exchanged.
In order to support enterprises in better interoperating with their partners, clients, providers, etc; enterprise
interoperability requires being assessed and continuously improved. One of the assessment methods consists in using
maturity models.
A maturity model is a framework that describes - for a specific area of interest - a number of levels of
sophistication at which activities in this area can be carried out. In our case, the specific area of interests is Enterprise
Interoperability [1], [4].
Problem description
Nowadays, Information Technology (IT) as well as human systems evolves in a worldwide heterogeneous
environment and works in network. For enterprises, operating in such environment requires flexibility and co-operation
between other enterprises, sharing their core competencies in order to exploit the market opportunities. Exchanges are
needed for both operational control and for a larger extend for the decision making process.
It is now admitted that a major issue in global collaboration and co-operation is the development of
interoperability between enterprise systems [2], [5], [6].
Our research goal is to find a way how to assess Interoperability Maturity levels in companies. Also find a
solution how to help companies measure Technological, Organizational and Conceptual layers in their organization and
what has to be reached for better Interoperability Maturity level in company.
In our case, when evaluating the alternatives it is necessary to find intersection points of Interoperability
Aspects and Concerns of Enterprises. Interoperability aspects are Conceptual, Technological and Organizational layers.
Enterprise concerns are Business, Process, Service and Data.
In our research both problem solving and decision making are very important especially because of large
amount of available data, information and fast globalization in the world. The latest one also affects the enormously fast
changes and increase of known regular data and information.
Decision group
There are different groups which are affected by reaching the goal of this research There are used experience
from references knowledge, student knowledge gained from researching interoperability problems, knowledge of
lecturers who are helps reaching the goal, and companies – they are directly affected by outcomes of the research.
Method of work
Interoperability level is very important in every company. To help evaluate the company's Interoperability we
are using DEXi (a program for multi-attribute decision making) which helps construct models, define utility functions
and evaluate options.
This decision making model will help companies to evaluate and admit decisions according to their
interoperability level.

70
 Decision model
This chapter describes interoperability evaluating model which is made by using DEX’i.
Criteria
We structured criteria tree (Figure 1B) using framework of MMEI (Maturity Model of Enterprise
Interoperability) (Figure 1A). We have chosen MMEI because it describes all models which help to evaluate enterprise
Interoperability. This model is not complex, it is easy to understand and it helps to evaluate interoperability of whole
enterprise.
Process and Service levels are integrated to one level because of few reasons. First of all is that four levels are
too much to make clear rules to create decision making tree by using DEX’i. Secondly – of all these levels, levels of
Processes and Services are most familiar to each other.

Figure 1A: Framework of MMEI. Figure 1B: Tree of decision making model in DEXi.

The dimension of interoperability barriers takes into account three categories of interoperability problems
which can be considered as following [1], [3]:
Conceptual layer are related to the problems of syntactic and semantic differences of information to be
exchanged. This category of barriers concerns the modelling at high levels of abstraction as well as modelling at the
level of programming.
Organizational layer are related to the definition of responsibilities and authority so that interoperability can
take place under good conditions.
Technological layer are related to the problem of use of information technologies. This category of barriers
concerns the standards that are used to present, store, exchange, process, and communicate data through the use of
computers.
The dimension of interoperability concerns identifies various levels of enterprise where interoperability takes
place. These levels are based on the ATHENA Technical framework: the business level, the processes level, the
services level and the data level [1], [2]:
Interoperability of data level aims to make work together different data models with different query
languages to share information coming from heterogeneous systems.
Interoperability of services level aims at making work together various services or applications (designed and
implemented independently) by solving the syntactic and semantic differences.
Interoperability of processes level aims to make various processes work together. In the interworked
enterprise, the aim will be to connect internal processes of two companies to create a common process.
Interoperability of business level aims to work in a harmonized way to share and develop business between
companies despite the difference of methods, decision making models, culture of the enterprises, the commercial
making, etc.

71
 The dimension of interoperability approaches takes into consideration the five admitted levels to develop
interoperability: the unprepared level, the defined level, the aligned level, the organized level and the adapted level.
Each intersection between an Interoperability Approaches, Enterprise Concerns and Interoperability Aspects represent
the research area of Interoperability Maturity levels.
Utility functions
For better Interoperability Maturity level valuation we assigned percentages for each criteria. We evaluated the
following criteria: Process 70% and for Service 30%, because we think process is much more important. The
importance of services is much higher because they are the core component of all business and all created services only
supports processes. That means firstly are created processes and secondly services to support them (models for
processes, interfaces, architectures and etc.).
Table 1: Grades for MMEI model.
Conceptual Organizational Technological
Business 35% 45% 20%
Process and Service 45% 35% 35%
Data 20% 20% 45%

In Conceptual layer Process and Service is most important level. It is graded by 45%, because this level
combines received information to a meaningful manner for Organizational layer. This information is from
Technological and Conceptual layers. For Business level we assigned 35% and for Data level 20%.
In Organizational layer Business level is most important factor which is graded by 45%, because
Organizational layer is mostly concerned with defining business goals and modelling business processes. Less
important factors are Process and Service level which are graded by 35% and Data level graded by 20%.
In Technological layer Data is most important area and it is graded by 45%, because all important calculations
and all results in Technological layer are received from Data level. For Processes and Service level we assigned 35%
and for Business level 20%.
Table 2: Grades for Interoperability Aspects.
Conceptual Organizational Technological
Interoperability 35% 20% 45%

Technological layer is the main aspect for Interoperability. This layer is basis of the whole MMEI structure. In
the first step, in Technological layer, system has to gather all available raw data. The second step, in Conceptual layer,
should be to combine all available information and forward it to the Organizational layer. The third step, in
Organizational layer, is to use combined information, analyze it and define main business objectives, create models of
business processes for companies. If there is no technological level in the company, it cannot proceed to next step.
Scale for evaluating criteria consists of four elements: NA – not achieved; PA – partially achieved; LA –
largely achieved; FA – fully achieved.
Scale for evaluating Enterprise Interoperability consists of five elements: Unprepared; Defined; Aligned;
Organized; Adapted.

Figure 2: Fully MMEI.

Description of alternatives
We used imaginable companies to evaluate interoperability level of alternatives. We did not assess real
companies because it can take very long time - 3 months or even more would be needed to gather all necessary data
from one company. If we want to compare company with other, we need same amount of time to assess it.
72
 Description of alternatives
Description of alternatives chapter describes how should or can be enterprises upgraded to higher
interoperability level.
Description of results
Results of research by DEXi – multi-attribute decision making program – are that interoperability level of
Company1 is only “Defined” (company is capable of properly modelling and describing systems and is ready for
interoperability) and interoperability level of Company2 is “Organized” (company is capable of meta modelling to
achieve the mappings needed to interoperate with multiple heterogeneous partners).
In Company1 Technological and Conceptual layers is partially achieved. Organizational layer is not achieved.
In Company2 Technological and Organizational layers is largely achieved. Conceptual layer is partially achieved, but it
does not prevent to achieve Organized Interoperability level for the whole company.
Analysis and explanation of proposed decision
Technological layer the most contributed to the results, because all Interoperability is about data exchanging
between different companies. It is possible to improve alternatives. For that we recommend upgrade some criteria
values which are described below.
If Company1 slightly increases: Technological Process from PA (partially achieved) to LA (largely achieved),
Technological layer will rise from PA (partially achieved) to LA (largely achieved). Conceptual Business from LA to
FA, Conceptual layer will rise from PA to LA. Organizational business from NA to PA Organizational layer will rise to
PA.
If Company1 improves all three steps together, the whole company Interoperability Maturity level will reach
“Organized” level.
If Company1 improves Organizational Business and Technological Process criteria Interoperability level will
rise to “Aligned” level.
If Company2 improves Organizational Business criteria from LA to FA Organizational level will rise to FA,
but there will be no effect for final Interoperability level.
Conclusion
In conclusion of this research we can say that our decision making model which is made with DEXi is really
useful. We can analyze Interoperability level of company and decide where it stands by using this model. This model
helps to evaluate company by answering only few questions contrary to using other complex ways to evaluate
Interoperability level. Also, this model helps indicate the main parts of organization where the upgrade is needed to
reach better Interoperability level.
References
[1] Taylor & Francis. Enterprise Information Systems: Maturity Model for Enterprise Interoperability.2011.
[2] Wided Guedria, Yannick Naudet, and David Chen. Interoperability Maturity Models.2008.
[3] N.Daclin, D.Chen, B.Vallespir. Methodology for Enterprise Interoperability.2008.
[4] Thomas, C., Ford, J.M., Colombi, S.R., Graham, D.R.: A Survey on Interoperability
[5] Measurement. In: 12th ICCRTS, Rhode Island (2007)
[6] IEEE Standards Information Network. 7th edn. IEEE, New York (2000)

73
 Priedas Nr.5

DEPLOYMENT OF DATA MINING AND MACHINE LEARNING TOOLS TO

IDENTIFY FACTORS INFLUENCING ALCOHOL CONSUMPTION: A
CROSS-COUNTRY ANALYSIS
Arūnas Bareišis, Aušra Kentraitė
Vytautas Magnus University, Department of Applied Informatics, Vileikos street 8, Kaunas, Lithuania,
e-mail: abareisis@gmail.com, ausra.kentraite@gmail.com
Abstract. This paper focuses on analysis of factors that influence alcohol consumption. It marks use of data
mining analysis with the help of Weka and Orange machine-learning toolboxes to discover most influencing
attributes, according to regional, taxes, religion, unemployment, and GDP levels. Analysis exposed that the
factors influencing alcohol consumption are GDP rate, continent and religion.
Keywords: data mining, machine learning, alcohol consumption, population health.

Introduction
The World Health Organization (WHO) estimates that there are about 2 billion people worldwide who
consume alcoholic beverages and 76.3 million with diagnosable alcohol use disorders. From a public health perspective,
the global burden related to alcohol consumption, both in terms of morbidity and mortality, is considerable in most parts
of the world [9].
We seek to document what is not researched about alcohol consumption and drinking patterns among various
countries and religions. Most of alcohol related researches is done by WHO [9] and National institute on alcohol abuse
and alcoholism [3]. They concentrate on alcohol consumption in countries by: age groups, genders, health
consequences, mortality, alcohol taxes, availability, marketing but a lot of areas aren’t considered. Our research is to
look at total alcohol consumption from a different point of view.
The aim of the project is to find the most alcohol usage affecting factors in the analysis of six major areas:
alcohol consumption, tax, religion, continent, GDP and unemployment. Idea is to gather data from different sources,
make data set, pre-processes data for data mining software and to use various machine learning methods for finding the
most accurate results.
The results from data mining may help countries and institutions to evaluate situations and admit decisions
according to alcohol consumption.
Data
The goal of our research is to identify factors influencing alcohol consumption from one of the following major
areas: Tax, GDP, Unemployment, Religion and Continent. To obtain data for a classifier, we collected 187 examples of
countries with 17 different attributes. Data were gathered from reports of various international health and economic
organizations: Tax [6], Alcohol consumption [9], Gross domestic product [7] Unemployment [1], Continents [2],
Religion [4].
Data description
The whole data set consist of 6 major groups comprising 17 attributes in total. 15 of attributes have numerical
values and two nominal (Continent and Country). There are no missing values in the whole date set (3179 values). 187
countries are assessed in this research work. Other countries are not used, because lack of data or their smallness (like
Vatican).
Data understanding
Main research focus is on total alcohol consumption target variable. By predicting target variable, it can help
health organizations to evaluate countries future situations if there will be Tax, GDP or other areas changes; predict
unknown alcohol consumption in country by specific attributes.
If countries have high individual taxation and raising unemployment rate, this may lead to increased alcohol
usage. Our initial research hypothesis: individual taxation and unemployment rate in the county can be the most
affecting factors for total alcohol consumption.
Data pre-processing
We are using 187 examples in the data set. 17 attributes for each example from 6 major areas. The field of
Country/region name is marked as Meta field, because it is not directly used in data analysis and prediction.

74
 Class is assigned to Total-alcohol-consumption attribute. It is numerical field with wide range of data. Since
we are not interested in numerical prediction of the total alcohol consumption, we have discretized the data. In this case
it is divided by the range of values that an attribute can have. That means that our data from 187 examples is divided by
equal–frequency method. The method splits the attribute into the given number of intervals (our case 3), so that each
contains approximately the same number of examples (62-62-63). That is our research interest bounds. First category of
data is low consumption bound (<=3.74 litres), second – medium bound (between 3.74 and 8.75) and the third – high
bound (more than 8.75 litres). In order to obtain maximum information from total alcohol consumption data there are
assigned class attributes for beer, wine and spirits fields separately. .
MACHINE LEARNING METHODS USED
To evaluate the most alcohol usage affecting factors we are using ORANGE [5] (a component-based data
mining and machine learning software suite) and WEKA [8] (Waikato Environment for Knowledge Analysis, a suite of
machine learning software) which help with data analysis, predictive modelling and results visualization.
Brief description of the methods used
Generally we are using classification tree learner [5] implemented in Orange and “JRIP” rule discovery
classifier as implemented in Weka. For visualization we use classification tree graph tool. Several attributes that affect
displayed tree are taken from data set. We can define the depth to which the widget will display the tree (the smaller
trees give more concentrate results).
Brief description of the evaluation criteria
Some of the attributes directly influence to the class. Total alcohol consumption is almost directly proportional
to the consumption of the beer, wine and spirits. It is logical that more beer is consumed in a country there is larger total
consumption. Hence, we created four different sets of attributes (Table 1).
Table 1: Four attribute sets of attributes.
Attributes No. of set Attributes No. of set
1 2 3 4 1 2 3 4
Country/Region x x x x Christian x x x
Tax. Corporate x x x x Muslim x x x
Tax. Individual x x x x Buddhist x x x
Tax. Sales/VAT/GST x x x x Hindu x x x
Total alcohol consumption x x x x Other religions x x x
Beer consumption x Non religious x x x
Wine consumption x GDP per capita x x x x
Spirits consumption x Unemployment x x x x
Continent x x

First set – none of the attributes is excluded from the data set. This set is constructed for finding how all
attributes affect class results. Second set – all alcohol–related attributes are removed from the data set. Results are not
affected by other direct alcohol-related attributes. Third set – all alcohol-related attributes, religion and continent
attributes are removed. Main focus is on tax and unemployment. Fourth set – all alcohol-related attributes and continent
attributes are excluded from the date set. Major results are affected by tax and religion factors. We use four different
sets and four different classes. In total, we are researching at 16 different cases.
Evaluation
Description of results with classifications trees
Various results come from our research working with Orange program. We are using a classification tree
learner tool for searching factors which are mostly affecting results. In all the situations classification tree max depth is
limited to 2 or 3 branches. Total alcohol consumption very differs depending on one of four created sets of attributes
and assigned class.
Class Total alcohol consumption:
First attribute set. Set consists of all the 17 attributes. By high beer consumption we can predict very high total
alcohol consumption even with 94.6 percentage accuracy. If beer usage is less than 1 litre per capita then country’s total
alcohol consumption will be lower than 3.74 litres per capita (Table 2).
Table 2: Attributes having most influence in set1.
Low bound Mid Bound High bound
IF Condition beer<1,01 beer in (1,01:3,895) beer>3,895
75
 Then Total= <3,74 (3,74:8,75) >8,75
Instances 56 of 77 42 of 73 35 of 37
Percentage 72,7 57,5 94,6

Second attribute set. Set consists of all the data except kinds of alcohol attributes. By continent we can find out
where is biggest total alcohol consumption. Results shows that people living in Europe use more alcohol then all other
regions (Fig. 1). Medium alcohol usage is in the North America. Asia has lowest alcohol consumption rate than all other
continents.

Figure 1: Alcohol consumption by continent. Green colour represents – high, Red – mid, blue – low alcohol usage.
Third attribute set. Set focuses on tax, GDP and unemployment rate. The main results affecting factor is GDP.
Higher gross domestic product (purchasing power parity per capita) leads to bigger total alcohol usage that means the
better are relative cost of living and the inflation rates of the countries there are more favorable conditions for alcohol
usage. We can predict average or low total alcohol consumption when GDP rate is lower than 10650$.
Fourth attribute set. Set consists of all the data except kinds of alcohol and continent attributes. Results show
that the biggest alcohol usage is in those countries where percentage of Christians is higher (Fig. 2). If country has more
than 20 percent of Christians and its GDP rate is higher than 14450$ then we can predict high total alcohol usage with
80.4 percentage accuracy. If country has less than 20 percentage of Christians there will be very low total alcohol usage.

Figure 2: Alcohol consumption by Christian religion. Green colour represents – high, Red – mid, blue – low alcohol usage.

Description of results with classifications trees

Depending on class and set of attributes some of most affecting attributes differs. In order to obtain maximum
information from total alcohol consumption data there are assigned class attributes for beer, wine and spirits fields
separately. It was compared results from “JRIP” rule discovery classifier implemented in Weka and classification tree
learner implemented in Orange for getting most reliable and accurate outcomes from created data set (Table 3).

76
 Table 3: Results from different classes and situations.
Class No. of set Orange Weka Class No. of set Orange Weka
1 Beer Beer 1 Continent Total
2 Continent Muslim 2 Continent GDP
Total Wine
3 GDP GDP 3 GDP GDP
4 Christian Christian 4 GDP GDP
1 Total GDP 1 Continent Muslim
2 Continent GDP 2 Continent GDP
Beer Spirits
3 GDP GDP 3 GDP Christian
4 Muslim GDP 4 GDP VAT

In all classes and sets most frequent results with classification tree learner were Continent and GDP attributes.
This means it is quite enough to have Continent and GDP data for prediction of total alcohol consumption in country.
According to results with “JRIP” rule discovery classifier the most affecting factor for total alcohol usage is GDP rate.
Average percentage of all the predictions is 67 percent. Some of them can be predicted only with 50 percent accuracy
but others - even with 95 percent.
As documented in this paper work, an unexpected finding is that taxes and unemployment rate do not affect the
total alcohol consumption, while Continent, GDP and Religion do. This analysis has shown that biggest usage of
alcohol is among Christians, in Europe, in countries with high GDP rate. Those European countries, which have high
purchasing power parity and considerable share of Christians, should be more concerned about alcoholic drinks usage.
Conclusion
We have made an analysis on factors that influence alcohols consumption in six major areas: alcohol
consumption, tax, religion, continent, GDP and unemployment. Our initial hypothesis that individual taxation and
unemployment rate in the county can be the most affecting factors for total alcohol consumption was not confirmed.
Instead, the analysis exposed that the factors influencing alcohol consumption are GDP rate, continent and religion. The
highest alcohol consumption per capita is in Europe, medium – North and South America, low – Oceania, Africa, Asia.
GDP rate greatly influence alcohol usage. If country has higher than 10650$ GDP rate there will very high total alcohol
consumption. In those countries where are higher percentage of Christians are used more alcohol when in all other
countries with different religions.
References
[1] Central Intelligence Agency. The World Factbook. [viewed 2012.01.09]. access via the Internet:
https://www.cia.gov/library/publications/the-world-factbook/
[2] Countries Listed By Continent. [viewed 2012.01.10]. access via the Internet: http://www.worldatlas.com/cntycont.htm
[3] National institute on alcohol abuse and alcoholism. International Comparisons of Alcohol Consumption. [viewed
2012.01.11]. access via the Internet: http://pubs.niaaa.nih.gov/publications/arh27-1/95-109.htm
[4] Nation Master. Religion Statistics - Religions (most recent) by country. [viewed 2012.01.11]. access via the Internet:
http://www.nationmaster.com /graph/rel_rel-religion-religions
[5] Orange. Data mining and machine learning software suite. [viewed 2012.01.03]. access via the Internet:
http://orange.biolab.si/
[6] Tax Rates. [viewed 2012.01.08]. access via the Internet: http://www.taxrates.cc/html/gambia-tax-rates.html
[7] The Wold Bank. [viewed 2012.01.08]. access via the Internet:http://data.worldbank.org
[8] Weka. Data Mining Software in Java. [viewed 2012.01.04]. access via the Internet: http://www.cs.waikato.ac.nz/ml/weka/
[9] World Health Organization (WHO). Global Status Report on Alcohol. 2004.

77