Grįžti į sąrašą

STEAM informacinės sistemos STEAM mobilių įrangos paketų valdymo komponento sukūrimas

Išanalizuota

Lietuvos neformaliojo švietimo agentūra

Skelbiama apklausaCPV: 72511000 - Tinklo valdymo programinės įrangos paslaugos
ID: 68726002026-03-10 09:17Pasiūlymai iki: 2026-03-17 09:00
Atidaryti CVP IS

Aprašymas

Perkančioji organizacija siekia sukurti ir integruoti STEAM mobilių įrangos paketų (MĮP) valdymo komponentą į jau veikiančią STEAM informacinę sistemą. Šis komponentas leis valdyti MĮP konfigūracijas, viešinti informaciją, administruoti turinį bei efektyviai teikti ir tvarkyti MĮP rezervacijas. Projektas skirtas palengvinti modernių edukacinių priemonių prieinamumą Lietuvos mokykloms ir sustiprinti STEAM ugdymo kokybę.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas per paskutinius 3 (trejus) metus iki pasiūlymų pateikimo termino pabaigos (arba nuo įregistravimo dienos, jei veiklą vykdo trumpiau) turi būti tinkamai įvykdęs bent 1 (vieną) informacinių sistemų ar skaitmeninės edukacinės priemonės sukūrimo projektą, kurio vertė ne mažesnė kaip 30 000 Eur be PVM.
  • 2Tiekėjas turi pasiūlyti paslaugas teiksiančių specialistų komandą, kuri būtų kompetentinga kokybiškai teikti perkamas paslaugas bei atitiktų žemiau nurodytus kvalifikacijos reikalavimus. Visi specialistai turi gebėti gerai rašyti, kalbėti ir suprasti lietuvių kalbą (jei lietuvių kalba nėra gimtoji, ne žemesnis, kaip C1 lygis pagal Europass kalbų pasą).
  • 3Projekto vadovas turi aukštąjį (ar jam prilygintiną) išsilavinimą ir per paskutinius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos vadovavo ar koordinavo ne mažiau kaip 3 Informacinės sistemos ir/ar skaitmeninės edukacinės priemonės kūrimo ar plėtros projektams, kuriuose buvo atlikta bent viena iš šių veiklų: funkcinių ir/ar techninių reikalavimų valdymas ir suderinimas su užsakovu; projekto planavimas, apimties kontrolė ir komunikacija su perkančiąja organizacija.
  • 4Informacinių technologijų specialistas per paskutinius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos turi informacinių technologijų specialisto patirties kuriant ir/ar atnaujinant ne mažiau kaip 1 (vieną) informacinę sistemą ir/ar skaitmeninę mokymo priemonę.
  • 5Vartotojo / naudotojo sąsajos dizaineris (UI/UX) per paskutinius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos turi vartotojo / naudotojo sąsajos kokybės vertinimo patirties įgyvendinant ne mažiau kaip 1 (vieną) informacinės sistemos sukūrimo ir/ar skaitmeninės mokymo priemonės projektą, kurio metu kūrė vartotojo / naudotojo sąsają ir atliko kokybės vertinimą.
  • 6Informacinių sistemų analitikas / architektas per paskutinius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos turi patirtį įgyvendinant ne mažiau kaip 1 (vieną) projektą dokumentuojant integracijas (UML, BPMN ar lygiaverčius procesų modeliavimo metodus) ir turi IT/inžinerijos išsilavinimą arba lygiavertes kompetencijas.

Techniniai reikalavimai

Mokymai

  • 1Diegėjas kartu su PO turi parengti, suderinti ir patvirtinti mokymų dalyvių sąrašus bei pagal poreikį suformuoti mokymų grupes.
  • 2Diegėjo vedamų mokymų grupių dydis turi neviršyti 20 dalyvių, nebent PO raštu nurodo kitokį maksimalų grupės dydį.
  • 3Diegėjas turi užtikrinti, kad mokymams būtų parengta nuo gamybinės aplinkos atskirta aplinka, įskaitant prieigas ir visas kitas mokymams būtinas priemones.
  • 4Diegėjas privalo vesti mokymus ir parengti mokymų medžiagą lietuvių kalba, užtikrindamas aiškų ir suprantamą medžiagos pateikimą.
  • 5Diegėjas turi neuždrausti PO filmuoti ar fotografuoti mokymų, laikantis BDAR reikalavimų dėl nuotraukų ir vaizdo medžiagos saugojimo bei naudojimo.
  • 6Diegėjas privalo parengti mokymų programą ir mokymų medžiagą, ją suderinti su PO, o medžiagoje naudoti aiškius pavyzdžius su IS ekrano vaizdais; galutinė mokymų programa turi būti suderinta ne vėliau kaip likus 5 darbo dienoms iki mokymų pradžios, jei PO nenustato kitokio termino.
  • 7Diegėjas turi pasirūpinti mokymų dalyvių registracija kiekvienos mokymo sesijos metu, fiksuodamas dalyvavimą.
  • 8Diegėjas turi užtikrinti, kad mokymų metu dalyvautų kompetentingi jo atstovai, galintys atsakyti į visus su diegiama IS susijusius klausimus.

Testavimas

  • 1Tiekėjas turi parengti išsamų testavimo planą, apimantį testavimo strategiją, aprėptį, naudojamas testavimo aplinkas, atsakomybes ir grafikus, taip pat turi parengti detalius testavimo scenarijus.
  • 2Testavimo planas ir scenarijai turi būti suderinti su PO prieš testavimo pradžią.
  • 3Testavimas turi būti atliekamas vadovaujantis suderintais testavimo scenarijais ir etapais, numatytais testavimo plane, dalyvaujant PO atstovams ir užtikrinant, kad testavimo rezultatai būtų fiksuojami realiu laiku.
  • 4Vidinis testavimas turi būti vykdomas nuosekliai diegimo metu ir turi būti pilnai užbaigtas iki priėmimo testavimo pradžios, užtikrinant, kad į priėmimo testavimą nepatektų neištestuotos ar nestabilios funkcijos.
  • 5Testavimo proceso metu turi būti atliktas visų sukurtų informacinės sistemos elementų testavimas, patvirtinantis jų atitiktį specifikacijoje apibrėžtiems reikalavimams.
  • 6Integruotos sistemos funkcinis testavimas turi užtikrinti, kad sukurtas komponentas kaip visuma atitinka veiklos procesus, duomenų srautus ir numatytą logiką.
  • 7Testavimo metu turi būti tikrinama, ar komponentas pilnai atlieka visas numatytas funkcijas, ar jo elgsena yra stabili ir atitinka reikalavimus, įskaitant kraštinių atvejų, neleistinų įvesčių ir gedimų scenarijų testavimą.
  • 8Testavimo metu elektroniniu būdu turi būti pildomas klaidų, neatitikimų ir problemų registravimo žurnalas, fiksuojant aptiktų klaidų aprašymus, būsenas, sprendimo terminus ir atsakingus asmenis; žurnalą turi turėti galimybę pildyti visi testavime dalyvaujantys asmenys.
  • 9Baigus priėmimo testavimą diegėjas turi parengti testavimo ataskaitą, kurioje būtų pateiktas visų testuotų scenarijų sąrašas, jų įvykdymo rezultatai, rastos ir ištaisytos klaidos bei likę neatitikimai.
  • 10Testavimas turi būti atliekamas izoliuotoje testavimo aplinkoje, atskirtoje nuo gamybinės sistemos.

Dokumentacija

  • 1Visi Projekto metu derinami ir tvirtinami dokumentai turi būti rengiami ir pateikiami lietuvių kalba.
  • 2Techniniai aprašai turi būti pateikiami lietuvių kalba, tačiau įvairūs techniniai protokolai ar techniniai tekstai gali būti pateikiami anglų kalba, kitos kalbos pateikimą iš anksto suderinus su PO.
  • 3Rengiama dokumentacija turi būti išsami ir iliustruota naudotojo sąsajos paveikslėliais ar filmuotu ekrano vaizdu su komentarais.
  • 4Visi dokumentai ir kita Užsakovui pateikiama medžiaga turi būti elektroniniame pavidale (MS Word arba kitu, su PO suderintu, formatu).

Licencijavimas

  • 1Diegėjo sukurtos IS programinės įrangos dalies licencijos turi būti neriboto galiojimo laikotarpio ir turi turėti kitus būtinus leidimus naudoti ir redaguoti programinę įrangą.
  • 2Visų kuriamos programinės įrangos licencijų mokesčiai ir licencijų kaina turi būti įskaičiuoti į pasiūlymo į kainą.
  • 3Visų sukurtų programinės įrangos komponentų naudojimas ir priežiūra negali ribojama autorių teisių ar kitų teisės aktų.

Bendrai sistemai

  • 1MĮP posistemė turi būti integruojama į jau veikiančią STEAM platformą ir veikti laikantis esamos sistemos architektūros principų.
  • 2Posistemės funkcionalumas turi papildyti jau veikiančias platformos funkcijas ir naudoti bendrus platformos komponentus bei paslaugas.
  • 3Turi būti užtikrintas suderinamumas su esama STEAM platformos technologine architektūra, duomenų struktūra ir naudotojų valdymo mechanizmais.
  • 4Posistemė turi naudoti bendrą platformos autentifikavimo ir autorizavimo infrastruktūrą bei bendrą naudotojų paskyrų valdymo sistemą.
  • 5Turi būti užtikrintas duomenų vientisumas, suderinamumas ir saugus apsikeitimas informacija tarp MĮP posistemės ir kitų STEAM platformos komponentų.
  • 6Architektūriniai sprendimai turi sudaryti galimybę ateityje plėsti MĮP funkcionalumą, nekeičiant pagrindinių STEAM platformos komponentų.
  • 7Projektuojant posistemę turi būti atsižvelgiama į bendrus platformos veikimo principus, naudotojo sąsajos logiką ir duomenų valdymo modelį.
  • 8MĮP posistemės duomenų bazės struktūra turi būti suprojektuota ir įgyvendinta pagal 1 paveiksle pateiktą pavyzdinę DB struktūros diagramą.
  • 9Santykinės duomenų bazės lentelės turi būti normalizuotos taip, kad būtų išvengta duomenų dubliavimo, o ryšiai tarp esybių būtų apibrėžti per pirminius ir išorinius raktus.
  • 10Kiekvienai esybei turi būti numatyti unikalūs identifikatoriai, o kritiniams laukams – unikalumo apribojimai.

IS eksploatavimas

  • 1Programinės įrangos modifikavimas, tobulinimas ir klaidų taisymas negali turėti įtakos anksčiau įvestų duomenų vientisumui.
  • 2Sistema turi būti įdiegta ir eksploatuojama esamos STEAM platformos infrastruktūroje, nekeičiat platformos veikimo logikos ir nebloginant kitų platformos dalių našumo, stabilumo ar saugos.
  • 3Sistema turi užtikrinti prieinamumą ne mažesnį kaip 99,5 % per kalendorinį mėnesį, neskaičiuojant planinių priežiūros langų, apie kuriuos informuojama iš anksto.
  • 4Sistema turi palaikyti planinių priežiūros darbų vykdymą, numatant priežiūros langus, atnaujinimus ir grąžinimo (angl. rollback) galimybę, jei po atnaujinimo nustatomi kritiniai sutrikimai.
  • 5Sistema turi užtikrinti našumą taip, kad įprastomis apkrovomis pagrindiniai viešos dalies puslapiai būtų pateikiami per 2 sek. ir neviršytų esamos platformos nustatytų našumo ribų.
  • 6Sistema turi užtikrinti horizontalios arba vertikalios plėtros galimybę (angl. scalability) esamos platformos kontekste, didėjant turinio kiekiui (naujienos, renginiai, nuotraukos) ir lankytojų srautui.
  • 7Sistema turi būti suderinama su esamos platformos atsarginių kopijų (angl. backup) politika, užtikrinant, kad MĮP turinys patektų į atsargines kopijas ir būtų atkuriamas kartu su visa platforma.
  • 8Sistema turi būti stebima (angl. monitoring) pagal esamus platformos stebėsenos sprendimus, renkant pagrindinius veikimo rodiklius (pvz., klaidų skaičius, atsako laikas, resursų panaudojimas) ir užtikrinant incidentų identifikavimą.
  • 9Sistema turi užtikrinti konfigūracijų valdymą taip, kad visi aplinkos nustatymai (pvz., žemėlapio teikėjo raktai, el. pašto nustatymai, talpyklos parametrai) būtų valdomi konfigūracijose ir nebūtų „kietai įrašyti“ (angl. hardcode) programiniame kode.
  • 10Sistema turi užtikrinti, kad diegimo metu būtų išlaikytas esamos platformos vizualinis vientisumas, laikantis bendrų dizaino ir prieinamumo principų, o nauji puslapiai ir komponentai būtų suderinti su bendra platformos vartotojo sąsaja.
  • 11Sistema turi užtikrinti talpyklos (angl. cache) naudojimo suderinamumą su platforma, kad būtų pasiektas optimalus greitis viešoje dalyje ir nebūtų pateikiamas pasenęs turinys ilgiau nei leidžia platformos taisyklės.
  • 12Sistema turi užtikrinti testavimo aplinką ir diegimo praktiką, kad prieš įkeliant pakeitimus į gamybinę aplinką jie būtų patikrinti testavimo aplinkoje, įskaitant regresinį testavimą (ypač žemėlapio, filtravimo, galerijų ir sutikimų logikos).

Sandėlio valdymas

  • 1MĮP posistemėje turi būti įgyvendintas priemonių sandėlio valdymo funkcionalumas, skirtas registruoti ir administruoti MĮP sudėtyje esančias priemones, jų kiekius ir būklę.
  • 2Sandėlio valdymo duomenų bazės struktūra turi būti suprojektuota ir įgyvendinta pagal 3 paveiksle pateiktą pavyzdinę DB struktūros diagramą.
  • 3Sistema turi sudaryti galimybę kiekvienam MĮP apibrėžti standartinę komplektaciją – priemonių sąrašą su jų pavadinimais, aprašais ir kiekiais.
  • 4Priemonių sandėlio funkcionalumas turi sudaryti galimybę registruoti kiekvienos priemonės tipą, identifikatorių, aprašą, kiekį MĮP komplekte ir kitą komplektacijos valdymui reikalingą informaciją.
  • 5Sistema turi sudaryti galimybę STEAM centro darbuotojui per administravimo aplinką peržiūrėti konkretaus MĮP priemonių sąrašą ir jo komplektacijos būseną.
  • 6Grąžinus MĮP iš mokyklos, sistema turi sudaryti galimybę STEAM centro darbuotojui atlikti MĮP komplektacijos patikrą, pažymint ar visos priemonės yra vietoje.
  • 7Jeigu patikros metu nustatoma, kad tam tikrų priemonių trūksta, jos sugadintos arba sunaudotos, sistema turi sudaryti galimybę registruoti trūkstamų ar sugadintų priemonių faktą.
  • 8Sistema turi sudaryti galimybę registruoti sunaudojamų priemonių papildymą, pažymint papildytą kiekį ir papildymo datą.
  • 9Priemonių sandėlio funkcionalumas turi leisti matyti priemonių likučius ir identifikuoti priemones, kurių kiekis yra mažesnis nei nustatytas minimalus kiekis. Minimalūs priemonių kiekiai turi būti parametrizuojami ir valdomi sistemos administravimo aplinkoje.
  • 10Sistema turi sudaryti galimybę registruoti priemonių papildymo ar pakeitimo operacijas ir susieti jas su konkrečiu MĮP.
  • 11Visi priemonių sandėlio operacijų veiksmai, įskaitant patikrą, papildymą, keitimą ar trūkumų registravimą, turi būti registruojami sistemos veiksmų audite.
  • 12Visa priemonių sandėlio istorija, susijusi su MĮP, turi būti matoma sistemos administravimo aplinkoje ties kiekvieno MĮP duomenų peržiūra.

Rezervacijos procesas

  • 1Rezervacijos procesas turi sudaryti galimybę STEAM platformos vidiniams naudotojams planuoti MĮP naudojimą, o STEAM centro darbuotojams – administruoti rezervacijas ir valdyti jų vykdymą.
  • 2Rezervacijos procesas turi būti realizuotas MĮP posistemėje kaip standartizuotas procesas.
  • 3Vidinis naudotojas turi turėti galimybę inicijuoti rezervaciją iš pasirinkto MĮP vizitinės kortelės per funkciją „Rezervuoti“.
  • 4Rezervacijos forma turi leisti naudotojui pateikti pagrindinę rezervacijai reikalingą informaciją, įskaitant pageidaujamą MĮP naudojimo laikotarpį, mokyklą ar organizaciją, atsakingo asmens kontaktinius duomenis ir kitą rezervacijos administravimui reikalingą informaciją.
  • 5Naudotojas turi turėti galimybę pateikti papildomus komentarus ar pastabas.
  • 6Rezervacijos formoje turi būti atsižvelgiama į minimalias ir maksimalias leistinas MĮP rezervacijos trukmes.
  • 7Pateikus rezervacijos formą, sistemoje turi būti sukuriamas rezervacijos įrašas su būsena „pateikta“, o rezervacija turi būti matoma atitinkamo STEAM centro administravimo aplinkoje.
  • 8Sistemos administravimo aplinkoje STEAM centro darbuotojui turi būti galimybė inicijuoti išankstinės sąskaitos už MĮP nuomą generavimą ir automatinį išsiuntimą rezervaciją atlikusio asmens nurodytu el. pašto adresu.
  • 9STEAM centro darbuotojas administravimo aplinkoje turi turėti galimybę matyti visų jo atstovaujamo STEAM centro MĮP rezervacijų sąrašą.
  • 10STEAM centro darbuotojui turi būti suteikta galimybė per administravimo aplinką patvirtinti rezervaciją, atmesti rezervaciją, pažymėti rezervaciją kaip įvykdytą arba ją atšaukti.
  • 11Visi veiksmai, atliekami su rezervacijos įrašu (pvz. būsenos keitimas, redagavimas), turi būti fiksuojami sistemos veiksmų audite su galimybe peržiūrėti audito įrašus administravimo aplinkoje.
  • 12Pateikus rezervaciją MĮP užimtumo kalendoriuje tokia rezervacija turi būti laikoma galiojančia ir rezervuotas laikotarpis turi būti laikomas užimtu konkrečiam MĮP. Tokiu laikotarpiu MĮP neturi būti prieinamas kitoms rezervacijoms.
  • 13STEAM centro darbuotojas turi turėti galimybę redaguoti rezervacijos duomenis per administravimo aplinką.
  • 14Sistemoje rezervuojant MĮP turi būti numatytas papildomas rezervacijos laikotarpis prieš ir po rezervacijos, skirtas MĮP pervežimui ir aptarnavimui. Aptarnavimo laikotarpiai prieš rezervacijos pradžią bei po jos turi būti parametrizuoti ir valdomi sistemos administravimo aplinkoje kiekvienam MĮP atskirai.
  • 15Sistemoje turi būti numatyta galimybė koreguoti rezervacijos laikotarpį, užtikrinant, kad pakeistas laikotarpis nesikirstų su kitomis patvirtintomis to paties MĮP rezervacijomis ar joms skirtais aptarnavimo laikotarpiais.
  • 16Rezervacijos būsena turi būti matoma tiek rezervaciją pateikusiam naudotojui, tiek STEAM centro darbuotojui administravimo aplinkoje.
  • 17Vidinis sistemos naudotojas turi vienoje vietoje matyti visas jo būsimas ir buvusias rezervacijas bei jų būsenas.
  • 18Visi rezervacijos sukūrimo, redagavimo ir būsenos pakeitimo veiksmai turi būti registruojami sistemoje.

Užimtumo kalendorius

  • 1MĮP posistemėje turi būti įgyvendintas MĮP užimtumo kalendorius, skirtas vizualiai atvaizduoti MĮP prieinamumą ir rezervacijų laikotarpius.
  • 2Užimtumo kalendoriuje turi būti atvaizduojami visi sistemoje registruoti MĮP rezervacijų laikotarpiai, įskaitant rezervacijos laiką ir papildomus aptarnavimo laikotarpius prieš ir po rezervacijos.
  • 3Kalendorius turi būti prieinamas vidiniams sistemos naudotojams per MĮP vizitinę kortelę ir turi leisti peržiūrėti konkretaus MĮP užimtumą pasirinktame laikotarpyje.
  • 4Kalendoriuje turi būti aiškiai vizualiai atskiriami skirtingi MĮP užimtumo laikotarpiai, tokie kaip rezervuotas laikotarpis, transportavimo laikotarpis ir aptarnavimo laikotarpis.
  • 5Kalendoriaus sąsajoje turi būti galimybė peržiūrėti MĮP užimtumą skirtingais laiko intervalais, pavyzdžiui dienos, savaitės ar mėnesio peržiūrose.
  • 6Sistemos naudotojui inicijuojant rezervaciją turi būti sudaryta galimybė per kalendorių matyti MĮP užimtumą ir pasirinkti tik tuos laikotarpius, kurie nėra užimti kitomis rezervacijomis ar aptarnavimo laikotarpiais.
  • 7Kalendorius turi užtikrinti, kad laikotarpiai, kurie jau yra rezervuoti arba skirti MĮP transportavimui ar aptarnavimui, būtų laikomi užimtais ir nebūtų prieinami naujoms rezervacijoms.
  • 8STEAM centro darbuotojas administravimo aplinkoje turi turėti galimybę per kalendoriaus sąsają peržiūrėti MĮP rezervacijų grafiką ir identifikuoti laisvus bei užimtus laikotarpius.
  • 9Kalendoriaus duomenys turi būti sinchronizuojami su rezervacijų valdymo funkcionalumu taip, kad rezervacijos sukūrimas, redagavimas ar atšaukimas automatiškai atsispindėtų MĮP užimtumo kalendoriuje.
  • 10Užimtumo kalendorius turi būti naudojamas kaip pagrindinė priemonė planuojant MĮP prieinamumą ir užtikrinant, kad skirtingos rezervacijos nesikirstų tarpusavyje.
  • 11Posistemėje taip pat turi būti bendras visų MĮP užimtumo kalendorius su galimybe filtruoti MĮP pagal STEAM centrus, mokymo dalykus ir klases.

Bandomoji eksploatacija

  • 1Posistemės įvedimo į eksploataciją etape turi būti vykdoma bandomoji eksploatacija gamybinėje aplinkoje, kurioje visi paslaugų naudotojai realiomis sąlygomis naudoja sistemą taip, kaip ji bus naudojama vykdant PO veiklos procesus ir teikiant paslaugas.
  • 2Bandomosios eksploatacijos laikotarpiu Diegėjas turi nuotoliniu būdu teikti pagalbą visiems IS naudotojams, operatyviai atsakydamas į klausimus ir padėdamas spręsti iškilusias problemas.
  • 3Bandomoji eksploatacija trunka ne mažiau kaip 30 kalendorinių dienų; jei iki šio termino pabaigos Diegėjas nėra ištaisęs visų bandomosios eksploatacijos metu užfiksuotų ir jam perduotų klaidų, bandomosios eksploatacijos laikotarpis pratęsiamas tol, kol visos žinomos klaidos bus ištaisytos ir sistema atitiks numatytus reikalavimus.

Garantinis aptarnavimas

  • 1Garantinės priežiūros objektas yra pagal šio konkurso sąlygas įdiegtas funkcionalumas esamoje IS. Garantinės priežiūros paslaugos apima projekto metu sukurtos programinės įrangos neatitikimų techninei specifikacijai, klaidų ir kitų veikimo sutrikimų šalinimą.
  • 2Programinės įrangos veikimo sutrikimu laikoma situacija kai IS naudotojai dėl Diegėjo sukurtos programinės įrangos funkcionalumo trūkumų negali atlikti numatytų IS funkcijų arba funkcijos vykdomos nekorektiškai.
  • 3Visos STEAM IS veikimo klaidos ir (ar) trikdžiai klasifikuojami: Veiklą blokuojanti klaida (kai IS apskritai nefunkcionuoja ar funkcionuoja netinkamai), Kritinė klaida (kai vidinis naudotojas negali vykdyti numatytų būtinų funkcijų ir nežinomas joks kitas alternatyvus šios funkcijos vykdymas, arba kai bent viena veiklos procesui būtina funkcija neveikia 10 proc. ir daugiau išorinių naudotojų, tinkamai nefunkcionuoja kuri nors IS integracija), Klaida (kai nustatytas trikdis ir (ar) problema, kuri kliudo vidiniam naudotojui vykdyti būtinas funkcijas, tačiau yra žinomas alternatyvus funkcijos vykdymas, arba kai nustatytas trikdis ir (ar) problema, kuri sukelia sunkumus naudojantis IS, bet neturi įtakos IS funkcijų veikimui ir nedaro jokio kito poveikio IS, arba, kai klaida nežymiai paveikia mažiau nei 10 proc. išorinių IS naudotojų).
  • 4Diegėjas privalo išanalizuoti trikdį ir (ar) Klaidą/ Kritinę klaidą ir numatyti jos pašalinimo būdą ne vėliau, kaip per 1 darbo valandą nuo jos užregistravimo Tiekėjo pateiktame klaidų registre.
  • 5Veiklą blokuojančios klaidos ir (ar) trikdžiai sprendžiami atskirai suderintais klaidų šalinimo terminais, tačiau ne ilgiau nei per 1 darbo valandą.
  • 6Kritinės klaidos ir (ar) trikdžiai sprendžiami atskirai suderintais klaidų šalinimo terminais, tačiau ne ilgiau nei per 6 darbo valandas.
  • 7Klaidos ir (ar) trikdžiai sprendžiami atskirai suderintais klaidų šalinimo terminais, tačiau ne ilgiau nei per 14 dienų po incidento užfiksavimo.
  • 8IS klaidos ir kritinės klaidos turi būti registruojamos šalių suderintame klaidų registre, pagal su PO suderintą incidentų sprendimo seką (angl. workflow).
  • 9Informacija apie pašalintas (pataisytas) klaidas ir (ar) trikdžius turi būti atnaujinama ir pateikiama kartą per mėnesį.
  • 10Garantinė priežiūra turi apimti Lietuvos Respublikos Civiliniame kodekse numatomas garantinės priežiūros teises.

MĮP vizitinė kortelė

  • 1Kiekvienam MĮP turi būti sukuriama ir sistemoje pateikiama standartizuotos struktūros vizitinė kortelė, kurioje pateikiama pagrindinė informacija apie MĮP.
  • 2Vizitinę kortelę turi sudaryti šie laukai: Mokymo dalykas, Kryptys ir sritys, Pavadinimas, Turimas kiekis STEAM centre, Būsena, Vieta, Veiklos trukmė, Rekomenduojamas mokinių skaičius vienai veiklai, Komplektacijos dydis, Raktiniai žodžiai, Aprašymas, Vizualas ar pagrindinė iliustracinė nuotrauka, Papildomi poreikiai, BUP ryšys, STEAM centras, kuriame MĮP tvarkomas, Klasių intervalas, LEAN lapas su galimybe jį atsisiųsti į kompiuterį arba peržiūrėti naršyklėje, Nuomos sąlygos.
  • 3Vizitinė kortelė turi būti pasiekiama visiems sistemos vidiniams naudotojams per MĮP katalogą ir turi būti pateikiama kaip pagrindinis informacijos šaltinis prieš inicijuojant MĮP rezervavimą ar užsakymą.
  • 4Vizitinėje kortelėje turi būti pateikiama informacija apie MĮP prieinamumą ir galimybę inicijuoti rezervaciją arba užsakymą per MĮP posistemę.
  • 5Vizitinės kortelės struktūra turi būti vienoda visiems sistemoje pateikiamiems MĮP.
  • 6Vizitinės kortelės turinys turi būti administruojamas per MĮP posistemės administravimo funkcijas.
  • 7Sistemoje turi būti galimybė administruoti MĮP galiojimą, nurodant MĮP galiojimo pradžios ir pabaigos datas.
  • 8Negaliojantys MĮP neturi būti rodomi vidiniams naudotojams.
  • 9Turi būti galimybė administruoti kiekvieno MĮP būsenas ir rezervacijas, naudojant MĮP posistemės administravimo funkcijas.
  • 10Administravimo aplinkoje turi būti nustatyti minimalų ir maksimalų rezervacijos laikotarpį dienomis kiekvienam MĮP atskirai.
  • 11Kiekvienam MĮP sistemoje turi būti priskiriama viena iš nustatytų būsenų: laisvas, išsiųstas, naudojamas mokykloje, grąžintas, aptarnaujamas, sugedęs arba remontuojamas.
  • 12MĮP būsenos turi būti keičiamos rankiniu būdu per posistemės administravimo aplinką, o teisę keisti MĮP būseną turi turėti tik įgalioti STEAM centro darbuotojai ar kiti administravimo teises turintys sistemos naudotojai.
  • 13STEAM centro darbuotojai turi galėti administruoti tik savo centrui priskirtus MĮP. Visus MĮP administruoti gali tik sistemos administratorius.
  • 14Sistema turi užtikrinti, kad vienu metu MĮP galėtų turėti tik vieną aktyvią būseną, o kiekvienas būsenos pakeitimas būtų registruojamas sistemoje.
  • 15MĮP būsenos turi būti naudojamos MĮP kataloge ir administravimo aplinkoje.

Turinio skaitmenizavimas

  • 1Tiekėjas turi atlikti MĮP turinio skaitmenizavimo darbus ir užtikrinti, kad skaitmenizuota informacija būtų parengta bei patalpinta MĮP posistemėje.
  • 2Skaitmenizavimo darbai turi apimti MĮP aprašų, metodinės informacijos ir susijusios medžiagos perkėlimą iš užsakovo pateiktos medžiagos į MĮP posistemę, užtikrinant, kad informacija būtų pateikta struktūrizuotu ir naudotojui suprantamu formatu.
  • 3Tiekėjas turi skaitmenizuoti ir sistemoje patalpinti ne mažiau kaip 10 MĮP, kiekvienam MĮP sukuriant pilnai užpildytą vizitinę kortelę ir susijusią informaciją pagal MĮP posistemės duomenų struktūrą.
  • 4Skaitmenizuojant MĮP turinį turi būti užtikrinama, kad visa informacija būtų sukelta į sistemą naudojant tam skirtas MĮP posistemės administravimo funkcijas ir atitiktų sistemoje apibrėžtą duomenų struktūrą.
  • 5Kiekvienam MĮP turi būti sukelta pagrindinė informacija, įskaitant MĮP pavadinimą, teminę sritį, trumpą aprašą (anotaciją), rekomenduojamą mokinių amžių ar klasių intervalą, susijusius mokomuosius dalykus ir kitą vizitinės kortelės informaciją.
  • 6Skaitmenizavimo metu turi būti patalpinta vizualinė medžiaga, susijusi su MĮP, pavyzdžiui MĮP nuotraukos ar iliustracijos, jei tokia medžiaga yra pateikiama Užsakovo.
  • 7Jeigu Užsakovas pateikia vizualinę medžiagą fragmentuotai, Tiekėjas turi struktūrizuoti ir apipavidalinti Užsakovo pateiktą medžiagą į vieningos struktūros vizualinę informaciją ir ją patalpinti į MĮP vizitinę kortelę.
  • 8Jeigu užsakovas pateikia papildomą metodinę ar instrukcinę medžiagą (pvz., naudojimo instrukcijas, metodinius aprašus ar kitus dokumentus), tiekėjas turi užtikrinti šios medžiagos skaitmeninimą ir patalpinimą MĮP posistemėje kaip susijusius MĮP turinio elementus.
  • 9Skaitmenizuotas turinys turi būti suformuotas taip, kad jis būtų tinkamai atvaizduojamas MĮP kataloge, vizitinėse kortelėse ir kituose MĮP posistemės moduliuose.
  • 10Tiekėjas turi užtikrinti, kad į sistemą įkelta informacija būtų suredaguota, struktūrizuota ir patikrinta prieš jos pateikimą galutiniams naudotojams.
  • 11Prieš publikuojant skaitmenizuotą MĮP turinį galutiniams sistemos naudotojams, tiekėjas turi pateikti parengtą turinį užsakovui peržiūrai ir suderinimui.
  • 12Užsakovui turi būti sudaryta galimybė peržiūrėti sistemoje patalpintą MĮP informaciją ir pateikti pastabas dėl turinio struktūros, pateikimo ar informacijos tikslumo.
  • 13Tiekėjas turi įvertinti užsakovo pateiktas pastabas ir, esant poreikiui, atlikti MĮP turinio patikslinimus ar koregavimus. Patikslinimai ir korekcijos gali būti atliekami ne daugiau kaip per 3 iteracijas.

Saugumas ir konfidencialumas

  • 1Duomenų perdavimas ir saugomi duomenys turi būti apsaugoti nuo sąmoningo iškraipymo.
  • 2Visi Sistemoje saugojami asmens ir kiti jautrūs duomenys privalo būti šifruojami. Šifravimo priemonės turės būti parenkamos ir suderintos su PO priklausomai nuo duomenų jautrumo lygio, greitaveikos poreikių ir kitų faktorių. Taip pat turės atitikti aktualius susijusius Europos sąjungos ir nacionalinius reglamentus ir direktyvų reikalavimus, sprendinius suderinus su PO.
  • 3Sistemos naudojamos administracinės, organizacinės ir teisinės priemonės turi užtikrinti duomenų konfidencialumą (duomenis turi tvarkyti ir naudoti tik tie asmenys, kuriems yra suteikiamos atitinkamos teisės) ir duomenų prieinamumą (duomenys ir komponentai turi būti prieinami tik naudotojams turintiems tam teisę).
  • 4Duomenų sauga turi būti užtikrinama užtikrinant duomenų vientisumą ir neprieštaringumą, darbui su moduliais IS naudotojus suskirstant į grupes pagal duomenų tvarkymo pobūdį, kai kuriems iš jų suteikiant specialiąsias teises (roles) atlikti tam tikrus tvarkymo veiksmus.
  • 5Saugoma informacija negali būti ištrinta jokiais kitais būdais ar aplinkybėmis, išskyrus PO numatytais atvejais.
  • 6Visi naudotojai, dirbantys su Sistema, turi būti autentifikuoti ir valdomi centralizuotai.
  • 7IS naudotojų vardai, telefonai, kiti asmens duomenys, kuriems taikomos duomenų apsaugos įstatymo nuostatos, slaptažodžiai turi būti saugomi su tinkamu prieigos kontrolės užtikrinimu duomenų bazės lygmenyje.
  • 8IS, veikdama darbiniame režime, privalo užtikrinti, kad įvykus nenumatytam įvykiui ar klaidai pateiks tik ribotą informaciją, kuri negalėtų būti panaudojama įsilaužiant į sistemą.
  • 9Visi realizuojami moduliai turi būti susieti audito ir saugos moduliu, įgyvendinančiu veiksmų registravimo ir kontrolės mechanizmą (angl. audit trail).
  • 10IS privalo užtikrinti tinkamą įvedimo laukų tikrinimą apsaugant nuo trečiųjų šalių pateikto programinio kodo vykdymo ar neleidžiamos peržiūrėti informacijos pateikimo (pvz., XSS (angl. cross-site scripting) ar SQL injekcijos (angl. SQL injection) atakos).
  • 11IS turi būti apsaugota nuo paskirstytų ir daug resursų reikalaujančių atakų (angl. distributed denial of service – DdoS). Turi būti parinktas toks sprendimas, kad viešai prieinamiems sistemos komponentams vykdant DdoS ataką nesutriktų visos IS veikla.

Vieningas naudotojų valdymas

  • 1Vieningo naudotojų valdymo mechanizmas turi būti taikomas ir kuriamoje MĮP posistemėje, užtikrinant, kad visi naudotojai būtų valdomi naudojant jau veikiančią STEAM platformos naudotojų valdymo infrastruktūrą.
  • 2MĮP posistemė turi naudoti esamą STEAM platformos autentifikavimo ir naudotojų paskyrų valdymo mechanizmą.
  • 3Posistemėje neturi būti kuriama atskira naudotojų registracijos ar paskyrų administravimo sistema.
  • 4Visi MĮP posistemės naudotojai turi būti tie patys naudotojai, kurie yra registruoti STEAM platformoje, o jų identifikavimas turi būti vykdomas naudojant platformoje naudojamus naudotojų identifikatorius.
  • 5Naudotojų autentifikavimas MĮP posistemėje turi būti vykdomas per bendrą STEAM platformos prisijungimo mechanizmą.
  • 6Prisijungus prie STEAM platformos, naudotojui turi būti suteikiama galimybė naudotis MĮP posistemės funkcijomis pagal jam priskirtas teises, nereikalaujant papildomo autentifikavimo.
  • 7Naudotojų duomenys, tokie kaip vardas, pavardė, kontaktiniai duomenys, organizacija ar naudotojo vaidmuo, turi būti gaunami iš STEAM platformos naudotojų valdymo sistemos ir naudojami MĮP posistemėje be jų dubliavimo.
  • 8MĮP posistemėje turi būti naudojamas bendras naudotojų teisių ir vaidmenų modelis, suderintas su STEAM platformos naudotojų valdymo logika.
  • 9Naudotojų paskyrų kūrimas, redagavimas, aktyvavimas ir pašalinimas turi būti atliekamas per centrinę STEAM platformos naudotojų administravimo aplinką, o visi tokie pakeitimai turi automatiškai atsispindėti MĮP posistemėje.
  • 10Naudotojui panaikinus prieigą prie STEAM platformos, jo prieiga prie MĮP posistemės turi būti panaikinama automatiškai.
  • 11MĮP posistemė turi užtikrinti, kad naudotojų duomenys būtų naudojami tik tiek, kiek būtina posistemės funkcijoms įgyvendinti.

Architektūra ir programinė įranga

  • 1Kuriami komponentai turi būti sukurti kaip nepriklausomi mikroservisai, veikiantys atskirai nuo esamos informacinės sistemos ir netrikdantys pagrindinės sistemos veikimo, jos apkrovos ar duomenų apdorojimo procesų.
  • 2Mikroserviso veikimas, klaidos ar prieinamumo sutrikimai neturi įtakoti pagrindinės sistemos stabilumo ar veikimo; sistemos komponentai turi būti atsparūs vienas kito sutrikimams (angl. fault isolation).
  • 3Mikroservisas turi būti diegiamas kaip atskiras komponentas, turintis galimybę dirbti su kitais mikroservisais per API be tiesioginės priklausomybės nuo esamos STEAM IS komponentų.
  • 4Mikroservisų sąveika turi būti realizuota naudojant REST API arba kitą plačiai naudojamą integracinėms sąsajoms skirtą protokolą, užtikrinant standartizuotus duomenų mainų formatus (JSON ar lygiaverčius).
  • 5Visi mikroserviso API turi būti dokumentuoti OpenAPI (pavyzdžiui, naudojant Swagger) ar lygiaverčiu formatu ir pateikti PO kartu su diegimu.
  • 6Mikroserviso duomenų saugojimas turi būti izoliuotas nuo pagrindinės sistemos: mikroservisas turi turėti savo duomenų bazę ar duomenų saugyklą, užtikrinant duomenų vientisumą ir nepriklausomumą.
  • 7Mikroserviso prieigos ir autorizavimo mechanizmai turi būti suderinti su esamos sistemos saugumo architektūra, bet diegiami taip, kad būtų įmanoma keisti mikroservisą nekeičiant kitos sistemos dalies.
  • 8Mikroserviso veikimas turi būti stebimas naudojant centralizuotą logų ir metrikų rinkimo mechanizmą, užtikrinant integraciją su esama monitoringo infrastruktūra (pvz., ELK, Prometheus ar lygiaverčiais).
  • 9Diegimo (angl. deployment) procesas turi būti nepriklausomas nuo pagrindinės sistemos diegimo proceso ir turi būti vykdomas atskirai.
  • 10Mikroservisas turi būti sukurtas taip, kad ateityje būtų galima jį pakeisti, išplėsti ar pašalinti nesutrikdant kitos sistemos veikimo ir nedarant pakeitimų esamos sistemos pagrindiniuose moduliuose.
  • 11Kuriamas mikroservisas turi turėti aiškiai apibrėžtas ribines sąsajas ir priklausomybes, kad būtų išvengta „tvirtų jungčių“ (angl. tight coupling) ir būtų išlaikytas architektūrinis lankstumas.
  • 12Visi MĮP posistemės funkciniai komponentai turi pilnai palaikyti Unicode (UTF-8) standartą, užtikrinant teisingą visų naudojamų kalbų simbolių apdorojimą, saugojimą ir atvaizdavimą.
  • 13Jeigu sutarties galiojimo metu kuriam nors kuriamos posistemės komponentui išleidžiama nauja programinės įrangos versija, diegėjas ją turi atnaujinti ne vėliau kaip per 3 mėnesius nuo oficialios versijos išleidimo datos, užtikrinant suderinamumą ir stabilų komponentų veikimą.
  • 14Sistemos architektūra turi būti grindžiama plačiai pripažintais ir rinkoje taikomais technologiniais standartais, tokiais kaip REST, SOA, JEE, OSGi, JMX, JPA, SSL, MTOM ar lygiaverčiais.
  • 15Visi sistemos komponentai turi būti tarpusavyje integruoti taip, kad būtų išlaikytas duomenų vientisumas, nuoseklumas ir vienareikšmiškumas, nepriklausomai nuo komponentų paskirties ar funkcionalumo.
  • 16Sistemos komponentų kūrimas turi būti atliekamas naudojant automatizuotus testus, o diegiamiems komponentams turi būti pateiktos automatizuotos testavimo galimybės, leidžiančios užtikrinti stabilų komponentų veikimą prieš juos įdiegiant.
  • 17Informacinės sistemos programinės įrangos surinkimo, komplektavimo, diegimo ir saugojimo (angl. deployment) priemonės turi būti tarpusavyje integruotos, nuoseklios ir lengvai valdomos, užtikrinant sklandų diegimo procesą.
  • 18Sistemos vidiniai parametrai turi būti prieinami stebėjimui ir keitimui, kad būtų galima identifikuoti veikimo sutrikimus, stebėti apkrovas ir atlikti konfigūracinius pakeitimus be sistemos darbo trikdžių.

Dokumentai12

  • Bendrosios sąlygos.docx
  • Skelbiamos paklausos specialiosios sąlygos.docx
  • Specialiųjų pirkimo sąlygų 6 priedas Suteiktų paslaugų sąrašas.docx
  • Sutarties projekto Specialiosios sąlygos.docx
  • 6872600_National Contract notice or Design Contest notice - general directive, standard regime_0.pdf
  • 3741_6872600.pdf
  • 4 priedas_Pasiūlymo forma.docx
  • 8. priedas_Tiekėjo_subtiekėjo deklaracija.docx
  • Bendrosios sutarties sąlygos.docx
  • Specialiųjų pirkimo sąlygų 2 priedas „Techninė specifikacija“.docx
  • Specialiųjų pirkimo sąlygų 5 priedas Siūlomų specialistų sąrašas.docx
  • 2_c4t_6872600_1.xml
tendis.lt · Sukurta recodin.lt