BENDROS DUOMENŲ MAINŲ SISTEMOS TECHNINĖ SPECIFIKACIJA
Pirkimo sąlygų 1 priedas
BENDROS DUOMENŲ MAINŲ SISTEMOS TECHNINĖ SPECIFIKACIJA
Turinys
2. VARTOJAMOS SĄVOKOS IR SUTRUMPINIMAI 2
3. TEISĖS AKTAI, KURIAIS TURI BŪTI VADOVAUJAMASI 3
4. PIRKIMO TIKSLAS, UŽDAVINIAI IR REZULTATAI 3
5. ESAMA SITUACIJA IR ESAMAS KOMPIUTERIZAVIMO LYGIS 4
6. REIKALAVIMAI BDMS SUKŪRIMUI 7
6.3 Funkciniai reikalavimai 10
6.3.1 Bendrieji reikalavimai 10
6.3.2 Reikalavimai vidinio naudojimo moduliui 12
6.3.3 Reikalavimai išorinio naudojimo moduliui 16
6.3.4 Reikalavimai integracinėms sąsajoms 20
7. NEFUNKCINIAI REIKALAVIMAI 22
7.1 Reikalavimų įgyvendinimas 22
7.3 Reikalavimai naudotojo sąsajai ir ergonomikai 24
7.4 Reikalavimai architektūrai 25
7.5 Reikalavimai programinei įrangai ir licencijoms 26
7.6 Reikalavimai greitaveikai ir našumui 27
7.7 Reikalavimai demonstracijoms 27
7.8 Reikalavimai testavimui 28
7.10 Reikalavimai bandomajai eksploatacijai 29
7.12 Reikalavimai garantinei priežiūrai 30
7.13 Reikalavimai sutarties vykdymo etapams 31
7.14 Baigiamosios nuostatos 38
1. BENDRA INFORMACIJA
1. Visagino savivaldybės administracija (toliau – Perkančioji organizacija) Visagino savivaldybės administracija įgyvendina projektą „Paslaugų ir asmenų aptarnavimo kokybės gerinimas Visagino savivaldybėje“ Nr. 10.1.3-ESFA-R-920-91-0001. Siekiant gerinti savivaldybės administracijos ir švietimo įstaigų teikiamas paslaugas (priėmimo į švietimo formaliojo ir neformaliojo ugdymo įstaigas) Perkančioji organizacija numato įsigyti bendros duomenų mainų sistemos (toliau – BDMS) sukūrimo ir diegimo paslaugas.
2. Šio dokumento tikslas – aprašyti BDMS funkcinius ir nefunkcinius reikalavimus.
3. Šioje specifikacijoje reikalavimai BDMS išorinio naudojimo moduliui aprašyti 1 – 7 skyriuose (išskyrus
6.3.2 skyrių), BDMS vidinio naudojimo moduliui aprašyti 1 – 7 skyriuose (išskyrus 6.3.3 skyrių).
2. VARTOJAMOS SĄVOKOS IR SUTRUMPINIMAI
Sutrumpinimas / apibrėžimas | Paaiškinimas |
BDMS | Bendra duomenų mainų sistema |
Bendrasis ugdymas | Pradinis ugdymas, pagrindinis ugdymas, vidurinis ugdymas |
DB | Duomenų bazė |
ESPBI IS | Elektroninės sveikatos paslaugų ir bendradarbiavimo infrastruktūros informacinė sistema |
Formalusis švietimas | Švietimas, vykdomas pagal Lietuvos Respublikos teisės aktų nustatyta tvarka patvirtintas ir įregistruotas švietimo programas, kurias baigus įgyjamas pradinis, pagrindinis, vidurinis arba aukštasis išsilavinimas ir (ar) kvalifikacija arba pripažįstama kompetencija, reikalinga įstatymų reglamentuojamam darbui ar funkcijai atlikti |
GR | Lietuvos Respublikos gyventojų registras |
IS | Informacinė sistema |
LR | Lietuvos Respublika |
Mokykla | Juridinis asmuo, valstybės narės juridinio asmens ar kitos organizacijos padalinys, įsteigtas Lietuvos Respublikoje teisės aktų nustatyta tvarka, kurio pagrindinė veikla yra formalusis arba (ir) neformalusis švietimas |
Mokinys | Asmuo, kuris mokosi |
Neformalusis švietimas | Švietimas pagal įvairias švietimo poreikių tenkinimo, kvalifikacijos tobulinimo, papildomos kompetencijos įgijimo programas, išskyrus formaliojo švietimo programas. |
Pagrindinio ugdymo programa | Šešerių metų (5–10 klasės) ugdymo programa, kurios pirmoji dalis apima ketverių metų pagrindinio ugdymo tarpsnį (5–8 klasės), antroji dalis – dvejų metų ugdymo tarpsnį (9–10 klasės arba gimnazijos I–II klasės) |
Paslaugų teikėjas, Diegėjas | Fizinis arba juridinis asmuo, kuris įgyvendina šios specifikacijos reikalavimus |
Perkančioji organizacija | Visagino savivaldybės administracija |
Pirkimas | Bendros duomenų mainų sistemos sukūrimo ir įdiegimo paslaugų pirkimas |
Pradinio ugdymo programa | Ketverių metų ugdymo programa, vykdoma 1–4 klasėse |
SAM | Lietuvos Respublikos sveikatos apsaugos ministerija |
ŠMSM | Lietuvos Respublikos švietimo, mokslo ir sporto ministerija |
TVS | Turinio valdymo sistema |
Vidurinio ugdymo programa | Dvejų metų (11–12 klasės arba gimnazijos III–IV klasės) ugdymo programa |
VIISP | Valstybės informacinių išteklių sąveikumo platforma |
3. TEISĖS AKTAI, KURIAIS TURI BŪTI VADOVAUJAMASI
4. Toliau yra pateikiamas sąrašas dokumentų ir teisės aktų, kuriais turi būti vadovaujamasi kuriant BDMS (sąrašas nėra baigtinis):
4.1. Visagino savivaldybės 2016-2022 m. strateginis plėtros planas, patvirtintas Visagino savivaldybės tarybos 2016 m. sausio 28 d. sprendimu Nr. TS-3;
4.2. Visagino savivaldybės 2019-2021 m. strateginis veiklos planas, patvirtintas Visagino savivaldybės tarybos 2019 m. vasario 21 d. sprendimu Nr. TS-30;
4.3. Visagino savivaldybės tarybos 2016 m. rugpjūčio 10 d. sprendimas Nr. TS-152 „Dėl Visagino savivaldybės bendrojo ugdymo mokyklų tinklo pertvarkos 2016-2020 m. bendrojo plano patvirtinimo“;
4.4. Visagino savivaldybės tarybos 2018 m. gruodžio 20 d. sprendimas Nr. TS-251 “Dėl mokinių priėmimo į Visagino savivaldybės bendrojo ugdymo mokyklas tvarkos aprašo patvirtinimo“ pakeitimo patvirtinimo;
4.5. Visagino savivaldybės tarybos 2018 m. rugpjūčio 29 d. sprendimas Nr. TS-159 „Dėl vaikų priėmimo į Visagino savivaldybės ikimokyklinio ugdymo, formalųjį švietimą papildančio ugdymo ir neformaliojo vaikų švietimo mokyklas ir grupių komplektavimo tvarkos aprašo patvirtinimo“;
4.6. Visagino savivaldybės tarybos 2011 m. kovo 24 d. sprendimas Nr. TS-52 „Dėl mokinių pavėžėjimo organizavimo ir važiavimo išlaidų kompensavimo tvarkos aprašo patvirtinimo“;
4.7. Visagino savivaldybės tarybos 2016 m. sausio 28 d. sprendimas Nr. TS-6 “Dėl Visagino savivaldybės paramos mokinio reikmenims įsigyti tvarkos aprašo patvirtinimo”;
4.8. Visagino savivaldybės tarybos 2012 m. vasario 23 d. sprendimas Nr. TS-29 ,,Dėl Visagino savivaldybės mokinių nemokamo maitinimo mokyklose tvarkos aprašo patvirtinimo“ ir jo pakeitimai 2014 m. sausio 30 d. Nr. TS-8, 2014 m. balandžio 3 d. Nr. TS-37, 2016-01-28 Nr. TS-6;
4.9. kiti su teikiamomis paslaugomis ir su Perkančiosios organizacijos veiklos reglamentavimu susiję teisės aktai ir dokumentai.
5. Paslaugų teikėjas privalo vadovautis ne tik aukščiau išvardintais, bet ir visais kitais su sutarties įgyvendinimu susijusiais teisės aktais, taip pat jų naujausiais pakeitimais ir papildymais. Paslaugų teikėjui privalomi ir visi sutarties vykdymo metu naujai priimti teisės aktai, jeigu jie susiję su sutarties įgyvendinimu.
4. PIRKIMO TIKSLAS, UŽDAVINIAI IR REZULTATAI
6. Pirkimo tikslas – įsigyti BDMS sukūrimo ir diegimo paslaugas.
7. Pirkimo uždaviniai:
7.1. atlikti detalią poreikių ir galimybių analizę;
7.2. sumodeliuoti ir suprojektuoti BDMS funkcionalumą;
7.3. parengti ir suderinti visą numatytą BDMS dokumentaciją;
7.4. realizuoti BDMS funkcijas;
7.5. įdiegti BDMS funkcijas;
7.6. sėkmingai įvykdyti BDMS sukurtų funkcijų testavimą bei bandomąją eksploataciją;
7.7. vykdyti BDMS garantinės priežiūros paslaugas.
8. Pirkimo rezultatas – pilna apimtimi sukurta, įdiegta ir ištestuota BDMS. Teikiamos garantinės priežiūros ir palaikymo paslaugos.
5. ESAMA SITUACIJA IR ESAMAS KOMPIUTERIZAVIMO LYGIS
9. Šiuo metu Xxxxxxxx savivaldybėje mokinių priėmimas į neformaliojo vaikų švietimo mokyklas ir vaikų priėmimas į ikimokyklinio ugdymo mokyklas vykdomas šiose įstaigose:
9.1. Visagino „Verdenės“ gimnazija;
9.2. Visagino „Atgimimo“ gimnazija;
9.3. Visagino Draugystės progimnazija;
9.4. Xxxxxxxx „Gerosios vilties“ progimnazija;
9.5. Visagino „Žiburio“ pagrindinė mokykla;
9.6. Visagino vaikų lopšelis – darželis „Auksinis gaidelis“;
9.7. Visagino vaikų lopšelis – darželis „Auksinis raktelis“;
9.8. Visagino vaikų lopšelis – darželis „Ąžuoliukas“;
9.9. Visagino vaikų lopšelis – darželis „Gintarėlis“;
9.10. Visagino vaikų lopšelis – darželis „Kūlverstukas“;
9.11. Visagino kūrybos ir menų akademija;
9.12. Visagino edukacijų centras;
9.13. Visagino sporto ir rekreacijos centras;
9.14. Visagino švietimo pagalbos tarnyba.
10. Šiuo metu priėmimo į Visagino savivaldybės formaliojo švietimo įstaigas, nurodytas 9.1-9.5 papunkčiuose, tvarka:
10.1. Priėmimą mokytis pagal pradinio, pagrindinio ugdymo pirmosios ir antrosios dalies ir vidurinio ugdymo, suaugusiųjų pagrindinio ir vidurinio ugdymo, individualizuotas pradinio ir pagrindinio ugdymo, socialinio ugdymo įgūdžių programas ir mokinių paskirstymą į klases organizuoja ir vykdo šias programas įgyvendinančių bendrojo ugdymo mokyklų direktoriai ir jų sudarytos mokinių priėmimo komisijos kiekvienais kalendoriniais metais nuo birželio 1 d. iki liepos 15 d. Prašymai teikiami mokykloje.
10.2. Asmuo, pageidaujantis mokytis, mokyklos vadovui teikia:
10.2.1. nustatytos formos prašymą (prašymą už vaiką iki 14 metų teikia vienas iš tėvų (globėjų, rūpintojų), nuo 14 metų – vaikas, turintis vieno iš tėvų (globėjų, rūpintojų) raštišką sutikimą);
10.2.2. vaiko gimimo liudijimą ar vaiko tapatybę patvirtinantį dokumentą arba notaro patvirtintą šio dokumento kopiją;
10.2.3. vaiko įgyto išsilavinimo pažymėjimą arba mokymosi pasiekimus liudijantį dokumentą (išskyrus priimamus į pirmą klasę vaikus);
10.2.4. gyvenamosios vietos deklaravimo pažymą (Lietuvos Respublikos piliečiams);
10.2.5. leidimą gyventi Lietuvoje (išskyrus Lietuvos Respublikos piliečius);
10.2.6. elektroninį Lietuvos Respublikos sveikatos apsaugos ministro 2015 m. lapkričio 26 d. įsakymu Nr. V-1336 nustatytos formos vaiko sveikatos pažymėjimą ir dvi nuotraukas.
10.3. Prašymas ir kiti teikiami dokumentai registruojami Dokumentų tvarkymo ir apskaitos taisyklių, patvirtintų Lietuvos vyriausiojo archyvaro 2011 m. liepos 4 d. įsakymu Nr. V-118 „Dėl Dokumentų tvarkymo ir apskaitos taisyklių patvirtinimo“, nustatyta tvarka.
10.4. Mokinių priėmimas mokytis į mokyklas įforminamas mokymo sutartimi. Mokymo sutartis su kiekvienu naujai atvykusiu asmeniu sudaroma iki pirmos jo mokymosi pagal ugdymo programą dienos.
10.5. Sudarius mokymo sutartį, asmuo registruojamas Mokinių registre, nurodoma pirmoji mokinio mokymosi diena.
10.6. Priimtų į mokyklas asmenų paskirstymo į klases tvarką ir kriterijus, suderinęs su mokyklos taryba, nustato mokyklos direktorius. Mokinių paskirstymo į klases tvarka ir kriterijai viešinami mokyklos interneto svetainėje.
10.7. Per mokslo metus atvykę mokiniai priimami į mokyklą, kurios aptarnaujamoje teritorijoje gyvena. Jei į bendrojo ugdymo mokyklą atvyksta mokinys, gyvenantis mokyklai priskirtoje teritorijoje, ir joje nėra laisvų vietų, jis nukreipiamas į artimiausią tą pačią programą vykdančią bendrojo ugdymo mokyklą, kurioje yra laisvų vietų. Nauji klasių komplektai per mokslo metus neformuojami.
10.8. Priėmimo mokytis pagal pradinio ugdymo, pagrindinio ugdymo programos pirmąją dalį kriterijai:
10.8.1. pirmumo teise priimami mokiniai, deklaravę gyvenamąją vietą mokyklai Visagino savivaldybės tarybos 2012 m. kovo 29 d. sprendimu Nr. TS-58 priskirtoje aptarnavimo teritorijoje;
10.8.2. į likusias laisvas vietas klasėse gali būti priimti asmenys, negyvenantys mokyklos aptarnavimo teritorijoje: pirmiausia priimami asmenys, dėl įgimtų ar įgytų sutrikimų turintys specialiųjų ugdymosi poreikių, mokykloje jau besimokančių mokinių broliai (įbroliai) ir seserys (įseserės) ir arčiausiai mokyklos gyvenantys asmenys;
10.8.3. priėmus visus pageidaujančius savivaldybės teritorijoje gyvenančius vaikus ir esant laisvų vietų, tėvų (globėjų, rūpintojų) pageidavimu gali būti priimami mokiniai, gyvenantys gretimoje savivaldybėje, pagal prašymo padavimo datą;
10.8.4. jeigu iš kitų savivaldybės mokykloms priskirtų aptarnavimo teritorijų pageidaujančių mokytis mokinių yra daugiau negu laisvų vietų, nauji klasių komplektai nesudaromi.
10.9. Priėmimo mokytis pagal pagrindinio ugdymo antrąją dalį ir vidurinio ugdymo programą kriterijai:
10.9.1. šias programas asmenys renkasi patys;
10.9.2. pirmumo teise priimami mokiniai iš savivaldybės teritorijos;
10.9.3. priėmus visus pageidaujančius savivaldybės teritorijoje gyvenančius vaikus, į likusias laisvas vietas priimami ne savivaldybės teritorijoje gyvenantys mokiniai pagal prašymo pateikimo datą;
10.9.4. jei norinčiųjų yra daugiau nei laisvų mokymosi vietų, pirmiausia priimami asmenys atsižvelgiant į jų pageidavimą tęsti dalykų, dalykų modulių, kurių buvo pradėję mokytis pagal pagrindinio ugdymo programos antrąją dalį, mokymąsi pagal vidurinio ugdymo programą ir mokymosi pasiekimus (pagrindinio ugdymo pasiekimų patikrinimo įvertinimus, metinius įvertinimus, atliktus projektinius darbus, mokinio sukauptą darbų aplanką ar kitus mokymosi pasiekimų vertinimus).
11. Šiuo metu priėmimo į Visagino savivaldybės neformaliojo švietimo įstaigas, nurodytas 9.6-9.10 papunkčiuose, tvarka:
11.1. Vaikai priimami į ikimokyklinę ir priešmokyklinę grupes vaiko atstovams pagal įstatymą pateikus šiuos dokumentus:
11.1.1. Mokyklos nustatytos formos prašymą, kuriame nurodoma:
11.1.1.1. xxxxx vardas, xxxxxxx, gimimo data;
11.1.1.2. vaiko atstovo pagal įstatymą vardas, pavardė, gyvenamoji vieta, kontaktai susisiekti;
11.1.1.3. prašymo gavimo data, registravimo numeris;
11.1.1.4. pageidaujamas vaiko priėmimo į grupę laikas;
11.1.1.5. pasirinktas priešmokyklinio ugdymo modelis (į priešmokyklinio ugdymo grupę);
11.1.1.6. duomenys, kuriais vadovaujantis turėtų būti teikiamas prioritetas priimant vaiką į Mokyklą;
11.1.1.7. dokumentus pateikusio asmens (vaiko atstovo pagal įstatymą) vardas, xxxxxxx, parašas;
11.1.2. vaiko gimimo liudijimą ir vaiko atstovų pagal įstatymą ar vieno iš jų asmens tapatybę patvirtinantį dokumentą bei jų kopijas. Ne Lietuvos Respublikos piliečiai pateikia asmens dokumentą ir užsieniečio teisinę padėtį (teisėtą gyvenimą Lietuvos Respublikoje) patvirtinantį dokumentą ir jų kopijas;
11.1.3. sveikatos apsaugos ministro nustatytos formos vaiko sveikatos būklės pažymėjimą.
11.2. Prašymai registruojami tėvų prašymų dėl vaikų priėmimo į ikimokyklines ir priešmokyklines grupes Mokyklos registracijos žurnale, kuriame nurodoma:
11.2.1. xxxxx vardas, xxxxxxx;
11.2.2. gyvenamoji vieta;
11.2.3. telefono numeris (vaiko atstovų pagal įstatymą namų ir darbo) ir el. paštas (jeigu yra);
11.2.4. nuo kada pageidauja pradėti lankyti grupę;
11.2.5. kokią grupę pageidauja lankyti;
11.2.6. vaiko gimimo data;
11.2.7. prašymo pateikimo data;
11.2.8. kada ir į kokią grupę vaikas priimtas;
11.2.9. kada vaikas išbrauktas iš sąrašų.
11.3. Vaiko priėmimas įforminamas Mokyklos direktoriaus įsakymu, sudaroma Mokyklos nustatytos formos dvišalė sutartis, kurioje nurodoma:
11.3.1. sutarties šalys,
11.3.2. ugdymo programa,
11.3.3. xxx xxxxxxx forma,
11.3.4. šalių įsipareigojimai,
11.3.5. jų nevykdymo pasekmės,
11.3.6. sutarties terminas,
11.3.7. xxx xxxxxxx, nutraukimo pagrindai ir padariniai.
11.3.8. Sutartį pasirašo Mokyklos direktorius ir vienas iš vaiko atstovų pagal įstatymą vaiko priėmimo į Mokyklą dieną.
11.4. Sutartis registruojama Mokyklos mokymo sutarčių registravimo žurnale.
11.5. Sudarius mokymo sutartį vaikas registruojamas Mokinių registre.
11.6. Priimant Visagino savivaldybės teritorijoje gyvenantį vaiką į ikimokyklinę ar priešmokyklinę grupę prioritetai teikiami:
11.6.1. specialiųjų poreikių vaikams;
11.6.2. socialiai remtinų šeimų vaikams;
11.6.3. vaikams, kuriems savivaldybės administracijos Vaiko gerovės komisijai rekomendavus savivaldybės administracijos direktoriaus įsakymu skirtas privalomas ikimokyklinis ugdymas;
11.6.4. vaikams iš šeimų, auginančių tris ir daugiau vaikų;
11.6.5. vaikams, kuriuos augina vienas iš vaiko atstovų pagal įstatymą;
11.6.6. vaikams, kurių vienas iš vaiko atstovų pagal įstatymą turi pirmos ar antros grupės neįgalumą ar yra netekęs daugiau kaip 45–55 procentų darbingumo;
11.6.7. vaikams, kurių vienas iš vaiko atstovų pagal įstatymą yra dieninių ar nuolatinių studijų programų mokiniai/studentai, kurie mokosi pagal bendrojo ugdymo ar formaliojo profesinio ugdymo programas;
11.6.8. vaikams, kurių brolis ar sesuo jau lanko šią Mokyklą;
11.6.9. vaikams, kurių vienas iš tėvų atlieka privalomąją pradinę karo tarnybą.
12. Šiuo metu priėmimo į Visagino savivaldybės neformaliojo švietimo įstaigas, nurodytas 9.11-9.13 papunkčiuose, tvarka:
12.1. Mokinys į Mokyklą priimamas pagal tėvų (įtėvių, globėjų, rūpintojų) (suaugusysis – jo paties) pateiktą prašymą Mokyklos direktoriui, kuriame xxxxxxxx:
12.1.1. xxxxxxx vardas ir pavardė,
12.1.2. gimimo data,
12.1.3. gyvenamoji vieta,
12.1.4. programos (-ų), kurią (-ias) mokinys nori lankyti, pavadinimas,
12.1.5. tėvų (įtėvių, globėjų, rūpintojų) (kai prašymą teikia suaugusysis – jo paties) adresas, telefonas, elektroninis paštas,
12.2. Prie prašymo pridedama:
12.2.1. asmens tapatybę patvirtinančio dokumento kopija,
12.2.2. sveikatos apsaugos ministro nustatytos formos mokinio sveikatos pažymėjimas, išduotas ne anksčiau kaip prieš metus (ar jo kopija / elektroninė pažyma),
12.2.3. dokumentai, patvirtinantys lengvatų taikymą (teikia mokiniai, turintys teisę gauti Visagino savivaldybės tarybos nustatytas lengvatas).
12.2.4. Jeigu mokinys (išskyrus suaugusįjį) atvyko iš kitos mokyklos, kur mokėsi pagal formalųjį švietimą papildančio ugdymo programą, prie prašymo prideda pažymą apie mokymosi pasiekimus ankstesnėje mokykloje toje pačioje ar artimoje pagal sritį programoje.
12.3. Prašymai dėl priėmimo į Mokyklą registruojami Prašymų registracijos knygoje (registre). Prašymų registravimą ir mokinių dokumentų priėmimą vykdo Mokyklos direktoriaus įgaliotas asmuo.
12.4. Mokinių priėmimas į Mokyklą įforminamas Mokyklos direktoriaus įsakymu ir dvišale mokymo sutartimi, kurioje nurodoma: sutarties šalys, mokymosi programa(-os), forma, šalių įsipareigojimai, sutarties terminas, sutarties keitimo, nutraukimo pagrindai ir padariniai. Sutartis sudaroma dviem egzemplioriais – po vieną kiekvienai sutarties šaliai. Ji registruojama Mokymo sutarčių registracijos knygoje (registre).
12.5. Priimtas į Mokyklą mokinys įrašomas į Mokinių registro duomenų bazę (išskyrus suaugusiuosius).
13. Šiuo metu ugdymo įstaigos savo veikloje nenaudoja programinių priemonių, automatizuojančių priėmimo į ugdymo įstaigas procesus. Kai kurios ugdymo įstaigos naudoja programines priemones, kurios automatizuoja tik nedidelę dalį priėmimo į ugdymo įstaigas procesų, tačiau nėra vieningos sistemos, užtikrinančios bendrų funkcijų automatizavimą ir procesų įgyvendinimui bei funkcijų automatizavimui reikalingus duomenų mainus.
6. REIKALAVIMAI BDMS SUKŪRIMUI
14. Šiame skyriuje pateikiama BDMS funkcinė architektūra. Galutinė architektūra gali būti tikslinama ir turi būti suderinta su Perkančiąja organizacija detalios analizės ir / ar projektavimo etapo metu.
8 | 38
6.1 pav. Funkcinės architektūros schema
9 | 38
6.1 lentelė. Funkcinės architektūros komponentų aprašymas
Komponentas | Aprašymas |
Išorinio naudojimo modulis | |
Prašymų teikimo ir peržiūros modulis | Modulis skirtas Išorinio naudojimo modulio identifikuotiems ir autentifikuotiems naudotojams (tėvams, globėjams) pildyti ir teikti prašymus priimti vaiką į formaliojo / neformaliojo švietimo įstaigas, peržiūrėti pateiktų prašymų informaciją, tikslinti prašymuose pateiktus duomenis ir kt. |
Sutarčių sudarymo modulis | Modulis skirtas Išorinio naudojimo modulio identifikuotiems ir autentifikuotiems naudotojams (tėvams, globėjams) sudaryti mokymo sutartis pagal pateiktus ir patenkintus prašymus, apimant sutarties pasirašymą, keitimą ir nutraukimą. |
Skundų teikimo modulis | Modulis skirtas Išorinio naudojimo modulio identifikuotiems ir autentifikuotiems naudotojams (tėvams, globėjams) teikti skundus, užpildant skundo formą. |
Turinio valdymo modulis | Modulis skirtas Išorinio naudojimo modulio administratoriams, turintiems reikalingas teises, tvarkyti Išorinio naudojimo modulyje pateikiamą informaciją (naujienas, teisės aktus, DUK ir kt.). |
Viešosios informacijos modulis | Modulis skirtas pasiekti Išorinio naudojimo modulyje pateikiamą informaciją (naujienas, teisės aktus, DUK ir kt.), kuri bus valdoma turinio valdymo modulio priemonėmis. |
Vidinio naudojimo modulis | |
Prašymų administravimo modulis | Modulis skirtas Vidinio naudojimo modulio identifikuotiems ir autentifikuotiems naudotojams (savivaldybės administracijos, švietimo įstaigų darbuotojams) vykdyti prašymų administravimą – peržiūrėti pateiktus prašymus, įvesti naujus prašymus, grąžinti prašymus tikslinimui, priimti pateiktus prašymus ir kt. |
Sutarčių administravimo modulis | Modulis skirtas Vidinio naudojimo modulio identifikuotiems ir autentifikuotiems naudotojams (savivaldybės administracijos, švietimo įstaigų darbuotojams) vykdyti sutarčių administravimą – peržiūrėti suformuotas, sudarytas sutartis, pasirašyti sutartis, vykdyti sutarčių keitimą ir nutraukimą. |
Sistemos administravimo modulis | Modulis skirtas Vidinio naudojimo modulio administratoriams, turintiems reikalingas teises, valdyti eilių/grupių sudarymo algoritmą, sistemos parametrus, tvarkyti naudotojus ir jų teises, klasifikatorius ir jų reikšmes. |
Ataskaitų modulis | Modulis skirtas Vidinio naudojimo modulio darbuotojams formuoti pasirinktas ataskaitas pagal nurodytus kriterijus, atsisiųsti suformuotas ataskaitas. |
Duomenų mainų komponentas | Komponentas skirtas vykdyti duomenų mainus su išorinėmis sistemomis ir registrais. |
BDMS išorinio naudojimo modulio DB – duomenų bazė, skirta Išorinio naudojimo modulio duomenų saugojimui. | |
BDMS vidinio naudojimo modulio DB – duomenų bazė, skirta Vidinio naudojimo modulio duomenų saugojimui. | |
Išorinės sistemos ir registrai | |
VIISP | VIISP skirtas BDMS naudotojų (Išorinio ir Vidinio naudojimo modulių) autentifikavimui. Taip pat iš VIISP bus gaunami duomenys apie pateiktus prašymus užregistruoti vaiką į ikimokyklinio ugdymo įstaigą, o į VIISP teikiama informacija apie prašymo būsenų pasikeitimus, pranešimus ir kt. |
GR | Gyventojų registras (GR), iš kurio bus gaunami duomenys apie šeimos sudėtį (mokinių asmens duomenys (vardas, pavardė, asmens kodas, gimimo data ir kt.), tėvų (globėjų) asmens duomenys (vardas, pavardė, asmens kodas ir kt.)) bei deklaruotą gyvenamąją vietą. |
Mokinių registras | Mokinių registras, iš kurio bus gaunami mokinio duomenys ir teikiami duomenys apie sudarytas mokymo sutartis. |
ESPBI IS | ESPBI IS, iš kurios bus gaunami vaiko sveikatos pažymėjimo duomenys. |
NDNT IS | Neįgalumo ir darbingumo nustatymo tarnybos IS, iš kurios bus gaunami neįgalumo pažymos apie vaiką ir šeimos narius duomenys. |
15. BDMS naudos šie naudotojai:
15.1. vidinio naudojimo modulio naudotojai:
15.1.1. ugdymo įstaigų darbuotojai;
15.1.2. Perkančiosios organizacijos darbuotojai;
15.2. išorinio naudojimo modulio naudotojai:
15.2.1. mokinių tėvai (globėjai);
15.2.2. administratoriai.
16. Reikalavimai naudotojų prisijungimui prie BDMS:
16.1. Turi būti galima prisijungti (identifikuotis) prie BDMS Išorinio naudojimo modulio su naudotojo duomenimis:
16.1.1. Prisijungimui (identifikacijai) turi būti naudojamas VIISP prisijungimo komponentas.
16.2. Turi būti galima prisijungti (identifikuotis) prie BDMS Vidinio naudojimo modulio su naudotojo duomenimis:
16.2.1. Prisijungimui (identifikacijai) turi būti naudojamas VIISP prisijungimo komponentas.
16.2.2. Administratorių prisijungimui turi būti naudojamas prisijungimo vardas ir slaptažodis. Turi būti galimybė keisti slaptažodį.
17. Turi būti realizuotas funkcionalumas, kuris, įvykus BDMS tam tikriems įvykiams, automatiškai turi išsiųsti sisteminius pranešimus apie įvykusį įvykį ar reikiamus atlikti veiksmus. Apie kiekvieną išsiųstą sisteminį pranešimą el. paštu turi būti informuojamas atitinkamas naudotojas. BDMS administravimo priemonėmis turi būti galima keisti siunčiamo pranešimo turinį bei turi būti galima išjungti pranešimo siuntimą.
17.1. Turi būti kuriami sisteminiai pranešimai ar užduotys BDMS naudotojams, kurie yra susiję su įvykiu, pavyzdžiui, pranešimas apie:
17.1.1. pateiktą prašymą;
17.1.2. pateikto prašymo tikslinimą (prašymą patikslinti);
17.1.3. pateikto prašymo registravimą;
17.1.4. Mokinio įtraukimą į ugdymo įstaigos sąrašus;
17.1.5. kvietimą sudaryti sutartį;
17.1.6. sutarties pasirašymą;
17.1.7. sutarties keitimą;
17.1.8. kiti su Perkančiąja organizacija suderinti pranešimai.
17.2. Detalios analizės ir projektavimo etape turi būti identifikuoti momentai, kuriais reikia formuoti ir siųsti pranešimus, bei gavėjai, kuriems reikia juos išsiųsti.
17.3. BDMS naudotojai turi galėti peržiūrėti gautų sisteminių pranešimų sąrašą.
18. Visos BDMS formos kiek įmanoma turi būti automatizuotai užpildomos duomenimis, kurie yra saugomi BDMS ar kitose per integracines sąsajas pasiekiamose informacinėse sistemose ir registruose. Naudotojui turi reikėti įvesti tik unikalią, BDMS iš anksto nežinomą informaciją.
19. Visoms šioje specifikacijoje aprašytoms funkcijoms, kurių metu yra sukuriami duomenys ar dokumentai, turi būti realizuojamos tų duomenų ar dokumentų redagavimo bei šalinimo funkcijos, kurios turi būti suderinamos su veiklos logika. Išimtys gali būti taikomos suderinus sprendimą su Perkančiąją organizacija.
20. Turi būti galima kiekvieną BDMS sąrašą spausdinti bei eksportuoti į PDF, DOCX, XLSX ar lygiavertes rinkmenas. Išimtys gali būti taikomos suderinus sprendimą su Perkančiąją organizacija.
21. Turi būti galima kiekvieną BDMS sąrašą filtruoti pagal tam sąrašui priklausančius atributus. Išimtys gali būti taikomos suderinus sprendimą su Perkančiąją organizacija.
22. BDMS sąrašuose turi būti atvaizduojamas įrašų sąraše skaičius. Atlikus sąrašo filtravimą turi būti vaizduojamas rastų įrašų skaičius.
23. Jei detalios analizės ar projektavimo metu identifikuojamas poreikis BDMS atvaizduoti šioje techninėje specifikacijoje neaprašytus papildomus sąrašus, Paslaugų teikėjas juos turi realizuoti, jei BDMS yra kaupiami sąrašų atvaizdavimui reikalingi duomenys.
24. BDMS formos turi būti konstruojamos taip, kad duomenų įvedimas būtų kiek įmanoma labiau struktūrizuotas, o dokumentai generuojami struktūrizuotų duomenų pagrindu. Turi būti kuriami ir naudojami klasifikatoriai.
25. BDMS sąrašuose turi būti realizuotas daugelio įrašų pažymėjimo funkcionalumas tam tikrų veiksmų atlikimui (pvz., eksportavimui, šalinimui, pasirašymui pasirinktų įrašų). Detalios analizės ar projektavimo etape turi būti suderinta, kuriuose sąrašuose turi būti leidžiamas daugelio įrašų pažymėjimas.
26. Turi būti realizuotas pagalbinės informacijos (angl. hints) funkcionalumas – naudotojams turi būti pateikiami paaiškinamieji pranešimai tose BDMS vietose, kuriose gali kilti neaiškumų siekiant suprasti reikalingus atlikti veiksmus (pvz., pateikiamas paaiškinimas, kokius duomenis reikia įvesti į tam tikrą dokumento / prašymo lauką). Detalios analizės ar projektavimo etapo metu turi būti identifikuotos vietos, kuriose turi būti pateikiami paaiškinamieji pranešimai.
27. Turi būti realizuotas prašymų, sutarčių ir kitų esybių būsenų priskyrimas ir būsenų atvaizdavimas pagal nustatytas veiklos taisykles. Būsenos turi būti suteikiamos automatiškai.
28. Turi būti vykdomas į BDMS formas įvedamų duomenų tikrinimas (angl. validation) pagal detalios analizės ir projektavimo metu formoms nustatytas tikrinimo taisykles:
28.1. Turi būti tikrinami privalomi įvesti duomenys;
28.2. Turi būti tikrinamas duomenų formatas (datos, skaičiaus, teksto ar kitas nustatytas taisykles);
28.3. Turi būti tikrinami pridedamų rinkmenų plėtiniai ir rinkmenos dydis;
28.4. Turi būti atliekamas loginis tikrinimas tarp formos elementų – vieno formos elemento parinkimas (įvedimas) turi galėti įjungti / išjungti kitus formos elementus ir pan.
6.3.2 Reikalavimai vidinio naudojimo moduliui
29. Reikalavimai prašymų administravimo funkcionalumui:
29.1. Turi būti sukurtas administravimo modulis, skirtas tėvų (globėjų) pateiktų prašymų priimti vaiką į formaliojo / neformaliojo švietimo įstaigas administravimui.
29.2. Turi būti galima peržiūrėti prašymų sąrašą. Sąraše turi būti pateikiami:
29.2.1. per Išorinio naudojimo modulį pateikti prašymai;
29.2.2. per VIISP pateikti prašymai;
29.2.3. Vidinio naudojimo modulyje įvesti prašymai.
29.3. Sąrašuose pateikiami duomenys turi būti suderinti su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
29.4. Ugdymo įstaigos naudotojai pagal turimas teises turi matyti ir administruoti savo prašymų sąrašą. Visų ugdymo įstaigų prašymus turi būti galima peržiūrėti tokias teises turintiems BDMS naudotojams.
29.5. Turi būti galima atlikti prašymų paiešką / filtravimą pagal su Perkančiąja organizacija suderintus kriterijus.
29.6. Turi būti galima peržiūrėti pasirinktą prašymą. Inicijuojant prašymo peržiūrą turi būti atveriama detali prašymo informacija, apimant ir prašymo nagrinėjimo būsenų istoriją.
29.7. Vidinio naudojimo modulio naudotojai turi galėti įvesti naują prašymą (tais atvejais, kai tėvai (globėjai) teikia popierinį prašymą). Paslaugų teikėjas turi realizuoti prašymų priimti vaiką į Visagino savivaldybės neformaliojo / formaliojo švietimo įstaigas įvedimo formas. Prašymo formos ir jų duomenys turi būti suderinti su Perkančiąja organizacija.
29.7.1. Prašymo formoje dalis duomenų turi užsipildyti automatiškai iš kitų sistemų / registrų gautais duomenimis (pvz., prašymo teikėjo vardas, pavardė, deklaruota gyvenamoji vieta ir kt.). Detalios analizės ar projektavimo etapų metu turi būti suderinti automatiškai užpildomi duomenų laukai su Perkančiaja organizacija.
29.7.2. Prašymo pildymo metu turi būti leidžiama pasirinkti vieną ugdymo įstaigą, kuriai teikiamas prašymas.
29.7.3. Prie pildomo prašymo turi būti galima prisegti papildomus dokumentus.
29.8. Turi būti galima išsaugoti prašymą vėlesniam pildymui ir pateikimui.
29.9. Turi būti galima patvirtinti (užregistruoti) pateiktą prašymą.
29.9.1. Pateikti prašymai turi būti registruojami automatiškai ir (ar) rankiniu būdu. Detalios analizės ir projektavimo etapų metu su Perkančiąja organizacija turi būti suderintos taisyklės, kuriais atvejais prašymai bus užregistruojami automatiškai, o kuriais reikalingas Vidinio naudojimo modulio naudotojo patvirtinimas.
29.10. Visi užregistruoti prašymai turi būti priskiriami į ugdymo įstaigos prašymų registracijos eilę.
29.10.1. Prašymų registracijos eilių sudarymas turi būti atliekamas atsižvelgiant į eilės sudarymo algoritmą, kuris administruojamas BDMS priemonėmis.
29.11. Prašymus turi būti galima teikti iki BDMS parametruose nurodyto termino. Po nurodyto termino pateikti prašymai turi būti registruojami į ateinančių mokslo metų prašymų registracijos eilę. Išimtys gali būti taikomos su Perkančiąja organizacija suderintais atvejais (pvz., neformaliojo ugdymo įstaigų atveju).
29.12. Turi būti galima peržiūrėti prašymų registracijos eiles:
29.12.1. Eilių peržiūrą turi būti galima atlikti pagal pagal ugdymo įstaigas ir kitus duomenis, suderintus su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
29.13. Turi būti galima tikslinti (koreguoti) prašymų duomenis. Leidžiami koreguoti duomenys ir koregavimo momentai turi būti suderinti su Perkančiąja organizacija.
29.14. Turi būti galima šalinti prašymus. Šalinimo momentai turi būti suderinti su Perkančiąja organizacija.
29.15. Vidinio naudojimo modulio naudotojai turi galėti grąžinti prašymus tikslinimui.
29.15.1. Turi būti galima įvesti priežastis, dėl kurių prašymas grąžinamas tikslinti.
29.15.2. Duomenys apie grąžintus tikslinti prašymus turi būti perduodami į Išorinio naudojimo modulį.
29.16. Turi būti atliekamas atsakingų asmenų (prašymo teikėjo, už prašymo nagrinėjimą atsakingo asmens ir kt.) informavimas apie prašymų būsenų pasikeitimus (priimtas, grąžintas tikslinti, atmestas ir pan.).
29.16.1. Turi būti sukurtas informavimo mechanizmas, užtikrinantis, kad informuojamas bus atsakingas asmuo pagal jo turimas roles (pvz., ugdymo įstaigos specialistas bus informuojamas apie tai ugdymo įstaigai pateiktus prašymus ir pan.). Informavimo mechanizmo veikimas turi būti suderintas su Perkančiąja organizacija.
29.16.2. Informavimas turi būti atliekamas šiais būdais:
29.16.2.1. jei prašymas teiktas per VIISP, duomenys per integracinę sąsają turi būti perduodami į VIISP;
29.16.2.2. jei prašymas teiktas per Išorinio naudojimo modulį / įvestas Vidinio naudojimo modulyje, turi būti informuojamas el. laišku ir sisteminiu pranešimu.
29.17. Prašymų duomenų pasikeitimai Vidinio naudojimo modulyje turi atsispindėti Išorinio naudojimo modulyje ir atvirkščiai.
29.17.1. Atliekant veiksmus (registruojant, grąžinant tikslinti ir pan.) su per VIISP pateiktais prašymais (užregistruoti vaiką į ikimokyklinio ugdymo įstaigą) duomenų pasikeitimai (būsenos, pranešimai ir kt.) per integracinę sąsają turi būti perduodami į VIISP.
29.18. Turi būti galima peržiūrėti priimamų / priimtų vaikų sąrašus:
29.18.1. Priimamų / priimtų vaikų sąrašai turi būti sudaromi automatiškai pagal prašymų / sutarčių duomenis.
29.18.2. Sąrašuose turi būti galima filtruoti / atlikti paiešką pagal ugdymo įstaigas ir kitus duomenų laukus, suderintus su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
30. Reikalavimai sutarčių administravimo funkcionalumui:
30.1. Turi būti sukurtas sutarčių administravimo modulis, skirtas sutarčių sudarymui ir valdymui.
30.2. Turi būti galima peržiūrėti sutarčių sąrašus.
30.2.1. Sutarčių sąrašai turi būti automatiškai sukuriami atsižvelgiant į užregistruotų prašymų duomenis. Sutarčių sąrašų formavimo taisyklės ir momentai turi būti suderinti su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
30.2.2. Ugdymo įstaigos naudotojai pagal turimas teises turi matyti ir administruoti savo sutarčių sąrašą. Visų ugdymo įstaigų sutartis turi būti galima peržiūrėti tokias teises turintiems BDMS naudotojams.
30.2.3. Sąrašuose pateikiami duomenys turi būti suderinti su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
30.3. Turi būti galima atlikti sutarčių paiešką / filtravimą pagal su Perkančiąja organizacija suderintus kriterijus.
30.4. Turi būti galima peržiūrėti pasirinktą sutartį. Inicijuojant sutarties peržiūrą turi būti atveriama detali sutarties informacija, apimant ir sutarties pasikeitimų būsenų istoriją.
30.5. Ugdymo įstaigos naudotojas, turintis reikiamas teises BDMS, turi galėti sudaryti (pasirašyti) sutartį.
30.5.1. Sutarčių formos turi būti generuojamos atsižvelgiant į ugdymo įstaigos sutarties šabloną, t. y. kiekviena ugdymo įstaiga BDMS gali naudoti savo sutarties šabloną.
30.5.2. Paslaugų teikėjas turi parengti pradines sutarčių šablonų formas. Formų struktūra turi būti suderinta su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
30.5.3. Prie pasirašomos sutarties / sutarčių turi būti galima pridėti dokumentus arba įvesti papildomą informaciją (pvz., direktoriaus įsakymo numerį).
30.5.4. Sugeneruotą sutartį / sutartis turi būti galima pasirašyti sisteminiu parašu.
30.6. Turi būti galima šalinti sutartis. Šalinimo momentai turi būti suderinti su Perkančiąja organizacija.
30.7. Turi būti galima keisti sudarytą (pasirašytą) sutartį, nurodant keitimo priežastį ir norimus pakeitimus.
30.7.1. Sutarties keitimą gali inicijuoti ugdymo įstaiga ir (arba) Mokinio tėvai (globėjai).
30.7.2. Sutarties keitimo veiksmas turi būti patvirtintas sisteminiu parašu.
30.7.3. Turi būti galima patvirtinti / atmesti tėvų (globėjų) inicijuotą sutarties keitimą (tikslinimą). Atmetimo atveju turi būti galima nurodyti priežastis.
30.8. Turi būti galima sutartį ar jos pakeitimą nutraukti, nurodant nutraukimo priežastis.
30.8.1. Turi būti galima pažymėti, kad sutarties nutraukimui reikalingas tėvų (globėjų) patvirtinimas. Pagal nutylėjimą sutarčių nutraukimui neturi būti reikalingas tėvų (globėjų) patvirtinimas.
30.8.2. Sutarties nutraukimo veiksmas turi būti patvirtintas sisteminiu parašu.
30.8.3. Turi būti galima patvirtinti / atmesti tėvų (globėjų) inicijuotą sutarties nutraukimą. Atmetimo atveju turi būti galima nurodyti priežastis.
30.9. Turi būti atliekamas atsakingo asmens (prašymo teikėjo, už sutarties sudarymą atsakingo asmens ir kt.) informavimas apie sutarčių būsenų pasikeitimus (sugeneruota, inicijuotas keitimas ir pan.).
30.9.1. Turi būti sukurtas informavimo mechanizmas, užtikrinantis, kad informuojamas bus atsakingas asmuo pagal jo turimas roles (pvz., ugdymo įstaigos specialistas bus informuojamas apie tai ugdymo įstaigai pateiktus prašymus ir pan.). Informavimo mechanizmo veikimas turi būti suderintas su Perkančiąja organizacija.
30.9.2. Informavimas turi būti atliekamas el. laišku ir sisteminiu pranešimu.
30.10. Turi būti automatiškai perduodami sudarytų, patikslintų ir nutrauktų sutarčių duomenys į Mokinių registrą. Duomenų perdavimo funkcionalumo veikimas turi būti suderintas su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
30.11. Sutarčių duomenų pasikeitimai Vidinio naudojimo modulyje turi atsispindėti Išorinio naudojimo modulyje ir atvirkščiai.
31. Reikalavimai ataskaitų funkcionalumui:
31.1. Turi būti galima formuoti ataskaitas pagal BDMS saugomus duomenis. Turi būti galima formuoti šias ataskaitas (sąrašas preliminarus ir gali būti tikslinamas analizės metu):
31.1.1. mokinių skaičius (1-4, 5-8, 9-12, 9-10 klasėse);
31.1.2. mergaičių ir berniukų mokinių skaičius;
31.1.3. bendras vaikų skaičius ir kt.
31.2. Paslaugos teikėjas turi realizuoti aukščiau reikalavime nurodytas ataskaitas, o taip pat kitas detalios analizės ir projektavimo etapų metu Perkančiosios organizacijos identifikuotas ataskaitas (bendras visų ataskaitų skaičius turi būti ne daugiau nei 10), jei toks poreikis bus išreikštas.
31.3. Kiekviena ataskaita turi būti formuojama pagal vartotojo nurodytus kriterijus (pvz., laikotarpį, ugdymo įstaigą ar kt.), suderintus detalios analizės ar projektavimo etapo metu.
31.4. Ataskaitų formavimo kriterijai, turinys ir forma turi būti suderinti detalios analizės ir projektavimo etapų metu.
31.5. Ataskaitos turi būti suformuojamos XLXS, PDF ar lygiaverčiais formatais, kuriuos sistema gebės atpažinti (dokumentų formatai turi būti suderinti su Perkančiąja organizacija detaliosios analizės metu).
31.6. Turi būti galima atsisiųsti suformuotas ataskaitas į kompiuterį.
32. Reikalavimai BDMS administravimo funkcionalumui:
32.1. Turi būti galima tvarkyti BDMS klasifikatorius.
32.1.1. Redaguoti esamų klasifikatorių reikšmes;
32.1.2. Įvesti naujas esamų klasifikatorių reikšmes;
32.1.3. Šalinti (padaryti nenaudojamais) esamas klasifikatoriaus reikšmes.
32.1.4. Paslaugų teikėjas turi įvesti (importuoti, sukurti ar pan.) visus klasifikatorius, kurie bus identifikuoti detalios analizės ar projektavimo etape.
32.2. Turi būti galima administruoti BDMS naudotojus.
32.2.1. Turi būti galima tvarkyti naudotojų teises ir roles.
32.2.2. Turi būti galima kurti, redaguoti ir šalinti naudotojus, blokuoti naudotojų prisijungimą prie BDMS.
32.2.3. Paslaugų teikėjas turi sudaryti BDMS naudotojų rolių ir teisių rinkinius.
32.3. Turi būti galima administruoti įvairius BDMS parametrus.
32.3.1. Turi būti galima keisti sisteminius parametrus (nustatytus prašymų teikimo terminus, reikšmes pagal nutylėjimą ir pan.). Detali administruojamų parametrų imtis turi būti nustatyta detalios analizės ir projektavimo etape.
32.4. Turi būti galima administruoti ugdymo įstaigų ir jų specialistų sąrašus.
32.4.1. Turi būti galima kurti naujas, redaguoti ir šalinti esamas ugdymo įstaigas ir specialistus.
32.4.2. Turi būti galima priskirti ugdymo įstaigoms specialistus.
32.4.3. Turi būti galima priskirti ugdymo įstaigoms el. pašto adresus, kuriais būtų siunčiami Išorinio naudojimo modulyje pateikti skundai / klausimai.
32.5. Turi būti galima administruoti ugdymo įstaigos sutarčių šablonus.
32.5.1. Turi būti galima redaguoti sutarčių šablonus. Redagavimą gali atlikti reikiamas teises BDMS turintys naudotojai.
32.5.2. BDMS administratorius turi galėti kurti naujus sutarties šablonus, redaguoti ir šalinti esamus šablonus, priskirti šablonus ugdymo įstaigoms.
32.6. Turi būti galima administruoti ugdymo įstaigų grupes.
32.6.1. Turi būti galima atlikti šiuos veiksmus:
32.6.1.1. įvesti naujas grupes;
32.6.1.2. redaguoti esamų grupių duomenis;
32.6.1.3. šalinti esamas grupes;
32.6.1.4. nurodyti maksimalų grupių dydį (vaikų skaičių);
32.6.1.5. priskirti grupei atsakingą specialistą.
32.6.2. Turi būti galima priskirti grupėms į ugdymo įstaigas priimtus vaikus.
32.6.2.1. BDMS naudotojams turi būti galima matyti ugdymo grupių užimtumą (laisvas vietas).
32.6.3. Detalus ugdymo įstaigų grupių administravimo funkcionalumas turi būti suderintas su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu.
32.7. BDMS turi vykdyti objektų (prašymų, sutarčių ir kt.) archyvavimą pagal apibrėžtas taisykles. Archyvuojamų duomenų taisyklės turi būti sudarytos detalios analizės ir projektavimo etape.
32.7.1. Archyvuojami duomenys turi būti iš BDMS duomenų bazės perkeliami į archyvavimo duomenų bazę (ar archyvavimo duomenų bazių lenteles).
32.7.2. Suarchyvuoti duomenys nebeturi būti atvaizduojami ar kitaip naudojami BDMS.
32.7.3. Turi būti realizuotos funkcijos, kurios turi leisti atlikti archyvinių duomenų paiešką ir peržiūrą. Detalios analizės ir projektavimo metu turi būti nustatytas poreikis duomenų paieškos galimybėms bei jų peržiūrai.
33. Reikalavimai prašymų registracijos eilių sudarymo algoritmui.
33.1. Registracijos eilės turi būti sudaromos automatiškai atsižvelgiant į tėvų (globėjų) pateiktų prašymų duomenis.
33.2. Turi būti realizuotos prašymų registracijos eilės kiekvienai ugdymo įstaigai atskirai.
33.3. Registracijos eilės turi būti sudaromos atsižvelgiant į:
33.3.1. prašymo pateikimo (registravimo) datą:
33.3.1.1. jei tą pačią dieną užregistruoti du vaikai su vienodais prioritetais, eilė skaičiuojama atsižvelgiant į prašymo registravimo laiką;
33.3.1.2. lyginant pateiktų tėvų (globėjų) prašymo registravimo datas ir pageidaujamas lankymo datas, pirmenybė suteikiama anksčiau užsiregistravusiam;
33.3.1.3. jei tėvų (globėjų) pateikti prašymai nėra patenkinami pageidaujamai datai, prašymai turi būti automatiškai perkeliami į kitų mokslo metų eilę.
33.3.2. pirmumo teisę suteikiančius kriterijus (pvz., asmens deklaruota gyvenamoji vieta yra Visagino savivaldybėje ir kt.);
33.4. Registracijos eilių sudarymo kriterijai turi būti administruojami BDMS priemonėmis. Turi būti galima keisti kriterijus – sukeisti vietomis, įtraukti naujus, koreguoti, šalinti esamus.
33.5. BDMS administravimo priemonėmis turi būti galima valdyti į ugdymo įstaigą priimamų vietų skaičių. Laisvų vietų skaičiaus funkcionalumo veikimas turi būti suderintas su veiklos logika (pvz., neleisti sudaryti daugiau sutarčių nei yra nustatyta vietų ir pan.) ir suderintas su Perkančiąja organizacija.
33.6. BDMS administratoriui turi būti galima koreguoti registracijos eiles, t. y. įterpti, keisti, pašalinti prašymą tam tikros ugdymo įstaigos eilėje.
33.7. Jei pateiktame prašyme yra pakeičiama ugdymo įstaiga, turi būti perskaičiuojama registracijos eilė, o vieta registracijos eilėje į buvusią įstaigą turi būti atlaisvinama.
33.8. Jei tėvų (globėjų) pageidaujamose ugdymo įstaigose laisvų vietų nėra, turi būti galima pateikti prašymą į kitą ugdymo įstaigą, kurioje yra laisvų vietų.
33.8.1. Gavus vietą ugdymo įstaigoje, prašymas registracijos eilėje į pageidautą ugdymo įstaigą turi likti.
6.3.3 Reikalavimai išorinio naudojimo moduliui
34. Reikalavimai prašymų teikimo ir peržiūros funkcionalumui:
34.1. Turi būti sukurtas prašymų teikimo ir peržiūros modulis, skirtas tėvams (globėjams) pildyti ir teikti prašymus priimti vaiką į formaliojo / neformaliojo švietimo įstaigas, peržiūrėti pateiktų prašymų informaciją, tikslinti prašymuose pateiktus duomenis ir kt.
34.2. Modulyje turi būti galima peržiūrėti mano (naudotojo) pateiktų prašymų sąrašą. Sąraše turi būti pateikiami:
34.2.1. per Išorinio naudojimo modulį pateikti prašymai;
34.2.2. per VIISP pateikti prašymai;
34.2.3. Vidinio naudojimo modulyje įvesti prašymai, kurie buvo pateikti popieriniu būdu.
34.3. Naudotojui turi būti rodoma informacija apie pateikto prašymo vietą ugdymo įstaigos registracijos eilėje.
34.4. Turi būti galima peržiūrėti pasirinktą prašymą. Inicijuojant prašymo peržiūrą turi būti atveriama detali prašymo informacija, apimant ir prašymo nagrinėjimo būsenų istoriją.
34.5. Išorinio naudojimo modulio naudotojai turi galėti pildyti pasirinktą prašymą. Prašymų formos turi atitikti Vidinio naudojimo modulyje Paslaugų teikėjo realizuotas prašymų priimti vaiką į Visagino savivaldybės neformaliojo / formaliojo švietimo įstaigas įvedimo formas.
34.5.1. Prašymo formoje dalis duomenų turi užsipildyti automatiškai iš kitų sistemų / registrų gautais duomenimis (pvz., prašymo teikėjo vardas, pavardė, deklaruota gyvenamoji vieta ir kt.). Detalios analizės
ar projektavimo etapų metu turi būti suderinti automatiškai užpildomi duomenų laukai su Perkančiaja organizacija.
34.5.2. Prašymo pildymo metu turi būti leidžiama pasirinkti vieną ugdymo įstaigą, kuriai teikiamas prašymas.
34.5.3. Prie pildomo prašymo turi būti galima prisegti papildomus dokumentus.
34.6. Turi būti galima pateikti užpildytą prašymą. Pateiktų prašymų duomenys turi būti perduodami į Vidinio naudojimo modulį.
34.6.1. Teikiami prašymai turi būti pasirašomi sisteminiu parašu.
34.6.2. Prašymus turi būti galima teikti iki BDMS parametruose nurodyto termino. Po nurodyto termino pateikti prašymai turi būti registruojami į ateinančių mokslo metų prašymų registracijos eilę. Išimtys gali būti taikomos su Perkančiąja organizacija suderintais atvejais (pvz., neformaliojo ugdymo įstaigų atveju).
34.7. Turi būti galima išsaugoti prašymą vėlesniam pildymui ir pateikimui.
34.8. Turi būti galima tikslinti (koreguoti) prašymo duomenis. Leidžiami koreguoti duomenys, koregavimo terminai ir koregavimo pasekmės turi būti suderinti su Perkančiąja organizacija.
34.8.1. Atliekant prašymo duomenų tikslinimą naudotojas turi būti įspėjamas apie tikslinimo pasekmes (pvz., gali pasikeisti prašymo vieta registracijos eilėje).
34.9. Turi būti galima atšaukti pateikus prašymus. Atšaukimo momentai turi būti suderinti su Perkančiąja organizacija.
35. Reikalavimai sutarčių sudarymo funkcionalumui:
35.1. Turi būti sukurtas sutarčių tvarkymo modulis, skirtas sutarčių sudarymui.
35.2. Modulyje turi būti galima peržiūrėti mano (naudotojo) sutarčių sąrašą.
35.3. Turi būti galima peržiūrėti pasirinktą sutartį. Inicijuojant sutarties peržiūrą turi būti atveriama detali sutarties informacija, apimant ir sutarties pasikeitimų / nutraukimo būsenų istoriją.
35.4. Turi būti galimybė sudaryti sutartį pagal ugdymo įstaigos sutarties šabloną.
35.4.1. Sutarčių formos turi būti automatiškai sugeneruojamos atėjus nustatytam terminui pagal BDMS patvirtintų (užregistruotų) prašymų duomenis (sutarties šalis, mokinį, sąlygas ir kt.).
35.4.2. Sutarčių formos turi būti generuojamos atsižvelgiant į ugdymo įstaigos sutarties šabloną, t. y. kiekviena ugdymo įstaiga BDMS gali naudoti savo sutarties šabloną.
35.4.3. Sugeneruotą sutartį turi būti galima pasirašyti sisteminiu parašu.
35.4.4. Turi būti galima nepasirašyti sugeneruotos sutarties.
35.5. Turi būti galima keisti sudarytą (pasirašytą) sutartį, nurodant keitimo priežastį ir norimus pakeitimus.
35.5.1. Sutarties keitimą gali inicijuoti ugdymo įstaiga ir (arba) Mokinio tėvai (globėjai).
35.5.2. Sutarties tikslinimo veiksmas turi būti patvirtintas sisteminiu parašu.
35.5.3. Turi būti galima patvirtinti / atmesti ugdymo įstaigos inicijuotą sutarties keitimą (tikslinimą). Atmetimo atveju turi būti galima nurodyti priežastis.
35.6. Turi būti galima sutartį ar jos pakeitimą nutraukti, nurodant nutraukimo priežastis.
35.6.1. Sutarties nutraukimo veiksmas turi būti patvirtintas sisteminiu parašu.
35.6.2. Turi būti galima peržiūrėti Vidinio naudojimo modulio naudotojų nutrauktų ir atmestų (dėl nutraukimo) sutarčių informaciją.
36. Reikalavimai skundų / klausimų teikimo funkcionalumui:
36.1. Išorinio modulio identifikuoti ir autentifikuoti naudotojai turi galėti užpildyti skundo / klausimo formos duomenis (vardas, pavardė, el. pašto adresas, telefono nr., skundo / klausimo tema, skundo / klausimo aprašymas ir kt.). Galutinė skundo / klausimo formos struktūra turi būti suderinta su Perkančiąja organizacija.
36.2. Turi būti galima pasirinkti ugdymo įstaigą, kuriai norima teikti skundą / klausimą.
36.3. Užpildytą skundą / klausimą turi būti galima pateikti. Skundas / klausimas turi būti išsiunčiamas BDMS parametruose nurodytu ugdymo įstaigos el. pašto adresu.
37. Reikalavimai turinio valdymo komponentui (TVS):
37.1. BDMS išorinio naudojimo modulio puslapiai turi būti sukurti išlaikant vieningą struktūrą. Paslaugų teikėjas turi sudaryti priemones TVS pagalba Perkančiosios organizacijos darbuotojams susidėlioti Išorinio naudojimo modulio struktūrą.
37.1.1. TVS priemonėmis turi būti galima administruoti Išorinio naudojimo modulio turinį ir struktūrą.
37.1.2. Turi būti galima valdyti Išorinio naudojimo modulio puslapių blokus, jų elementus ir išdėstymą.
37.1.3. Turi būti galima kurti neriboto gylio puslapių struktūrą.
37.1.4. Turi būti sukurta galimybė maketuoti bet kurį Xxxxxxxx naudojimo modulio puslapį:
37.1.4.1. Kurti naujus puslapius.
37.1.4.2. Pakeisti aktualiausių informacijos blokų ir elementų padėtį ir informaciją juose.
37.1.4.3. Įkelti / panaikinti papildomus blokus ir elementus, koreguoti esamus.
37.1.4.4. Blokuose naudoti hierarchinį (iki trijų lygių) elementų pateikimą.
37.1.4.5. Galimybė blokuose įkelti paveikslėlius, video, nuorodas į kitas svetaines ir kt.
37.1.4.6. Sukurti ir koreguoti bet kurio portalo elemento pavadinimą (pvz. meniu punktas, antraštė, modulis).
37.1.4.7. Naikinti ir įtraukti naujus meniu punktus, keisti juos vietomis (išdėstymo tvarką).
37.1.5. Pradinę Išorinio naudojimo modulio puslapių struktūrą turi parengti Paslaugų teikėjas, ją suderinęs su Perkančiąja organizacija analizės ir projektavimo etapų vykdymo metu.
37.1.6. Išorinio naudojimo modulis turi būti realizuotas lietuvių kalba.
37.2. Reikalavimai TVS administravimo ir valdymo priemonėms:
37.2.1. TVS administravimo ir valdymo priemonės turi būti prieinamos per atskirą administravimo naudotojo sąsają.
37.2.2. Prisijungimui prie TVS turi būti naudojamas naudotojo vardas ir slaptažodis.
37.2.3. Prieiga prie TVS turi būti ribojama ir valdoma.
37.2.4. TVS valdymas ir konfigūravimas vykdomas interneto naršyklės pagalba ir turi būti paremtas tik interneto naršyklės naudotojo sąsaja.
37.2.5. Turi būti galima valdyti (įvesti, atnaujinti, šalinti) Išorinio modulio turinį nenaudojant HTML kalbos žinių (išskyrus su Perkančiąja organizacija suderintus komponentus).
37.2.6. Turi būti galima vykdyti paiešką / filtravimą / rikiavimą TVS esančiuose sąrašuose (pvz., naujienų) pagal su Perkančiąja organizacija analizės ir projektavimo etapų metu suderintus kriterijus.
37.2.7. Turi būti galima tvarkyti Išoriniame modulyje naudojamus klasifikatorius, klasifikatorių reikšmes, sisteminius parametrus, išvedamų rezultatų skaičius sąrašuose ir kitus parametrus, administruoti naudotojus.
37.3. TVS turi turėti tekstų stiliaus (CSS) redagavimo, peržiūros priemonę su teksto valdymo galimybėmis (redaguoti, šalinti, sukurti naujus stilius, keisti šriftą, dydį, spalvą, storį, lygiavimą, transformavimą).
37.4. Reikalavimai TVS teksto redaktoriui:
37.4.1. Teksto redaktorius turi veikti WYSIWYG principu (angl. What You See Is What You Get, liet. „tai, ką matote, atitinka tai, ką gausite“) arba analogišku.
37.4.2. Turi būti lentelių kūrimo, jų redagavimo ir lentelės bei jos langelių formatavimo funkcijos.
37.4.3. Turi būti įprastos teksto formatavimo funkcijos (lygiavimas, šrifto, jo stiliaus, dydžio, spalvos ir kitų parametrų valdymas).
37.4.4. Turi būti galimybė įkelti paveiksliuką, audio ir video failus.
37.4.5. Turi būti galimybė formatuoti įkeltą paveiksliuką, atliekant:
37.4.5.1. Lygiavimo keitimą.
37.4.5.2. Atstumo tarp eilučių/pastraipų nustatymą.
37.4.5.3. Apvado keitimą.
37.4.5.4. Teksto atstumo nuo paveiksliuko nustatymą.
37.4.5.5. Paveikslėlio dydžio keitimą.
37.4.6. Redaktorius turi automatiškai tikrinti pasirinktos kalbos rašybą ir neatitinkančius rašybos taisyklių žodžius pabraukti.
37.4.7. Redaktorius turi palaikyti lietuviškų simbolių palaikymą (kabutės, brūkšniai ir kt.) ir tinkamą jų atvaizdavimą.
37.4.8. Turi būti galimybė kurti įvairias nuorodas (į kitą puslapį, dokumentą, kitą svetainę, el. pašto adresą).
37.5. Turi būti sukurtas naujienų tvarkymo modulis, skirtas kurti, peržiūrėti, publikuoti, redaguoti, šalinti bei atlikti kitus su naujienomis susijusius veiksmus.
37.5.1. Turi būti galima kurti naujienas. Naujienos kūrimo metu turi būti galima nurodyti naujienos pavadinimą, turinį (aprašymą), publikavimo datą ir laiką, prioriteto požymį (jei pažymėtas, naujiena Išorinio modulio puslapyje bus atvaizduojama naujienų sąrašo viršuje), žymes (angl. tags) ir kitus su Perkančiąja organizacija analizės ir projektavimo etapų metu suderintus duomenų laukus.
37.5.2. Turi būti galima publikuoti naujienas Išoriniame modulyje. Publikavimas turi veikti šiais principais:
37.5.2.1. Naujienos turi būti publikuojamos atitinkamame Išorinio modulio puslapyje.
37.5.2.2. Turi būti išpublikuojamos tik naujienos su būsena „Publikuota“.
37.5.3. Išoriniame modulyje turi būti atvaizduojamos išpublikuotos naujienos. Pasirinkus naujieną turi būti atveriamas jos turinys peržiūrai.
37.5.3.1. Turi būti galima nurodyti naujienos publikavimo datą (data ir laikas), kuriai atėjus naujienos turi būti automatiškai išpublikuojamos Išoriniame modulyje.
37.5.4. Turi būti galima pasidalinti naujiena socialinio bendravimo interneto svetainėse (Facebook, LinkedIn, YouTube, Twitter).
37.5.5. Turi būti galima peržiūrėti naujienas. Sukurta naujiena turi būti išsaugoma naujienų sąraše, kuriame pateikiamas naujienos pavadinimas, publikavimo data, autorius, būsena ir kita su Perkančiąja organizacija analizės ir projektavimo etapų metu suderinta informacija.
37.5.5.1. Naujienų sąraše turi būti pateikiamos visos sukurtos naujienos surikiuotos pagal datą nuo naujausios iki seniausios.
37.5.6. Turi būti galima redaguoti naujienas:
37.5.6.1. Turi būti galima redaguoti naujienas, kurios nėra publikuotos Išorinio naudojimo modulyje. Jei naujiena yra publikuota Išorinio naudojimo modulyje, turi būti galima pakeisti naujienos būseną į
„Nepublikuota“ ir tuomet redaguoti naujienos atributus.
37.5.7. Turi būti galima šalinti naujienas.
37.5.8. Naujienų kūrimui ir redagavimui turi būti naudojamas teksto redaktorius, aprašytas aukščiau skyriuje.
37.6. Turi būti sukurtas funkcionalumas, leidžiantis administruoti dažniausiai užduodamų klausimų (toliau
– DUK) sąrašą.
37.6.1. Turi būti galima sukurti DUK įrašą. Kuriant įrašą turi būti nurodoma ši informacija:
37.6.1.1. Klausimas.
37.6.1.2. Atsakymas.
37.6.1.3. Klausimų grupė, kuriai priskiriamas kuriamas įrašas (darželiai, neformalioji švietimo įstaigos ir kt.).
37.6.1.4. Kiti su Perkančiąja organizacija analizės ir projektavimo etapų metu suderinti duomenys.
37.6.2. Turi būti galima sukurti klausimų grupę. Kuriant klausimų grupę turi būti nurodomas grupės pavadinimas.
37.6.3. Turi būti galima sudaryti klausimų grupių hierarchiją. Turi būti galima kuriamai klausimų grupei priskirti tėvinę / vaikinę klausimų grupę.
37.6.4. Paslaugų teikėjas turi parengti pradinius klausimų grupių rinkinius, kurie galutinai turi būti suderinti su Perkančiąja organizacija analizės ir projektavimo etapų vykdymo metu.
37.6.5. Turi būti galima publikuoti klausimų grupes ir jiems priskirtus DUK įrašus Išorinio naudojimo modulyje. Klausimų grupių sąrašas turi būti atvaizduojamas hierarchiniame medyje, jame pateikiant klausimų grupes ir joms priskirtus DUK įrašus.
37.6.6. Turi būti galima peržiūrėti ir redaguoti klausimų grupes ir DUK įrašus.
37.6.7. Turi būti galima pašalinti klausimų grupę ir DUK įrašą. Pašalintas klausimų grupė / DUK įrašas turi būti nebeatvaizduojami Išorinio naudojimo modulyje.
37.7. Kiti reikalavimai TVS komponentui:
37.7.1. Turi būti realizuota bet kurio BDMS puslapio spausdinimo galimybė spausdinimui pritaikytu formatu, suderintu su Perkančiąja organizacija analizės metu.
37.7.2. Išoriniame modulyje turi būti numatyta galimybė viešinti TVS priemonėmis patalpintas rinkmenas ir nuorodas į aktualius duomenis.
37.7.3. TVS administruojamuose sąrašuose (naujienų ir pan.) turi būti galimybė eksportuoti duomenis. Eksporto funkcionalumas turi būti suderintas su Perkančiąja organizacija analizės ir projektavimo etapų vykdymo metu.
37.7.4. TVS priemonėmis kuriamų įrašų (naujienų ir kt.) kiekis neturi būti ribojamas, t. y. turi būti galima sukurti neribotą skaičių įrašų.
37.7.5. Išorinio modulio puslapiuose turi būti galima atlikti paiešką pagal įvestus raktinius žodžius. Nurodžius žodžius be lietuviškų raidžių, turi būti grąžinami rezultatai pagal sutampančius žodžius jau su lietuviškomis raidėmis.
38. Reikalavimai viešos informacijos funkcionalumui:
38.1. Išoriniame modulyje turi būti leidžiama pasiekti viešos informacijos komponento funkcijas. Viešosios informacijos komponentą turi sudaryti šios sritys:
38.1.1. Prieiga prie Išorinio modulio autentifikuotos srities (identifikuotiems naudotojams).
38.1.2. Bendroji informacija:
38.1.2.1. Naujienos.
38.1.2.2. DUK skiltis.
38.1.2.3. Kontaktai.
38.1.2.4. Susiję teisės aktai.
38.1.2.5. Pagalbos (naudotojų instrukcijų) skiltis.
38.1.2.6. Kitos su Perkančiąja organizacija analizės ir projektavimo etapų vykdymo metu suderintos sritys.
38.1.3. Kita informacija, suderinta detalios analizės ar projektavimo etapų metu.
38.2. Viešos informacijos komponentas turi būti valdomas turinio valdymo komponento priemonėmis.
38.3. Galutinė Išoriniame modulyje pateikiamos informacijos struktūra turi būti suderinta su Perkančiąja organizacija analizės ir projektavimo etapų vykdymo metu.
6.3.4 Reikalavimai integracinėms sąsajoms
39. Paslaugų teikėjas turi suprojektuoti ir realizuoti integracines sąsajas su žemiau išvardintomis valstybės informacinėmis sistemomis ir registrais.
40. Integracinių sąsajų būdu gaunamų duomenų apimtis ir jų gavimo periodiškumas turi būti suderinti detalios analizės ar projektavimo etapų metu.
41. Paslaugų teikėjas atsakingas už integracinių sąsajų specifikacijų sudarymą ir suderinimą su duomenų teikėjais. Už duomenų teikimo sutarčių sudarymą ir suderinimą atsakinga Perkančioji organizacija.
42. Paslaugų teikėjas gali siūlyti alternatyvius žemiau pateiktų integracinių sąsajų realizavimo būdus (technologijas, apimtis ir kt.), jeigu jie niekaip nedarytų neigiamos įtakos projekto tikslui, uždaviniams ir galutiniams rezultatams, taip pat nesutrikdytų kitų registrų ir informacinių sistemų, veikiančių toje pačioje infrastruktūroje, darbo, bei neprieštarautų pirkimus reglamentuojančių teisės aktų reikalavimams. Pasiūlytas alternatyvus integracijos realizavimo būdas turi užtikrinti lygiavertę ar geresnę sąsajos greitaveiką, aukštą prieinamumą, plečiamumą, interoperabilumą, palaikymą ir saugumą. Kiekvienas siūlomas alternatyvus integracijos realizavimo būdas turi būti suderinamas su Perkančiąja organizacija.
43. Žemiau lentelėje aprašytos integracinės sąsajos, kurios turi būti sukurtos Projekto metu. Paslaugų teikėjas atsakingas už sąsajų sukūrimą BDMS pusėje. Detalios analizės ir projektavimo etape turi būti detalizuotas integracinių sąsajų kiekis, tikslas, paskirtis, duomenys, technologija ir laikiškumas. Paslaugų teikėjas turi parengti kiekvienos duomenų mainų sąsajos specifikacijas.
44. Paslaugų teikėjas turės realizuoti visą reikiamą funkcionalumą, kad žemiau aprašytos sąsajos veiktų,
t.y. jeigu specifikacijoje nenumatyta konkreti funkcija užklausai išsiųsti ar gautos informacijos peržiūrai atlikti, turi būti sukurtas atitinkamas funkcionalumas.
45. Visos BDMS realizuojamos tinklinės paslaugos skirtos išorinėmis informacinėms sistemomis ir registrams turi būti registruojamos VIISP saityno paslaugų kataloge (xxxxx://xxx.xxxxxxxxxx.xx/xxxxxx/xxxxxxx/0000). Paslaugų teikėjas turi parengti saityno paslaugų techninių parametrų ir duomenų teikimo tvarkos aprašą pagal VIISP pateikiamą struktūrą (xxxxx://xxx.xxxxxxxxxx.xx/xxxxxx/xxxxxxx/0000) ir, esant poreikiui, atlikti saityno sąsajų konfigūravimo darbus siekiant saityno paslaugas publikuoti VIISP duomenų mainų platformoje.
6.2 lentelė. BDMS integracinių sąsajų aprašymas
Eil. Nr. | Institucija | IS / registras | Gauti / teikti | Tikslas / paskirtis | Technol ogija | Periodiškumas |
45.1. | IVPK | VIISP | Gauti | Gauti asmens identifikavimo elektroninėje erdvėje duomenis. Gauti prašymų užregistruoti vaiką į ikimokyklinio ugdymo įstaigą duomenis. | WS | Pagal poreikį |
45.2. | IVPK | VIISP | Teikti | Teikti prašymų užregistruoti vaiką į ikimokyklinio ugdymo įstaigą duomenis (būsenų pasikeitimus, pranešimus ir kt.). | WS | Pagal poreikį |
45.3. | RC | GR | Gauti | Gauti mokinių asmens duomenis (vardas, pavardė, asmens kodas, gimimo data ir kt.), tėvų (globėjų) asmens duomenis (vardas, pavardė, | WS | Pagal poreikį |
asmens kodas, gyvenamoji vieta ir kt.) | ||||||
45.4. | SAM | ESPBI IS | Gauti | Gauti el. medicininės pažymos duomenis (forma 094/a) | WS | Pagal poreikį |
45.5. | ŠMSM | Mokinių registras | Gauti | Gauti mokinių duomenis. | WS | Pagal poreikį |
45.6. | ŠMSM | Mokinių registras | Teikti | Teikti priimtų į ugdymo įstaigą mokinių ir mokinių sutarčių duomenis. | WS | Pagal poreikį |
45.7. | NDNT | NDNT IS | Gauti | Gauti asmens neįgalumo duomenis. | WS | Pagal poreikį |
7. NEFUNKCINIAI REIKALAVIMAI
46. Paslaugų teikėjas privalo realizuoti visus šios Techninės specifikacijos reikalavimus.
47. Šiame dokumente vartojami terminai „turi būti“, „turi turėti“, „turi leisti“, „turi turėti galimybę“ yra lygiaverčiai ir reiškia, kad Paslaugų teikėjas privalo sukurti ir įdiegti (ar pateikti ir įdiegti) atitinkamą funkcionalumą ir suteikti atitinkamas paslaugas (žr. 7.13 skyriuje pateiktą 7.1 lentelę): funkcionalumo sukūrimas ir testavimas, testavimo scenarijų sukūrimas (Perkančiajai organizacijai), naudotojų mokymai, dokumentacijos parengimas. Funkcionalumas, kuris yra nurodytas būsimuoju laiku (bus, leis, apims) nurodo siekiamą įgyvendinti būseną ir reiškia, kad Paslaugų teikėjas privalo sukurti ir įdiegti (ar pateikti ir įdiegti) atitinkamą funkcionalumą.
48. Paslaugų teikėjas ar Perkančioji organizacija gali siūlyti alternatyvų atskiro Techninės specifikacijos reikalavimo įgyvendinimo būdą arba reikalavimo įgyvendinimo iškeitimą į lygiavertį funkcionalumą, kuris nedarytų neigiamos įtakos projekto tikslo, uždavinių ir galutinių rezultatų įgyvendinimui, taip pat netrikdytų registrų ir informacinių sistemų, veikiančių toje pačioje infrastruktūroje, veiklos, bei neprieštarautų pirkimus reglamentuojančių teisės aktų reikalavimams. Kiekvienas siūlomas alternatyvus ar Techninės specifikacijos reikalavimą keičiantis funkcionalumas turi būti suderinamas su Perkančiąja organizacija bei tvirtinimas Reikalavimo pakeitimo žurnale.
49. Paslaugų teikėjas gali siūlyti alternatyvius architektūros realizavimo būdus, kurie užtikrintų lygiavertę ar geresnę BDMS greitaveiką, aukštą prieinamumą, plečiamumą, interoperabilumą, palaikymą, saugumą ir patogumą. Kiekvienas siūlymas turi būti įvertintas ir patvirtintas Perkančiosios organizacijos.
50. BDMS turi būti projektuojama ir kuriama atsižvelgiant į teisės aktų saugumo ir duomenų saugos reikalavimus keliamus valstybės informacinėms sistemoms.
51. BDMS turi būti projektuojama ir kuriama atsižvelgiant į 2016 m. balandžio 27 d. Europos Parlamento ir Tarybos reglamentą (ES) 2016/679 dėl fizinių asmenų apsaugos tvarkant asmens duomenis ir dėl laisvo tokių duomenų judėjimo ir kuriuo panaikinama Direktyvos 95/46/EB (Bendrasis duomenų apsaugos reglamentas arba Reglamentas (ES) 2016/679) reikalavimus.
52. BDMS turi būti projektuojama ir kuriama atsižvelgiant į asmens duomenų tvarkymo Visagino savivaldybės administracijoje taisykles.
53. BDMS turi būti užtikrinamas saugumas programos lygmeniu, duomenų bazės lygmeniu, tinklo lygmeniu, aparatiniu lygmeniu.
54. Įdiegta programinė įranga (kuriamos aplikacijos ar standartinė programinė įranga) negali turėti Open Web Application Security Project (OWASP) Top 10 periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.
55. BDMS turi būti apsaugota nuo:
55.1. neautentifikuotos prieigos;
55.2. nesankcionuoto naudotojo sesijos perėmimo;
55.3. nesankcionuoto duomenų perėmimo ar jų įterpimo;
55.4. žalingo kodo įterpimo (angl. Injection, XSS (Cross-sitescripting));
55.5. kitų saugumo pažeidimų, kurie įvardijami OWASP TOP 10 (xxxxx://xxx.xxxxx.xxx) periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.
56. Aplikacijose turi būti numatyta apsauga nuo kenkėjiško kodo įkėlimo į aplikaciją (pavyzdžiui, apribota galimybė įkelti bylas su plėtiniais .com, .exe, .bat ir pan.).
57. BDMS aplikacijų ryšys su darbuotojų darbo vietomis (interneto naršyklėmis ir/ar aplikacijomis) turi būti šifruojamas naudojant SSL (angl. Secure Socket Layer) arba kitas lygiavertes šifravimo priemones.
57.1. Paslaugų teikėjas turi pateikti ir įdiegti SSL sertifikatus, kuriuos interneto naršyklės laiko patikimais (angl. trusted).
57.2. Priklausomai nuo IS architektūros, Paslaugų teikėjas turi pateikti reikiamą kiekį bei reikiamų paskirčių sertifikatus, kuriuos naudojant bus atliekamas perduodamos / gaunamos informacijos šifravimas.
57.3. Šifravimui naudojamas sertifikatas turi būti patvirtintas kvalifikuotu sertifikatu (pavyzdžiui: Veri Sign ar analogišku), kurį populiariosios interneto naršyklės gali verifikuoti automatiškai, t. y. darbo vietos naudotojui neturi reikėti savarankiškai sertifikato įtraukti į naršyklės ar operacinės sistemos patikimų sertifikatų saugyklą.
57.4. Paslaugų teikėjo pateiktas sertifikatas turi galioti ne mažiau nei du metus. Pateikiamo sertifikato garantinis aptarnavimas (angl. support) turi būti užtikrinamas ne mažiau dviems metams.
58. Turi būti vykdomas aplikacijose naudotojų atliekamų veiksmų auditavimas. Atliekant auditavimo įrašo išsaugojimą duomenų bazėje, turi būti kaupiama:
58.1. kas atliko veiksmą (naudotojas);
58.2. iš kokio IP adreso atliktas veiksmas;
58.3. kada atliko veiksmą (data);
58.4. kokius duomenis atnaujino;
58.5. kokius duomenis įterpė;
58.6. kokius duomenis pašalino;
58.7. kokius duomenis peržiūrėjo;
58.8. kokias paieškos frazes naudojo;
58.9. kita informacija, nustatyta analizės ir projektavimo etapų metu.
59. Turi būti audituojami integracinėmis sąsajomis siunčiamų / gaunamų duomenų momentai, išsaugant informaciją:
59.1. iš kokios sistemos gaunami duomenys;
59.2. į kokią sistemą siunčiami duomenys;
59.3. duomenų gavimo/siuntimo data ir laikas;
59.4. siųsti/gauti duomenys (jeigu tam yra poreikis);
59.5. kita informacija, nustatyta analizės ir projektavimo etapų metu.
60. Siekiant išvengti perteklinės auditavimo informacijos kaupimo tikslūs audito įrašų darymo momentai turi būti suderinti su Perkančiąja organizacija analizės ir projektavimo etapų metu.
7.3 REIKALAVIMAI NAUDOTOJO SĄSAJAI IR ERGONOMIKAI
61. BDMS naudotojo sąsaja turi būti prieinamos naudojant interneto naršyklę (išimtys gali būti taikomos standartinei licencinei programinei įrangai (ataskaitų ir statistikos programinei įrangai, duomenų bazių administravimo programinei įrangai ir pan.)).
62. BDMS turi būti konstruojamas „responsive web design“ principais.
63. Per interneto naršyklę pasiekiami BDMS komponentai turi vienodai funkcionuoti bei būti atvaizduojami su Perkančiąja organizacija suderintose interneto naršyklėse. Preliminariai BDMS turi veikti šiose interneto naršyklėse (naujausiose jų versijose):
63.1. Microsoft Edge;
63.2. Mozilla Firefox;
63.3. Google Chrome;
63.4. Safari;
63.5. Opera.
63.6. Detalios analizės ir projektavimo etape gali būti suderintas siauresnis BDMS palaikomų naršyklių kiekis.
64. BDMS naudotojo sąsaja (formos, tekstas, pagalbinė informacija, sistemos pranešimai ir kt.) turi būti realizuota lietuvių kalba. Kalba turi būti naudojama laikantis bendrinių lietuvių kalbos taisyklių. BDMS administratoriams skirtos programinės priemonės (pvz., administravimo aplikacija) ir pranešimai turi būti lietuvių ar anglų kalba.
65. BDMS turi būti realizuotas lietuvių kalba.
66. Naudotojų sąsajos klaidų pranešimai turi būti suformuluoti taip, kad naudotojui būtų aišku, kas atsitiko ir kokius veiksmus jam toliau reikia atlikti, kad galėtų tęsti darbą.
67. BDMS komponentų naudotojo sąsaja turi būti intuityvi, suprantama ir nesudėtinga naudoti naudotojams, turintiems reikalaujamą kompiuterinio raštingumo lygį (ECDL ar aukštesnį), bei atitikti šiuolaikinius ergonomikos reikalavimus.
68. Siekiant užtikrinti šiuolaikinius naudotojų sąsajos ergonomikos reikalavimus, rekomenduojama vadovautis LST EN ISO 9241-110:2006 „Žmogaus ir sistemos sąveikos ergonomika. 110 dalis. Dialogo principai (ISO 9241-110:2006)“ standartu arba lygiaverčiu.
69. Naudotojo sąsaja turi būti pritaikyta reikalavimams, kurie keliami neįgaliesiems pritaikytų valstybės ir savivaldybių institucijų ir įstaigų interneto svetainių kūrimo, testavimo ir įvertinimo metodinėse rekomendacijose, patvirtintose Informacinės visuomenės plėtros komiteto prie Lietuvos respublikos Vyriausybės direktoriaus 2004 m. kovo 31 d. įsakymu Nr. T-40 „Dėl Neįgaliesiems pritaikytų valstybės ir savivaldybių institucijų ir įstaigų interneto svetainių kūrimo, testavimo ir įvertinimo metodinių rekomendacijų patvirtinimo“.
71. Naudotojų sąsajos valdymas turi remtis pelės ir klaviatūros įrenginiais.
72. Turi būti realizuotas naudojimo patogumą užtikrinantis funkcionalumas:
72.1. TAB klavišo seka einant per duomenų įvedimo laukus.
73. Duomenų įvedimo formose duomenų laukai turi būti užpildomi automatiškai, jeigu BDMS yra saugomi atitinkami duomenys.
74. Paslaugų teikėjas turi suderinti unikalų naudotojo sąsajos grafinį dizainą su Perkančiąja organizacija analizės ir projektavimo etapo metu. Suderinus eskizus derinimui turi būti pateikiamas galutinis naudojo sąsajos sprendimas (turinio išdėstymas, ikonos, spalvos, nuotraukos ir visi kiti dizaino elementai).
75. Naudotojo sąsajos vaizdai turi būti pateikiami eskizais ar prototipais. Priėmimo testavimo ir bandomosios eksploatacijos metu Paslaugų teikėjas turės atlikti visus naudotojo sąsajos pakeitimus, jeigu to bus reikalaujama.
76. Duomenų sąrašai turi būti:
76.1. Puslapiuojami, su galimybe nurodyti kiek sąrašo puslapyje rodyti eilučių;
76.2. Filtruojami pagal sąrašui aktualius kriterijus (vieną ar daugiau kriterijų vienu metu). Paslaugų teikėjas, detalios analizės metus, turės identifikuoti kiekvieno sąrašo filtravimo kriterijus ir juos realizuoti;
76.3. Rikiuojami pagal sąrašo rikiuotinus elementus;
76.4. Eksportuojami į rinkmenas (.pdf, .docx, .xlxs ar lygiavertes). Detalios analizės metu turi būti nustatyta, kuriems sąrašams yra reikalinga pastaroji funkcija.
76.5. Atveriami spausdinimo režimu. Detalios analizės metu turi būti nustatyta, kuriems sąrašams yra reikalinga pastaroji būsena.
77. BDMS kuriamiems įrašams turi būti realizuojamos veiklos taisykles tenkinančios tų įrašų redagavimo, trynimo, šalinimo funkcijos.
78. BDMS turi būti indikuojami ilgiau trunkantys procesai (funkcijos), kad naudotojui būtų aišku, jog BDMS veikia ir nėra būtinybės iškviesti tų pačių funkcijų keletą kartų.
79. Reikalavimai naudotojų informavimui:
79.1. Naudotojui pateikiami pranešimai turi būti suformuluoti taip, kad naudotojui būtų aiški pranešimo pateikimo priežastis. Informacija apie pranešimo pateikimą sąlygojančią priežastį privalo būti pateikiama nurodant konkrečius BDMS duomenų objektus (pavyzdžiui, laukų pavadinimus).
79.2. Naudotojui pateikiamame klaidos pranešime privalo būti nurodoma, kokius veiksmus naudotojas privalo atlikti tam, kad galėtų pašalinti pranešimo pateikimo priežastis ir tęsti darbą su BDMS. Įvykus klaidai naudotojas apie tai turi būti aiškiai informuojamas (pvz., nukreipiamas į klaidą sąlygojančią ekraninės formos vietą, paryškinami netinkamai užpildyti formos laukai ir pan.).
79.3. Naudotojui turi būti pateikiami sėkmės pranešimai, nurodantys, kad naudotojo atlikti veiksmai yra sėkmingi (pavyzdžiui, informuojama, kad įrašas išsaugotas / ištrintas / pakoreguotas, duomenys sėkmingai įkelti ir pan.).
79.4. Klaidų pranešimai, sėkmės pranešimai ir informaciniai pranešimai turi būti išskirti skirtingomis spalvomis ar skirtingais simboliais, kad vizualiai būtų galima atskirti.
79.5. Jeigu naudotojui atlikus veiksmus rezultatai turės didelės įtakos, prieš atliekant veiksmą BDMS turi pateikti pranešimą ir paprašyti naudotojo patvirtinti, kad tikrai norima vykdyti.
80. Naudotojui turi būti pateikiamos pagalbos priemonės padedančios greičiau išmokti naudotis BDMS (pavyzdžiui, pagalbos mygtukai, naudotojo vadovas).
7.4 REIKALAVIMAI ARCHITEKTŪRAI
81. Architektūrinis sprendimas turi užtikrinti BDMS aukštą prieinamumą (angl. High availability), kuris gali būti realizuojamas operacinių sistemų funkcionalumu, techninės įrangos galimybėmis ar kitos programinės įrangos pagalba. Aukštas prieinamumas turi būti realizuojamas paslaugų lygyje, integracijų lygyje ir duomenų lygyje.
82. Aukšto prieinamumo sprendimai turi veikti automatiškai (incidentų atveju). Žmogaus įsitraukimas gali būti reikalingas tik BDMS veikimą atstatant į būseną, kuri buvo prieš incidentą.
83. Architektūros sprendimas turi užtikrinti apkrovų balansavimą (angl. load balancing) jeigu to reikia, kad būtų pasiekti BDMS našumo reikalavimai.
84. Aukšto prieinamumo sprendimas turi būti aprašytas projektavimo dokumente ir patvirtintas Perkančiosios organizacijos.
85. Paslaugų teikėjas turi pasiūlyti ir suderinti su Perkančiąja organizacija rezervinių kopijų darymo procesus, priemones ir taisykles. Atsarginių kopijų darymui turi būti naudojama Paslaugų teikėjo pateikta atsarginių kopijų darymo ir atstatymo įranga.
86. BDMS turi leisti atstatyti duomenis iš rezervinių duomenų kopijų. Paslaugų teikėjas turi pasiūlyti ir suderinti su Perkančiąja organizacija rezervinių kopijų atstatymo procesus, priemones ir taisykles.
87. BDMS turi atitikti plečiamumo principą, t. y., sistemos pajėgumus turi būti galima didinti papildant papildomą techninę įrangą ir / arba didinant esamos įrangos pajėgumus bei nekeičiant programinės įrangos išeities tekstų, programinė įranga neturi būti ribojantis veiksnys didinant našumą.
88. Turi būti realizuoti sistemos ir jos komponentų veikimo stebėjimo ir išankstinio perspėjimo (angl. monitoringo) sprendimai. Sistemos administratoriaus teises turintiems naudotojams turi būti užtikrinta galimybė web priemonėmis stebėti sistemos bei atskirų jos komponentų (visuose lygmenyse: aplikacijų, operacinių sistemų, techninės įrangos) veikimo rodiklius (aktyvūs naudotojai, atminties panaudojimas, procesorių apkrova ir kiti svarbūs rodikliai) bei gauti parnešimus sutrikus komponentų veikimui ar rodikliams pasiekus kritines reikšmes.
89. Turi būti įdiegtos priemonės, užtikrinančios centralizuotą žurnalinių įrašų (angl. logs) surinkimą iš visų sistemos kuriamų komponentų. Turi būti realizuotos priemonės šių žurnalinių įrašų peržiūrai ir analizei.
90. BDMS būti suprojektuojama ir kuriama taip, kad tam tikrų funkcionalumų pakeitimas vienoje ar keliose funkcinėse srityse neturi būti visos informacinės sistemos arba modulių perkūrimo priežastimi.
7.5 REIKALAVIMAI PROGRAMINEI ĮRANGAI IR LICENCIJOMS
91. Paslaugų teikėjas, įvertinęs Perkančiosios organizacijos turimą standartinę programinę įrangą ir licencijas bei leidimus ją naudoti, privalo pateikti papildomą standartinę programinę įrangą ir licencijas reikalingas siūlomo sprendimo realizacijai, jeigu šioje techninėje specifikacijoje tokia programinė įranga ar licencijos nėra reikalaujamos, tačiau yra būtinos BDMS kūrimo veikloms įgyvendinti (pavyzdžiui, aplikacijų serveriai, ataskaitų programinė įranga, programavimo karkasai (angl. framework) ar pan.).
92. Paslaugų teikėjo pateikiama standartinė licencinė programinė įranga (angl. Commercial Off-The-Shelf Software) (aplikacijų serveriai, duomenų bazės valdymo sistemos, monitoringo programinė įranga, atsarginių kopijų darymo programinė įranga, ataskaitų sudarymo programinė įranga, programavimo karkasai, turinio valdymo sistemos ir pan.), kuri reikalinga BDMS veikimui, turi būti pateikiama kartu su visomis reikiamomis licencijomis, kad Perkančiajai organizacijai ne mažiau kaip 3 metus nereikėtų įsigyti papildomų licencijų (ar kitaip investuoti) programinės įrangos veikimui.
93. Standartinė licencinė programinė įranga turi turėti ne mažiau 3 metų licencijos gamintojo palaikymą: atnaujinimų parsisiuntimą ir diegimą, naujų komponentų pateikimą.
94. Jeigu siūloma standartinė licencinė programinė įranga yra licencijuojama priklausomai nuo sistemą naudojančių naudotojų (žmonių ar sistemų) kiekio, tarnybinių stočių parametrų ar pan., tai Paslaugų teikėjas turi pateikti licencijas, kurios užtikrintų racionalų ir efektyvų BDMS veikimą ir naudojimą.
95. Visi reikalingos programinės įrangos kaštai turi būti įskaičiuoti į pasiūlymą.
96. Visos reikalingos licencijos turi būti įgyjamos Perkančiosios organizacijos vardu. Perkančiajai organizacijai turi būti perduotos visos BDMS veikimui reikalingos licencijos. Pateikiamų licencijų (ir sertifikatų) galiojimo pradžia turi būti ne ankstesnė nei bandomosios eksploatacijos etapo pradžia ir ne vėlesnė nei garantinės priežiūros etapo pradžia.
97. Paslaugų teikėjas gali pasiūlyti lygiavertę BDMS reikalingą programinę įrangą. Teikdamas lygiavertę programinę įrangą turi detalizuoti siūlomos programinės įrangos lygiavertiškumą architektūriniu, funkciniu, licencijavimo, plečiamumo, prieinamumo, valdymo, diegimo, atstatomumo, našumo, pernešamumo, gedimų tolerantiškumo, interoperabilumo, eksploatavimo, saugumo, palaikomumo, panaudojamumo (patogumo naudotis) požiūriu.
98. Siūlomos programinės įrangos lygiavertiškumo deklaravimas ir detalizavimas turi būti pateikiamas Paslaugų teikėjo pasiūlyme. Pasiūlymo vertinimo metu bus priimamas sprendimas dėl siūlomos programinės įrangos lygiavertiškumo. Paslaugų teikėjų pasiūlymai, kuriuose siūloma nelygiavertė programinė įranga, bus atmetami.
7.6 REIKALAVIMAI GREITAVEIKAI IR NAŠUMUI
99. BDMS Išorinio naudojimo modulio realizacija turi užtikrinti, kad kai su BDMS Išorinio naudojimo moduliu vienu metu dirba 300 naudotojų ir jų veiksmų – dokumentinių įrašų įterpimo, keitimo ir šalinimo, kitų veiksmų atlikimo (kurių vykdymo laikas nepriklauso nuo sąsajų su išorinėmis sistemomis), vidutinė atsako trukmė (trukmė nuo serverio HTTP užklausos gavimo iki HTTP atsakymo išsiuntimo) neturi viršyti 2 sekundžių, esant bendram HTTP užklausų kiekiui per minutę 250. Galimi išimtiniai atvejai, kurie turi būti suderinti su Perkančiąja organizacija (pvz., ataskaitų generavimas, duomenų importavimas ar eksportavimas, didelės apimties rinkmenų įkėlimas, veiksmai apimantys užklausas ir atsakymų gavimus iš trečių šalių sistemų ir kt.).
100. BDMS realizacija turi užtikrinti, kad kai su BDMS vienu metu dirba 50 naudotojų ir jų veiksmų – dokumentinių įrašų įterpimo, keitimo ir šalinimo, kitų veiksmų atlikimo (kurių vykdymo laikas nepriklauso nuo sąsajų su išorinėmis sistemomis), vidutinė atsako trukmė (trukmė nuo serverio HTTP užklausos gavimo iki HTTP atsakymo išsiuntimo) neturi viršyti 2 sekundžių esant bendram HTTP užklausų kiekiui per minutę
250. Galimi išimtiniai atvejai, kurie turi būti suderinti su Perkančiąja organizacija (pvz., ataskaitų generavimas, duomenų importavimas ar eksportavimas, didelės apimties rinkmenų įkėlimas, veiksmai apimantys užklausas ir atsakymų gavimus iš trečių šalių sistemų ir kt.).
101. Turi būti realizuotas užklausų, kurios viršija nustatytus našumo reikalavimus, auditavimas. Audito įraše turi būti pakankamai duomenų, kad būtų galima nustatyti kuri BDMS funkcija netenkina našumo reikalavimų.
102. Integracinių sąsajų realizacija turi užtikrinti, kad projektavimo metu apibrėžti integraciniai scenarijai įvyks per racionalų laiko tarpą ir niekaip neigiamai neįtakos BDMS išorinės ir vidinės aplikacijos naudojimo patogumo ir našumo.
7.7 REIKALAVIMAI DEMONSTRACIJOMS
103. Paslaugų teikėjas kūrimo etape turi atlikti kuriamos BDMS demonstracijas gyvai demonstruojant sistemos veikimą. Turi būti atliekamas sukurtos BDMS demonstravimas, o ne prototipo.
104. Demonstruojamo funkcionalumo apimtis ir laikiškumas turi būti nustatyti projekto reglamente. Iki priėmimo testavimo etapo pradžios Perkančiajai organizacijai turi būti pademonstruotas visas BDMS funkcionalumas, išskyrus tą funkcionalumą, kuris bus suderintas kaip nedemonstruotinas (pavyzdžiui, integracijos).
105. Demonstracijų tikslas – supažindinti Perkančiąją organizaciją su kuriama programine įranga bei gauti atsiliepimus dėl sukurto (kuriamo) funkcionalumo.
106. Pastabos (atsiliepimai) gali būti išsakomos pakartotinai priėmimo testavimo etape, jeigu į jas nebus atsižvelgta iki pastarojo etapo.
107. Demonstracijų metu išsakomi atsiliepimai (pastabos) turi būti registruojami susitikimo protokoluose ar kita sutarta forma (pavyzdžiui, specializuotoje klaidų registravimo ir sekimo sistemoje).
108. Funkcionalumo demonstraciją turi vykdyti Diegėjas, o Perkančiosios organizacijos atstovai turi teikti atsiliepimus.
109. Turi būti atliktas BDMS testavimas. Testavimo tikslai:
109.1. įsitikinti, kad yra įgyvendinti visi funkciniai ir nefunkciniai techninės specifikacijos, detalios analizės ir projektavimo dokumentų, naudotojo sąsajos prototipų, integracinių sąsajų specifikacijos bei architektūros dokumentų reikalavimai;
109.2. įsitikinti, kad reikalavimų įgyvendinimas atliktas tinkama apimtimi;
109.3. nustatyti ar reikalavimų įgyvendinimas tenkina Perkančiąją organizaciją ir kitas suinteresuotas šalis;
109.4. identifikuoti ir užregistruoti funkcionalumo klaidas (angl. bugs).
110. Turi būti atlikti šie testavimai:
110.1. Vidinis testavimas. Vidinius atskirų komponentų testavimus Paslaugų teikėjas turi atlikti nedalyvaujant Perkančiosios organizacijos atstovams, tačiau turi pateikti tokio testavimo įrodymus – vidinio testavimo ataskaitą ir nustatytų neatitikimų sąrašą.
110.2. Priėmimo testavimas (angl. acceptance testing). Šis testavimas turi būti atliekamas dalyvaujant Paslaugų teikėjui, Perkančiajai organizacijai ir kitoms suinteresuotoms šalims. Šio testavimo metu turi būti tikrinamas testavimo tikslų įgyvendinimas (įgyvendinimo lygio nustatymas). Priėmimo testavimo veiklos turi būti vykdomos remiantis Paslaugų teikėjo parengtu priėmimo testavimo planu ir priėmimo testavimo metodika. Paslaugų teikėjas rengia priėmimo testavimo scenarijus pagal testavimo metodikoje nustatytus reikalavimus.
111. Atliktas testavimas turi užtikrinti, kad BDMS yra tinkama eksploatavimui.
112. Priėmimo testavimo metu turi būti vykdomas identifikuotų klaidų (problemų) registravimas:
112.1. Priėmimo testavimo metu elektronine forma turi būti vedamas pastebėtų klaidų (problemų) ir jų būsenų kaupimo žurnalas. Paslaugų teikėjas turi pateikti tokį įrankį, kuris nuolat būtų prieinamas internetu Perkančiosios organizacijos atstovams.
112.2. Klaidų žurnalas turi būti specializuota problemų registravimo ir sekimo programinė įranga (angl. issue tracking software), paremta tinklinėmis technologijomis, t. y. pasiekiama naudojant interneto naršyklę.
112.3. Paslaugų teikėjas turės parengti visus priėmimo testavimui reikalingus testavimo duomenis.
112.4. Paslaugų teikėjas turės užtikrinti, kad priėmimo testavimo metu BDMS bus suvesta (importuota) pakankamai testinių duomenų, kurie leistų pilnai ištestuoti BDMS funkcionalumą.
113. Priėmimo testavimas turi būti vykdomas Perkančiosios organizacijos techninės įrangos pagrindu. Jeigu priėmimo testavimo metu nebus tokios galimybės, testavimas turės būti vykdomas naudojant Paslaugų teikėjo pateiktą techninę įrangą (jos pagrindu veikiančią testinę aplinką). Tokiu atveju turės būti atliktas atskiras testavimas Perkančiosios organizacijos pateiktoje techninėje įrangoje siekiant įsitikinti, kad BDMS korektiškai veikia kitos techninės įrangos pagrindu.
114. Paslaugų teikėjas turi įdiegti ir sukonfigūruoti BDMS testavimo aplinką, kai Perkančioji organizacija sudarys tam technines ir organizacines sąlygas. Testinėje aplinkoje turi būti naudojami depersonalizuoti duomenys. Turi būti įgyvendintos integracinės sąsajos su integruotinų išorinių sistemų testinėmis aplinkomis (jeigu tokios yra, o jei nėra – turi būti suimituojami iš išorinių sistemų gaunami atsakymai).
115. Priėmimo testavimo aplinkos architektūros principai turi atitikti numatomos darbinės BDMS aplinkos architektūrą.
116. Priėmimo testavimus Paslaugų teikėjas turi vykdyti stebint Perkančiosios organizacijos atstovams. Paslaugų teikėjas turi užtikrinti reikiamas sąlygas sėkmingam BDMS testavimui atlikti.
117. Priėmimo testavimas bus užbaigiamas, kai bus tenkinami testavimo plane įvardinti testavimo priėmimo kriterijai.
118. Paslaugų teikėjas turi parengti priėmimo testavimo ataskaitą, po kiekvieno užbaigto priėmimo testavimo etapo.
119. Paslaugų teikėjas turės įdiegti BDMS į Perkančiosios organizacijos pateiktą techninę įrangą bei atlikti techninės ir programinės įrangos konfigūravimo darbus, kad būtų užtikrintas tinkamas BDMS darbinės aplinkos veikimas.
120. Paslaugų teikėjas po bandomosios eksploatacijos turi perduoti Perkančiajai organizacijai sukurto BDMS išeities kodą, licencinės programinės įrangos instaliacinius paketus bei BDMS įdiegimo instrukcijas.
121. Paslaugų teikėjas turi įdiegti priemones, užtikrinančias automatinį naujų sistemos versijų diegimą, užtikrinant jos veikimą diegimo metu.
122. Turi būti realizuoti sprendimai, kad programinio kodo, aplikacijų, duomenų bazių atnaujinimas reikiamose aplinkose būtų atliekamas be papildomų naudotojo veiksmų
123. BDMS išeities kodas turi būti pateikiamas Paslaugų teikėjo naudotoms kūrimo priemonėms suprantamu formatu įrašytas į DVD ar kitą skaitmeninę laikmeną. Kartu turi būti pateikiamas sukompiliuotas išeities kodas (parengtas diegimui).
124. Paslaugų teikėjas turi dokumentuoti programinės įrangos diegimo į Perkančiosios organizacijos BDMS gamybinę ir testinę aplinkas procesą bei pateikti tam reikalingas programines priemones. Procesas turi būti dokumentuotas taip, kad:
124.1. Atsakingas Perkančiosios organizacijos darbuotojas iš pateiktų išeities tekstų galėtų pagaminti (angl. build) programinę įrangą bei valdyti gaminimo konfigūraciją.
124.2. Atsakingas Perkančiosios organizacijos darbuotojas programinę įrangą galėtų įdiegti į testinę ir gamybinę aplinką bei valdyti diegimo konfigūraciją.
7.10 REIKALAVIMAI BANDOMAJAI EKSPLOATACIJAI
125. Turi būti atlikta BDMS bandomoji eksploatacija.
126. Bandomosios eksploatacijos tikslai:
126.1. užtikrinti BDMS kokybę;
126.2. išbandyti gamybinę BDMS komponentų konfigūraciją;
126.3. identifikuoti ir pašalinti bandomosios eksploatacijos metu pastebėtus defektus;
126.4. stabilizuoti darbinės aplinkos konfigūraciją, atsižvelgiant į bandomosios eksploatacijos metu sukauptą patirtį.
127. Bandomosios eksploatacijos veiklas Paslaugų teikėjas turės vykdyti pagal parengtą ir su Perkančiąja organizacija suderintą bandomosios eksploatacijos planą.
128. Paslaugų teikėjas iki bandomosios eksploatacijos pradžios privalo paruošti BDMS infrastruktūrą darbui:
128.1. Atlikti BDMS komponentų konfigūravimą, kad visi bandomosios eksploatacijos dalyviai turėtų galimybę prisijungti prie BDMS iš savo darbo vietų. Naudotojų darbo vietų parengimą užtikrins Perkančioji organizacija. Paslaugų teikėjas turi pateikti rekomendacijas dėl naudotojų darbo vietų paruošimo.
128.2. Sumigruoti (suvesti) visus būtinus BDMS duomenis bei pašalinti perteklinius (bandomajai eksploatacijai nereikalingus) duomenis. Privalo užtikrinti, kad visi duomenys būtų integralūs.
129. Paslaugų teikėjas privalo užtikrinti BDMS veikimą visos bandomosios eksploatacijos metu, jeigu nebus sutarta kitaip.
130. Bandomosios eksploatacijos aplinka turi būti realizuota gamybinėje aplinkoje, jeigu nebus sutarta kitaip.
131. Bandomoji eksploatacija yra baigiama, kai tenkinami bandomosios eksploatacijos priėmimo kriterijai, kurie pateikiami bandomosios eksploatacijos plane.
132. Paslaugų teikėjas turi atlikti BDMS naudotojų mokymus. Turi būti apmokyti:
132.1. Ne mažiau kaip 4 Perkančiosios organizacijos nurodyti asmenys darbui su BDMS funkcionalumu. Vienos grupės mokymų trukmė – ne mažiau 5 valandos. Mokymų grupės dydis turi būti suderintas su Perkančiaja organizacija, bet neturi būti didesnis nei 20 asmenų.
132.2. Ne mažiau kaip 30 Perkančiosios organizacijos ar kitų institucijų administratorius darbui su BDMS administravimo komponentais ir BDMS standartinės programinės įrangos administravimu. Mokymų trukmė – ne mažiau 10 valandų.
133. Mokymai vedami lietuvių kalba Perkančiosios organizacijos patalpose ir Perkančiosios organizacijos darbo valandomis, jeigu nėra sutarta kitaip.
134. Mokymų metu naudotojai turi būti apmokyti dirbti su visu BDMS funkcionalumu. Atlikti apmokymai turi sudaryti galimybę naudotojui su BDMS dirbti savarankiškai. Paslaugų teikėjas turi parengti mokymų planą ir mokymų medžiagą.
135. Paslaugų teikėjas turi parengti BDMS naudojimo instrukcijas ir BDMS administravimo instrukcijas.
7.12 REIKALAVIMAI GARANTINEI PRIEŽIŪRAI
136. Paslaugų teikėjas privalės užtikrinti BDMS ir kitos įdiegtos programinės įrangos (aplikacijų, duomenų bazių ir kt.) garantinę priežiūrą, kuri turi būti vykdoma pagal su Perkančiaja organizacija suderintą garantinės priežiūros bei vidinių naudotojų konsultavimo reglamentą.
137. Garantinės priežiūros terminas 36 mėnesiai nuo priėmimo–perdavimo akto pasirašymo datos.
138. Garantinės priežiūros paslaugos apima sukurtos ir modernizuotos programinės įrangos sutrikimų šalinimą bei Perkančiosios organizacijos atsakingų asmenų konsultavimą.
139. Paslaugų teikėjas turi vykdyti Perkančiosios organizacijos atsakingų asmenų konsultavimą BDMS veikimo, naudojimo bei tobulinimo klausimais. Konsultacijos turi būti teikiamos telefonu, el. paštu, naudojant Perkančiosios organizacijos pateiktą priežiūros tarnybos (angl. Help Desk) programinę įrangą ar atvykus į Perkančiąją organizaciją.
140. Paslaugų teikėjas turi teikti skubią pagalbą įsilaužimo atveju ir užtikrinti BDMS informacijos atstatymą per Perkančiosios organizacijos nurodytą laikotarpį po pranešimo užregistravimo.
141. Programinės įrangos veikimo sutrikimu laikoma situacija, kai BDMS naudotojai dėl Paslaugų teikėjo sukurtos programinės įrangos funkcionalumo trūkumų negali atlikti numatytų BDMS funkcijų ar funkcijos veikia nekorektiškai.
142. Programinės įrangos sutrikimų atstatymo trukmė:
142.1. Reakcijos į sutrikimą laikas – ne ilgiau kaip 1 (viena) darbo valanda nuo pranešimo apie sutrikimą gavimo sutartu būdu;
142.2. Programinės įrangos veikimo sutrikimai turi būti pašalinti per tokį laiką, kad darbas BDMS naudotojams nesutriktų ilgiau negu 12 valandų. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko;
142.3. Neesminių sutrikimų šalinimas – ne ilgiau kaip 5 darbo dienos nuo pranešimo gavimo sutartu būdu. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko. Neesminis sutrikimas – kosmetinės ar panašios BDMS klaidos, kurios neįtakoja korektiško funkcijų veikimo;
142.4. Svarbių sutrikimų šalinimas – ne ilgiau kaip 3 darbo dienos nuo pranešimo gavimo sutartu būdu. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko. Svarbus sutrikimas – neapibrėžtas funkcijos veikimas, kuris leidžia įvykdyti numatytą BDMS funkciją, tačiau naudotojui reikia atlikti papildomus, nenumatytus ar alternatyvius veiksmus;
142.5. Kritinių sutrikimų šalinimas – ne ilgiau kaip 1 darbo diena nuo pranešimo gavimo sutartu būdu. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko; Kritinis sutrikimas – funkcijos neveikimas, be galimybės reikiamą funkciją vykdyti alternatyviai.
143. Paslaugų teikėjas turi parengti prieinamas ir Perkančiajai organizacijai tinkamas informavimo apie BDMS sutrikimus, jų registravimo ir taisymo veiksmų būseną priemones: Perkančiosios organizacijos ir Paslaugų teikėjo suderintus telefonus, el. pašto adresus, garantinio aptarnavimo ir priežiūros tarnybos programinio įrankio adresą (nuorodą). Išvardintais būdais Perkančiosios organizacijos atsakingiems asmenims turi būti galimybė pranešti apie BDMS sutrikimus, reikiamas konsultacijas, reikiamus tobulinimus (naujo funkcionalumo kūrimą) ir pan.
144. Garantinės priežiūros paslaugos, konsultacijos telefonu ir elektroniniu paštu turi būti teikiamos Perkančiosios organizacijos darbo dienomis darbo valandomis.
7.13 REIKALAVIMAI SUTARTIES VYKDYMO ETAPAMS
32 | 38
7.1 lentelė. Paslaugų etapai, etapų rezultatai
Nr. | Paslaugų teikimo etapas | Reikalavimai etapo darbams | Rezultatas | Terminas |
1. | Inicijavimas | Paslaugų teikėjas: • Parengia Paslaugų teikimo darbo reglamentą ir suderina su Perkančiąja organizacija. Perkančioji organizacija (pagal kompetenciją): • Suteikia reikalingą informaciją; • Teikia pastabas ir rekomendacijas. | Paslaugų teikimo darbo reglamentas. Paslaugų teikimo reglamente nurodoma Projekto tikslai, prioritetai, etapų apimtys ir rezultatai, suinteresuotos šalys, darbų atlikimo grafikas, naudojami standartai ir kokybiniai reikalavimai, rizikos ir jų suvaldymo būdai, komunikavimo principai, atsakomybės, Projekto problemų nustatymo ir valdymo procedūros, tarpinių ir galutinių rezultatų priėmimo kriterijai, pokyčių valdymo procedūra, atsakomybės, problemų sprendimo procedūra ir visa kita Projekto vykdymui aktuali informacija. | Etapo rezultatai turi būti pateikti per 5 (penkias) darbo dienas nuo Paslaugų teikimo sutarties įsigaliojimo datos. |
2. | Detali analizė | Paslaugų teikėjas: • Atlieka esamos ir siekiamos padėties įvertinimą, parengia detalios analizės dokumentaciją ir ją suderina su Perkančiąja organizacija. Perkančioji organizacija (pagal kompetenciją): • Suteikia reikalingą informaciją; • Teikia pastabas ir rekomendacijas; • Tvirtina etapo Paslaugų teikėjo rezultatus. | Detalios analizės dokumentai. Detalios analizės dokumentuose išanalizuojami ir detalizuojami funkciniai ir nefunkciniai Techninės specifikacijos reikalavimai bei kiti Perkančiosios organizacijos išsakyti poreikiai, parengiami naudojimo atvejai (angl. use case), kurie pateikiami naudojimo atvejų diagramomis pagal UML (angl. Unified Modeling Language) notaciją ir detalizuojami aprašant kiekvieno naudojimo atvejo vykdymo žingsnius (pagrindinę eigą, alternatyvią eigą, išimtinę eigą) ir kitus apribojimus. Sudėtingesni naudojimo atvejai ar jų grupės turi būti detalizuojami pateikiant veiklos procesus, naudojant procesų modeliavimo diagramas (angl. UML activity diagram, BPMN (Business Process Model and Notation) ar lygiavertes diagramas). Pateikiami pastarųjų diagramų struktūrizuoti aprašai. Aprašomi | - |
naudotojai ir jų teisės. Turi būti atliktas visų šios Specifikacijos funkcinių ir nefunkcinių reikalavimų susiejimas su detalios analizės dokumento turiniu (skyriais, naudojimo atvejais, diagramomis ir pan.). Siejimas turi būti atliekamas tokia forma, kad būtų aišku kokiu būdu yra projektuojamas ir realizuojamas kiekvienas šios Specifikacijos reikalavimas. | ||||
3. | Projektavimas | Paslaugų teikėjas: • Parengia BDMS projektavimo dokumentaciją; • Parengia integracines sąsajas aprašančius dokumentus. Perkančioji organizacija (pagal kompetenciją): • Suteikia reikalingą informaciją; • Teikia pastabas ir rekomendacijas; • Tvirtina etapo Paslaugų teikėjo rezultatus. | Projektavimo dokumentai. Kuriamos BDMS architektūros aprašymas fizinių komponentų ir programinių komponentų požiūriu, naudojamos technologijos (jų pavadinimai, versijos), informacinis vaizdas (duomenų bazės struktūros (su komentarais), duomenų bazių sąsajų schemos ir kt.), funkcinis vaizdas (BDMS funkciniai vienetai, jų funkcijos, tarpusavio sąsajos, naudotojo sąsajos prototipai, integracinis vaizdas (sąsajos tarp vidinių ir išorinių sistemų, kuriamos sistemos atžvilgiu), operacinis vaizdas (sisteminiai procesai, algoritmai, periodiniai sisteminiai darbai ir pan.), dislokavimo vaizdas (programinių komponentų pasiskirstymas techninėje įrangoje) ir kt. Reikalavimai infrastruktūrai. Pateikiami reikalavimai BDMS veikimui reikalingai infrastruktūrai. Integracines sąsajas aprašantys dokumentai. Juose turi būti detalizuojama kiekvienos integracinės ir duomenų mainų sąsajos paskirtis, realizavimo sprendimas, prisijungimo ir kiti parametrai ir pateikiami struktūrizuotų pranešimų aprašymai (pvz., XML formatu), funkcijos priimančios ir teikiančios duomenis, integracinės sąsajos naudojimo pavyzdžiai ir kita aktuali informacija, | - |
aprašanti integracinės sąsajos veikimą, jos naudojimą. | ||||
4. | Kūrimas | Paslaugų teikėjas: • Vykdo reikalingus programavimo ir konfigūravimo darbus (savo kūrimo aplinkoje), įgyvendina funkcinius ir nefunkcinius reikalavimus; • Atlieka komponentų (angl. unit) testavimą, vidinį saugumo testavimą, BDMS vidinį testavimą, sąsajų su kitomis sistemomis ir registrais (integravimo) testavimą ir parengia vidinio testavimo ataskaitą. • Vykdo BDMS kūrimo demonstracijas. Perkančioji organizacija (pagal kompetenciją): • Suteikia reikalingą informaciją; • Parengia testavimo aplinką turimoje infrastruktūroje; • Peržiūri ir įvertina vidinio testavimo rezultatus; • Teikia pastabas ir rekomendacijas. | Vidinio testavimo ataskaita, kurioje aprašyti atlikto vidinio saugumo testavimo rezultatai ir vidinio testavimo rezultatai (apimtis, vykdymo metodika, naudoti testavimo scenarijai, testavimo tipai, procedūra, testavimo aplinka), pateikiant informaciją apie BDMS sritis, į kurias reikia atkreipti papildomą dėmesį testavimo metu. Parengta programinė įranga diegimui. Atliktos BDMS demonstracijos. | Vidinio testavimo ataskaita turi būti pateikta bent 2 savaitės iki kūrimo etapo pabaigos. BDMS demonstracijos turi būti vykdomos nuolatos, pagal atskirai suderintą grafiką. |
5. | Diegimas testavimo aplinkoje | Paslaugų teikėjas: • Parengia ir pateikia programinę įrangą tinkamą įdiegimui Perkančiosios organizacijos testavimo aplinkoje; • Atlieka sukurtos programinės įrangos įdiegimą testavimo aplinkoje; Perkančioji organizacija (pagal kompetenciją): • Suteikia reikalingą informaciją; • Kontroliuoja testavimo aplinką; • Pateikia priėmimo testavimo scenarijus ir testavimo metodiką. | Sukurta programinė įranga įdiegta Perkančiosios organizacijos testavimo aplinkoje. Parengta priėmimo testavimo metodika, planas ir testavimo scenarijai. | Šis diegimo etapas turi būti baigtas iki priėmimo testavimo etapo pradžios. |
6. | Priėmimo testavimas | Paslaugų teikėjas: • Parengia naudotojų vadovus (dokumentus): BDMS naudojimo instrukciją ir BDMS administravimo dokumentus ir instrukcijas; • Vykdo priėmimo testavimą; • Atlieka testavimo metu išaiškėjusius reikalingus klaidų / neatitikčių taisymus; • Parengia priėmimo testavimo ataskaitą. Perkančioji organizacija (pagal kompetenciją): • Vykdo priėmimo testavimą; • Priima programinę įrangą diegimui į gamybinę aplinką. | Sėkmingai atliktas priėmimo testavimas (tenkinami sėkmingo priėmimo testavimo kriterijai). Parengti naudotojų vadovai (dokumentai) ir BDMS administravimo dokumentai ir instrukcijos. Parengta priėmimo testavimo ataskaita. Diegimui į gamybinę aplinką parengta BDMS. | Priėmimo testavimas turi būti atliktas iki bandomosios eksploatacijos pradžios. |
7. | Diegimas gamybinėje aplinkoje | Paslaugų teikėjas atlieka šiuos darbus: • Parengia ir pateikia programinę įrangą tinkamą įdiegimui Perkančiosios organizacijos eksploatavimo aplinkoje. • Įdiegia programinę įrangą eksploatavimo aplinkoje. Perkančioji organizacija: • Teikia pastabas ir rekomendacijas; Įdiegia programinę įrangą į eksploatavimo aplinką. | Parengta eksploatavimo aplinka Perkančiosios organizacijos infrastruktūroje. Sukurta programinė įranga įdiegta Perkančiosios organizacijos eksploatavimo aplinkoje. Parengta bandomosios eksploatacijos metodika, planas ir bandymų scenarijai. | Šis diegimas gali vykti tik po sėkmingai įvykusio priėmimo testavimo. Šis diegimo etapas turi būti baigtas ne ilgiau kaip per dvi savaites nuo priėmimo testavimo etapo pabaigos ir baigtas iki bandomosios eksploatacijos pradžios. |
8. | Mokymai | Paslaugų teikėjas atlieka šiuos darbus: • Parengia mokymų planą; • Parengia mokymų medžiagą ir kitas reikalingas priemones; • Parengia mokymų aplinką; • Vykdo apmokymus. | Parengtas mokymų planas. Dokumente turi būti aprašytas mokymų kursų organizavimas, pateikti detalūs mokymų planai/grafikai, mokymų grupės, mokymų vietos, nurodytos mokymų priemonės. Parengta mokymų medžiaga. Įvykdyti mokymai sutartam naudotojų kiekiui. | Mokymai turi būti įvykdyti iki bandomosios eksploatacijos pradžios. |
Perkančioji organizacija (pagal kompetenciją): • Pateikia pastabas mokymų planui; • Dalyvauja mokymuose. | ||||
9. | Bandomoji eksploatacija | Paslaugų teikėjas: • Teikia konsultacijas bandomosios eksploatacijos klausimais; • Reaguoja ir pašalina eksploatacijos metu nustatytus defektus; • Užtikrina ekspertų konsultavimą Perkančiosios organizacijos darbuotojams ir IT specialistams; • Užtikrina į BDMS importuotų ir suvestų duomenų integralumą ir vientisumą; • Parengia garantinės priežiūros ir palaikymo procedūros dokumentus Perkančioji organizacija (pagal kompetenciją) ar techninę priežiūrą vykdantis konsultantas: • Dirba su įdiegta BDMS; • Registruoja bandomosios eksploatacijos metu nustatytas klaidas; • Vykdo bandomosios eksploatacijos metu nustatytų problemų šalinimo kontrolę. | Pašalintos bandomosios eksploatacijos metu nustatytos klaidos. Paslaugų teikėjas bandomosios eksploatacijos metu pagal suderintą klaidų šalinimo grafiką turi šalinti visus BDMS trūkumus, užregistruotus bandomosios eksploatacijos problemų registre. Suteiktos konsultacijos. Parengtas garantinės priežiūros ir palaikymo procedūros dokumentas. Dokumente turi būti aprašytas garantinės priežiūros ir palaikymo teikimo būdas, detalizuotos garantinės priežiūros ir palaikymo teikimo sąlygos, Paslaugų teikėjo atsakomybė, Perkančiosios organizacijos atsakomybė, kontaktinė informacija, papildomos tvarkos (eskalavimo, klaidų registravimo, konsultavimo)). | Bandomosios eksploatacijos trukmė derinama su Perkančiąja organizacija. Garantinės priežiūros procedūros dokumentas turi būti pateiktas likus ne mažiau kaip 1 mėnesiui iki bandomosios eksploatacijos pabaigos. |
10. | Garantinė priežiūra ir palaikymas | Paslaugų teikėjas suteikia ne trumpesnį nei 24 mėnesių garantinį aptarnavimą. | Teikiami garantinės priežiūros ir palaikymo įsipareigojimai. | 36 mėnesių nuo galutinio perdavimo-priėmimo akto pasirašymo dienos. |
Viso Projekto metu | ||||
11. | Ataskaitų rengimas | Paslaugų teikėjas: • Rengia BDMS kūrimo eigos ataskaitą ne rečiau, kaip kartą kas ketvirtį; | Parengtos ataskaitos. Ataskaitose išdėstoma (neapsiribojant): | - |
• Rengia galutinę BDMS kūrimo ir diegimo ataskaitą (po bandomosios eksploatacijos). Perkančioji organizacija (pagal kompetenciją): • Pateikia pastabas ir rekomendacijas ataskaitoms. | • pasiekti rezultatai, vykdomos veiklos ir jų progresas BDMS kūrimo grafiko atžvilgiu; • rizikos, kritiniai faktoriai ir numatomi veiksmai, prognozės ir kitos Projekto įgyvendinimui svarbios aplinkybės; • BDMS kūrimo grafiko pakeitimai. |
38 | 38
145. Galutinis BDMS priėmimas bus vykdomas pasibaigus bandomajai eksploatacijai, t. y. priėmimas galės būti vykdomas tik tada, kai bus pasiekti bandomosios eksploatacijos priėmimo kriterijai.
146. BDMS bus priimama pasirašant priėmimo-perdavimo aktą.
147. Siekiant užtikrinti sklandų Projekto tęstinumą:
147.1. Paslaugų teikėjas, nepažeidžiant autoriaus teisių turėtojo ar trečiųjų šalių intelektinės nuosavybės teisių, sutartimi perduoda Perkančiajai organizacijai autorių turtines teises į pagal užsakymą sukurtą programinę įrangą ir parengtus projektinius dokumentus, įskaitant, bet neapsiribojant, teisę neribotą laiką ir be papildomo atlygio naudoti sukurtą programinę įrangą; teisę daryti sukurtos programinės įrangos kopijas; teisę modifikuoti ir toliau plėtoti sukurtą programinę įrangą; teisę perkelti programinę įrangą į kitą technologinę platformą; teisę naudoti ir keisti jai sukurtos programinės įrangos pradinį kodą (mašininės kalbos pradinius tekstus).
147.2. Jeigu pagal užsakymą sukurtoje programinėje įrangoje panaudota kita autoriaus teisių turėtojo ar trečiųjų šalių programinė įranga, kuri integruota į pagal užsakymą sukurtą programinę įrangą ar kitaip susieta su atliktu užsakymu ir autoriaus turtinių teisių į sukurtą programinę įrangą ar parengtus projektinius dokumentus, perdavimas Perkančiajai organizacijai, užsakiusiai sukurti programinę įrangą ar parengti projektinius dokumentus, neturi apriboti šias teises perdavusio Paslaugų teikėjo teisės be atskiro Perkančiosios organizacijos sutikimo toliau vystyti, tobulinti, platinti ir atlikti kitus reikiamus veiksmus su sukurta programine įranga ar parengtais projektiniais dokumentais.
147.3. Kartu su kompiuterine programa, kaip ši sąvoka apibrėžta Lietuvos Respublikos autorių teisių ir gretutinių teisių įstatyme, užsakovui perduodamas ir programos išeitinis kodas. Kompiuterių programos autoriaus asmeninės neturtinės teisės negali būti naudojamos tokiu būdu, kuris suvaržytų autorių turtinių teisių į šią kompiuterinę programą turėtojo teises, tarp jų ir teisę savo nuožiūra adaptuoti, keisti ir neatlygintinai platinti šiuos kūrinius. Šiame punkte numatytos autorių turtinės teisės, vadovaujantis Lietuvos Respublikos Autorių teisių ir gretutinių teisių įstatymo ir Valstybės informacinių išteklių valdymo įstatymo 12 str. nuostatomis, perduodamos ir suteikiamos Lietuvos Respublikos ir Europos Sąjungos šalių teritorijoje neribotam laikui.
148. Paslaugų teikėjas neturi teisės atskleisti jokios su paslaugų teikimu susijusios informacijos trečiosioms šalims be Perkančiosios organizacijos raštiško leidimo arba jei to reikalauja įstatymai.