1. Informacijos sistemos samprata, paskirtis, pavyzdžiai, tipai.
IS tikslas-užtikrinti efektyvų inf-jos panaudojimą organizacijoje, aprūpinti ją tikslia ir pilna inf-a, užtikrinančia įmonės reikmes priimant valdymo sprendimus. Galima išskirti kelis IS tipus, priklausomai nuo jų įtakos (teikiamos pagalbos), įmonės funkcionavimo:
Duomenų apdorojimo sistema (DAS). DAS-tai informacijos sistema, apdorojanti didelius inf-os kiekius, atspindinčius elementarius organizacijoje vykstančius procesus.
Informacinė valdymo sistema (IVS). IVS-išplėsta DAS. Jos tikslas ne tik registruoti ir kaupti inf-ją, bet ir aprūpinti reikiama inf-a vadybininkus bei kitus tam tikrų procesų valdymą užtikrinančius asmenis. Ši inf-a dažniausiai būna labiau struktūrizuota, apibendrinta, pateikiama abstraktesnėje formoje. Pvz.: elementari pagamintos produkcijos apskaita (DAS).
Gaminys Kiekis Atsilikimas nuo gamyb. užd.
(darbo dienomis)
Jei DAS atlieka elementarią atlyginimų apskaitą, tai IVS pateikia statistinę inf-ą apie vidutinį atlyginimo per laikotarpį, kvalifikacijos kėlimo rezultatus ir pan. IVS turi pateikti inf-ą apie organizacijos veiklos vystymosi tendencijos nukrypimus nuo siekiamų tikslų.
Sprendimų priėmimo sistema (SPS). SPS-tai išplėsta IVS. Ji turi išvystytas analizės ir sprendimų priėmimo priemones. Pvz.: SPS gali turėti optimizavimo priemones priimant tam tikrus sprendimus, tačiau ir visais atvejais galutinį sprendimą priima žmogus.
2. Informacijos sistema, kaip tam tikros organizacijos (darbinės sistemos) dalis.
Žmonės registruojantys, apdorojantys ir naudojantys inf-ą.
Inf-a apie darbą, kurį vykdo žmonės ir tam tikra technologija.
Formatuoti duomenys, tekstai, vaizdai, garsai.
Informacinė įranga, algoritminė įranga.
3. Tikslai, veiksmai ir objektai: trys probleminės srities tyrimo aspektai. Reikalavimai veiksmų, tikslų ir objektų modeliavimo priemonės.
Tiriant probleminę sritį tikslų aspektu tenka atsakyti į klausimus: kokie organizacjos egzistavimo tikslai? Ko siekia organizacijos žmonės? Kokios organizacijos veiksmų vykdymo garantijos (perspektyvos)? Analizuodami organizaciją tikslų aspektu, nustatome probleminės srities gyvavimo tikslus, atskleidžiame konfliktus tarp jų bei aplinkybes, galinčias sutrukdyti pasiekti tikslus. Pvz.:
pakviesti optimalų plenarinių pranešėjų skaičių;
įtraukti į konferencijos programą tik geriausius pranešėjus;
konferencijoje turi dalyvauti ne mažiau kaip 100 moksleivių.
Analizuodami organizaciją veiksmų aspektu, užduodami tokie klausimai: kokie veiksmai vykdomi organizacijoje? Kokie žmonės (padaliniai) kokius veiksmus atlieka? Kokie veikmų tarpusavio ryšiai? Šios analizės metu identifikuojami organizacijos veikėjai, jų veiksmai bei atsakomybės struktūra. Pvz.: išsiųsti kvietimus atrinktiems pranešėjams; sudaryti konferencijos dienotvarkę; registruoti pageidavimus viešbučiams.
Analizuojant organizaciją objektų pjūvyje, atsakome į klausimus: kokie objektai, reiškiniai, sąvokos egzistuoja organizacijoje ir jos aplinkoje? Kokiomis savybėmis objektai pasižymi? Kokie objektų tarpusavio ryšiai? Kaip objektai atsiranda, kinta, išnyksta? Kokie įvykiai įtakoja objektus? Analizuojant objektus tiriamas jų elgesys ir kitimas laike. Be to, nustatomos taisyklės, ribojančios objektų būsenas bei jų elgesį. Pvz.:
straipsniai, pranešėjai, sekcijos ir pan. (objektai);
pavėluotai atsiųsti straipsniai atmetami;
straipsnio peržiūrėti negali asmuo, dirbantis ten pat kaip ir autorius.
Tikslai nusako objektų pageidaujamas būsenas, tuo pačiu, kokie objektai yra reikalingi kokios jų savybės (pageidaujamos) ir kaip jie turi sąveikauti tarpusavyje. Veiksmai įtakoja objektų būsenas, be to, jie turi būti įvykdyti taip, kad patenkinti tikslus. Kuriant IS būtina sudaryti organizacijos modelį, atspindintį ją 3 aspektais. Jis turi patenkinti tokius reikalavimus:
Turi būti paprastai ir suprantamai aprašyti, kad projektuotojas ir vartotojas galėtų juo naudotis kaip tarpusavio bendravimo pagrindu.
Modelis turi būti detalizuotas ir nedviprasmiškas, kad būtų pagrindu kitiems IS projektavimo etapams.
Veiksmams modeliuoti yra nemažai priemonių: duomenų srautų diagrama, būsenų kaitos diagrama. Tikslų modeliavimui tokiu priemonių nėra. Tėra tik nauji, dar neištirti metodai. Objektų modeliavimui seniausi priemonė-ER modelis; tačiau ER modelis daugiau išreiškia statistinius probleminės srities aspektus ir tik nesudėtingos taisyklės, nusakančios objektams keliamus reikalavimus. Šį trukūmą pašalina objektiškai orientuoti metodai, atspindintys tiek statinius, tiek dinaminius probleminės srities aspektus.
4. Tradicinio infornacijos sistemų kūrimo proceso sudėtis.
5. Reikalavimų nustatymo etapo turinys ir specifika (bendra charakteristika).
Tai mažiausiai apibrėžtas ir struktūrizuotas etapas. Priežastys:
Labiausiai priklausantis nuo konkrečios probleminės srities; (mažiausiai techniškas).
Reikalavimai iš prigimties nėra apibrėžiami, naudojant griežtus metodus.
6. Problemos apibrėžimas reikalavimų nustatymo metu.
Pagrindžiamos sistemos kūrimo priežastys. Tradiciškai tai gali būti pateikta techniniame pasiųlyme (sistemos kūrimo pagrindime). Šis dokumentas neturi griežtos formos. Jame apibrėžiama sistemos paskirtis ir jos kūrimo tikslai. Kuriant sistemą galima siekti
bent vieno tikslo: išspęsti problemą, įvykdyti nurodymą, išplėsti tam tikros veiklos galimybes. Jie vėliau detalizuojami. Sistemos kūrimą pagrindžiantys fatoriai:
inf-os apdorojimo galimybių išplėtimas (padidinti inf-os apdorojimo greitį, paieškos galimybes);
komunikavimo galimybių išplėtimas (organizacijos vidaus ir išorės ryšių patobulinimas, padidinant pranešimų perdavimo greitį; tikslumą, kompiuterizuojant dokumento perdavimą);
valdymo patobulinimas (valdymo tikslumas, pilnumas, savalaikiškumas);
kainų (pinigų) valdymas;
konkurentabilumo padidinimas.
Techninį pasiūlymą rengia labiausiai patyrę IS kūrimo ir analizės specialistai. Procesas trunka keletą dienų. Pateikiama ataskaita, susidedanti iš:
spręstino uždavinio apibrėžimas;
siūlomas sprendimas, kuriame paaiškinama IS pagalba ir numatoma nauda ją sukūrus;
reikalingi resursai; (fiksavimo, laiko).
7. Sistemos kūrimo galimybių analizė ir jos atlikimo aspektai.
Jo metu įvertinamos realizavimo galimybės techninio pasiųlymo išanalizuojant uždavinį ir parenkant optimalų sprendimą. Gali būti keli alternatyvūs sprendimai ir nefunkciniai reikalavimai sistemos kūrimo galimumas pagrindžiamas šiais aspektais:
sistemos atitikimas organizacijos funkcionalumo tikslams (reikia, kad atliktų organizacijai reikiamas (trūkstamas) f-jas);
ekonominis kūrimo galimumas (įvertinamos finansinės išlaidos ir numatoma nauda. Pinigais įvertinami nefunkciniai reikalavimai);
techninis kūrimo galimumas (įvertinama, ar sisteos kūrimo idėja suderinama su egzistuojama technologija. Kai kurie sprendimai reikalauja papildomos techninės įrangos. Analizuojami nefunkciniai reikalavimai);
kūrimo galimumo įvertinimas organizaciniu aspektu (tai įvertina organizacijos darbuotojų pasiruošimą ir nusiteikimą eksploatuoti IS. Tai gali būti sąlygota, kai sprendimas kurti sistemą priimamas aukščiausiu lygiu, o sistemos techniniame (kūrimo) metu nedalyvauja tiesiogiai sistemos vartotojai (apie nepasitenkinimą)).
Projekto sekmės faktoriai:
Projekto palaikymas iš vadovybės pusės.
Betarpiškas tiesioginių sistemos vartotojų dalyvavimas kuriant sistemą.
8. Sistemos kūrimo galimybių analizės rezultatai ir jų panaudojimas projekto planavimui.
Sistemos kūrimo galimybių analizės rezultatai. Šis etapas sudėtingas todėl, kad dauguma klausimų negali būti tiksliai atsakyti dėl nepakankamo probleminės srities žinojimo. Vienas iš faktorių, lemiančių IS kūrimo sekmę yra IS projektuotojų komandos pasiruošimas darbui. Jis nėra analizuojamas pakankamai. Šio etapo metu tyrimas atliekamas apytiksliai ir greitai, atmetant pasiūlymus, neatitinkančius organizacijos vystymosi strategijos, techniniu požiūriu neįmanomus, duodama nauda nepateikiant išlaidų, bei vartotojui nesant pasiruošiusiam (nusiteikusiam) naudoti šios sistemos. Šį etapą vykdo sistemos analitikai, diskutuojantys su vartotojais bei analizuojantys dokumentaciją. Jei paruošia ataskaitą, kurioje pateikiama:
bendri funkciniai reikalavimai;
svarbiausi nefunkciniai reikalavimai (pvz.: saugumas);
Ataskaitoje turi būti apžvelgti visi 4 IS kūrimo galimumo aspektai. Taip pat gali būti priimtas vienas iš sistemos kūrimo variantų:
Sistema kūriama savo jėgomis.
Sistema užsakoma kitoje organizacijoje.
Perkamas jau sukurtas paketas.
Sistemos kūrimu gali būti išskirti keli etapai: sukūriamas pilotinis projektas, kuris paskui išplėčiamas, išvystant funkcines galimybes.
Projekto planavimas. Atlikus sistemos kūrimo galimumo analizę, galima sudaryti IS kūrimo planą. Jis apima finansavimo poreikius laiko ir projektuotojų poreikius. Projekto planas yra hierarchijos struktūros, kuriame sistemos kūrimoetapai detalizuojami, numatant jų turinį ir atliekamus darbus, gaunamus rezultatus, reikalavimus kokybei ir būdus (taškus).
9. Reikalavimų įgijimo paskirtis ir metodai.
Reikalavimų įgyjimas. Patvirtinus sistemos kūrimo galimumą, toliau detalizuojami vartotojo poreikiai. Nustatomi naudojant:
Stebėjimą. Jo metu stebimas tam tikro probleminės srities aktoriaus elgesys darbo metu ir jo darbo aplinka. Stebint jo vietą nustatoma:
jo funkcijos ir vieta sistemoje;
pagrindiniai naudojami inf-os šaltiniai, pateikiami rezultatai ir inf-os pobūdis.
Stebint aktoriaus darbo apliką nustatomi jo poreikia inf-ai bei galimybės išplėsti jo veiklą, pagerinant darbo aplinkos inf-nę infrastruktūrą. Šis metodas naudojamas tuomet, kai kitų poreikių šaltiniai duoda prieštaringus rezultatus arba kitų šaltinių nėra. Stebėjimas gali būti atliekamas betarpiškai, dalyvaujant ar jam nedalyvaujant.
esamo sistemos dokumentacijos (inf-os srautų) analizę. Ji atliekama tiriant esamoje sistemoje naudojamus duomenis : kiekybinio ir kokybinio tipo. Kiekybiniai-ataskaitų formos, pirminiai dokumentai, veiklos instrukcijos ir t.t. Kokybiniai (jie leičia organizacijos veiklos kultūrą)-reklama, skelbimų lentos pranešimai, atmintinės. Papildomai galima nustatyti: pvz.: organizacija, turinti daug dokumentų, pasirašytų vadovaujančio personalo ir reglamentuojanti veiklos taisykles yra daugiau centralizuota negu organizacijos, kuriose paplitę pranešimai skelbimų lentoje ar kiti laisvo pobūdžio dokumentai. Tai leid-ia nuspręsti ar kuriamos IS ataskaitos apie organizacinę veiklą reikia orientuoti vadovams ar daugiau žemesniam personalui.
kūriamosios sistemos
dokumentacijos analizę. Tai pastabos apie vartotojo poreikius ir apribojimus kuriamai sistemai, pateiktos ankstesniu naujosios sistemos kūrimo etapo metu. Tai daugiausia bendri reikalavimai, pateikti organizacijų strateginiame plane, problemos apibrėžimo ataskaitoje bei sistemos kūrimo galimumo pagrindime.
interviu ir anketavimą. Dažniausiai naudojamas poreikių įgyjimo metodas-interviu. Jis leidžia vartotojui savarankiškai ir betarpiškai pareikšti pageidavimus sistemai. Interviu reikia pasiruošti. Išskiriami žingsniai:
susipažinti su bazine informacija;
pagrįsti interviu tikslus;
pasirinkti tinkamą probleminės srities specialistą;
sudaryti interviu struktūrą;
numatyti klausimų tipus ir sudėtį.
Interviu struktūra:
piramidės tipo D. Pradedamas nuo specifinių klausimų išplėčiant interviu kontekstą ir baigiant apibendrinančiomis išvadomis. Naudojama vėlesniuose analizės etapuose.
piltuvėlio tipo Ñ. Pradedamas nuo bendrų klausimų ir einama link detalių. Naudojama analizės pradžioje, laisvesnio pobūdžio, leidžia atskleisti daugiau detalių.
deimanto tipo à. Pradedamas specialiais klausimais, išplėčiamas jų kontekste ir baigiama vėl. spec. klausimais.
smėlinio laikrodžio tipo.
Anketavimas. Vartotojas apklausiamas raštu. Naudojama kai reikia inf-os iš daugelio probleminės srities atstovų. Ypač tai pasiteisina, kai yra daug tokiu pat sistemos vartotojų ir reikia apibendrinti jų nuomonę arba norime atlikti paruošiamąjį darbą prieš apklausą interviu būdu. Sunkumai:
vartotojui sunkiau atsakyti į atviro pobūdžio klausimus;
anketavimas užtrunka ilgiau negu interviu.
Anketoje gali būti praleisti svarbūs aspektai, kurie interviu metu išaiškėja.
Anketą reikia sudaryti, išplatinti ir atlikti analizę.
Interviu geresnis dėl betarpiškumo, leidžia atskeisti prieštaravimus ir konfliktus ankščiau pateiktoje medžiagoje, tačiau jo metu viską reikia ne tik užregistruoti, bet ir suprasti. Poreikių įgyjimo metu nustatoma didesnė dalis vartotojo reikmių, tačiau vėlaiu jie turi būti datalizuojami ir patvirtinami.
Reikalavimų analizė. Jos metu neformalūs reikalalvimai transformuojami sudarant struktūrizuotą jų aprašymą (reikalavimų specifikaciją). Nauda:
analitikui lengviau suprasti (surasti) prieštaravimus ir trūkstamą inf-ą;
sistemiškas reikalavimų atvaizdavimas leidžia pateikti juos vartotojo patikrinimui ir patvirtinimui.