Transcript Informacinių sistemų ir registrų inicijavimo, kūrimo ir eksploatavimo

Informacinių sistemų ir registrų inicijavimo,
kūrimo ir eksploatavimo metodinės
rekomendacijos ES struktūrinių fondų lėšomis
finansuojamiems informacinės visuomenės
plėtros projektams
Viktoras Bulavas, CISA, CGEIT
Informacinių sistemų audito ir valdymo asociacija ISACA
KO SIEKIAMA?
• Parengtomis informacinių sistemų ir registrų inicijavimo,
kūrimo ir eksploatavimo rekomendacijomis IVPK siekia:
– Tobulinti projektų, vykdomų pagal 2007–2013 metų Ekonomikos
augimo veiksmų programos 3 prioriteto „Informacinė visuomenė
visiems“ (IVV) inicijavimą, kūrimą ir eksploatavimą, ypač:
• Padėti IVV projektų vykdytojams apibrėžti informacinių sistemų
diegimo projektų galimybių studijų apimtį ir sudėtį;
• Tobulinti IS inicijavimą, kūrimą ir kitas IS gyvavimo ciklo stadijas,
atsižvelgiant į spėriai plintančius naujus IS kūrimo metodus;
• Tobulinti IS eksploatavimą institucijoje apimant atvejus, kai
eksploatavimo priežiūra perduodama kitam juridiniam asmeniui,
apžvelgiant geriausią bendrai paplitusią praktiką;
2
DARBOTVARKĖ
1.
2.
3.
4.
5.
6.
Investicinių projektų praktika
IS galimybių studija
IS inicijavimas
IS specifikavimas
IS priežiūra
Jūsų klausimai ir pastabos
3
Europinė investicinių projektų praktika
Projektų valdymo ciklas
2007-2013 m. programavimo periodas
4
Projekto valdymo ciklas
http://www.esf.lt/lt/documents/?type=5
http://ec.europa.eu/europeaid/multimedia/publica
tions/publications/manuals-tools/t101_en.htm
5
Projekto valdymo ciklas
Šaltinis: ESF Agentūra
6
Projekto valdymo ciklo etapai
1. Programavimo etapas – ieškomi ir analizuojami dokumentai,
susiję su organizacijos vykdoma veikla bei sritimi, kurioje
būtų įgyvendinamas projektas.
2. Identifikavimo etapas – identifikuojamos projektų idėjos
atsižvelgiant į programos prioritetus. Šio etapo tikslas yra
nustatyti ir apibrėžti problemą, iškelti ir preliminariai
įvertinti galimas projekto idėjas bei sprendimų alternatyvas.
3. Projekto rengimo etapas - rengiamas detalizuotas projekto
aprašymas (projekto paraiška) ir pasirašoma sutartis dėl
paramos gavimo.
7
Projekto valdymo ciklo etapai
4. Projekto įgyvendinimo etapas -sutartyje numatyti ištekliai
naudojami veikloms įgyvendinti ir projekto tikslams pasiekti.
5. Vertinimo etapas - sistemingas ir tikslinis projekto
įgyvendinimo ir rezultatų įvertinimas. Šio etapo tikslas yra
nustatyti pasiekimų aktualumą ir sėkmę, įgyvendinimo
efektyvumą ir projekto poveikį bei tęstinumą, taip pat
pasimokyti iš praeities.
8
Terminai (1)
• Investicinis projektas - detalus būsimo projekto įgyvendinimo
aprašymas, kuriame išnagrinėjami visi pagrindiniai
planuojamos veiklos aspektai ir pateikiamas projekto
finansinis ir ekonominis pagrindimas bei rizikos įvertinimas.
• Išlaidų-naudos analizė - sisteminis kiekybinis investicinių
projektų vertinimo metodas, leidžiantis nustatyti ir įvertinti
ilgalaikius finansinius ir ekonominius projektų padarinius
(naudą ir žalą) ir galimą projektų poveikį aplinkai.
9
Terminai (2)
• Parengiamoji, priešprojektinė studija – dokumentas
rengiamas iki sprendimo atlikti išsamią galimybių studiją,
nustatantis projekto tikslus ir pagrindžiantis reikalingumą,
apibūdinantis ir įvertinantis investicijų ir galimo finansavimo
galimybes, apibūdinantis galimą projekto naudą.
• Galimybių studija - dokumentas, aprašantis numatyto
įgyvendinti projekto analizę pagal iš anksto nustatytus
kriterijus ir pagrindžiantis optimalaus (geriausio) projekto
įgyvendinimo varianto parinkimą.
• Alternatyva – vienas iš galimų projekto scenarijų.
10
Investicinio projekto teikimo tikslas
• Išsamiai pristatyti esamą situaciją, dėl kurios reikalinga
įgyvendinti projektą.
• Pristatyti pokyčius, kurie pasireikš dėl įgyvendinto projekto.
• Atlikti projekto kaštų-naudos analizę šiais etapais:
– Įgyvendinamumo ir alternatyvų analizė;
– Finansinė analizė;
– Ekonominė (socialinė) analizė;
• Gauti finansavimą.
PARAIŠKA
• A dalis – bendroji: apibendrinta, glausta ir konkreti
informacija apie įgyvendinamą projektą;
• B dalis – specialioji: informacija projekto įgyvendinimo sričiai
aktualiais klausimais, projekto biudžeto išlaidų pagrindimas;
• Investicijų projektas (IP) – išsami informacija, susijusi su
esamos situacijos, poreikio įgyvendinti projektą bei projekto
įgyvendinimo galimybių analize, jų palyginimu bei įvertinimu –
t.y. kaštų-naudos analize.
IVV projekto vertinimui pateikiama
• Paraiška dėl projekto finansavimo, kurią sudaro:
– Bendroji (A) dalis –visiems projektams bendra, nustatyta Finansų
ministerijos, forma
– Specialioji (B) dalis – Finansavimo sąlygų aprašo priedas, patvirtintas
Lietuvos Respublikos Informacinės visuomenės plėtros komiteto
direktoriaus įsakymu (pavyzdžiui 2009 m. birželio 23 d. įsakymu Nr. T55 dėl Projektų, vykdomų pagal Ekonomikos augimo veiksmų
programos 3 prioriteto „Informacinė visuomenė visiems“
įgyvendinimo priemonę Nr. VP2-3.1-IVPK-01-V „Elektroninės valdžios
paslaugos“, finansavimo sąlygų aprašo 2 priedas)
– Investicijų projektas (IP)
Tipinės IP dalys (1)
1. Projekto esmė;
2. Užsienio valstybių patirties analogiškų elektroninių paslaugų
diegimo srityje apžvalga;
3. Galimybių pasinaudoti Viešojo administravimo institucijų
informacinių sistemų interoperabilumo sistemos (toliau
vadinama – VAIISIS) duomenų mainų sistema ir VAIISIS
teikiamomis paslaugomis aptarimas;
Tipinės IP dalys (2)
4. Aprašyta ir pagrįsta, kaip numatyta sukurti elektroninė
paslauga apims įvairialypės terpės komponentus:
1.
2.
informacijos pateikimo įvairiais pavidalais: tekstu, vaizdu, garsu,
animacija ir kt., aspektu;
informacijos pasiekiamumo įvairiais kanalais ir priemonėmis:
kompiuteriu, mobiliaisiais telefonais, skaitmenine televizija ir kt.,
aspektu;
5. Projekto įgyvendinimo alternatyvų apibūdinimas ir geriausio
sprendimo pasirinkimas;
6. Projekto finansinė analizė ir projekto gaunamos pajamos;
7. Projekto ekonominė analizė;
Naudingi šaltiniai
16
Šaltinis
http://ec.europa.eu/regional_policy/sources/docoffic/working/sf2000_en.htm
17
Naudingi šaltiniai
• 1) Guide to COST-BENEFIT ANALYSIS on investment projects
(Structural Funds, Cohesion Fund and Instrument for PreAccession) (versija 2008-06-16)
• 2) Europos Komisijos parengtas dokumentas Nr. 4
„Ekonominės naudos analizės atlikimo metodinės gairės“
(angl. Guidance on the Methodology for carrying out costbenefit analysis, Working Document No. 4)
• http://ec.europa.eu/regional_policy/sources/docoffic/workin
g/sf2000_en.htm
Tipinės IP dalys (3)
8. Projekto valdymo ir administravimo struktūros ir procedūrų
numatymas;
9. Partnerystės pridėtinės vertės projekte aptarimas (jeigu
projekte yra partnerių);
10. Projekto rizikų analizė;
11. Projekto veiklų tęstinumo apibūdinimas fiziniu, veiklos
rezultatų ir finansiniu aspektais.
REKOMENDUOJAMOS
ALTERNATYVOS
„Veikti kaip įprastai“ arba
„Nedaryti nieko“
Veikla vykdoma nedarant investicijų
„Daryti minimalius
pakeitimus“
Veikla vykdoma investuojant
minimaliai
„Daryti pakeitimus“
Veikla vykdoma investuojant
reikšmingas sumas, būtinas
įgyvendinti techninį sprendimą Nr.1
„Daryti pakeitimus kitaip“
Veikla vykdoma investuojant
reikšmingas sumas, būtinas
įgyvendinti techninį sprendimą Nr.2
20
Rekomenduojama IS diegimo projektų
galimybių studijų apimtis ir sudėtis
2007–2013 metų Ekonomikos augimo veiksmų programos 3
prioritetas „Informacinė visuomenė visiems“ (IVV)
21
Galimybių studijos ruošimo tikslas
• Šia metodika galimybių studiją rekomenduojama rengti
siekiant pagrįsti sistemos reikalingumą prieš ją steigiant ir
surinkti reikiamą informaciją paraiškų A ir B dalims bei
investiciniam projektui siekiant finansavimo pagal IVV
prioritetą.
• Vienas iš galimybių studijos rezultatų gali būti organizacijos
galimybių vykdyti tokį projektą vertinimas, arba išvada, kad
reikia vykdyti keletą projektų sekoje.
• Galimybių studija rengiama taip, kad sukaupta medžiaga būtų
naudinga ruošiant investicinį projektą ir paraiškų formas, o
vėliau ir techninę specifikaciją.
22
SISTEMŲ GYVAVIMO CIKLO
PROCESAI
1. Projekto
inicijavimas
2. Galimybių
studija
8. Peržiūra
3. Reikalavimų
specifikavimas
7. Diegimas
6. Vartotojų
priėmimo
testavimas
4. Sistemos
projektavimas
5. Sistemos
kūrimas
*Gyvavimo ciklas pagal
INTOSAI
23
SDLC TECHNINIAI PROCESAI
(ISO 15288:2008)
1. Dalininkų
reikalavimų
įvardinimas
11. Naikinimas
2. Reikalavimų
analizė
3. Architektūros
dizainas
10. Priežiūra
9. Valdymas
4. Diegimas
8. Validavimas
5. Integravimas
7. Perkėlimas
6. Verifikavimas
24
Galimybių studijos perspektyvos
Techninė
Laikinė
Operacinė
Ekonominė
Teisinė
25
Kitos galimybių studijų perspektyvos
Geografinė
Aplinkosauginė
Resursų
Konkurencinė
Kultūrinė
Socialinė
26
Galimybių studijos turinys
•
•
•
•
•
•
•
Įvadas;
Santrauka;
Esamos situacijos analizė;
Įgyvendinimo alternatyvų aprašymas;
Finansinis ir ekonominis alternatyvų vertinimas;
Detali pasirenkamos alternatyvos analizė;
Priedai.
27
Įvadas
• Įvade apibūdinamos projekto ištakos,
• įvardinami jo iniciatoriai ir pagrindiniai dalininkai,
• įvardinami pagrindiniai projekto iniciatorių tikslai bei
projekto rezultato panaudojimo lūkesčiai jo įvykdymo atveju,
• pagrindžiamas projekto atitikimas organizacijos strategijai ir
2007–2013 metų Ekonomikos augimo veiksmų programos 3
prioritetui „Informacinė visuomenė visiems“, pasirinktos
priemonės įgyvendinimo stebėsenos rodikliams, pristatomas
projekto išskirtinumas.
28
Santrauka
• Santraukoje pateikiama vėlesniuose skyriuose detaliai
išdėstytos, projektą pagrindžiančios informacijos, esmė.
• Šioje dalyje pristatomi:
– pasirinktos alternatyvos apimties uždaviniai,
– dalininkų rolės vykdant uždavinius,
– papildomo finansavimo poreikiai,
– esminės sėkmės prielaidos ir prognozuojama nauda.
29
Esamos situacijos analizė
• Vertinamas pokyčių savalaikiškumas; pagal procesų brandos
vertinimo metodiką siekiamas veiklos procesas negali peršokti
per kelis lygius, todėl nustačius nenusistovėjusius ir
neaprašytus procesus, jiems negali būti teikiama
rekomendacija automatizuoti.
• Pateikiamas paslaugų tobulinimo galimybių aprašymas;
• Šio skyriaus rezultatų apibendrinimui atliekama vidinių
stiprybių ir silpnybių bei išorinės aplinkos grėsmių ir galimybių
analizė, kuri įvertina esamą būklę, nustato sritis, kurias reikėtų
tobulinti, atskleidžia išorinės aplinkos galimybes, kuriomis
galima pasinaudoti bei pavojus, kurių būtina išvengti.
30
Esamos situacijos analizė
• Esamos būklės analizėje atliekamas visapusiškas esamos
automatizuotinos veiklos situacijos įvertinimas, nustatant
projekto reikšmę ir vietą organizacijos plėtroje ir aplinkoje;
• Nagrinėjama automatizuotinos veiklos srities būklė, svarbiausi
organizacijos pasiekimai IVV prioriteto kontekste, esamo šios
veiklos kompiuterizavimo būsena;
• Analizuojami teisės aktai, įstatymai ir kiti teisės aktai, kuriais
reglamentuojama numatoma kompiuterizuoti veiklos sritis;
• Įvardinamos pagrindinės priežastys, lemiančios esminius
pokyčius organizacijoje;
31
Esamos situacijos analizė
• Analizuojami vidinių ir išorinių naudotojų poreikiai, pateikiami
svarbiausių apklausų ir tyrimų rezultatai, formuojantys naujus
sisteminius reikalavimus;
• Atliekama užsienio valstybių patirties analogiškų elektroninių
paslaugų diegimo srityje apžvalga;
• Galimybių pasinaudoti Viešojo administravimo institucijų
informacinių sistemų interoperabilumo sistemos (toliau
vadinama – VAIISIS) duomenų mainų sistema ir VAIISIS
teikiamomis paslaugomis aptarimas;
32
Esamos situacijos analizė
• Atliekamas esamų procesų ir sprendimų identifikavimas,
esamos procesų brandos įvertinimas ir nustatomos prielaidos
siekti aukštesnio proceso brandos lygio;
• Automatizuotiniems veiklos procesams vertinti
rekomenduojama taikyti procesų brandos vertinimo metodiką
( daugiau informacijos ISO/IEC 15504-2:2003 standarte);
• Būsimo sistemos valdytojo IS pasirengimo projektui vertinimui
– COBIT, ITIL, telekomunikacijoms – ETOM ar kitas metodikas.
33
Procesų ir veiklų hierarchija
Strateginiai
procesai
Automatizuojami
dažniausiai
Taktiniai procesai
Operaciniai procesai
Veiklos
Užduotys
34
PROCESŲ BRANDOS VERINIMAS
• Brandos lygiai pagal ISO IEC 15504-02:
0.
1.
2.
3.
4.
5.
Nevykstantis - proceso nėra.
Kartotinis – dažniausiai kartojami tie patys žingsniai, su panašiais
tikėtinais rezultatais.
Valdomas – planuojamas, pagal poreikius matuojami rezultatai,
daromi pakeitimai
Galima
automa
tizuoti
Apibrėžtas – procesas suskaidytas į aprašytus žingsnius, kuriems
patvirtintos darbo instrukcijos.
Valdomas – procesas automatizuotas, matuojamas ir valdomas pagal
apibrėžtas metrikas.
Optimizuojamas – proceso valdyme numatytas proceso tobulinimo
žingsnis.
35
ALTERNATYVŲ ANALIZĖ
• Alternatyvų analizės dalyje pateikiamas pokyčių įgyvendinimo
alternatyvų apibūdinimas, visapusiškai pagrindžiant nustatytų
visoms alternatyvoms bendrų nefinansinių kriterijų reikšmių
prielaidas.
• Išvadose pateikiamas tarpusavio sulyginimas, suteikiant
absoliučius rangus pagal nustatytus kriterijus, parenkant
optimalų projekto įgyvendinimo sprendimą.
36
PRIVALOMOS ALTERNATYVOS
• „Veikti kaip įprasta“ - veikla vykdoma nedarant papildomai
finansuotinų iš prioriteto „Informacinė visuomenė visiems“
investicijų.
• „Daryti minimalius pakeitimus“ - veikla vykdoma investuojant
minimaliai, peržiūrint ir keičiant vidinius organizacijos
procesus ir susijusias turimas informacines sistemas savo
jėgomis.
• „Daryti pakeitimus“ - veikla vykdoma investuojant
reikšmingas sumas. Atliekant galimybių analizę pagal šį
scenarijų privaloma glaustai išnagrinėti atmetamas
alternatyvas ir pateikti ne mažiau kaip dvi praktiškai
įgyvendinamas technines galimybes.
37
„DARYTI PAKEITIMUS”
ALTERNATYVOS: KŪRIMAS
•
•
•
•
Pritaikyti turimą sprendimą;
Įsigyti komponentus ir kurti jų pagrindu;
Kurti naudojant atviro kodo iniciatyvas;
Kurti naują programinės įrangos sprendimą.
38
„DARYTI PAKEITIMUS”
ALTERNATYVOS: ĮSIGIJIMAS
•
•
•
•
•
Įsigyti prototipą ar analogą;
Įsigyti kūrimo keliais etapais paslaugas;
Įsigyti analogą su pritaikymu;
Išsinuomoti (infrastruktūrą);
Samdyti kitus atlikti reikiamas funkcijas.
39
VERTINIMO KRITERIJAI
• Alternatyvų vertinimo kriterijų sąrašas sudaromas
vadovaujantis priemonės aprašymu ir individualiai projekto
specifikai parenkamais kriterijais.
• Lyginamas vertes rekomenduojama sunormuoti ir nustatyti
tarp 1 ir 10, kur 1 balas būtų teikiamas mažiausiai kriterijų
tenkinančiai alternatyvai, 10 – geriausiai kriterijų tenkinančiai
alternatyvai.
• Sulyginimą rekomenduojama pateikti lentelės pavidalu,
alternatyvos rangą nustatant pagal pasirinktų kriterijų
ekspertinio vertinimo sumą, kur didžiausias reikšmes
surinkusios alternatyvos būtų pateikiamos ankstesniuose
stulpeliuose.
40
NEFINANSINIO VERTINIMO
KRITERIJAI
• Alternatyvių sprendimų nefinansinio vertinimo kriterijai ir
alternatyvos rango nustatymas vykdomas lyginant atitiktį
veiksmų programos stebėsenos rodikliams ir papildomai
rekomenduojamiems kriterijams, tame tarpe:
• Suderinamumas su tikslais;
• Techninis architektūrinis tinkamumas, įgyvendinamumas;
• Organizacinis įgyvendinamumas (pasirengimo ar brandos
vertinimas);
• Naujumas arba analogija lyginant su kitose ES organizacijose
įdiegtais sprendimais;
41
NEFINANSINIO VERTINIMO
KRITERIJAI
• Įgyvendinimo trukmė, numanoma alternatyvos naudojimo
trukmė;
• Geografinis (komandos, organizacijos ir pan.) išplitimas;
• Socialinis poveikis (atskirties mažinimas ir pan.);
• Rizikingumas;
• Veiklos brandos lygio padidėjimas;
• Poveikis informacijos ir asmens duomenų apsaugai;
• Subrangos mastas;
• Eksploatavimo organizavimo galimybės.
42
FINANSINĖ ANALIZĖ
• Įvertinti šių finansinių rodiklių reikšmes:
• Finansinė grynoji dabartinė vertė (angl. financial net present
value) ( FNPV),
• finansinė grąžos norma (angl. financial rate of return) (FRR) ir
• sąnaudų (naudos) santykis (angl. benefit/cost ratio).
43
EKONOMINIAI RODIKLIAI
• ekonominė grynoji dabartinė vertė (angl. economic net
present value) (ENPV), ekonominė grąžos norma (angl.
Economic rate of return) (ERR) ir sąnaudų (naudos) santykis
(angl.benefit/cost ratio). Rodiklių reikšmės įrodo projekto
ekonominį pagrįstumą, atsižvelgiant į projekto investicijas ir
būsimas sąnaudas.
• Ekonominė grynoji dabartinė vertė (EGDV): turėtų būti
didesnė už nulį, kad projektas būtų patrauklus ekonominiu
požiūriu.
• Ekonominė grąžos norma (EGN): turėtų būti didesnė už
socialinę diskonto normą.
• Ekonominės naudos santykis (ENS): turėtų būti didesnis už
vienetą.
44
DETALI PASIRENKAMOS
ALTERNATYVOS ANALIZĖ
• Šioje dalyje detaliai aprašoma optimaliausios,
rekomenduojamosios alternatyvos, esmė;
• Argumentuojamas alternatyvos pasirinkimas;
• Aprašoma alternatyvos kuriama nauda;
• Pagrindžiamas projekto institucinis, technologinis ir finansinis
tęstinumas;
• Atliekama sprendimo keičiamų veiklų funkcinė analizė,
pagrindžiami numatomi pasikeitimai veikloje;
• Aprašomos priemonės ir būdai užtikrinsiantys suformuotos
infrastruktūros funkcionavimą ir projekto rezultatų
naudojimą;
45
DETALI PASIRENKAMOS
ALTERNATYVOS ANALIZĖ
• Parenkamas architektūrinis sprendimas;
• Parenkamas tinkamiausias sistemos įgyvendinimo ciklo tipas;
• Atliekama įrangos tiekimo/diegimo bei eksploatacijos,
sistemos priežiūros reikalavimų analizė, kuri apima sistemos
priežiūros plano sudarymą, priežiūros kainos ir išteklių
poreikių nustatymą, aptarnavimo sutarčių aptarnavimo lygio
parametrų nustatymą;
• Sudaromas projekto įgyvendinimo planas;
• Atliekama rizikos analizė;
• Pateikiamos išvados.
46
ARCHITEKTŪRINIO SPRENDIMO
PARINKIMAS
• Tikslas - įvertinant technines galimybes paskirstyti
informacinės sistemos reikalavimus struktūriniams
komponentams, bei dokumentuoti sukurtą IS architektūrą;
• Bendruoju atveju vykdomos šios IS architektūros
projektavimo stadijos veiklos:
1. Architektūros apibrėžimas;
2. Architektūros įvertinimas(viena iš galimybių studijos
užduočių);
3. Architektūros dokumentavimas ir palaikymas.
47
IS ARCHITEKTŪROS APIBRĖŽIMAS
• IS architektūros apibrėžimas susijęs su šiomis veiklomis:
– Programinės įrangos strateginis pasirinkimas;
– Techninės įrangos strateginis pasirinkimas;
– Informacinės struktūros strateginis pasirinkimas.
• Galimybių studijos atveju turime įsivardinti kokie strateginiai
sprendimai jau priimti, nes tai esamos situacijos analizės
atspirties taškas.
48
IS ARCHITEKTŪROS VERTINIMAS
• Sekančiu žingsniu rengiant galimybių studiją ir vertinant IS
architektūrą:
– atliekamas esamos techninės infrastruktūros atitikimo ir
galimybių įvertinimas;
– veiklos reikalavimų tenkinimo esamomis programinės
įrangos galimybėmis įvertinimas;
– veiklos reikalavimų tenkinimo, pasirenkant naujus
architektūros elementus, galimybių įvertinimas.
49
ARCHITEKTŪROS
DOKUMENTAVIMAS
• Bendruoju atveju architektūros dokumentavimo ir palaikymo
veikloje kuriami arba pagal poreikius tikslinami šie
pagrindiniai dokumentai:
– Esamos IS architektūros planas;
– Veiklos reikalavimai IS architektūrai;
– IS architektūros pokyčių projektas.
50
IS ARCHITEKTŪROS PLANAS
• IS architektūros plane rekomenduojama:
– dokumentuoti esamą IS architektūrą, jos esamus ir IS
strategijoje numatytus elementus;
– apibrėžti IS elementų struktūrinius ryšius;
– nustatyti kiekvieno architektūros elemento kritiškumą
veiklai;
– suderinti su visais suinteresuotais subjektais ir patvirtinti
architektūros planą.
51
IS ARCHITEKTŪROS REIKALAVIMŲ
DOKUMENTAS (1)
• IS architektūros reikalavimų dokumente rekomenduojama:
– aprašyti svarbius IS architektūrai veiklos reikalavimus;
– Įvardinti pagrindinius veiklos reikalavimus, galinčius įtakoti
architektūros pasirinkimą;
– įvardinti elementų ryšius su projekto tikslais ir
reikalavimais;
– nustatyti kiekvieno architektūros elemento svarbą
reikalavimų atžvilgiu;
52
IS ARCHITEKTŪROS REIKALAVIMŲ
DOKUMENTAS (2)
– patikrinti kaip IS architektūra atitinka reikalavimus;
– nustatyti architektūros vertinimo kriterijus: nefunkcinių
reikalavimų ir ribojimų išpildymas; projektavimo standartų
ir metodų tinkamumas; IS komponentų atitikimas
reikalavimams ir įgyvendinamumas; veikimo ir priežiūros
įgyvendinamumas, taip pat kita pagal poreikį;
– suderinti su visais suinteresuotais subjektais ir patvirtinti
architektūros vertinimo kriterijus.
53
ARCHITEKTŪROS PROJEKTAVIMAS
• IS architektūros projektavimo proceso tikslas – įvertinant
technines galimybes paskirstyti veiklos reikalavimus
informacinės sistemos struktūriniams komponentams
(programinei įrangai, infrastruktūrai ir informacinei
struktūrai), bei dokumentuoti sukurtą IS architektūrą (ISO IEC
15288:2008, ISO IEC WD4 42010:2009).
• IS architektūros modeliavimo bendrasis žodynas aprašytas ISO
IEC WD4 42010:2009, tačiau modelio lygmenyje terminologija
specifinė kiekvienai metodikai. Pavyzdžiu gali būti atviro
Architektūros Grupės modelis TOGAF, arba ISO 15704
(Geram) ar ISO/IEC 10746 (RM-ODP).
54
IS ARCHITEKTŪROS POKYČIŲ
PROJEKTAS
• IS architektūros projektavimas remiasi veiklos architektūros
analizės rezultatais. Veiklos architektūros analizė turi būti
atlikta iš struktūrinės ir funkcinės perspektyvų, o jos rezultatas
– veiklos procesų žemėlapis bei rolių ir atsakomybių
priskyrimas procesų ir veiklų savininkams.
55
ARCHITEKTŪROS POKYČIŲ GAIRĖS
• Galimybių studijoje rekomenduojama:
– aprašyti architektūros pokyčius, būtinus pasiekti
automatizuotinos veiklos tikslams;
– įvardinti naujų elementų ryšius su projekto tikslais ir
reikalavimais;
– nustatyti kiekvieno naujo architektūros elemento svarbą
reikalavimų atžvilgiu;
– suderinti su visais suinteresuotais subjektais ir patvirtinti
architektūros projektą.
56
IS ARCHITEKTŪROS PROJEKTAVIMO
REZULTATAI
• Apibrėžtos kiekvieno IS komponento vidinės ir išorinės
sąsajos, jų tarpusavio ryšiai;
• Apibrėžti IS sąsajų informaciniai modeliai, atitinkantys
dalykinės srities koncepcinį modelį, kuris gali būti papildytas ir
patikslintas, suderinant pakeitimus su visais suinteresuotais
subjektais;
• Gali būti sudaromi architektūros komponentų elgsenos ir
sąveikų modeliai, pavyzdžiui, UML diagramos.
57
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS
• Svarbiausius du taikytinus valstybės informacinių sistemų
kūrimui IVV rėmuose gyvavimo ciklo įgyvendinimo metodus
galima įvardinti taip:
1. Nuoseklusis
2. Laipsniškasis
• Moksliniuose tiriamuosiuose ir naujo produkto kūrimo
projektuose naudojami ir kiti – evoliuciniai, lankstieji,
ekstremalūs įgyvendinimo metodai, tačiau jų specifika
neleidžia pakankamai tiksliai specifikuoti reikalavimų ir
numatyti biudžetų, todėl valstybės informacinių sistemų
kūrimui IVV rėmuose taikomi nebus.
58
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS
• Įgyvendinimo ciklą galima pasirinkti remiantis kūrimo
skubumu, IS kūrimo sudėtingumu ir neapibrėžtumu.
• Pagrindiniai pasirinkimo kriterijai įgyvendinimo ciklo tipui
pasirinkti yra kuriamos IS sudėtingumas ir apibrėžtumas.
• Neapibrėžtoms IS reikalingi evoliuciniai, sudėtingoms –
laipsniškieji ciklai.
59
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS
IS kūrimo gyvavimo ciklas
Situaciniai faktoriai
Nuoseklusis
IS kūrimo
IS
planas grafikas sudėtingumas
Normalus
Paprasta
(nuosekliai
kuriama visa
IS
neapibrėžtumas sistema)
Apibrėžta
X
Laipsniškasis
Evoliucinis
(sistema
kuriama
moduliais)
(sistema
kuriama
versijomis)
Neapibrėžta
Sudėtinga
Apibrėžta
X
X
Neapibrėžta
Skubus
Paprasta
Apibrėžta
X
X
Neapibrėžta
Sudėtinga
Apibrėžta
Neapibrėžta
Šaltinis: IVPK ir KTU studija 2009
X
X
X
X
60
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS (NUOSEKLUSIS)
• Nuoseklusis - susideda iš viena po kitos vykdomų stadijų, kai sistema
kuriama pirma dokumentavus visus poreikius ir tik tada pradedant kūrimo
darbus.
• Informacinė sistema kuriama, nuosekliai įgyvendinant atskiras stadijas
vieną kartą, nuo pradžios iki galo, stadijos nepasikartoja ir nepersidengia.
• Visoms stadijoms galima fiksuota kaina, ir analizės metu dokumentuoti
reikalavimai yra galutiniai, todėl juos realizavus projektas yra sėkmingai
užbaigtas.
• Šis metodas aprašytas ir taikomas Valstybės informacinių sistemų kūrimo
metodikoje, patvirtintoje Informacinės visuomenės plėtros komiteto prie
Lietuvos Respublikos Vyriausybės direktoriaus 2004 m. spalio 15 d.
įsakymu Nr. T-131 (Žin., 2004, Nr. 155-5679).
61
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS (LAIPSNIŠKASIS)
• Laipsniškasis, dar vadinamas iteraciniu, informacinės sistemos gyvavimo
ciklo įgyvendinimo metodas taikomas, kai iš anksto negalima detaliai
nustatyti informacinės sistemos reikalavimų, reikalingas dažnas ir
pilnavertis užsakovo grįžtamasis ryšys, ir yra laiko paraleliai kurti ir
aiškintis užsakovo poreikius.
• Kūrimas pradedamas žinant visus reikalavimus, tačiau užsakovo poreikiai
nėra nusistovėję praktikoje, nėra pakankamai žinomi, kad taikyti nuoseklų
metodą.
• Šiuo atveju informacinė sistema dalijama į sudėtines dalis (modulius)
pagal veiklos scenarijus arba proceso žingsnius, kurias galima kurti
nustatytu eiliškumu nuosekliai, arba su daliniu kūrimo proceso
persidengimu, kol išnaudojamas tam skirtas laiko ir pinigų biudžetas.
62
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS (LAIPSNIŠKASIS)
• Kiekvienas reikalavimų rinkinys sudaro išbaigtą sistemos dalį (modulį),
kurią galima naudoti su aiškiai žinomais apribojimais ir dokumentuotomis
išeitimis (angl. work-around). Tuo būdu per projektui skirtą laiką ir kelias
iteracijas yra sukuriamas užsakovą tenkinantis funkcionalumas.
• Kiekvienoje naujoje iteracijoje įvertinami prieš tai buvusios iteracijos
rezultatai, esant reikalui, tikslinamos sukurtos priemonės ir pereinama
prie kito modulio kūrimo.
• Šis metodas su apribojimais gali būti taikomas kuriant valstybines
informacines sistemas.
63
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS (LAIPSNIŠKASIS)
• Apribojimai: Kuriant sistemas, pretenduojančias į finansavimą pagal
Ekonomikos augimo veiksmų programos 3 prioritetą „Informacinė
visuomenė visiems“, sistemos kūrėjai, naudojantys laipsniškuosius būdus,
turi tiksliai prognozuoti etapiškumą ir įsipareigoti fiksuotai etapų kainai, o
užsakovai atsižvelgti į tai, kad gali būti realizuoti ne visi poreikiai, arba
nepilnai.
• Užsakovai, galintys prisiimti šią riziką turi priimti etapus ir forminti
pakeitimus panaudojant pakeitimų valdymo tvarką, aprašytą Valstybės
informacinių sistemų kūrimo metodikoje, patvirtintoje Informacinės
visuomenės plėtros komiteto prie Lietuvos Respublikos Vyriausybės
direktoriaus 2004 m. spalio 15 d. įsakymu Nr. T-131 (Žin., 2004, Nr. 1555679).
64
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS (EVOLIUCINIS)
• Evoliucinis informacinės sistemos gyvavimo ciklo įgyvendinimo metodas
taikomas tiriamiesiems investiciniams ir naujo produkto kūrimo
projektams, kai žinomi tik pirminiai informacinės sistemos kūrimui keliami
reikalavimai, kurių pagrindu gali būti sukurtas tik informacinės sistemos
prototipinis modelis (prototipas).
• Prototipo bandymai leidžia nustatyti detalesnius informacinės sistemos
kūrimo reikalavimus ir pereiti prie pilnavertės informacinės sistemos
kūrimo.
• Šis metodas naudojamas tada, kai nėra žinomas pilnas reikalavimų
rinkinys o tuo pačiu žinomų reikalavimų detalumas yra nepakankamas
specifikacijai parengti.
65
SISTEMOS ĮGYVENDINIMO CIKLO
PARINKIMAS (EVOLIUCINIS)
• Pagrindinis šio metodo ribojimas yra tai, kad neįmanoma tiksliai įvertinti
visos informacinės sistemos sukūrimo kainos, nes nežinoma visa
informacinės sistemos apimtis.
• Šis metodas netinka fiksuotos kainos kontraktams ir nebus taikomas
projektams, pretenduojantiems į finansavimą pagal Ekonomikos augimo
veiksmų programos 3 prioritetą „Informacinė visuomenė visiems“ dėl
neatitikimo koncepciniam modeliui.
• Galimybių studijos metu nustačius tokio gyvavimo ciklo poreikį
rekomenduojama išnagrinėti galimybę atlikti papildomą analizę siekiant
sumažinti neapibrėžtumus iki priimtino anksčiau minėtiems metodams
lygio.
66
PROJEKTO ĮGYVENDINIMO PLANAS
• Parengiamas projekto įgyvendinimo gairių planas, kuris
apima:
–
–
–
–
–
–
–
–
–
reikalavimų projekto įgyvendinimo proceso valdymui apibūdinimą;
stadijų ar iteracijų grafiką bei susijusias pateiktis;
valdymo modelį, vaidmenis ir atsakomybes;
kontrolės taškus ir juose vertinamas pateiktis;
pirkimų tipai, pirkimų planas – prekėms, darbams, paslaugoms;
pateikčių kokybės vertinimo kriterijus;
kokybės užtikrinimo priemones;
projekto vertinimo kriterijus;
projekto audito, administravimo ir stebėsenos procedūras.
67
RIZIKOS ANALIZĖ
• Įvertinamos numatomos su projektu susijusios rizikos, jų
priežastys, mažinimo ir/ar neutralizavimo priemonės.
• Sudaromas rizikos registras ir valdymo planas.
• Projekto rizikos vertinimą rekomenduojama atlikti
vadovaujantis ISO 27005 serijos standartu. Bendrieji projektų
rizikos tipai, strategijos ir valdymo būdai plačiai aprašyti
PMBOK 4 metodikoje, o informacinių sistemų gyvavimo ciklo
rizikos valdymo būdai detaliausiai išnagrinėti COBIT 4
metodikos kontrolės praktikos aprašymuose.
68
RIZIKA PROJEKTŲ VALDYME
• Rizika ekonominėje veikloje, tai ūkinės operacijos aplinkybės,
kuriomis apsisprendimas imtis tam tikro veiksmo, priemonės
arba jo nesiimti gali turėti teigiamų ar neigiamų pasekmių
vienam ar daugiau projekto tikslų (Lietuviškoji enciklopedija).
• Apibrėžimas pagal PMBOK: Rizika tai aplinkybė ar tikėtinas
įvykis, kuris, jei įvyks, gali turėti teigiamą arba neigiamą
poveikį projekto tikslų pasiekimui.
• Aplinkybės sinonimai - sąlyga, priežastis.
69
SĄVOKOS AIŠKINIMAS
• Tik trečia šio žodžio reikšmė Lietuviškoje enciklopedijoje
reiškia nepasisekimo tikimybę. Šia bendrinės kalbos prasme
rizikos sąvoka projektų valdyme beveik nenaudojama.
• Rizika, kurios pasekmės ar padariniai yra naudingi, vadinama
galimybėmis
• Rizika, kurios pasekmės ar padariniai yra žalingi, vadinama
grėsmėmis
70
RIZIKOS VERTINIMAS
• Rizika suvokiama kaip tikėtina aplinkybės fizinė ar piniginė
išraiška.
• Rizikos vertinimas skaičiuojamas galimą normalizuotą
nuokrypio padarinių vertę sudauginus iš įvykio tikimybės.
• Norint suvienodinti rizikos padarinių vertinimą įvesta bematė,
normalizuota vertinimo skalė – nuo –1 iki +1. Tam
normalizavimui naudojami sąvokų “mažai” ir “daug” laipsniai.
• Laipsniai atitinka geometrinę progresiją, kurios pirmas narys
0,1 o daugiklis 2.
• Rizikos vertinimas = rizikos tikimybė x galimo įvykio padariniai
71
ĮVYKIO PADARINIŲ IŠMATAVIMO IR
ĮVERTINIMO SKAIČIAIS LENTELĖ (PAVYZDYS)
Įvykio padariniai pagrindiniams projekto objektams
Vidutiniai
>0,2
Dideli
>0,4
Labai dideli
>0,8
(dažniausiai
neverta traukti
į rizikų
registrą)
(sprendžia
projekto
komanda)
(derintina su
užsakovu)
(grėsmė
projektui)
(Būtina keisti projekto
planą, negalime traukti
į rizikų registrą)
Išlaidos
Nežymus
išlaidų
padidėjimas
Išlaidų
padidėjimas
1%-5%
Išlaidų
padidėjimas
5-10%
Išlaidų
padidėjimas 1020%
Išlaidų padidėjimas
>20%
Laikas
Nežymus
tvarkaraščio
nesilaikymas
Vykdymo laiko
pailgėjimas
1%-5%
Vykdymo
laiko
pailgėjimas
5-10%
Vykdymo laiko
pailgėjimas 1020%
Vykdymo laiko
pailgėjimas >20%
Apimtis
Nežymus
apimties
nevykdymas
Apimties
nevykdymas
1%-5%
Apimties
nevykdyma
s 5-10%
Nepriimtinas
klientui 10-20%
apimties
nevykdymas
Apimties nuokrypis
>20%
Kokybė
Nežymus
kokybės
sumažėjimas
1%-5%
Kokybės
neatitikimas
5-10%
Kokybės
neatitikimas
Kokybės
neatitikimas 1020%
Nuokrypis nuo
kokybės tikslų >20%
Objektai
Maži
>0,1
Rizikos
Labai maži
<0,1
72
Rizikos valdymo standartai
•
•
•
•
•
•
ISO 31000 (tarptautinis)
RISK IT (sektorinis, IT)
COSO ERM
AAIRM
AS/NZ 4360 (NZ)
M_o_R (UK)
73
PROJEKTĄ VEIKIANČIŲ RIZIKŲ TIPAI
1. Tvarkaraščio rizika – tai rizika, kad keisis numatyta projekto
užduočių trukmė
2. Kaštų rizika – tai rizika, kad nepakaks numatytų investicijų,
arba bus nenumatytų išlaidų
3. Apimties rizika – tai rizika, kad bus padaryta daugiau ar
mažiau darbų
4. Kokybės rizika – tai rizika, kad bus neleistinai nukrypta nuo
projekto tikslams sutartų kokybinių reikalavimų
5. Vadovavimo rizika – tai rizika, kad vadovai neatliks savo
darbo valdydami projekto procesus
74
RIZIKOS VALDYMO VEIKLOS
1.
2.
3.
4.
5.
6.
Rizikos valdymo planavimas
Rizikos identifikavimas
Rizikos apskaičiavimas
Rizikos rangavimas
Atsako planavimas
Rizikos matavimas ir kontrolė
•
Komentaras: atsako vykdymas nėra rizikų valdymo veiklų
sąraše. Jis yra projekto vykdymo dalis.
75
RIZIKŲ VALDYMO STRATEGIJOS
• Įvardinamos skirtingos tiek negatyvias pasekmes, tiek
pozityvias pasekmes galinčių turėti įvykių valdymo strategijos;
• Šios strategijos skiriasi požiūriu ir gali būti aktyvios ir pasyvios.
• Aktyvios strategijos atveju įvykio stengiamasi arba išvengti,
arba galimybės atveju ją maksimaliai realizuoti, tuo tarpu
• Pasyvios strategijos atveju negatyvi rizika prisiimama tikintis,
kad pavyks ją perkelti kitiems arba dalinai sumažinti
pasekmes, o galimybes tikimasi išnaudoti kai jos pasitaikys,
arba tikintis pasinaudoti pritraukiant geriau tam pasiruošusius
76
RIZIKŲ VALDYMO STRATEGIJOS (-)
• Negatyvių rizikų valdymo strategijos:
– Išvengti – keičiamas projekto planas, tikslinami tikslai, apimtis,
biudžetas, kokybiniai reikalavimai, organizacija, jei reikia ir vadovai,
siekiant, kad rizikingas įvykis neįvyktų.
– Perkelti – atsakomybė perkeliama trečiai šaliai. Tai gali būti
draudimas, labiau patyrusio subkontraktoriaus, ekspertų samdymas.
Sudaromos ribotos civilinės atsakomybės sutartys.
– Priimti – numatomas rezervas laike, biudžete, tikintis, kad pavyks
atlikti veiksmus, sumažinančius įvykio pasekmes.
– Sumažinti – atliekami veiksmai, leidžiantys tikėtis dalinių pasekmių ar
mažesnės įvykio tikimybės. Pavyzdžiui, sistemų testavimas, atsarginių
komponentų įsigijimas gedimo atvejui.
77
RIZIKŲ VALDYMO STRATEGIJOS (+)
• Pozityvių rizikų valdymo strategijos:
– Išnaudoti – keičiamas projekto planas, tikslinami tikslai, apimtis,
biudžetas, didinami kokybiniai reikalavimai, skiriama daugiau resursų,
talentingesni žmonės, siekiant, kad įvykis būtinai įvyktų.
– Pasidalinti – pakviečiama trečia šalis, geriau pasiruošusi išnaudoti
galimybę. Tai gali būti ‘jungtinės veiklos sutartis’, labiau patyrusio
subkontraktoriaus, ekspertų samdymas. Sudaromos ‘sėkmės
mokesčio’ sutartys.
– Priimti – numatomas rezervas laike, biudžete, tikintis, kad pavyks
atlikti veiksmus, pasinaudojant įvykio pasekmėmis.
– Padidinti – atliekami veiksmai, leidžiantys tikėtis didesnių pasekmių ar
įvykio tikimybės. Pavyzdžiui, įvardinant sėkmės faktorius, sukeliant
kitus įvykius, kurių pasekme tampa laukiami įvykiai.
78
IŠVADOS
• Šioje dalyje glaustai apibendrinamos pasirinktos alternatyvos
analizės išvados, kuriose pateikiama:
– Pasirinktos alternatyvos argumentacija.
– Alternatyvos naudos apibendrinimas.
– Projekto rizikos valdymo ir tęstinumo užtikrinimo
apibendrinimas.
79
IS INICIJAVIMAS
• IS inicijavimo etape rengiami IS nuostatai, kurie turi apimti
steigimo teisinį pagrindą, tikslus ir uždavinius, organizacinę
struktūrą, informacinę struktūrą, funkcinę struktūrą,
duomenų šaltinius ir apdorojimo rezultatus kitą apibūdinančią
informaciją.
• Rengiami IS nuostatai turi atitikti Valstybės informacinių
sistemų (toliau vadinama – IS) steigimo ir įteisinimo taisykles,
patvirtintas Lietuvos Respublikos Vyriausybės 2004 m.
nutarimu Nr. 451 (Žin., 2004, 58-2061).
• Rengiami registrų nuostatai turi atitikti Valstybės registrų ir
kadastrų steigimo, reorganizavimo ir likvidavimo taisykles,
patvirtintas Lietuvos Respublikos Vyriausybės 2005 m.
80
nutarimu Nr. 485 (Žin. 2005 Nr.58-2015, su pakeitimais)
IS INICIJAVIMAS
• Informacinių sistemų, tame tarpe registrų, kuriamų
įgyvendinant IVV projektus, steigimą ir įteisinimą bei valstybės
registrų ir kadastrų, kuriamų įgyvendinant IVV projektus,
steigimą ir sukūrimą koordinuoja Informacinės visuomenės
plėtros komitetas ir Centrinė projektų valdymo agentūra
apraše (IVPK direktoriaus 2009 birželio 30d. įsakymas Nr. T59) nustatyta tvarka.
• Pagal minėtą aprašą, IVV projekto darbai negali būti pradėti ir
išlaidos negali būti apmokamos jei nėra patvirtinti nuostatai ir
specifikacija.
81
NUOSTATŲ PAPILDYMAI
• Papildomai numatoma įpareigoti IVV pareiškėjus, rengiant IS
nuostatus:
– atlikti analogų apžvalgą;
– atlikti galimybių pasinaudoti Viešojo administravimo
institucijų duomenų mainų sistema (VAIISIS) analizę;
– atlikti esamų registrų duomenų klasifikavimo analizę;
– nustatyti pirminių duomenų šaltinių ir duomenų teikėjus;
– sudaryti duomenų klasifikatoriaus struktūros aprašus;
– nustatyti duomenų pateikimo kitiems naudotojams
tvarkas.
82
TECHNINĖ SPECIFIKACIJA
• Reikalavimai informacinėms sistemoms, kuriamoms kaip IVV
projektas, techninė specifikacija reglamentuojama Valstybės
informacinių sistemų kūrimo metodikoje, patvirtintoje
Informacinės visuomenės plėtros komiteto prie Lietuvos
Respublikos Vyriausybės 2004 m. spalio 15 d. įsakymu Nr. T131 (Žin., 2004, Nr. 155-5679), papildant ją šiomis dalimis:
83
PAPILDYMAI TECHNINEI
SPECIFIKACIJA
• Atlikti architektūros analizės ir projektavimo darbus;
• Įvardinti naudotojų, išorinės ir vidinės kokybės matavimo
reikalavimus ir metrikas (pavyzdžiui panaudojant ISO IEC TR
9126-3:2003);
• Kiekvienam reikalavimui nurodyti diegimo prioritetą ir
kritiškumą (kaip buvo pristatyta galimybių studijos rengimo
gairėse);
• Nustatyti reikalavimų funkcinį dydį (pavyzdžiui ISO IEC
29881:2008 aprašytu FiSM ar lygiaverčiu metodu).
84
Programinės įrangos kokybės
techninės rekomendacijos (TR)
• ISO/IEC TR 9126 yra pripažintas programinio produkto
kokybės vertinimo modelis. Sukurtas 1991 metais, atnaujintas
2001 ir naudojamas dabar.
• Jame apibrėžiamos vidinės, išorinės ir vartojamumo metrikos.
• Turi keturias dalis:
–
–
–
–
Kokybės modelis (quality model);
Išorinės metrikos (external metrics);
Vidinės metrikos (Internal metrics);
Kokybės naudojime metrikos (quality in use metrics);
85
ISO 9126 POŽIŪRIS Į PROGRAMINĖS
ĮRANGOS KOKYBĖS VERTINIMĄ
Proceso
kokybė
Proceso
metrikos
Vidiniai
kokybės
atributai
Išoriniai
kokybės
atributai
Vartojamumo
kokybės
atributai
Vidinės
metrikos
Išorinės
metrikos
Vartojamumo
metrikos
86
Hierarchinis kokybės modelis
(ISO/IEC 9126)
• Kokybės modelis turi paprastą hierarchiją: modelis
sudarytas iš charakteristikų, kurių kiekviena turi
atitinkamas sub-charakteristikas;
• ISO/IEC 9126 turi 6 charakteristikas vidinei ir išorinei
kokybei vertinti ir 4 charakteristikas “kokybei naudojime”
vertinti.
• IS diegimo tikslų pasiekimo vertinimo atributų
(charakteristikų) ir metrikų specifikavimas aprašomas
ISO/IEC 9126-1.
ISO 9126 charakteristikos vidinei ir
išorinei kokybei vertinti
•
•
•
•
•
•
Funkcionalumas
Patikimumas
Naudojamumas
Našumas
Palaikomumas
Perkeliamumas
88
KOKYBĖS CHARAKTERISTIKOS
Perkeliamumas
Palaikomumas
Našumas
Naudojamumas
Patikimumas
Funkcionalumas
Vidiniai ir išoriniai kokybės vertinimo atributai
Vartojimo
kokybės
atributai
Efektyvumas
Produktyvumas
Saugumas
Tinkamumas
Tikslumas
Integruojamumas
Saugumas
Funkcionalumo
atitiktis
Suprantamumas
Brandumas
Išmokstamumas
Atsparumas
Kontroliuojamumas
Greitaveika
Patrauklumas
Našumo atitiktis
Atstatomumas
Patikimumo
atitiktis
Naudojamumo
atitiktis
Utilizacija
Nagrinėjamumas
Adaptyvumas
Keičiamumas
Instaliuojamumas
Stabilumas
Bendraveika
Testuojamumas
Pakeičiamumas
Palaikomumo
atitiktis
Perkeliamumo
atitiktis
Pasitenkinimas
89
VIDINIAI IR IŠORINIAI KOKYBĖS
VERTINIMO ATRIBUTAI
• Funkcionalumas – programinės įrangos galimybės užtikrinti
nurodytą ir tikslingą poreikį, kai programinė įranga yra
naudojama nurodytomis sąlygomis.
• Patikimumas – programinės įrangos galimybės užtikrinti
nustatytą prieinamumo lygį, kai programinė įranga yra
naudojama nurodytomis sąlygomis.
• Naudojamumas – programinės įrangos galimybės veikti
suprantamai, išmokstamai ir patraukliai vartotojui, kai
programinė įranga yra naudojama nurodytomis sąlygomis.
90
VIDINIAI IR IŠORINIAI KOKYBĖS
VERTINIMO ATRIBUTAI
• Našumas – programinės įrangos galimybės užtikrinti
nustatytą pajėgumo ir greitaveikos lygį, kai programinė
įranga yra naudojama nurodytomis sąlygomis.
• Palaikomumas - programinės įrangos galimybės užtikrinti
ilgalaikį veikimą ir pakeitimus, kai programinė įranga yra
naudojama nurodytomis sąlygomis.
• Perkeliamumas - programinės įrangos galimybės užtikrinti
perkėlimą į kitą aplinką, kai programinė įranga yra
naudojama nurodytomis sąlygomis.
91
Funkcionalumas (angl. functionality)
Subcharakteristika
Apibūdinimas
Tinkamumas
(suitability)
Programos funkcijų, atliekančių reikiamas užduotis,
pilnumas bei atitikimas reikalavimams.
Tikslumas
(accurateness)
Programos veikimas pateikiant teisingus arba sutartus
rezultatus.
Bendradarbiavimas
(interoperability)
Programos bendradarbiavimo su kitomis sistemomis
galimybės.
Laikymasis
Programos atitikimas įvairiems standartams: PĮ kūrimo
(susitarimų, įstatymų
standartams, įstatymams ir pan.
ir t.t.) (compliance)
Apsauga (security)
Programos galimybės uždrausti neautorizuotą priėjimą
prie programos arba programos duomenų.
92
Patikimumas (angl. reliability)
Subcharakteristika
Apibūdinimas
Brandumas (maturity)
Nesėkmingų programos veikimo atvejų dėl gedimų
dažnis.
Gedimų tolerancija
(Fault tolerance)
Programos galimybės palaikyti nustatytą
funkcionavimo lygį atsiradus tam tikriems gedimams.
Atkuriamumas
(recoverability)
Programos gebėjimas atstatyti funkcionavimo lygį bei
prarastus duomenis nesėkmingo programinės
operacijos atlikimo atveju nustatytose laiko bei kaštų
ribose.
93
Vartosena (angl. usability)
Subcharakteristika
Apibūdinimas
Suprantamumas
(understandability)
Vartojo pastangos, reikalingos programos loginio
konteksto atpažinimui.
Išmokstamumas
(learnability)
Vartotojo pastangos, reikalingos siekiant išmokti dirbti
su programa.
Veikimas (operation)
Vartotojo pastangos, reikalingos programos operacijų
atlikimui bei jų valdymui.
94
Patikimumas (angl. reliability)
Subcharakteristika
Apibūdinimas
Brandumas (maturity)
Nesėkmingų programos veikimo atvejų dėl gedimų
dažnis.
Gedimų tolerancija
(Fault tolerance)
Programos galimybės palaikyti nustatytą
funkcionavimo lygį atsiradus tam tikriems gedimams.
Atkuriamumas
(recoverability)
Programos gebėjimas atstatyti funkcionavimo lygį bei
prarastus duomenis nesėkmingo programinės
operacijos atlikimo atveju nustatytose laiko bei kaštų
ribose.
95
Našumas (angl. efficiency)
Subcharakteristika
Apibūdinimas
Laikinė elgsena
(time behaviour)
Programos atsako bei veikimo laikai.
Elgsena resursų
atžvilgiu (resource
behaviuor)
Programos naudojamų resursų apimtis bei jų
panaudojimo trukmė.
96
Palaikomumas (angl. maintainability)
Subcharakteristika
Apibūdinimas
Analizuojamumas
(analyzability)
Pastangų apimtis, reikalinga programų trūkumų arba
defektų analizei, arba modifikuojamų programos dalių
nustatymui.
Keičiamumas
(changebility)
Pastangų apimtis, reikalinga programos
modifikacijoms, klaidų pašalinimui arba perėjimui prie
kitos funkcionavimo aplinkos.
Stabilumas (stability)
Rizikos dydis susijęs su nenuspėjamu funkcionavimu
po programos modifikacijų.
Testuojamumas
(testability)
Pastangų apimtis, reikalinga atliekant programinės
įrangos validavimą po modifikavimo.
97
Pernešamumas (angl. portability)
Subcharakteristika
Apibūdinimas
Prisitaikomumas
(adaptability)
Programos galimybės prisitaikyti prie skirtingų
funkcionavimo aplinkų
Įdiegiamumas
(installability)
Pastangų apimtis, reikalinga diegiant programinę
įrangą nustatytoje funkcionavimo aplinkoje.
Atitikimas
(conformance)
Programinės įrangos atitikimas pernešamumo
standartams ar susitarimams.
Pakeičiamumas
(replaceability)
Galimybė panaudoti programinę įrangą vietoje kitos
programinės įrangos jos funkcionavimo aplinkoje.
98
REKOMENDUOJAMAS IVV IS
TECHNINĖS SPECIFIKACIJOS TURINYS
SU PAKEITIMAIS
•
•
•
•
•
•
•
•
•
•
1. Santrauka
2. Panaudotų dokumentų sąrašas
3. IS paskirtis ir tikslai
3.1. IS paskirtis
1.2. IS pagrindiniai tikslai
4. Kompiuterizuojamo objekto pageidaujama būsena
4.1. Kompiuterizuojamo objekto apibūdinimas
4.2. IS informacijos srautai
4.2.1. IS išoriniai informacijos srautai
4.2.2. IS vidiniai informacijos srautai
99
REKOMENDUOJAMAS IVV IS
TECHNINĖS SPECIFIKACIJOS TURINYS
SU PAKEITIMAIS
• 4.2. IS laikoma informacija
• 4.3. IS vartotojams teikiama informacija
• 4.4. Duomenų, esančių valstybės kadastruose ir
registruose panaudojimo poreikiai ir galimybės.
• 5. Kompiuterizuojamo objekto pageidaujamos būsenos
įgyvendinimas
• 6. IS efektyvumas
• 6.1. IS kūrimo sąnaudos (nustatyti reikalavimų funkcinį
dydį)
• 6.2. IS aptarnavimo sąnaudos
• 6.3. IS prognozuojama nauda
100
REKOMENDUOJAMAS IVV IS
TECHNINĖS SPECIFIKACIJOS TURINYS
SU PAKEITIMAIS
• 7. IS keliami reikalavimai ir sprendimo architektūra
• 7.1. IS reikalavimai techninėms priemonėms ir architektūra
• 7.2. IS reikalavimai programinei įrangai (kiekvienam
reikalavimui nurodyti diegimo prioritetą ir kritiškumą)
• 7.3. IS duomenų laikymo reikalavimai
• 7.4. IS duomenų rinkimo, ruošimo ir kontrolės reikalavimai
• 7.5. IS duomenų apsaugos reikalavimai
• 7.6. Personalo kvalifikacijos reikalavimai
• 7.7. Teisinės ir organizacinės sąlygos IS parengti ir
eksploatuoti
101
REKOMENDUOJAMAS IVV IS
TECHNINĖS SPECIFIKACIJOS TURINYS
SU PAKEITIMAIS
• 7.8. Vartotojų, išorinės ir vidinės kokybės matavimo
reikalavimai ir metrikos
• 7.9. Kiti IS reikalavimai
• 8. IS projekto valdymas
• 8.1. IS projekto struktūra
• 8.2. IS finansavimo šaltiniai ir finansavimo tvarka
• 8.3. Darbų grafikai ir vykdytojai
102
REKOMENDUOJAMAS IVV IS
TECHNINĖS SPECIFIKACIJOS TURINYS
SU PAKEITIMAIS
•
•
•
•
•
•
8.4. IS projekto rezultatai
8.5. Darbų kontrolė ir priėmimas
8.6. IS diegimas
9. Pavartotos sąvokos ir terminai
10. Priedai
11. Pakeitimų registravimo žurnalas
103
KONTROLĖS TAŠKAI (1)
• Nuo gyvavimo ciklo priklauso projekto rezultatų kokybei
vertinti numatomi išorinės ir vidinės kontrolės taškai ir
tikrinimo procedūros.
• Kontrolės taškuose pagal tikrinimo rezultatus priimami
sprendimai dėl IS projekto koregavimo.
• Išorinės kontrolės taškai gali būti periodiniai ir / ar turi sutapti
su tais laiko momentais, kuriuose numatoma gauti konkrečius
rezultatus (projektinius sprendimus, dokumentus ir t. t.).
• Išorinės kontrolės taškai gali būti metų, pusmečių, ketvirčių,
mėnesių eilės. Vidinės kontrolės taškai daug dažnesni, vienos
ar kelių savaičių eilės.
104
KONTROLĖS TAŠKAI (2)
• Kontrolės taškai vykdant projektą pagal nuoseklųjį gyvavimo
ciklą aprašyti Valstybės informacinių sistemų kūrimo
metodikoje, patvirtintoje Informacinės visuomenės plėtros
komiteto prie Lietuvos Respublikos Vyriausybės direktoriaus
2004 m. spalio 15 d. įsakymu Nr. T-131 (Žin., 2004, Nr. 1555679).
• Vykdant projektą pagal laipsniškuosius gyvavimo ciklus
nustatomi šių keturių (4) išorinės kontrolės rūšių taškai: a)
kiekvienos projekto fazės pradžioje, b) paruošus IS ar
pakeitimo (papildomo modulio) specifikaciją c) sukūrus
modulius prieš vartotojų priėmimo testavimą d) prieš
sistemos perdavimą užsakovui.
105
KONTROLĖS TAŠKAI (3)
• Kontrolės taškų pasirinkimą lemia situaciniai ir rizikos
faktoriai. Kuo didesnė rizika, neapibrėžtumas ir sudėtingumas,
tuo dažnesnė ir formalesnė turi būti kontrolė. Kontrolės
taškus galima taikyti po kiekvienos stadijos, iteracijos arba
laiko intervalo. Formalios kontrolės taškai turi griežtai
apibrėžtą dokumentaciją ir vykdomi periodiškai.
• Nustatomi kontrolės taškai turi būti suderinti su projekto
dalininkais ir dalyviais bei priimtini projekto organizacinei
kultūrai, išsaugant pagrindiniu projekto tikslu veikiančią ir
reikalavimus atitinkančią sistemą.
106
REKOMENDACIJOS APTARNAVIMO
SUTARTIMS
• Rengiant galimybių studiją turi būt įvertintos IS eksploatavimo
ir valdymo galimybės, tame tarpe naudojant išorinių paslaugų
tiekėją, ko rezultatu būtų parengti aptarnavimo lygio
reikalavimai. Ši metodika rekomenduoja, kuriant informacinių
sistemų paslaugų valdymo sistemą remtis standartais ISO IEC
20000-1 bei ISO IEC 20000-2.
• Pagrindinis paslaugų valdymo aptarnavimo lygio proceso (ISO
IEC 20000-1:2005, 6.1) tikslas yra kokybiškas IT paslaugų
teikimas vidinių ir/arba išorinių paslaugų naudotojams. Jis
rekomenduoja sudaryti aptarnavimo lygio sutartis tiek tarp
vidines paslaugas teikiančio IT padalinio tiek su išoriniais
paslaugų tiekėjais.
107
REKOMENDACIJOS APTARNAVIMO
SUTARTIMS
• Pagrindinis paslaugų ataskaitų valdymo proceso (ISO IEC
20000-1:2005, 6.2) tikslas yra laiku ir tiksliai pateikti teikiamų
paslaugų lygio atitikties susitarimui ataskaitas.
• Pagrindinis paslaugų tęstinumo ir prieinamumo valdymo
proceso (ISO IEC 20000-1:2005, 6.3) tikslas yra užtikrinti, kad
yra sudaryti paslaugų tęstinumo planai, pagal kuriuos
paslaugos būtų teikiamos sutrikus pagrindiniam paslaugos
teikimo scenarijui. Rengiant tęstinumo planus taip pat
rekomenduojama atsižvelgti į rekomendacijas veiklos
tęstinumo valdymui (ISO IEC 17799:2005, 14), rekomendacijas
dokumentų sudėčiai.
108
REKOMENDACIJOS APTARNAVIMO
SUTARTIMS
• Pagrindinis paslaugų biudžetavimo ir apskaitos proceso (ISO
IEC 20000-1:2005, 6.4) tikslas yra užtikrinti, kad yra būtų
planuojamos ir apskaitomos susijusios išlaidos.
• Pagrindinis paslaugų pajėgumo valdymo proceso (ISO IEC
20000-1:2005, 6.5) tikslas yra užtikrinti, kad visada pakanka
resursų vykdyti įsipareigojimus pagal aptarnavimo lygio
susitarimą.
• Pagrindinis paslaugų informacijos saugos valdymo proceso
(ISO IEC 20000-1:2005, 6.6) tikslas yra valdyti ir užtikrinti
duomenų, tame tarpe asmens ir strateginės svarbos
informacijos, saugą.
109
REKOMENDACIJOS APTARNAVIMO
SUTARTIMS
• ISO IEC 20000-2 rekomenduoja paslaugų valdymo praktiką ir
susijusių dokumentų turinį.
110
DAŽNIAUSIAI NAUDOJAMOS
SĄVOKOS
• Paslaugos teikėjas - pagal paslaugų lygio susitarimą IT
paslaugas teikiantis padalinys ar organizacija.
• Paslaugos gavėjas - paslaugos gavėjas yra visi, tame tarpe ir
pagal laikinas sutartis įstaigoje ar organizacijoje dirbantys
darbuotojai.
• Paslaugų katalogas – teikiamų paslaugų sąlygų aprašymų
sąvadas.
• Paslaugų lygio susitarimas - paslaugų teikimo sąlygos, tarp
paslaugų gavėjo ir IT paslaugų teikėjo, išreikštos paslaugų
katalogu ir matuojamais paslaugų atlikimo rodikliais.
111
DAŽNIAUSIAI NAUDOJAMOS
SĄVOKOS
• Vidinis paslaugų lygio susitarimas - paslaugų teikimo sąlygos,
išreikštos matuojamais rodikliais, tarp paslaugų gavėjo ir IT
paslaugas teikiančio įstaigos vidinio padalinio.
• Operacinis lygio susitarimas - paslaugų teikimo sąlygos,
išreikštos matuojamais rodikliais, tarp paslaugų gavėjui IT
paslaugas teikiančio paslaugų teikėjo ir jo vidinių/išorinių
partnerių, turinčių tiesioginę įtaką atliekamai paslaugai.
• Reagavimo laikas - reagavimo laiku laikomas paslaugos teikėjo
darbuotojo veiksmų pradžios laikas, užregistruotas
aptarnavimo sistemoje.
• Sprendimo laikas - sprendimo laiku laikomas galutinis
išsprendimo laikas, užregistruotas aptarnavimo sistemoje.
112
APTARNAVIMO PERDAVIMO
PASLAUGŲ TEIKĖJAMS PRIELAIDOS
(1)
• Aptarnavimo perdavimas paslaugų teikėjams
rekomenduojamas kai tenkinamos šios prielaidos:
– Galimybių studija nustato, kad galimas sąnaudų
sumažinimas;
– Gerėja darbuotojų organizacinis panaudojimas;
– Mažėja mokymo išlaidos, pritraukiamos specializuotų
išorinių specialistų kompetencijos;
– Srityje nusistovėjusi ir paplitusi išorinių paslaugų pirkimo
praktika, yra pakankama konkurencija;
113
APTARNAVIMO PERDAVIMO
PASLAUGŲ TEIKĖJAMS PRIELAIDOS
(2)
– Paslaugų tiekėjas įgalina greitesnį gerosios paslaugų
praktikos perteikimą;
– Atliktas duomenų perdavimo paslaugų teikėjui rizikos
vertinimas;
– Atliktas vidinis organizacinio palankumo sprendimui
tyrimas;
– Raštu užtikrintas ilgalaikis vadovybės palaikymas
sprendimui;
– Parengtas aptarnavimo perdavimo projekto planas.
114
REKOMENDUOJAMA APTARNAVIMO
LYGIO SUTARTIES SUDĖTIS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Sutarties tikslai ir apimtis
Paslaugų lygio susitarimo sąlygos
Sutarties galiojimo sąlygos
Nukrypimų nuo sutarto aptarnavimo lygio valdymas
Sutarties pakeitimų valdymas
Ataskaitų pateikimo tvarka
Paslaugų apmokestinimo tvarka
Mokėjimo sąlygos
Bendradarbiavimo saugumo sąlygos
Nenugalimos jėgos
Kitos sąlygos
115
PRIEDAI:
•
•
•
•
•
•
•
•
Paslaugų katalogas – paslaugų aprašymai
Ataskaitų formos
Darbų užsakymo, pridavimo ir perdavimo aktų formos
Sutarties ir paslaugų pakeitimų valdymo formos
Nuobaudų ir paskatinimų formos
Paslaugų kainos
Sąvokos ir terminai
Konfidencialumo pasižadėjimo formos
116
SUTARTIES GALIOJIMO SĄLYGOS
• Rekomenduojama pasirašinėti aptarnavimo lygio sutartis ne
trumpesniam kaip 36 mėnesių laikotarpiui.
• Sutartyse galima numatyti automatinio pratęsimo kriterijus ir
sąlygas.
• Svarbi ir galimybė sutartį nutraukti vienašališkai, kas turi būti
reglamentuojama abiems šalims vienodomis sąlygomis.
117
PASLAUGŲ LYGIO SUSITARIMO
SĄLYGOS
• Aptarnavimo lygio susitarimų reikalavimuose turi būti
apibrėžiami teiktinų paslaugų tikslai ir kokios yra šalių
atsakomybės ribos bei paslaugų apimtis.
• Aptarnavimo veikla vykdoma tik pagal paslaugų kataloge
aprašytas, į bendrą paslaugų apimtį įtrauktas, paslaugas. Jokia
veikla neįtraukta į bendrą paslaugų valdymo apimtį neturi būti
vykdoma.
• Į paslaugų katalogą rekomenduojama įtraukti ne tik
infrastruktūros priežiūros ar sistemos aptarnavimo incidentų
ar problemų sprendimo paslaugas, bet ir duomenų tvarkymo,
papildomo vystymo, sistemos konsultavimo ar vartotojų
mokymo paslaugas.
118
PASLAUGŲ LYGIO SUSITARIMO
SĄLYGOS
• Šiuo tikslu kiekvienai paslaugai lentelėje nustatomi paslaugos
aptarnavimo metrika ir lygis.
• Metrikų lygis (vertės) parenkamas įvertinus esamų, viduje
teikiamų paslaugų reagavimo ir sprendimo laikus, incidentų
išsprendimo laiku procentus ir panašiai. Rekomenduojama
surinkti paslaugų lygio parametrų vertes kitų paslaugas
perkančių organizacijų apklausos būdu, užklausti potencialius
tiekėjus.
• Rekomenduojama metrikas pasirinkti pagal ISO IEC TR 9126
119
NUKRYPIMŲ NUO SUTARTO
APTARNAVIMO LYGIO VALDYMAS
• Numatomos šalių pareigos ir atsakomybės dėl įsipareigojimų
stebėsenos.
• Numatoma informavimo apie nukrypimą nuo sutarto
paslaugos lygio tvarka, pranešimų terminai ir turinys.
120
SUTARTIES TURINYS
• Sutarties pakeitimų valdymas
• Aptarnavimo lygio sutarčių sritis yra labai dinamiška, todėl
siekiant visokeriopo lankstumo rekomenduojama numatyti
papildomų paslaugų įtraukimo į katalogą, o taip pat sutarties
ir jos priedų pakeitimų valdymo terminus, pareigas ir
atsakomybes, aprašyti eskalavimo tvarką.
• Ataskaitų pateikimo tvarka
• Šioje dalyje aptariama sutarties vykdymo ir paslaugų kokybės
stebėsenos ataskaitų pateikimo tvarka. Ataskaitų formos
nustatomos sutarties prieduose.
121
PASLAUGŲ APMOKESTINIMO TVARKA
• Rekomenduojama vengti fiksuoto mokesčio modelio, siejant
apmokėjimą su sprendžiamų incidentų ir problemų, vystymo,
mokymo ir konsultavimo darbų apimtimis ir jų kokybe,
sutarties prieduose numatant bonus-malus (baudų ir
paskatinimų) sąlygas.
122
BENDRADARBIAVIMO SAUGUMO
SĄLYGOS
• Visa informacija, susijusi su paslaugomis arba prieinama
netiesiogiai paslaugų teikimo metu, yra paslaugų gavėjo
nuosavybė ir negali būti kopijuojama bei turi būti saugoma tik
paslaugų gavėjo informacinėse sistemose.
• Paslaugų teikėjas saugo paslaugų gavėjo sistemose esančius
asmens duomensi bei konfidencialą informaciją, kaip ji
reglamentuota paslaugų gavėjo informacinės sistemos
duomenų saugos nuostatuose ir saugaus elektroninės
informacijos tvarkymo taisyklėse ir kituose paslaugų gavėjo
informacijos saugos dokumentuose (rengiami pagal saugos
dokumentų turinio gaires, patvirtintas Lietuvos Respublikos
vidaus reikalų ministro 2007 m. gegužės 8 d. įsakymu Nr. 1V172).
123
KLAUSIMAI IR PASTABOS
Šis laikas skirtas jūsų klausimams ir pastaboms, siekiant
atsižvelgti į pareiškėjų ir paslaugų teikėjų nuomonę ruošiant
rekomendacijas paskelbimui IVPK direktoriaus įsakymu
124
KLAUSIMAI IR PASTABOS
125
AČIŪ UŽ DĖMESĮ.
126