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 pat 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). Projektuojama 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 to į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 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 elementai 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