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.

Komponentinio sistemos modelio elementai

Komponentinio sistemos modelio elementai

Organizacijos informacijos sistemos komponentams ir sąsajoms tarp jų identifikuoti siūloma nauja grafinė notacija – komponentinis sistemos modelis. Šis modelis apjungia veiklos informacinės architektūros (VIA) modelio ir darbų sekos modelio savybes.

Veiklos informacinės architektūros modelis apibrėžia IS komponentų tipus, atitinkančius organizacijos veiklos domenus, kurie aprašyti Komponentinio sistemos modelio elementai lentelėje. Remiantis tuo, komponentinis sistemos modelis (analogija su darbų sekų modeliu) skirstomas į penkis takelius, kurie skirti atitinkamo vieno veiklos domeno komponentams:

• takelis „valdymo funkcijos“ atitinka verslo domeną ir skirtas šiame domene naudojamiems IS komponentams (tai IS vartotojo sąsajos komponentai) specifikuoti;

Komponentinio sistemos modelio elementai

·  takelis „taikomieji uždaviniai“ atitinka informacinių procesų domeną ir skirtas IS taikomųjų uždavinių logiką (skaičiavimus ir kitokį duomenų apdorojimą) realizuojantiems komponentams (tai IS funkciniai komponentai) specifikuoti;

·  takelis „duomenų struktūros“ atitinka informacijos domeną ir skirtas IS saugyklose (duomenų bazėse, duomenų sandėliuose) saugomos informacijos elementams, t.y. duomenų komponentams specifikuoti;

·  takelis „technologiniai procesai“ atitinka technologinių procesų domeną ir skirtas šiame domene naudojamiems IS komponentams (tai IS vartotojo sąsajos komponentai) specifikuoti;

·  takelis „išorinės aplinkos veiksniai“ atitinka VIA modelio aplinkos domenus (verslo rinkos, technologijų ir informacinių technologijų rinkos) ir skirtas šiuose domenuose esantiems aktualiems komponentams (sąveikaujantiems su jau aptartais IS komponentais) specifikuoti.

Komponentiniame sistemos modelyje informacijos sistemos komponentas vaizduojamas stačiakampiu suapvalintais kampais, sąsajos tarp komponentų žymimos rodyklėmis, šalia nurodomi sąsajų tipai.

Komponentiniame sistemos modelyje gali būti nurodytos valdymo eigos sąsajos (angl. control flow – CF), kurios sieja vieno domeno komponentus ir nurodo priežastinius domeno komponentų ryšius. Pastebėsime, kad terminas „valdymo eiga“ naudojamas objektiniame modeliavime ir reiškia proceso vykdymo valdymą.

Komponentinio sistemos modelio sudarymas

Komponentinis sistemos modelis suformuojamas transformuojant darbų sekų modelį pagal šias taisykles:

1.  Darbų sekos modelyje skaičiavimą atliekantys procesai transformuojami į informacinių procesų domeno (IPD) komponentus.

2.  Darbų sekos modelyje valdymą atliekantys procesai transformuojami į verslo domeno (BD) komponentus.

3.  Informacijos srautai, jungiantys procesus darbų sekos modelyje, transformuojami į duomenų domeno (DD) komponentus.

Materialūs srautai darbų sekos modelyje transformuojami į technologinių procesų domeno (TPD) komponentus.

Komponentinių sistemos modelių hierarchija

Analizuojant IS projektavimo aplinkoje saugomus darbų sekos modelius (jie aprašo veiklos funkcijas), gali būti sudaromi komponentiniai IS modeliai, suformuojama jų hierarchija (H={1,2„ n}), kuri siejasi su darbų sekų modelių hierarchiją. Kiekvienas kitas hierarchijos lygmuo detalizuoja aukštesniojo lygmens modelio komponentus (Komponentinių sistemos modelių hierarchijos pavyzdys pav.)

Komponentinių sistemos modelių hierarchijos pavyzdys

Komponentinio sistemos modelio atskiro domeno komponentėms ir jų ryšiams modeliuoti gali būti naudojami UML ar kitų notacijų (pavyzdžiui, IDEF standarto) atitinkami modeliai. Pavyzdžiui, BD, TPD ir DD komponentams ir jų struktūriniams ryšiams modeliuoti gali būti pritaikyta klasių diagrama, IPD komponentams modeliuoti -bendradarbiavimo diagrama.

Projektuojant integruotas kompiuterizuotas informacijos sistemas tikslinga apjungti IS kūrimą informacinės architektūros modelio pagrindu bei komponentinį IS projektavimą, siekiantį surinkti IS iš kompiuterizuotų veiklos komponentų.

Komponentinis IS projektavimo metodas susieja IS architektūros modelį, darbų sekų modelį ir atvaizduoja juose esančią informaciją į naujo tipo modelį – komponentinį sistemos modelį, kuriame išskiriami tokio tipo komponentai: valdymo funkcijos (BD), skaičiavimai arba funkciniai komponentai (IPD), duomenų struktūros (DD), technologiniai procesai (TPD), išorinė aplinka (ENV).

Pagrindiniai komponentinio sistemos modelio sudarymo tikslai yra išsaugoti veiklos modelyje egzistuojančias sąsajas tarp IS informacinės architektūros komponentų bei tiksliau specifikuoti komponentus ir jų sąsajas. Toks modelis padėtų užtikrinti organizacijos veiklos ir visų projektuojamų sistemų integralumą.

Organizacijos IS komponentų identifikavimas leistų IS projekte pakartotinai naudoti specifikuotus komponentus, kurie išsaugo veiklos srities procesų ir objektų semantiką, o realizavus projektą – surinkti IS taikomąsias programas iš komponentų, turinčių prasminius vardus aprašytoje straipsnyje sistemos komponentų diagramoje. Naudojantis aprašytu metodu, galima modifikuoti CASE priemonių (ir struktūrinių funkcinių, ir objektiškai orientuotų), kuriose naudojami veiklos procesų modeliai (darbų sekų modeliai arba jų analogai), projektavimo aplinkas.

Panaudojamumo personos: Kitos poliklinikos ir administratorius

2.3.4 Kitos poliklinikos

Siekiai projekte

Kitos poliklinikos gali įvertinti šios poliklinikos registratūros darbą, atkreipia dėmesį į tam tikrus registratūros sistemos veikimo trūkumus bei privalumus. Projekto siekis šiuo atveju – tai panaudojamumo užtikrinimas, teisingas ir taisyklingas sistemos apipavidalinimas, aiškumas.

Charakteristikos

Kitų poliklinikų  apibendrinta

charakteristika

Programų sistemos  ir aparatūra,  kuriomis

moka naudotis

Tekstiniai redaktoriai, poliklinikos informacijos pateikimo sistemos, naršyklės.
Naudotojų įgūdžiai ir

motyvacija

Kitos poliklinikos  gali  tūrėti  klaviatūros  naudojimo įgūdžių, valdyti pelę ir kitus sąveikos būdus.
Aplinka Kitų poliklinikų darbuotojai dirba skirtingose aplinkose, kartais naudojama „vietinio eksperto“ pagalba.

Naudotojo tipas:  vidutiniškai patyrę naudotojai

Problemų aprašas:

Kitos poliklinikos rado sistemoje pacientų ligos istorijas. Greitai poliklinikos pacientai sužinojo apie duomenų konfidencialumo pažeidimą, prasidėjo teismai, sumažėjo poliklinikos pacientų skaičius.

Patobulintos sąveikos vizija

Sistema turi užtikrinti pacientų bei kitų poliklinikos darbuotojų duomenų saugumą ir konfidencialumą, apriboti kiekvieno naudotojo galimybes sistemoje, skirti naudotojų teises sistemos funkcijų naudojimui.

Esminių užduočių panaudojamumo  tikslai

  • klavišų paspaudimų kiekis: 5
  • naudojamų komandų kiekis: 5
  • naudotojo atliekamų veiksmų kiekis: 3
  • klavišo paspaudimo, komandų rinkimo, užduočių atlikimo trukmė 3-5 s.
  • laikas, reikalingas išmokti komandų aibę 1-3 min.
  • komandų kiekis, kurias reikia įsiminti, siekiant sėkmingai dirbti: 3
  • sistemos naudojimo žinios: didelės
  • nuostatos ir nuomonės: vidutinės
  • paramos medžiagos prieinamumas: vidutinis
  • poligrafinės ir suvokimo klaidos: vidutinės
  • laikas, reikalingas atstatyti klaidingus veiksmus: 1-5 s.

2.3.5. Sistemos administratorius

Siekiai projekte

Sistemos administratorius projektuoja, realizuoja ir prižiūri sistemą, todėl pagrindinis siekis – leisti  efektyviai projektuoti, realizuoti ir prižiūrėti sistemą. Sistemos administratoriui naudinga pateikti ataskaitas apie visos sistemos veikimą, jam yra svarbu apjungti pagrindinius sistemos žingsnius į grupes, siekiant kuo našiausio darbo ir labiausiai naudingas greitas, aiškus ir trumpas sistemos atsakas.

Charakteristikos

Sistemos administratorius projektuoja, realizuoja ir prižiūri sistemą. Sistemos administratorius gali daryti esminius informacijos sistemos duomenų saugyklos pakeitimus dėl poliklinikos personalo struktūros pakeitimų arba poliklinikos personalo atleidimo iš darbo.

Sistemos administratoriaus apibendrinta

charakteristika

Programų sistemos  ir aparatūra,  kuriomis

moka naudotis

Tekstiniai redaktoriai, poliklinikos informacijos pateikimo sistemos, naršyklės.
Naudotojų įgūdžiai ir

motyvacija

Kitos poliklinikos  gali  tūrėti  klaviatūros  naudojimo įgūdžių, valdyti pelę ir kitus sąveikos būdus.
Aplinka Kitų poliklinikų darbuotojai dirba skirtingose aplinkose, kartais naudojama „vietinio eksperto“ pagalba.

Naudotojo tipas:  ekspertas

Sistemos administratorius kaip patyręs naudotojas  dažnai naudoja sistemą, todėl kad jos vienas iš pagrindinių užduočių sistemos aptarnavimas ir prižiūrėjimas, jam  svarbus greitas, aiškus ir trumpas sistemos veikimas.

Problemų aprašas

Sistemos administratorius susiduria su daugeliu nereikalingų pranešimų, kurie yra rodomi, kai sistemos administratorius jungiasi prie sistemos.

Patobulintos sąveikos vizija

Patobulintoje sąveikoje būtų prasminga suteikti sistemos administratoriui galimybę išjungti nereikalingus jo darbui pranešimus, todėl kad administratoriui daugiausiai yra svarbus sistemos aptarnavimo greitis.

Esminių užduočių panaudojamumo  tikslai

  • klavišų paspaudimų kiekis: 10
  • naudojamų komandų kiekis: 25
  • naudotojo atliekamų veiksmų kiekis: 20
  • klavišo paspaudimo, komandų rinkimo, užduočių atlikimo trukmė: 30-60 s.
  • laikas, reikalingas išmokti komandų aibę: 5-10 min.
  • komandų kiekis, kurias reikia įsiminti, siekiant sėkmingai dirbti:15
  • sistemos naudojimo žinios: didelės
  • nuostatos ir nuomonės: didelės
  • paramos medžiagos prieinamumas: mažas
  • poligrafinės ir suvokimo klaidos: mažos
  • laikas, reikalingas atstatyti klaidingus veiksmus: 1-5 s.

Kolegos kalba apie: personas