ekonomines informacines sistemos kurimo principai

1. Ekonominės informacinės sistemos kūrimo principai

Literatūroje yra išskiriami keturių pagrindinių rūšių principai, kurie
padeda racionalizuoti projektavimo darbus ir sukurti kuo kokybiškesnes
sistemas įmonėms, tai (Simanauskas, 2000):

1. sąryšių su valdymo objektu principai;

2. projektavimo metodologijos principai;

3. informacinių išteklių formavimo ir naudojimo principai;

4. kiti principai, kuriems priskiriami tokie principai, kaip:

standartizacijos ir unifikacijos principai, laisvos konkurencijos

principas ir technologinės pažangos principas.

Darbo tema daugiau įpareigoja išskirti ir aptarti projektavimo
metodologinius principus.

Projektavimo metodologijos principai

Projektavimo kompleksiškumo principas. Esmė, kad projektuojant
sistemą, reikia kiek galima išsamiau analizuoti, įvertinti ir išlaikyti
visus svarbiausius tiek valdymo objekto, tiek valdymo sistemos, taip ppat
informacinės sistemos ir išorinės aplinkos ryšius. Išsamiau įvertinamos
prielaidos, sąlygos ir ištiriamos elementų sąveikos. Be to, geriau
nustatomi veiksmai, kurie lemia sistemos kokybę ir veiksmingumą, ieškoma
efektyviausių projektinių sprendimų.

Hierarchijos principas. Gali būti kalbama apie struktūrinę objektų
hierarchiją ir struktūrinę klasių hierarchiją. Pirmu atveju, turime
hierarchiją „yra dalis” (part of), kuri rodo, kad vieni objektai yra kitų
objektų dalys (vieni objektai susideda iš kitų objektų). Antru atveju,
turime „yra vienas iš” (is a) hierarchiją, kuri rodo, kad vieni objektai
yra atskiras kitų objektų atvejis (vieni objektai yra kitų objektų
apibendrinimas). PProjektuojama naudojant smulkinamojo arba stambinamojo
projektavimo strategijas.

Pirmu atveju struktūrizavimą galima sieti su dekompozicijos principu.
Dekompozicija – visumos išskaidymas į paprastesnes sudedamąsias dalis
siekiant analizuoti, vertinti, o neretai ir projektuoti kiekvieną
nepriklausomai nuo kitų. Matematiniu požiūriu – tai didesnio matavimo
skaičiaus uždavinio pakeitimas keliais mažesniais.

Nuoseklių tikslinimų principas. Jo idėja: iš

š pradžių priimami bendresni
ir apytikriai sprendimai, realizuojami bendresni tikslai. Po to vertinami
konkretesni tikslai ir priimami detalesni sprendimai. Analizė pradedama nuo
sistemos, kaip visumos, kuri projektuojant skaidoma į posistemius ir
kompleksus, nagrinėjimo. Analizuojama ir vertinama kiekvieno įtaka kitoms
sistemos dalims ir sistemos vartotojams. Taip reikia projektuoti, kai iš
pradžių nėra pakankamai reikiamų žinių, kai ne viskas apibrėžta.

Abstrakcijos principas. Nagrinėjami keli projektinių sprendimų lygmenys,
pradedant nuo detalesnio. Kiekvienu paskesniu abstrakcijos lygmeniu
nagrinėjami bendresni sprendimai, atsisakoma vis daugiau detalių.

Struktūrizavimo principas. Jis atsirado pradėjus plėtoti struktūrinį
programavimą. Jis naudingas struktūrizuojant kompiuterizuojamas funkcijas,
duomenis.

Iteracijų principas. Remiantis šiuo principu turi būti projektuojama
taip, kad kiekvienu etapu būtų naudojami prieš tai gauti rezultatai, ir tai
dažniausiai daroma labiau detalizuotai (arba apibendrintai). Pirmiausiai
etapuose naudojami artutiniai metodai ir bendri vertinimai, atmetami
antraeiliai veiksniai, siekiama suprasti pagrindinius procesus, nustatyti
svarbiausius parametrus. Tik po tto įtraukiami ir nagrinėjami anksčiau
atmesti veiksniai ir parametrai. Vėl grįžtama prie pagrindinių veiksnių,
procesų ir parametrų analizės, tačiau dabar jau visa tai įvertinama kartu
su antraeiliais veiksniais ir konkrečiau. Toliau kartojamas procesas
tikslinamas, detalizuojamas ar apibendrinamas.

Adaptacijos principas. Jo laikantis nereikia stengtis sistemos daryti
absoliučiai ir visam laikui tobulos, o padaryti tik pakankamai gerą,
tenkinančią projektuojant keliamus reikalavimus. Svarbu jau iš pat pradžių
numatyti galimybes ekonominę informacinę sistemą nesunkiai modernizuoti ir
tobulinti jos dalis, plėsti, naudoti naujus elementus, metodus ir pan.

Išskyrėme ir aptarėme pagrindinius informacinių sistemų projektavimo
principus, kurie t
taip pat tinka projektuojant ekonomines informacines
sistemas. Kitame skyrelyje trumpai išanalizuosime informacinių sistemų
(taip pat ir ekonominių informacinių sistemų) projektavimo metodus.

2. Ekonominių informacinių sistemų projektavimo metodai

Aptarsime metodus, kurių dėmesio centre yra tinkamas ir efektyvus
sudėtingos sistemos struktūrizavimas. Juos galima sieti su programavimo
stiliais, kaip būdais organizuoti programas remiantis tam tikru koncepciniu
programavimo modeliu ir programavimo kalba, kuri yra tinkama rašyti aiškias
programas šiuo stiliumi. Plačiausiai yra žinomi procedūrinis ir objektinis
projektavimo stiliai. Pirmasis pagrįstas informacinių procesų algoritmavimu
ir geriausiai tinka sistemoms su intensyviais skaičiavimais projektuoti.
Atliekant objektinį programavimą baziniais loginiais konstravimo blokais
yra ne algoritmai, o objektai (Simanauskas, 2000).

1. Procedūrinis informacinės sistemos projektavimas

Informacinės sistemos projektavimas įsivaizduojamas kaip informacijos,
jos išdėstymo įvairiose laikmenose ir apdorojimo procedūrų projektavimas.
Paprastai realizuojama žemėjančio projektavimo strategija, pereinant visas
projekto kūrimo, jį detalizuojant, proceso stadijas. Išskiriamos tokios
projektavimo stadijos (Simanauskas, 2000):

1. Sistemos specifikavimas.

Analizuojama esama padėtis, kitų patyrimas ir vartotojų pageidavimai.
Juos apibendrinus formuluojami tikslai, kurių siekiama kuriant sistemą.
Tikslai transformuojami į jų pasiekimo vertinimo kriterijus, ribojimus ir
reikalavimus, keliamus būsimai sistemai. Aptariama kompiuterizuojamo
objekto būsena, planuojamos sąnaudos ir nauda. Iškeliami techninių
priemonių, programinės įrangos ir kompiuterių tinklo, dokumentacijos,
duomenų rinkimo, ruošimo, laikymo, kontrolės ir apsaugos, taip pat
personalo kvalifikacijos reikalavimai, teisinės ir organizacinės sąlygos
sistemai sukurti ir eksploatuoti. Parengiama ir patvirtinama sistemos
specifikacija.

2. Bendrasis projektavimas.

Detalizuojami ir patikslinami sistemos specifikacijoje nustatyti
tikslai, kriterijai ir ribojimai, aptariamos juos realizuojančios sistemos
funkcijos, parengiamas bendras kompiuterizuojamo objekto modelis. Aprašomi
kompiuterizuojamos veiklos

požiūriu svarbūs objekto komponentai
(padaliniai, darbuotojai ir pan.), jų tarpusavio ryšiai, išsidėstymas,
duomenų srautai, juos veikiantys procesai, procesus sąlygojantys įvykiai,
jų vykdymo tikslai ir realizavimo strategijos. Detalizuojant
specifikacijoje pateiktus aprašus ir reikalavimus, perfrazuojamos
vartotojų (valdymo personalo) sąvokos ir terminai į specialistų
(projektuotojų) sąvokas ir terminus. Visi siūlymai įvertinami ir
įsitikinama, kad pagal pasiūlytą bendrą projektą realizuota ekonominė
informacinė sistema (arba bent jos pagrindiniai komponentai) tikrai leis
pasiekti suformuluotuosius tikslus ir tenkins reikalavimus. Sistemai
keliami reikalavimai turi būti perfrazuojami į reikalavimus atskiriems
sistemos komponentams, detalizuojami tų komponentų parametrai, išskiriamos
prasmingų sistemos realizavimo variantų alternatyvos, jos įvertinamos ir
išrenkami geriausi (efektyvūs) jų variantai ir deriniai, formuluojami
taikomieji kompleksai.

3. Detalus projektavimas.

Parengus ir suderinus bendrą projektą, specifikuojami, projektuojami
ir konstruojami arba įgyjami visi reikalingi sistemos komponentai
(techninės priemonės, programų sistemos, taikomosios programos, duomenų
bazės, kompiuterizuotos darbo vietos). Po to jie sujungiami į visumą
(sistema integruojama), įsitikinama, kad suprojektuota sistema tenkina
reikalavimus, numatytus sistemos specifikacijoje ir bendrame sistemos
projekte.

4. Projekto realizavimas.

Patikrinama, kaip sistema veikia realiomis sąlygomis, pasirengiama
dirbti veikiant naujai sistemai ir apmokomi būsimieji jos vartotojai. Po
bandomojo eksploatavimo pašalinami pastebėti defektai ir sistemos projektas
patikslinamas, atsižvelgiant į jo eksploatavimo metu sukauptą patirtį.

2. Objektinis ekonominės informacinės sistemos projektavimas

Pastaruoju metu vis populiarėja objektinis programavimo stilius ir
atitinkamai objektinis projektavimas. Jo atsiradimą sąlygojo tai, kad
prireikė rengti vis sudėtingesnes programų sistemas, o programavimui
naudojant algoritmines kalbas darėsi vis sunkiau tai daryti (Simanauskas,
2000).

Projektavimo esmė: realaus pasaulio aprašymui sudaromi objektiniai
modeliai, kurių baziniai el

lementai ir yra taikomosios srities objektai,
turintys savo savybių ir srautus; kiekvienas objektas yra tam tikros klasės
elementas; klasės yra hierarchiškai susietos. Projektuojant konstruojami
loginiai modeliai, aprašantys klases ir objektus, ir fiziniai modeliai –
modulius ir procesus, taip pat jų statinius ir dinaminius aspektus.
Modeliai padeda geriau suvokti problemas, modeliuoti dalykines sritis,
bendrauti su taikymo srities ekspertais, projektuoti programas ir duomenų
bazes, net rengti dokumentus.

Objektinis projektavimas būtinai susijęs su objektine dekompozicija ir
naudojamos skirtingos notacijos išreikšti įvairius loginius ir fizinius
sistemos modelius. Objektiniame projektavime klasės ir objekto abstrakcijos
padeda logiškai suskaidyti sistemas.

Objektinio stiliaus koncepcinė bazė yra objektinis modelis, o
pagrindiniai elementai – abstrahavimas, inkapsuliavimas, moduliškumas ir
hierarchija. Jei trūksta nors vieno elemento, modelis nėra objektinis.

Abstrahavimas leidžia nusakyti esmines objekto charakteristikas,
kurios išskiria jį iš kitų objektų ir tuo būdu apibrėžia griežtas
konceptualias ribas, priklausančias nuo stebėtojo perspektyvos. Pagal
naudingumą gali būti naudojamos dalykinės srities objektų abstrakcijos:
esybės, kai objektas vaizduoja naudingą dalykinės srities arba sprendimo
srities esybės modelį; elgsenos abstrakcija, kai objektas susideda iš
apibendrintos aibės operacijų, kurios atlieka tos pačios rūšies funkciją;
virtualios mašinos abstrakcija, kai objektas susideda iš operacijų; kurias
kartu naudoja aukštesnis valdymo lygmuo, arba pačios naudoja tam tikrą
žemesnio lygmens operacijų rinkinį; atsitiktinė abstrakcija, kai objektas
susideda iš operacijų, kurios tarp savęs neturi nieko bendro.

Inkapsuliavimas. Objekto abstrakcija turi būti sukurta prieš
nusprendžiant, kaip jis turi būti realizuotas. Kai tik pasirenkama, kaip
objektas bus realizuotas, šis pasirinkimas turi būti nuslėptas nuo kitų,
kad jokia sudėtingos sistemos dalis nepriklausytų nuo kitos dalies vidinių
detalių. Abstrahavimas ir inkapsuliavimas papildo vienas kitą:
abstrahavimas siejamas su objekto elgesiu, o inkapsuliavimas- realizacija,
kuri ir sukuria šį elgesį. Inkapsuliavimas dažniausiai pasiekiamas
nuslepiant atitinkamą informaciją.

Moduliškumas – sistemos savybė būti suskaidytai į vientisų ir silpnai
susietų modulių aibę. Modulio vientisumas (cohesion) reiškia, kad modulyje
esantys programos struktūriniai vienetai (klasės, objektai ir kt.) tinka
vienas kitam, yra logiškai susieti, panašūs. Kai modulių susietumas silpnas
(loose coupling), modulių priklausomybės yra minimizuotos. Dažniausiai
modulius galima kompiliuoti atskirai.

Hierarchija yra abstrakcijų sutvarkymas ir struktūrizavimas. Skiriamos
klasių struktūros „yra” (iš a) – struktūrinė objektų hierarchija, rodo, kad
vieni objektai yra kitų objektų atskiras atvejis – vieni objektai yra kitų
objektų apibendrinimas ir jos objektų struktūros „turi” (jiurt of) –
struktūrinė klasių hierarchija, rodo, kad vieni objektai yra kitų objektų
dalys – vieni objektai susideda iš kitų objektų). Svarbiausia „yra” (« a)
tipo hierarchija yra paveldėjimas, kuris apibrėžia tokį klasių santykį, kai
viena klasė bendrai naudoja struktūrą arba elgesį, apibrėžtą kitose
klasėse. Jei tų kitų klasių yra viena, paveldėjimas pavienis (xingle
inlieritance), jei kilų klasių yra bent dvi, paveldėjimas daugialypis (mul-
liple inheritance).

Kiti objektinio modeliavimo elementai, tai: tipizavimas,
lygiagretumas, išliekamumas, objektinės analizės ir pan.

Taigi, ekonominių informacinių sistemų projektavimui yra naudojami du
pagrindiniai metodai, tai: procedūrinis ir objektinis informacinių sistemų
projektavimo metodai, išanalizavome šių metodų pagrindinius elementus.

Kitame skyrelyje išanalizuosime taip vadinamas “verslo taisykles”,
taikomas projektuojant ir modeliuojant ekonomines informacines sistemas.

3. Ekonominės informacijos sistemų projektavimo “verslo taisyklės”

Ruošiantis projektuoti ekonominės informacijos sistemą, projektuotojas
privalo sukaupti daug informacijos, nusakančios probleminės srities
struktūrą, joje vykstančius procesus bei jos sėkmingo funkcionavimo
sąlygas. Paprastai darbas pradedamas nuo interviu su nagrinėjamoje srityje
dirbančiais specialistais apie analizės objektą, pavyzdžiui, buhalterijos,
žaliavų sandėlio ar savivaldybės administracijos veiklą. Specialistas
pasakojimo forma nusako savo veiklos pobūdį ir ypatybes. Šią informaciją
projektuotojas privalo kuo pilniau pasinaudoti. Tačiau panaudoti tokį
laisvu stiliumi pateiktą tekstą nėra paprasta, čia ir iškyla informacijos
pirminio struktūrizavimo būtinybė, o tuo pačiu susiduriama su “verslo
taisyklės” (VT) samprata (Butleris, Gruzdys, 1997).

Apie “verslo taisyklę” galima galvoti kaip apie būdą atvaizduoti
raktiniams sakiniams probleminės srities analizės dalyvių bendravimo metu.
Informacijos sistemos projektuotojui aktualu atrinkti nestruktūrizuotos
informacijos sraute svarbiausią informaciją – raktines sąvokas ir
teiginius. Interviu ir anksčiau sukauptos informacijos analizės metu jis
atrenka tokius sakinius arba jų fragmentus ir sustruktūrizuoja juos
suformuodamas abstraktesnį ar detalesnį probleminės srities modelį.

Jie tradiciškai turi tokią struktūrą: “Daiktavardis nusakomas kaip
probleminės srities aktorius arba aktoriaus veiklos objektas “. Pavyzdžiui:
“Klientas yra asmuo arba organizacija, kuri naudojasi firmos paslaugomis”.
Kiti sakiniai nusako sąryšį tarp probleminės srities objektų ir turi tokią
struktūrą: “Daiktavardis susijęs su daiktavardžiu”. Pavyzdžiui, “Klientas
gali pateikti užsakymą”. Kai kuriais atvejais sakiniai atspindi tam tikras
priklausomybes (apribojimus) ir turi tokią sudėtį: “Daiktavardis priklauso
nuo daiktavardžio”. Pavyzdžiui, “Klientas negali pateikti užsakymo, kurio
suma viršija jo turimą kreditą”.

Analizuojant “verslo taisyklių” prigimtį ir išvystymą, galima išskirti
“verslo taisyklių” kilmės ir gyvavimo etapus:

1 paveikslas. “Verslo taisyklių” gyvavimo etapai

Šaltinis: Informacinės technologijos’ 97: Konferencijos pranešimų medžiaga.

“Verslo taisyklės” pasižymi tokiomis savybėmis bei atlieka šias
funkcijas:

• suteikia pagrindą pradėti veiklą, o jų vieta yra tarp veiklos aktoriaus

ir veiklos objekto;

• nusako probleminės srities aktorių vietą ir funkcijas objekto veikloje;

• susieja probleminės srities sąvokas pagal jų prasmę;

• nusako ne tik esamą probleminės srities būseną, bet ir ateities

perspektyvas;

• apibrėžia sąlygas ir apribojimus, kuriais remiantis išaiškinama arba

nutraukiama probleminės srities funkcionavimo tikslams prieštaraujanti

veikla;

• suartina probleminės srities aktoriaus ir informacijos sistemų

projektuotojo

supratimą apie analizės objektą;

• atspindi pagrindinius pokyčius probleminėje srityje;

• apibrėžia trūkstamus ryšius, siekiant transformuoti neformalų verslo

partnerių bendravimą į žmogaus ir kompiuterio tarpusavio sąveiką.

Paprastai informacinės sistemos projektuotojas – profesionalas turi savo
individualius metodus “verslo taisyklėms” išskirti ir apdoroti, tačiau šie
metodai pasižymi ir daugeliu bendrų savybių. Pagrindiniai reikalavimai
keliami “verslo taisyklei” bei jos išskyrimo procesui yra šie:

Nedalomumas: Kiekvienas tam tikrą veiklą ar probleminę sritį
nusakantis sakinys turi būti dekomponuotas į nedalomų “verslo taisyklių”
aibę.

Probleminės srities formatas: Kiekviena “verslo taisyklė” turi būti
taip išreikšta, kad ją suprastų probleminės srities specialistas.

Analizės objekto terminologija: Kiekviena “verslo taisyklė” turi būti
sudaryta iš sąvokų ir terminų, suprantamų probleminės srities atstovams.

Priklausomybė probleminei sričiai: Kiekviena “verslo taisyklė” privalo
būti kilusi iš probleminės srities aplinkos, kurios bazėje būtų galima ją
patikrinti, įsitikinti jos teisingumu bei, esant, reikalui, ją keisti.

Klasifikuojamumas: “Verslo taisyklės” turi būti klasifikuojamos
priklausomai nuo jų paskirties.

Formalizuotumas: Kiekviena “verslo taisyklė” turi būti transformuota
naudojant tam tikrą formalizmą arba struktūrizavimo technologiją, siekiant
didesnio tikslumo atspindint probleminės srities savybes.

Verslo taisyklių suderinamumas: Kiekviena “verslo taisyklė” gali būti
sugrupuota su kitomis, suformuojant korektišką sudėtinę “verslo taisyklę”.

Nepertekliškumas: “Verslo taisyklių” aibė turi turėti minimalų
pertekliškumą.

Neprieštaringumas: “verslo taisyklių” aibė turi būti neprieštaringa,
t.y. joje neturi būti viena kitai prieštaraujančių taisyklių.

Analizuojant “verslo taisyklių” nedalomumo savybę, galima konstatuoti,
kad pirminį probleminės srities aprašymą reikia išskaidyti į elementarias
dedamąsias, kurios daugiau negali būti dekomponuojamos neprarandant jų
esmės.

Pagrindžiant reikalavimą “verslo taisykles” išreikšti taip, kad jas
suprasti galėtų probleminės srities specialistas, galima teigti, kad
“verslo taisyklės” aprašo analizės objektą, o ne informacijos sistemą, kuri
kuriama probleminėje srityje vykstantiems procesams automatizuoti.
Probleminės srities specialistas puikiai žino tik savo darbo aplinką ir
specifiką, todėl “verslo taisyklės” jam turi būti suprantamos, kad
pasikeitus jo veiklos sąlygoms, jis galėtų tiksliai pasakyti, kuri “verslo
taisyklė” pasikeitė. Taigi, “verslo taisyklės” turi būti kaupiamos ir
tvarkomos probleminės srities specialistui suprantamoje formoje, o ne
sumodeliuotos griežtai disciplinuotoje formoje, orientuotoje į kompiuterį.

Struktūrizuojant informaciją apie probleminę sritį nėra

vienareikšmiško kelio – patį dalyką galima išreikšti keletu skirtingų

formų. Iš vienos pusės, orientuojantis į probleminės srities

auditoriją, “verslo taisyklę” galima išreikšti minimaliai

disciplinuotai. Iš kitos pusės, galima vadovautis griežtais apribojimais,

laikantis modeliavimo principų ir logikos, taip išgaunant kuo didesnį

tikslumą. Be to, “verslo taisyklę” galima atvaizduoti grafiškai.

“Verslo taisyklių” išskyrimo ir formalizavimo mechanizmo sukūrimas

turėtų papildyti ekonominių informacinių sistemų projektavimo metodologiją.

Atlikome trumpą taip vadinamųjų “verslo taisyklių”, naudojamų

informacinių sistemų projektavime, analizę, išskirdami pagrindines šių

taisyklių savybes ir atliekamas funkcijas bei jų išskyrimo procesui

keliamus reikalavimus.

Kitame skyrelyje analizuosime pasaulio ir Lietuvos situaciją

ekonominių informacinių sistemų projektavimo sektoriuje, t.y. pereisime

informacinių sistemų vystymosi istoriją nuo nedidelių prie modernių ir

korporatyvių informacinių sistemų; išskirsime pagrindinius tikslus ir

bruožus tokių ekonominių informacinių sistemų, kaip VADIS ir FORPOST.

4. Ekonominės informacijos sistemų projektavimo metodai pasaulyje ir

Lietuvoje

Lietuvoje ilgą laiką buvo projektuojamos nedidelės ekonominės
informacijos sistemos, kurios neviršydavo taip vadinamo “3*3” lygio (tai
reiškia, jog tokią sistemą su FoxPro ar Clarion trys specialistai
realizuoja per tris mėnesius). Aktyvėjant administracinei veiklai ir
pradedant atsigauti didžiosioms pramonės įmonėms, Lietuvoje didelių
informacijos sistemų (IS) projektavimui vėl yra skiriamas nemažas
dėmesys (Kulbokas, Telešius, 1997).

Klasikiniai IS projektavimo metodai egzistavo ir buvo taikomi
autonomiškai, be bendrų sąlyčio taškų su organizacijų administracijos
sistemų ar valdymo sistemų tobulinimu. Tačiau tik dabar, šiuolaikiniame
informacinių technologijų vystymosi etape tapo galima pažiūrėti į veiklos
procesų reinžinieriją, naujas IT ir žmogiškąjį faktorių ne kaip trijų
atskirų komponentų sumą, o kaip į visumą, vadinamą naujuoju sisteminiu
projektavimu (NSP). Veiklos procesų reinžinierija dabar jau IT ir IS
srities terminas, apimantis kiberkorporacijų formavimą ir projektavimą.

Informacinių sistemų projektavimas yra suprantamas kaip organizacinių
priemonių ir projektavimo metodų visuma, skirta projektuoti tiek bendros
paskirties, tiek specializuotoms informacijos sistemoms (bankų, apskaitos,
sandėlių, biržos ir pan. sistemos), tiek universalioms adaptyvioms IS
(elektroniniai archyvai, biuro veiklos automatizavimo sistemos, statistinių
duomenų apdorojimo sistemos ir pan.). Metodai ir technologijos kartu su
naudojama programine įranga sudaro projektavimo instrumentarijų.
Instrumentarijų sudaro priimtos metodikos ir standartai, reliacinė
duomenų bazių valdymo sistema (RDBVS, dažniausiai tai Oracle arba
Informix), CASE sistema (RDBVS – orientuota arba bendresnė,
pavyzdžiui, VanageTeam). Į projektavimo instrumentarijų įeina naudotojo
bei projektuotojo grafinių sąsajų programos, duomenų saugyklos,
kolektyvaus projektavimo priemonės ir panašaus lygio programinė įranga.

Visa tai vadinama klasikiniais IS projektavimo metodais. Projektavimo
eiga buvo labai aiškiai suskirstyta į stadijas, kiekviena kurių turėjo
baigtis pateikus griežtai reglamentuotą dokumentaciją.

Tokia IS projektavimo eiga užsieninėje literatūroje buvo vadinama
vaterfall modell ir reiškė nors ir iteratyvų, bet vis tiek nuoseklų IS
projektavimo būdą. Kalbant apie klasikinius projektavimo metodus labiausiai
žinomomis notacijomis tapo DFD (Data Flow Diagrams) kartu su DD (Data
Dictionary) ir procesų specifikacijomis, ERD (Entity – Relatioship
Diagrams) ir STD (State Transition Diagrams) notacijos.

Lygia greta informacinių sistemų projektavimo krypčiai vystėsi E.
Deming pradėti gamybos valdymo ir administracinio darbo tobulinimo (CPI,
Continious Prcess Improvement) darbai. Iš E. Deming darbų išsivystė BPR ir
TQM ( Total Quality Management) kryptys. Jose buvo sprendžiami tokie
pagrindiniai organizacijų veiklos klausimai:

• nedidinant žmonių, laiko ir kitų resursų sėkmingai spręsti pagrindinius

funkcinius uždavinius;

• kaip globalizuoti administracinės sistemos veiklą, užtikrinant jos darbą

paskirstytiems klientams 24*365 laiko režime;

• kaip palaikyti mobilių klientų darbą;

• kaip, orientuojantis į būsimus klientų poreikius, diegti naujas

technologijas

• ir kiti.

Naujasis sisteminis projektavimas nagrinėjamas, kaip trijų komponentų
visuma:

• veiklos procesų reinžinierija,

• naujos informacinės technologijos,

• žmogiškasis faktorius.

Jei klasikiniai projektavimo metodai buvo kuriami tranzakcijų
apdorojimui orientuotoms IS, tai NSP apima ir į komunikacijas bei
koordinavimą orientuotas IS. Klasikiniai projektavimo metodai gerai tinka
IS, kurios atlieka santykinai daug skaičiavimų, operatyviai tenkina laisvas
SQL kalbos naudotojo užklausas ir leidžia saugoti didelius griežtai
struktūrizuotos informacijos kiekius.

Taikant NSP akcentas nuo informacijos srautų analizės perkeliamas link
naudotojų tarpusavio sąveikų analizės. Projektuojant IS tokiu būdu tiesiog
savaime įvertinamas ir veiklos procesų reinžinierijos aspektas. Grupinės
infrastruktūros apima ne vien technologinius klausimus. Diegiant
jas, neišvengiamai keičiasi žmonių bendradarbiavimo procesai.

4.1 Lietuvos Vyriausybės administracinės (ekonominės) sistemos VADIS

projektavimas

Lietuvoje įgyvendinti Vyriausybės administracinės informacijos
sistemos VADIS projektavimo darbai. VADIS kūrimo darbai vyko trylikoje
tarpusavyje susijusių darbų krypčių, tai sudaro apie šimtą
įvairių koordinuojamų darbų pozicijų. Pagal priimtas tarptautines
normas: VADIS projektas priklauso didelių ir sudėtingų projektų
kategorijai. VADIS grupinėje infrastruktūroje tarpusavyje derinami
reliacinių duomenų bazių, grupinio darbo sistemų ir Internet/Intranet
krypties privalumai. Pagrindiniai vykdomi darbai projekto etapuose
(Kulbokas, Telešius, 1997):

• VADIS infrastruktūros sukūrimas;

• Tarpinstitucinių ryšių posistemio projektavimas;

• VADIS informacinių fondų projektavimas;

• apsaugos priemonių sistemos sukūrimas;

• VADIS naudotojų, administratorių ir diegimo ekspertų mokymas;

• standartų ir juridinių aktų paruošimas;

• projekto administravimo duomenų bazių ir technologinių priemonių

sukūrimas;

• projektinių sprendimų integralumo palaikymo darbai;

• žinių apie VADIS skleidimas ir kiti.

Susipažinome su Lietuvos Vyriausybės administracinės – ekonominės
informacinės sistemos VADIS esme ir jos įgyvendinimo etapais.

Šalia šios sistemos tiek pasaulyje, tiek ir Lietuvoje yra šiuo metu
plačiai naudojama FORPOST bankų informacinė sistema. Todėl kitame skyrelyje
išsamiau išanalizuosime šios sistemos architektūrą ir pagrindines
charakteristikas.

2. FORBIS – FORPOST bankų informacinė sistema

FORPOST yra vieninga realiai įgyvendinta bankų valdymo programinė
įranga. Tai vienintelis produktas pasaulyje sujungiantis Retail, Wholesale,
Credit Assessment ir Bank Management į vieną sistemą. FORPOST yra
pakankamai lanksti sistema dirbanti UNIX, Windows NT, Novell NetWare,
Windows 3.x ir Windows 9x aplinkose. Taip pat panaudotos CASE technologijos
su ORACLE Developer/2000 ir Designer/2000 (prieiga per internetą:
http://www.forbis.lt/index/index.html).

FORPOST yra pažangi sistema, kurios pagrindinė savybė CRM (Customer
Relation Management) garantuoja perėjimą nuo “transakcijų banko”,
atliekančio atitinkamų operacijų registravimo rezultato funkciją, prie
“santykių banko”, skiriančio pagrindinį dėmesį klientui. FORPOST
realizuotos sudėtingos priemonės nuolatiniam išteklių ir užduočių
administravimui bei prognozei.

FORPOST yra funkcionalus produktas, naudojantis Retail ir Wholesale
aplikacijų rinkinį, apimantis visą banko transakcijų spektrą ir padedantis
kontroliuoti Didžiosios knygos apskaitą, indėlių iki pareikalavimo ir
taupymo indėlių, paskolų, klientų santykių valdymą, rizikų ir resursų
valdymo mechanizmą, vertybinius popierius, finansus, pinigų rinką,
aptarnavimą telefonu, Internet banką ir t.t. Statistika apie banko
finansinę padėtį gali būti pateikta bet kuriuo metu ir bet kurio
laikotarpio.

Aukštas programų komplekso slaptumo ir saugumo lygis sudarė galimybę
padidinti filialų, departamentų ir kitų struktūrinių vienetų
nepriklausomumą ir atsakingumą.

Forpost pagrindinės charakteristikos:

• Tai vienintelis informacinis produktas suderinęs Retail & Wholesale –

nereikia pašalinės programinės įrangos;

• Klientų santykių valdymo sistema (CRM) – integruotas kliento vaizdas;

• “Klientas-serveris” technologijų pagrindu galima palaikyti ne tik

tradicinę, bet ir elektroninę, GSM bankinę veiklą;

• Sistema nepriklauso nuo kompiuterinės įrangos;

• Sistemoje įdiegtas darbo srauto valdymas;

• Sistema palaiko 24/7 duomenų apdorojimą visoje architektūroje;

• Daugiakalbiškumo principas – vienu metu gali būti naudojama daugiau nei

viena kalba;

• Daugiavaliutinės operacijos;

• Parametrizuota produktų kūrimo sistema, skirta operatyviam produktų

kūrimui;

• Valdymo įrankiai einamajai finansinei analizei sukurti;

• Integruotos front-ofiso, middle-ofiso ir back-ofiso lygio operacijos.

• Sistemoje išvystytas rizikų ir kompanijų valdymo mechanizmas.

Susipažinome su šiuo metu ne tik pasaulyje, bet ir Lietuvoje gana
greitai bankų ekonominių informacinių sistemų projektavime plintančia
FORBIS – FORPOST programa: jos esme bei pagrindinėmis charakteristikomis.

Kitame skyrelyje detaliai analizuodami kompiuterizuotos apskaitos
diegimo įmonėje projektą, apjungsime ir praktiškai išnagrinėsime tai, kas
buvo išdėstyta ankstesniuose skyriuose, t.y., kokie paruošiamieji darbai
turi būti atlikti, kokie metodai naudojami, kokios išskiriamos darbų
stadijos projektuojant kompiuterizuotos apskaitos sistemą įmonėje bei kaip
atliekamos sukurtos sistemos įvertinimas.

5. Kompiuterizuotos apskaitos sistemos projektavimas įmonėje

Norint sėkmingai mechanizuoti bei automatizuoti apskaitos darbus, visų
pirma būtina atlikti projektuojamojo objekto tyrimą ir sukurti šių darbų
mechanizavimo bei automatizavimo projektą (Christauskas, 1999).

Projektas turi būti sukurtas remiantis duomenimis, kurie buvo surinkti
visuose firmos hierarchijos pakopose, tiksliai išanalizavus kiekvieno
darbuotojo atliekamas funkcijas (pradedant darbininku ir baigiant
direktoriumi). Šių duomenų analizė leidžia sukurti pirminį, projektą kuriuo
remiantis galimas tolesnis diegimo etapas – būsimos kompiuterizuotos
apskaitos paieška, aiškiai žinant poreikius ir išvengiant didelių klaidų.

Projektuojant yra taikomi tokie metodai:

• smulkinamojo projektavimo metodas (projektuojama iš viršaus žemyn),

• stambinamojo projektavimo metodas (projektuojama iš apačios į viršų),

• plečiamojo projektavimo metodas.

Paskutiniu atveju projektuojant pirma parengiamas vienas svarbiausios
dalies projektas, kuris vėliau papildomas naujomis funkcijomis, naujų
uždavinių kompleksais ar uždavinių kompiuterizavimo projektais, susietais
su anksčiau parengtais.

Galima išskirti tokias pagrindinės diegimo projektavimo darbų stadijas:

• poreikių nustatymas,

• sistemos įvertinimas ir parinkimas,

• sistemos eksploatavimo ir priežiūros stadijos.

Poreikių nustatymo stadijoje suformuluojami tikslai, kurių siekiama
diegiant sistemą. Tikslams suformuluoti atliekami tyrimai, kuriuos vykdo
projektuotojas pagal iš anksto sudarytą programą.

Suformuluoti tikslai transformuojami į reikalavimus, keliamus būsimai
sistemai, nustatomi finansiniai ir kiti apribojimai sistemos diegimo
procesui, paruošiama ir patvirtinama užduotis (techninė užduotis). Joje
aprašomi sistemos diegimo tikslai, jai keliami reikalavimai, pateikiama
sąnaudų analizė, įvertinamos planuojamos pajamos ir efektas,
kompiuterizuojamo objekto-apskaitos esama, siekiama būklės.

Sistemos įvertinimo ir parinkimo metu įsitikinama, kad pagal pasiūlytą
bendrą projektą gauta informacinė sistema tikrai leis pasiekti techninėje
užduotyje suformuluotus tikslus ir tenkins keliamus reikalavimus.
Reikalavimai sistemos detalizuojami į reikalavimus atskiriems jos
elementams:

1. tachninėms priemonėms,

2. duomenų bazėms,

3. kompiuterizuotoms darbo vietoms.

Sistemos diegimo metu patikrinama, kaip sistema veikia realiomis
sąlygomis, ji paruošiama darbui ir apmokomi būsimieji sistemos vartotojai.
Jei reikia pašalinami pastebėti defektai ir sistema tobulinama.

Projektuotojai turi atlikti tokius darbus: parengti informacijos
klasifikatorius, postovios laike naudojamos informacijos žinynus,
vartojimo, programos naudojimo ir paleidimo instrukcijas, rezultatinę
informaciją panaudoti operatyviai ūkinių operacijų kontrolei, analizei ir
valdymo sprendimams priimti.

IŠVADOS

Atlikus literatūros analizę galima reziumuoti tokias pagrindines darbo
išvadas:

1. Išskiriami tokie pagrindiniai ekonominių informacinių sistemų
projektavimo principai, kaip: kompleksiškumo, hierarchijos, dekompozicijos,
nuoseklių tikslinimų, abstrakcijos, struktūrizavimo, iteracijų ir
adaptacijos principai;

2. Ekonominių informacinių sistemų projektavimui yra naudojami du
pagrindiniai metodai, tai: procedūrinis ir objektinis informacinių sistemų
projektavimo metodai;

3. Ekonominių informacinių sistemų projektavimo ir modeliavimo
procese labai svarbu laikytis “verslo taisyklės” pagrindinių reikalavimų,
kas leidžia daug paprasčiau ir sparčiau atlikti projektavimo ir modeliavimo
darbus;

4. Pasaulyje ir tuo pačiu Lietuvoje yra naudojama daug įvairių
ekonominių informacinių sistemų, pradedant RDBVS Oracle ar Informix ir
baigiant iš E. Deming darbų išsivysčiusiomis BPR ar TQM (Total Quality
Management);

5. Lietuvoje ypač gerai žinomos Lietuvos Vyriausybės administracinė
-ekonominė informacinė sistema VADIS ir populiarėjanti bankų informacinė
sistema Forbis- Forpost;

6. Kiekviena įmonė, nusprendusi diegti bet kokią ekonominę informacinę
sistemą, tarkim kompiuterizuotos apskaitos, turi itin didelį dėmesį skirti
šios sistemos projektavimo procesui, kuris turėtų prasidėti projektuojamo
objekto tyrimu ir baigtis įdiegtos sistemos patikrinimu.

4.

———————–

1. Pradiniai duomenys apie probleminę sritį

2. Detalus pasakojimas apie probleminę sritį

3. Verslo taisyklės

4. Verslo taisyklių formalus aprašas

Leave a Comment