Niquaragva

By: semenas | August 20, 2017

1. Pritaikymas (Cutover)

Pateikiamas pritaikymo veikos (darbų) sąrašas; pateikiamas jų realizavimo grafikas.

Punkto paskirtis - identifikuoti pritaikymo uždavinius, kurie turi būti įkomponuoti į projekto planavimo procesą. Jei naudojamas nuoseklus (“pažingsninis”) sistemos diegimas, tuomet reikia pateikti kiekvieno didesnio etapo šiam procesui keliamus reikalavimus.

Kokios rankinės kopijavimo/išsaugojimo operacijos reikalingos sistemos diegimo metu.

Sistemos kiekvienos vystymo fazės (etapo) specifikacija bei veikimo aplinkos komponentų charakterizavimas.

1.1.Reikalavimai esamų duomenų perkėlimui

Kokie turi būti atlikti duomenų perkėlimo darbai, ar yra reikiama programinė įranga? Jei nėra, tai čia turi būti aprašyti reikalavimai šiai įran...

By: semenas | August 20, 2017

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.  Egzi...

By: semenas | August 20, 2017

Nefunkciniai reikalavimai

Nusako sistemos savybes, kuriomis ji turi pasižymėti. Tai kokybinės funkciniuose reikalavimuose numatytų funkcijų vykdymo charakteristikos.

 

1.   Reikalavimai sistemos išvaizdai (Look and feel)

Bendri reikalavimai vartotojo sąsajai.

Pavyzdžiui:

  lengvai skaitoma sąsaja;

  paprastas (nesudėtingas) panaudojimas;

  prieinamumas, kad vartotojas nesivaržytų naudodamas sistemą;

  atitinkantis kitus vartotojo naudojamus produktus (pavyzdžiui, Lotus Notes tipinės sąsajos imitavimas);

  spalvota ir patraukli vaikams sąsaja;

  neįkyri sąsaja (pavyzdžiui, nereikalaujanti pastoviai ką nors kelis kartus patvirtinti);

  novatoriška ir meniška išvaizda;

  profesion...

By: semenas | August 20, 2017

1. Funkciniai reikalavimai ir reikalavimai duomenims

Funkcinius ir nefunkcinius reikalavimus tikslinga pateikti prisilaikant vieningos formos. Ši forma atstoja vieningą reikalavimo specifikavimo struktūrą. Ši reikalavimų forma gali būti pateikiama ant atskiros kortelės, tačiau vėliau tokiu pavidalu užregistruota reikalavimų specifikacija gali būti apdorojama kompiuterizuotu būdu.

 

Reikalavimo identifikavimas. Reikalavimas identifikuojamas trimis parametrais:

  numeriu;

  tipu;

  įvykiu arba panaudojimo atvejo numeriu.

Reikalavimas turi būti trasuojamas (stebimas) per visą sistemos kūrimo laiką, todėl logiška, kad numeravimas turi būti unikalus.

Suklasifikavus reikalavimus pagal tipus paprasčiau:

   nusta...

By: semenas | August 20, 2017

Funkciniai reikalavimai

1.  Veiklos sfera (The scope of the work)

1.1.Veiklos kontekstas (pateikiama konteksto diagrama)

Nagrinėjamai veiklos sričiai apibrėžti naudojama “Konteksto diagrama”. Šią sritį tenka ištirti, kad sukurti sistemą. Veiklos kontekstas apima plačiau, nei kuriamos sistemos atliekamos funkcijos. Kol nesuprasime darbo (veiklos), kuriam turi talkinti sistema, tol nesukursime tinkamos sistemos, kurį “įsirašys” į aplinką. Veiklos kontekstas apibrėžia dominančią veiklą ir jos naudojamus bei formuojamus informacijos srautus. Veiklos “atsakomybė” prasideda kai informacijos srautas įeina į sistemą ir baigiasi, kai rezultatinis srautas išeina iš sistemos. Išorinės esybės diagramoje modeliuoja kaimynines (gretimas) sistemas (t...

By: semenas | August 20, 2017

Projekto Apribojimai

Tai apribojimai, kurie įtakoja reikalavimų specifikaciją bei sistemos kūrimo eigą bei charakteristikas.

 

1.  Įpareigojantys apribojimai. (Mandated constraints)

1.1. Apribojimai sprendimui

Tai išankstiniai apribojimai sistemos kūrimo eigai ar charakteristikoms. Jie turi nurodymo (griežto reikalavimo) pobūdį. Juos reikia tiksliai aprašyti, nepamirštant numatyti, kaip galima “išmatuoti” (testuoti) jų laikymąsi sukurtoje sistemoje. Čia galima apibūdinti ir tokio apribojimo atsiradimo priežastis.

Šiuos apribojimus dažniausiai pateikia užsakovas, pirkėjas arba vartotojas dėl įvairiausių priežasčių. Neįvertinus šių apribojimų, sistema gali būti nepriimta. Šie apribojimai apibrėžia tam tikrą galimų sprendimų konteks...

By: semenas | August 20, 2017

Projekto varovai (Project Drivers)

1.  Sistemos paskirtis

Tai sistemos kūrimo priežastis bei nauda, kurią sistema duos, jeigu bus sukurta;Čia gali būti įvardintos veiklos problemos, su kuriomis susiduria klientas, numatant, kaip jas gali išspręsti kuriama sistema

 1.1. Projekto kūrimo pagrindas (pagrindimas)

Projekto pagrindimui gali būti pasiremta įvairiomis nuorodomis, argumentuojančiomis sistemos kūrimo reikalingumą. Galimas atvejis, kad problemos nėra, tačiau yra poreikis (galimybė) plėsti tam tikrą veiklą. Tuomet tokia galimybė turi būti aprašyta

 1.2. Sistemos tikslai (paskirtis)

Aprašoma, ko norima iš sistemos, ką ji turi atlikti, kaip ji įtakos veiklos tikslų sėkmingą pasiekimą.

 2.  Užsakovai, pirkėjai i...

By: semenas | August 20, 2017

3. CASE sistemos

 

 

Kompiuterizuotos IS projektuotojo darbo vietos programinė įranga vadinama CASE {Computer Aided System Engineering) sistema - tai IS inžinerijos programų paketas. CASE sistemos yra stambios programų sistemos, kurios skirtos informacijos sistemų projektavimo darbams kompiuterizuoti. Visos CASE sistemos sukurtos konkretaus IS inžinerijos metodo pagrindu.

Tipinė IS kompiuterizuoto projektavimo aplinka - CASE sistemos architektūra pateikta CASE sistemos architektūros schema paveiksle.

 

Pagrindinės CASE sistemos dalys:

 

Viena svarbiausių CASE sistemos dalių - projektinių sprendimų saugykla (Repository). CASE priemonė saugykla yra specializuota duomenų bazė, kurioje talpinama visa informacija, surenkama ...

By: semenas | August 20, 2017

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 I...

By: semenas | August 17, 2017

Veiklos informacinės architektūros modelis (apibendrintas)

IS architektūros elementų identifikavimas veiklos modelyje

 

Toliau pateikti sudaryti įmonės modeliai bei konkrečių modelių objektų skirstymas į domenus. Naudojami tokie sutrumpinimai: verslo domenas - VD, informacijos (duomenų) domenas - ID, informacinių procesų domenas - IPD, technologinių procesų domenas - TPD, darbo vietų domenas – DVD

 

Veiklos sąveikų modelio analizė architektūriniu požiūriu

 

Veiklos sąveikų modelio analizė architektūriniu požiūriu paveiksle pateiktame veiklos sąveikų modelyje nurodyta organizacijos objektų priklausomybė konkretiems veiklos IA domenams:

  duomenų srautai priklauso duomenų domenui (DD), materialūs srautai priklauso technologinių procesų domenui TPD;

  administraciniai padaliniai (veiklos srities objektai) priklauso biznio domenui, jeigu jie priima sprendimus, jei tik apdoroja informaciją (pirminius duomenis) - priskiriami technologinių procesų domenui TPD;

  gamybiniai padaliniai priklauso technologinių procesų domenui TPD.

 

Taikomųjų uždavinių modelio analizė architektūriniu požiūriu

 

Taikomųjų uždavinių modelį paskirstysime pagal organizacijos architektūros domenus.

Šiame modelyje nagrinėjami use case (pažymėti ovalu) yra arba veiklos procesai (tada jie priklauso biznio domenui) arba taikomieji uždaviniai (tada jie priskiriami informacinių procesų domenui).

 

Informacijos srautai tarp dalyvių ir biznio procesų (arba taikomųjų uždavinių) gali būti klasifikuojami kaip duomenų domeno komponentai (jei tai saugomi duomenys) arba veiklos domeno komponentai (jei tai analitinės suvestinės, ataskaitos,) arba kaip technologinių procesų domeno komponentai (jei tai pirminių duomenų įvedimui skirti dokumentai ar formos).

 

2.3. Komponentinio IS projektavimo metodo principai

 

Komponentinis projektavimas teoriškai turi daug privalumų, iš kurių svarbiausias - pakartotino komponentų panaudojimo galimybė. Dėl šios savybės padidėja IS kūrimo produktyvumas, IS palaikymo ir modifikavimo galimybės, o lygiagrečiai sutrumpėja IS projekto kūrimo ciklas ir sumažėja kaštai.

IS projekto lygmens komponentai projektuojami pagal modeliu pagrįstą (model-driven) projektavimo paradigmą, kurioje komponentai paveldi aprašus iš veiklos proceso modelio. IS komponentai turi būti visiškai save aprašantys. Tai reiškia, kad IS komponentas turi aiškiai apibrėžtą interfeisą ir atitinka nurodytą elgseną, bendrą visiems sistemos architektūros vidaus komponentams.

Aptariamas metodas aprašo architektūrinio IS projektavimo etapą, kuriame identifikuojami IS projekto komponentai ir jų sąsajos (interfeisai). Toliau, detalaus projektavimo etape, komponentai turi būti specifikuojami, parengiant projektą IS programinės įrangos generavimui.

Komponentinio projektavimo požiūriu IS projekto komponentai (IS projekto komponentai lentelė) yra skirstomi į:

vartotojo sąsajos komponentus (meniu, ekrano formos, ataskaitos),

duomenų komponentus (duomenų bazėse ar duomenų saugykloje talpinami informacijos vienetai),

funkcinius komponentus (skaičiavimai ir taikomųjų uždavinių logika).

 

IS projekto komponentus identifikuoja projektuotojas, CASE sistemos aplinkoje analizuodamas darbų sekų modelį, kuris aprašo konkrečią veiklos funkciją ar procesą. Taip projektuotas sudaro komponentinį sistemos modelį, kuris aprašo identifikuotus IS komponentus ir jų sąveikas.

Toliau sudaromi žemesniųjų lygmenų komponentiniai sistemos modeliai, taip tikslinama IS komponentų sudėtis ir specifikacijos.

 

Detalaus IS komponentų specifikavimo etape gali būti naudojami atitinkami objektiniai modeliai (UML, OML).

 

IS projekto komponentai

 

 

Veiklos domenas

Žymėjimas

IS komponentas

Verslo procesų domenas (biznio domenas)

BD

VARTOTOJO SĄSAJA (vadybos lygmens): Formos, skirtos duomenų peržiūrai ir analizei, ataskaitos, užklausos

Informacijos domenas (duomenų

DD

DUOMENŲ KOMPONENTAI: Saugomi duomenys (Duomenų bazių ir duomenų sandėlių turinys)

Informacinių procesų

IPD

FUNKCINIAI IS KOMPONENTAI (taikomieji uždaviniai): skaičiavimo procedūros, informacijos tvarkymo procedūros, procedūros, užpildančios duomenimis formas ir ataskaitas,

Technologinių procesų domenas technologinių, operacijų)

TPD

VARTOTOJO SĄSAJA (gamybos ir valdymo technologinių procesų lygmens): Gamybos operacijos; Pirminių duomenų įvedimo ir koregavimo formos

Aplinkos domenas

DVD

IŠORINIO VARTOTOJO SĄSAJA: Išoriniams vartotojams skirtos duomenų peržiūros formos, Užklausos, ataskaitos

 

 

IS projekto komponentus realizuoja programinės įrangos lygmens komponentai. Programinės įrangos lygmens komponentas yra programinės įrangos objektas, sąveikaujantis su kitais komponentais, atliekantis tam tikrą funkciją ar aibę funkcijų. Komponentų valdymo ir funkcionavimo optimizavimo priemonės naudoja vieningą komponentų aprašų saugyklą.


https://semenas9.wixsite.com/la-campa http://lington.livejournal.com/

next>>