PROJEKTO IŠEIGA (PROJECT ISSUES)

1. Atviri klausimai (problemos)

Tai išaiškėję, tačiau dar sprendimo neturinčios problemos arba klausimai, dar neturintys atsakymo, faktorių apibūdinimas, kurie dar nėra aiškūs, tačiau svarbūs sistemai.

Pavyzdžiui:

Tyrimas, siekiant nustatyti ar panaudoti regiono meteorologinio centro duomenų bazę dar nėra užbaigtas. Tai turi įtakos meteorologiniams duomenims”;

Planuojami vairuotojų darbo valandų pakeitimai gali įtakoti darbo grafiko sudarymą bei nuvalomų kelių ilgį. Pakeitimai iki šiol yra tik siūlymų stadijoje, o galutinis sprendimas galimas tik metų pabaigoj ”;

Vyriausybė planuoja pakeisti atsakomybės už automagistralių valymą taisykles, tačiau dar neaišku, kas bus keičiama”.

2.  Egzistuojantys sprendimai (Off-the-Shelf Solutions)

2.1.Pagamintos sistemos, kurios gali būti nupirktos

Pateikiamas sąrašas sistemų, kurios gali būti įsigytos ir panaudotos iškilusiems uždaviniams spręsti. Čia pateiktinos nuorodos į šių sistemų platesnes apžvalgas ar kitą charakterizuojančią medžiagą. Punkto paskirtis – įvertinti jau esamų sistemų panaudojimo galimybę, čia galima pateikti ir žinomų sistemų pavadinimus, kurių nereikėtų naudoti.

2.2.Pagaminti komponentai, kurie gali būti panaudoti

Pateikiamas sąrašas komponentų, kurie gali būti nupirkti iš kitų firmų arba panaudoti pakartotinai, perimant juos iš organizacijoje veikiančių sistemų. Čia reiktų įvardinti komponentų šaltinius (bibliotekas)

2.3.Galimas pakartotinas panaudojimas

Pateikiamas sąrašas kitų panašių sistemų. Geriau (pigiau) pakartotinas panaudojimas, nei naujo sukūrimas.

Pavyzdžiui, ”Kita organizacija įdiegė užsakovų aptarnavimo sistemą, kuri naudoja kitą operacinę aplinką bei techninę įrangą. Tačiau galima pasinaudoti (nusipirkti) sistemos specifikaciją ir sutaupyti ~ 60% analizės sąnaudų”.

3.  Naujos problemos

3.1.Problemos diegimo palinkai

Pateikiama charakteristika kuriamos sistemos įtakos jos diegimo aplinkai. Čia reikėtų charakterizuoti ir tuos dalykus, kurių nauja sistema neturėtų daryti. Punkto paskirtis – atskleisti potencialius konfliktus, kurie gali išaiškėti tik diegiant sistemą. Šis punktas reikalauja platesnio sistemos diegimo aplinkos supratimo.

Pavyzdžiui, “ Bet kuris kelių valymo tvarkaraščio sudarymo principų pakeitimas įtakos dispečerių bei valymo įrengimų vairuotojų darbą”.

3.2.Įtaka jau instaliuotoms sistemoms

Pateikiama charakteristika kuriamos sistemos įtakos jau instaliuotoms sistemoms. Labai retai sistema diegiama “tuščioje vietoje”. Būtina įvertinti kuriamos sistemos eksploatavimo problemas kartu su kitomis organizacijoje eksploatuojamomis sistemomis bei numatyti galimus konfliktus.

3.3.Neigiamas vartotojų nusiteikimas

Charakterizuojama esamų vartotojų bet kurio pobūdžio neigiama reakcija kuriamos sistemos atžvilgiu. Galimas atvejis, kad vartotojai taip eksploatuoja sistemą, kad jie patiria diskomfortą bei kitas neigiamus reiškinius. Reikia numatyti neigiamą vartotojų reakciją bei priimamas priemones.

3.4.Kliudantys diegimo aplinkos apribojimai

Pateikiama charakteristika galimų problemų, susijusių su naujos technologijos įdiegimu arba reikalingu organizacijos restruktūrizavimu.

Pavyzdžiui,”Sistemai diegti numatomas serveris nėra pakankamas apdoroti planuojamą skaitmeninių vaizdų apimtį”.

3.5.Galimos naujos sistemos sukeltos problemos

Charakterizuojamos situacijos, su kuriomis galime nesusidoroti.

Pavyzdžiui. Ar sugebėsime susidoroti su sistemos aptarnavimu, jei bus didelis jos poreikis? Ar sistema neprivers mūsų pažeisti įstatymus? Ar egzistuojanti techninė įranga pakankama sistemai diegti? 

4.  Uždaviniai

4.1.Sistemos pateikimo žingsniai (etapai)

Aprašoma sistemos gyvavimo ciklo detalės bei sistemos pateikimo būdas. Tam tikslui gali būti tinkama aukšto lygio (nedetalizuota) procesų diagrama, kurioje parodomi realizuojami uždaviniai bei jų sąsaja. Punktas skirtas numatyti būdus sistemai pateikti, kad kiekvienas turėtų vienodą supratimą apie sistemą. Nereikėtų pamiršti duomenų perkėlimo, apmokymo ir kitų uždavinių.

4.2.Vystymo etapai

Sistemos kiekvienos vystymo fazės (etapo) specifikacija bei veikimo aplinkos komponentų charakterizavimas. Punkto paskirtis – numatyti etapus naujos sistemos veikimo aplinkai sukurti, kad kūrimo procesą būtų galima valdyti. Būtina numatyti techninę bei kitą įrangą , reikalingą kiekviename sistemos kūrimo etape. Tai gali galutinai paaiškėti tik projektavimo etape.

Architektūra grindžiamas IS projektavimas

Viena iš pažangiausių veiklos procesų ir taikomųjų programų integravimo metodologijų vadinama „architektūriniu modeliavimu“ ar „architektūra grindžiamas IS projektavimas“ (angį. Architecture-Driven Approach). Veiklos informacinė architektūra apima bendros sistemos struktūros, sistemos komponenčių, loginių jų ryšių ir išoriškai matomų savybių modeliavimą (projektavimą). Organizacijų informacinės architektūros modeliavimas tiesiogiai skirtas informacijos sistemų, atitinkančių realius veiklos poreikius, projektavimo ir realizavimo metodams vystyti.

2.1. J. Zachman modelis „ISA Framevvork“

1987 m. IBM darbuotojas John Zachman, turintis 26-ių metų taikomųjų informacinių sistemų projektuotojo patirtį, sukūrė Zachman Framevvork for Enterprise Architecture – organizacinių sistemų architektūros modelį, skirtą organizacijų veiklai aprašyti ir analizuoti veiklos integralumą, vykdant veiklos kompiuterizavimą.. J.Zachman tvirtina, kad veiklos sistemos architektūros tyrimas tampa ne tik svarbus, bet ir būtinas, ruošiant organizacijas konkurencinei kovai globalioje XXI amžiaus ekonomikoje.

J.Zachman modelis trumpai yra vadinamas „ISA modeliu“ („ISA Framework“). Sis modelis teikia bendrą terminologiją ir struktūrą, skirtą sudėtingų šiuolaikinių organizacijų veiklai aprašyti. ISA Framevvork modelis turi aiškią praktinę paskirtį – apsaugoti sparčiai besivystančius biznio procesus (t.y. sparčiai augančias organizacijas) nuo desintegravimo.

Vėliau, populiarindamas šį modelį, J.Zachman įkūrė ZIFA – The Zachman Institute for Framevvork Advancement (www.zifa.com). Tai informacinių technologijų srities profesionalų tinklas, vienijantis tuos, kurie supranta organizacijų architektūros tyrimo svarbą kuriant XXI amžiaus organizacijas.

Šiuo metu J.Zachman modelis populiarus – naudojamas kuriant veiklos modeliavimo ir kompiuterizuoto IS projektavimo programų paketus (pavyzdžiui, sistema System Architect), yra plėtojamas -sukurtas trijų matavimų šio modelio variantas, kuris aprašytas ZIFA interneto svetainėje.

ISA modelio sudėtis

Organizacijos informacijos sistemos architektūros (ISA) modelis yra bazinė struktūra, kuri atvaizduoja visų paskirčių informacinių sistemų (IS), veikiančių organizacijoje, architektūrą keliais svarbiausiais aspektais, būtinais organizuojant IS kūrimą, jas integruojant, valdant, vystant ir analizuojant jų veikimą.

Tokie skirtingus tyrimo aspektus atitinkantys architektūros atvaizdavimai yra vadinami artifaktais. ISA modelis sukuria dvimatį veiklos architektūros modelį: organizacijos veikla dekomponuojama dvimatėje erdvėje. Vertikalios ašies kryptimi išdėstyti veiklos aprašymo (modeliavimo) lygmenys, horizontalios ašies kryptimi išdėstyti veiklos analizės aspektai (ISA Framework modelio sudėtis lentelė).

Pirmajame ISA modelio variante buvo trys organizacijos veiklos tyrimo aspektai „funkcijos“, „duomenys“ ir „tinklas“. 1992 m. modelis buvo papildytas trimis naujais veiklos tyrimo aspektais „žmonės“, „laikas“ ir „motyvavimas“. ISA modelio sudėtis pateikta ISA Framework modelio sudėtis lentelėje.

Veiklos aprašymo aspektai

Kiekviename aprašymo lygyje organizacijos veikla tiriama šešiais aspektais (ISA Framework modelio sudėtis lentelės stulpeliai), kurių sąlyginiai pavadinimai yra tokie:

•  „Duomenys“ (Data) , atsako į klausimą „ką?“ (What ?);

Šis stulpelis aprašo organizacijoje naudojamos informacijos turinį: duomenis. Duomenys susideda iš esybių (entities) ir jų tarpusavio ryšių (relationships).

•  „Funkcijos“ (Function), atsako į klausimą „kaip?“ (How?)

Sis stulpelis skirtas organizacijoje vykstančių procesų ir funkcijų aprašymui. Jis aprašo tai, kaip yra naudojami duomenys. Aprašo elementai yra procesai (funkcijos), argumentai, procesų (funkcijų) įeigos ir išeigos.

•  „Tinklas“ (Network), atsako į klausimą „kur?“ (Where?)

Šis stulpelis aprašo, kurioje organizacijos vietoje (kur) vyksta procesai, kur preduodami ir apdorojami duomenys. Modelis susideda iš tinklo viršūnių ir lankų.

•  „Žmonės“ (People), atsako į klausimą „kas?“ (Who?)

Šis stulpelis aprašo darbų (procesų) vykdytojus: organizacijos valdymo ir pareigų išsidėstymą: darbuotojus, padalinius ir atliekamus darbus ar formuojamus produktus. Modelis susideda iš vykdytojų (agents) ir darbų (works).

•  „Laikas“ (Time), atsako į klausimą „kada?“ (When?)

Šis stulpelis skirtas įvykių sekos aprašo sudarymui, kuris apibrėžia veiklos kriterijus, organizacijos resursų naudojimo tvarką.

•  „Motyvavimas“ (Motivation), atsako į klausimą „kodėl?“ (Why?) Šis stulpelis skirtas organizacijos veiklos motyvavimui aprašyti, kur veiklos rezultatai (produktai) ir yra tikslai ir siekiai, o veiklos priemonės yra strategijos ir metodai.