Grįžti į sąrašą

STEAM informacinės sistemos STEAM ambasadorių tinklaveikos komponento sukūrimas

Išanalizuota

Lietuvos neformaliojo švietimo agentūra

Skelbiama apklausaCPV: 72413000 - Visuotinio žiniatinklio (WWW) tinklaviečių projektavimo paslaugos
ID: 68394812026-03-06 12:38Pasiūlymai iki: 2026-03-12 08:00
Atidaryti CVP IS

Aprašymas

Perkamos paslaugos, susijusios su STEAM informacinės sistemos plėtra, sukuriant STEAM ambasadorių tinklaveikos komponentą. Tai apima ambasadorių registracijos, profilių valdymo, vidinės komunikacijos, mokymų medžiagos talpinimo, diskusijų forumo ir resursų valdymo funkcionalumą. Siekiama pagerinti STEAM ambasadorių bendruomenės veiklą ir informacijos apsikeitimą centralizuotoje sistemoje.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas per paskutinius 3 (trejus) metus arba per laiką nuo Tiekėjo įregistravimo dienos (jei Tiekėjas vykdė veiklą mažiau kaip 3 (trejus) metus) turi būti įdiegęs bent 1 (vieną) švietimo srities IT sprendimą: informacinę sistemą ir (ar) skaitmeninę mokymo priemonę (SMP) / e. mokymosi sprendimą, kurios vertė būtų ne mažesnė kaip 30 000 EUR (trisdešimt tūkstančių eurų) be PVM.
  • 2Tiekėjo siūlomas informacinių technologijų specialistas (toliau – Specialistas Nr. 1) per paskutinius 3 (tris) metus iki pasiūlymų pateikimo termino pabaigos turi informacinių technologijų specialisto patirties kuriant ir / arba adaptuojant ir / arba atnaujinant ne mažiau kaip 1 (vieną) skaitmeninę mokymo priemonę ir / arba informacinę sistemą (pvz. internetinė svetainė, specializuotas skaitmeninis įrankis).
  • 3Tiekėjo siūlomas vartotojo / naudotojo sąsajos dizaineris (UI/UX) (toliau – Specialistas Nr. 2) 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 / arba / modernizavimo projektą / sutartį, kurio / kurios metu vykdytas vartotojo / naudotojo sąsajos kokybės vertinimas.

Techniniai reikalavimai

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 SA turinys (įrašai, taksonomijos, nustatymai, mediateka) patektų į atsargines kopijas ir būtų atkuriamas kartu su visa platforma.
  • 8Sistema turi būti stebima (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 (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 testinėje aplinkoje, įskaitant regresinį testavimą (ypač žemėlapio, filtravimo, galerijų ir sutikimų logikos).

Išteklių modulis

  • 1Išteklių modulis turi sudaryti galimybę kaupti, struktūruoti ir dalintis tarp SA metodine medžiaga, bendro pobūdžio mokymų turiniu, aktualiais straipsniais, naudingomis nuorodomis bei informacija apie artimiausius renginius.
  • 2Ši dalis turi būti prieinama visiems prisijungusiems SA tinklaveikos naudotojams.
  • 3Sistema turi sudaryti galimybę administratoriui kurti atskiras išteklių kategorijas, įskaitant, bet neapsiribojant: metodinė medžiaga, mokymų medžiaga, aktualūs straipsniai, naudingos nuorodos, artėjantys renginiai.
  • 4Kategorijų sąrašas turi būti konfigūruojamas ir plečiamas be programavimo darbų.
  • 5Kiekvienas išteklius turi būti registruojamas kaip struktūruotas įrašas, turintis pavadinimą, trumpą aprašymą, išsamų turinį arba nuorodą, priskirtą kategoriją, publikavimo datą ir, jei taikoma, susijusias temas ar veiklos sritis.
  • 6Metodinės ir mokymų medžiagos ištekliai turi leisti įkelti dokumentus ar kitus failus bei nurodyti jų formatą.
  • 7Sistema turi užtikrinti galimybę atsisiųsti ar peržiūrėti dokumentus sistemos viduje.
  • 8Aktualūs straipsniai turi būti pateikiami kaip struktūruotos nuorodos su aprašymu, šaltinio pavadinimu ir, jei taikoma, publikavimo data.
  • 9Sistema turi sudaryti galimybę pažymėti straipsnį kaip rekomenduojamą ar svarbų.
  • 10Naudingos nuorodos turi būti skirstomos į atskiras kalbines kategorijas (ENG ir LT).
  • 11Kiekvienai nuorodai turi būti nurodomas pavadinimas, trumpas aprašymas ir tikslinė interneto svetainė.
  • 12Sistema turi užtikrinti galimybę atnaujinti ar pašalinti pasenusias nuorodas.
  • 13Sistema turi sudaryti galimybę filtruoti ir ieškoti išteklių pagal kategoriją, raktažodžius, publikavimo datą ar susijusias temas.
  • 14Įkelti naują išteklių turi galėti bet kuris prisijungęs SA naudotojas.
  • 15Administratoriui turi būti suteikta galimybė redaguoti, archyvuoti ar pašalinti išteklius, taip pat nustatyti jų publikavimo būseną (juodraštis, paskelbta, archyvuota).
  • 16Išteklių modulis turi užtikrinti navigaciją, leidžiančią naudotojams rasti aktualią informaciją.
  • 17Pateikimas turi būti optimizuotas skirtingiems įrenginiams.
  • 18Sistema turi būti realizuota taip, kad ateityje būtų galima išplėsti išteklių funkcionalumą, pavyzdžiui, įdiegiant naudotojų vertinimo ar žymėjimo funkcijas, nekeičiant esamos esminės išteklių struktūros.

Mokymų reikalavimai

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

SA diskusijų forumas

  • 1SA diskusijų forumo modulis turi sudaryti galimybę patvirtintiems ir prisijungusiems SA dalyvauti struktūruotose teminėse diskusijose vidinėje sistemos aplinkoje.
  • 2Forumą turi sudaryti temos (kategorijos) ir atskiros diskusijų gijos.
  • 3Sistema turi sudaryti galimybę administratoriui kurti, redaguoti ir archyvuoti forumo kategorijas (pvz., metodinės idėjos, renginių organizavimas, regioninės iniciatyvos, iššūkiai).
  • 4Kiekviena kategorija turi turėti pavadinimą, aprašymą ir matomumo nustatymus.
  • 5Prisijungę SA turi turėti galimybę kurti naujas diskusijų temas jiems prieinamose kategorijose, atsakyti į kitų naudotojų pranešimus.
  • 6Sistema turi palaikyti pagrindinį teksto formatavimą ir galimybę pridėti dokumentus ar nuorodas.
  • 7Sistema turi fiksuoti diskusijų chronologiją ir aiškiai atvaizduoti pranešimų autorius, publikavimo datą bei laiką.
  • 8Turi būti galimybė rūšiuoti diskusijas pagal naujausią aktyvumą arba sukūrimo datą.
  • 9Turi būti įdiegta paieškos funkcija, leidžianti ieškoti diskusijų temų ir pranešimų pagal raktažodžius.
  • 10Taip pat turi būti galimybė filtruoti diskusijas pagal kategoriją ar kitus metaduomenis.
  • 11Administratorius turi turėti moderavimo funkcijas: redaguoti ar šalinti netinkamą turinį, perkelti diskusijas tarp kategorijų, užrakinti temas, pažymėti temas kaip svarbias ar prisegti jas kategorijos viršuje.
  • 12Forume turi būti įgyvendintas „Idėjų banko“ funkcionalumas kaip atskira forumo dalis arba speciali kategorija su papildomomis funkcijomis.
  • 13Sistema turi sudaryti galimybę SA diskutuoti Idėjų banko temomis.
  • 14Turi būti galimybė pažymėti idėją kaip palaikomą (pvz., balsavimo ar palaikymo funkcija), jei tai numatyta sistemos konfigūracijoje.
  • 15Administratorius turi turėti galimybę generuoti idėjų sąrašą pagal būseną, datą ar teritoriją, siekiant analizuoti iniciatyvų aktyvumą.
  • 16Sistema turi užtikrinti, kad forumo ir idėjų banko turinys būtų prieinamas tik prisijungusiems SA naudotojams ir nebūtų indeksuojamas viešųjų paieškos sistemų.
  • 17Turi būti įgyvendintas pranešimų mechanizmas, informuojantis SA apie atsakymus jų sukurtose temose, naujus komentarus prie pateiktų idėjų ar idėjos būsenos pasikeitimą.
  • 18Sistema turi fiksuoti pagrindinius forumo ir idėjų banko veiksmus (temų kūrimas, redagavimas, šalinimas, būsenų keitimas), užtikrinant veiksmų atsekamumą.

Testavimo reikalavimai

  • 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, taip pat integruotos sistemos funkcinis testavimas, užtikrinantis, kad sukurtas komponentas kaip visuma atitinka veiklos procesus, duomenų srautus ir numatytą logiką.
  • 6Testavimo 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ą.
  • 7Testavimo 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.
  • 8Baigus 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, jeigu tokių yra.
  • 9Testavimas turi būti atliekamas izoliuotoje testavimo aplinkoje, atskirtoje nuo gamybinės sistemos, užtikrinant, kad testavimo procesas neturėtų įtakos realiems duomenims ir naudotojams.

Turinio skaitmenizavimas

  • 1Tiekėjas privalo savo ištekliais atlikti visą SA tinklaveikos pradinio turinio skaitmenizavimą ir suvedimą į sistemą pagal PO pateiktą informaciją.
  • 2Sistema negali būti perduodama eksploatacijai su tuščiais moduliais ar testiniais duomenimis.
  • 3Tiekėjas turi susisteminti ir suvesti pirminius SA naudotojų duomenis, gautus iš PO.
  • 4Jei duomenys pateikiami struktūruotu formatu (pvz., lentelėmis), tiekėjas turi juos importuoti arba suvesti į atitinkamus sistemos laukus.
  • 5Jei duomenys pateikiami nestruktūruotu ar mišriu formatu, tiekėjas turi juos struktūruoti pagal sistemos duomenų modelį.
  • 6Tiekėjas turi sukurti pirmines SA naudotojų paskyras, suvesti jų profilio informaciją ir užtikrinti, kad kiekvienas profilis atitiktų nustatytą struktūrą.
  • 7Jei būtinas aktyvavimo procesas, tiekėjas turi parengti naudotojus prisijungimui pagal suderintą tvarką.
  • 8Tiekėjas turi skaitmenizuoti ir sukelti pradinį vidinių informacinių puslapių turinį, kurį pateikia PO, užtikrindamas, kad tekstai būtų tinkamai suformatuoti, struktūruoti, susieti su atitinkamomis kategorijomis ir parengti publikavimui.
  • 9Tiekėjas turi sukurti ir užpildyti pirmines forumo kategorijas bei, jei PO pateikia, perkelti esamas diskusijų temas ar turinį į sistemą, išlaikant logišką struktūrą.
  • 10Tiekėjas turi skaitmenizuoti ir sukelti pradinį idėjų banko turinį, jei PO pateikia jau turimų iniciatyvų ar pasiūlymų sąrašą, užtikrindamas jų suskirstymą pagal nustatytas būsenas ir struktūrą.
  • 11Tiekėjas turi sukurti ir suvesti pirminę mokymų medžiagą bei resursus, jei tokie pateikiami PO, įskaitant dokumentų įkėlimą, kategorijų priskyrimą ir metaduomenų užpildymą.
  • 12Jeigu PO pateikia dokumentus ar medžiagą netinkamu skaitmeniniu formatu (pvz., nuskenuotus dokumentus, neoptimizuotas nuotraukas), tiekėjas turi atlikti konvertavimą, optimizavimą ir parengimą naudojimui sistemoje.
  • 13Tiekėjas turi užtikrinti, kad visi suvesti duomenys būtų patikrinti prieš pateikiant sistemą PO peržiūrai.
  • 14Patikra turi apimti duomenų tikslumą, struktūros atitikimą, nuorodų veikimą, dokumentų atsisiuntimą ir teisingą matomumo nustatymą.
  • 15Skaitmenizavimo metu turi būti laikomasi asmens duomenų apsaugos reikalavimų.
  • 16Viešai ar vidinėje aplinkoje publikuojami duomenys turi būti tvarkomi tik pagal PO suteiktą teisinį pagrindą.
  • 17Baigus skaitmenizavimo ir suvedimo darbus, tiekėjas turi pateikti PO sistemą peržiūrai ir sudaryti galimybę atlikti turinio patvirtinimą.
  • 18Turinio skaitmenizavimo darbai laikomi įvykdytais tik po PO patvirtinimo.

Esamos sistemos kontekstas

  • 1Eksploatuojama STEAM informacinė sistema sukurta naudojant PHP programavimo kalbą.
  • 2Sistemoje naudojama SystemSight turinio valdymo sistema.
  • 3Sistemoje naudojama MySQL duomenų bazė.

Licencijavimo reikalavimai

  • 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ų.

Dokumentacijos reikalavimai

  • 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).

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.
  • 3Šifravimo priemonės (DBVS, operacinės sistemos ar aplikacijų) turės būti parenkamos ir suderintos su PO priklausomai nuo duomenų jautrumo lygio, greitaveikos poreikių ir kitų faktorių.
  • 4Taip pat turės atitikti aktualius susijusius Europos sąjungos ir nacionalinius reglamentus ir direktyvų reikalavimus, sprendinius suderinus su PO.
  • 5Sistemos 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.
  • 6Duomenų prieinamumą: duomenys ir komponentai turi būti prieinami tik naudotojams turintiems tam teisę.
  • 7Duomenų sauga turi būti užtikrinama: užtikrinant duomenų vientisumą ir neprieštaringumą.
  • 8Darbui 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.
  • 9Saugoma informacija negali būti ištrinta jokiais kitais būdais ar aplinkybėmis, išskyrus PO numatytais atvejais.
  • 10Visi naudotojai, dirbantys su Sistema, turi būti autentifikuoti ir valdomi centralizuotai.
  • 11IS 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.
  • 12IS, 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ą.
  • 13Visi realizuojami moduliai turi būti susieti audito ir saugos moduliu, įgyvendinančiu veiksmų registravimo ir kontrolės mechanizmą (angl. audit trail).
  • 14IS 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).
  • 15IS turi būti apsaugota nuo paskirstytų ir daug resursų reikalaujančių atakų (angl. distributed denial of service – DdoS).
  • 16Turi būti parinktas toks sprendimas, kad viešai prieinamiems sistemos komponentams vykdant DdoS ataką nesutriktų visos IS veikla.

SA mokymų medžiagos modulis

  • 1SA mokymų medžiagos modulis turi sudaryti galimybę talpinti, struktūruoti ir valdyti STEAM ambasadoriams skirtą mokymų turinį uždaroje vidinėje aplinkoje.
  • 2Prieiga prie mokymų medžiagos turi būti suteikiama tik prisijungusiems ir patvirtintiems SA naudotojams, jei administratorius nenustato kitaip.
  • 3Sistema turi sudaryti galimybę administratoriui kurti atskirus mokymų vienetus ar kursus.
  • 4Kiekvienas mokymų vienetas turi turėti pavadinimą, trumpą aprašymą, išsamų turinį, kategoriją (pvz., metodika, komunikacija, projektų valdymas ir kt.), susijusias temas ar veiklos sritis, publikavimo būseną ir, jei taikoma, galiojimo laikotarpį.
  • 5Mokymų turinys turi būti sudaromas iš struktūrinių elementų, leidžiančių į vieną mokymų vienetą įtraukti tekstinę medžiagą, dokumentus, nuorodas, vaizdo įrašus, pateiktis, iliustracijas ar kitus su PO suderintus skaitmeninius išteklius.
  • 6Sistema turi palaikyti dažniausiai naudojamus dokumentų ir medijos formatus ne mažiau kaip .docx, .xlsx, .csv, .pptx, .pdf, .mp3, .mp4, .wav, .jpg, .jpeg, .png, .bmp.
  • 7Turi būti galimybė suskirstyti mokymų medžiagą į modulius ar temas, kad mokymai būtų pateikiami nuosekliai ir struktūruotai.
  • 8Naudotojui turi būti aiškiai matoma mokymų struktūra ir navigacija tarp temų.
  • 9Sistema turi užtikrinti, kad mokymų medžiaga būtų lengvai randama.
  • 10Turi būti įdiegta paieškos ir filtravimo funkcija pagal mokymų kategoriją, temą, raktažodžius ar publikavimo datą.
  • 11Sistema turi sudaryti galimybę atnaujinti mokymų turinį išlaikant versijų istoriją, kad būtų galima peržiūrėti ankstesnes turinio redakcijas arba atkurti ankstesnę versiją.
  • 12Turi būti galimybė pažymėti mokymų medžiagą kaip aktualią, naujai pridėtą ar rekomenduojamą, kad SA naudotojai galėtų greitai identifikuoti svarbiausią turinį.
  • 13Sistema turi užtikrinti galimybę atsisiųsti pridedamus dokumentus, jei tai leidžiama administratoriaus nustatymuose.
  • 14Jei reikalinga, turi būti galimybė riboti dokumentų atsisiuntimą ir leisti tik peržiūrą sistemos viduje.
  • 15Mokymų medžiaga turi būti pateikiama taip, kad būtų užtikrintas patogus naudojimas skirtinguose įrenginiuose.
  • 16Vaizdo ir dokumentų peržiūra turi būti optimizuota mobiliesiems įrenginiams.
  • 17Administracinėje aplinkoje turi būti galimybė peržiūrėti mokymų turinio sąrašą, matyti jų būseną (juodraštis, paskelbta, archyvuota) ir valdyti publikavimo procesą.

SA tinklaveikos funkcionalumas

  • 1Sistema turi sudaryti galimybę asmeniui pateikti registracijos paraišką tapti SA tinklaveikos naudotoju.
  • 2Registracijos forma turi būti konfigūruojama administratoriaus ir apimti ne mažiau nei šiuos laukus: vardas ir pavardė, atstovaujama institucija, pareigos, kontaktinis el. paštas, telefono numeris, atstovaujama teritorija ir sutikimai dėl duomenų tvarkymo.
  • 3Pateikus registracijos paraišką, sistema turi automatiškai informuoti administratorių apie naują registracijos užklausą.
  • 4Naudotojo paskyra turi būti aktyvuojama tik po administratoriaus patvirtinimo.
  • 5Iki patvirtinimo naudotojas neturi turėti prieigos prie vidinės aplinkos.
  • 6Administracinėje aplinkoje turi būti galimybė peržiūrėti registracijos paraiškas, jas patvirtinti, atmesti arba grąžinti patikslinimui.
  • 7Sistema turi fiksuoti registracijos patvirtinimo ar atmetimo datą ir administratoriaus veiksmą.
  • 8Sistema turi užtikrinti, kad kiekvienas patvirtintas SA turėtų individualų naudotojo profilį vidinėje aplinkoje.
  • 9SA profilis turi apimti pagrindinę informaciją apie ambasadorių: vardą ir pavardę, instituciją, teritoriją, veiklos sritis, trumpą aprašymą, nuotrauką ir kontaktinius duomenis.
  • 10SA tinklaveikos modulis turi sudaryti galimybę registruotiems STEAM ambasadoriams naudotis uždara vidine aplinka, skirta tarpusavio komunikacijai, informacijos apsikeitimui ir aktualios informacijos gavimui.
  • 11Prieiga prie tinklaveikos funkcijų turi būti suteikiama tik patvirtintiems ir prisijungusiems naudotojams.
  • 12SA turi turėti galimybę savarankiškai redaguoti savo profilio informaciją, išskyrus laukus, kurie identifikuoja naudotoją sistemoje.
  • 13Profilio pakeitimai turi būti fiksuojami sistemos įvykių žurnale.
  • 14Vidinėje aplinkoje turi būti sudaryta galimybė skelbti informacinius puslapius, skirtus tik SA bendruomenei.
  • 15Šie puslapiai neturi būti indeksuojami viešųjų paieškos sistemų ir neturi būti pasiekiami neprisijungusiems naudotojams.
  • 16Sistema turi sudaryti galimybę administratoriui kurti, redaguoti ir publikuoti naujienas, skirtas tik SA vidinei aplinkai.
  • 17Tokios naujienos turi būti rodomos tik prisijungusiems SA ir neturi būti matomos viešojoje svetainės dalyje.
  • 18Vidinės naujienos turi būti rodomos chronologine tvarka, su galimybe jas filtruoti pagal kategoriją, datą ar susijusią temą.
  • 19Turi būti galimybė prisegti dokumentus ar nuorodas, skirtas tik SA naudojimui.
  • 20Sistema turi užtikrinti, kad vidinės informacijos prieiga būtų valdoma pagal naudotojų roles.
  • 21Sistema turi užtikrinti saugų autentifikavimo mechanizmą ir galimybę atkurti slaptažodį.
  • 22Turi būti įgyvendintos apsaugos priemonės nuo neteisėto prisijungimo bandymų.
  • 23Sistema turi fiksuoti pagrindinius naudotojų veiksmus vidinėje aplinkoje (prisijungimai, profilio atnaujinimai, turinio publikavimas), užtikrinant veiksmų atsekamumą.
  • 24SA tinklaveikos modulis turi būti pritaikytas naudoti skirtinguose įrenginiuose ir užtikrinti patogų naudojimą tiek kompiuteriuose, tiek mobiliuosiuose įrenginiuose.
  • 25Sprendimas turi būti realizuotas taip, kad ateityje būtų galima plėsti tinklaveikos funkcionalumą, pavyzdžiui, įdiegiant vidinę pranešimų sistemą, darbo grupes ar temines bendruomenes, nekeičiant pagrindinės naudotojų ir profilių valdymo struktūros.

Garantinio aptarnavimo reikalavimai

  • 1Garantinės priežiūros objektas yra pagal šio konkurso sąlygas įdiegtas funkcionalumas esamoje IS.
  • 2Garantinės priežiūros paslaugos apima projekto metu sukurtos programinės įrangos neatitikimų techninei specifikacijai, klaidų ir kitų veikimo sutrikimų šalinimą.
  • 3Programinė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.
  • 4Veiklą blokuojanti klaida – kai nustatytas IS trikdis ir (ar) problema, dėl kurio IS apskritai nefunkcionuoja ar funkcionuoja netinkamai, ko rezultate PO apskritai negali teikti paslaugų.
  • 5Kritinė klaida ir (ar) trikdis – kai nustatytas trikdis ir (ar) problema, dėl kurios 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.
  • 6Klaida ir (ar) trikdis – 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ų.
  • 7Diegėjas privalo išanalizuoti trikdį ir (ar) Klaidą/ Kritinę klaidą ir numatyti jos pašalinimo būdą ne vėliau, kaip per 1 darbo val. nuo jos užregistravimo Tiekėjo pateiktame klaidų registre, nepriklausomai nuo to, kokio tipo Klaida ir (ar) trikdis užfiksuotas.
  • 8Veiklą blokuojančios klaidos ir (ar) trikdžiai – sprendžiami atskirai suderintais klaidų šalinimo terminais, tačiau ne ilgiau nei per 1 darbo val.
  • 9Kritinės klaidos ir (ar) trikdžiai – sprendžiami atskirai suderintais klaidų šalinimo terminais, tačiau ne ilgiau nei per 6 darbo val.
  • 10Klaidos ir (ar) trikdžiai – sprendžiami atskirai suderintais klaidų šalinimo terminais, tačiau ne ilgiau nei per 14 dienų po incidento užfiksavimo.
  • 11IS klaidos ir kritinės klaidos turi būti registruojamos šalių suderintame klaidų registre, pagal su PO suderintą incidentų sprendimo seką (angl. workflow).
  • 12Informacija apie pašalintas (pataisytas) klaidas ir (ar) trikdžius, jei tokie buvo užfiksuoti, ataskaitos forma turi būti atnaujinama ir pateikiama kartą per mėnesį.
  • 13Garantinė priežiūra turi apimti Lietuvos Respublikos Civiliniame kodekse numatomas garantinės priežiūros teises.

Sistemos administravimas (bendrasis)

  • 1SA tinklaveikos administravimo aplinka turi būti pasiekiama tik autorizuotiems naudotojams, turintiems administratoriaus teises.
  • 2Prieiga turi būti ribojama pagal roles ir mažiausių privilegijų principą.
  • 3Sistema turi sudaryti galimybę administratoriui peržiūrėti, tvirtinti, atmesti arba grąžinti tikslinimui SA registracijos paraiškas.
  • 4Turi būti matoma registracijos paraiškos pateikimo data, pateikti duomenys ir sprendimo istorija.
  • 5Sprendimas turi būti fiksuojamas sistemos žurnale.
  • 6Administravimo aplinka turi sudaryti galimybę valdyti SA naudotojų paskyras: redaguoti profilio duomenis, keisti naudotojo rolę, aktyvuoti ar deaktyvuoti paskyrą, sustabdyti prieigą arba pašalinti naudotoją.
  • 7Visi šie veiksmai turi būti registruojami įvykių žurnale.
  • 8Sistema turi sudaryti galimybę administratoriui valdyti naudotojų roles ir prieigos lygius, įskaitant galimybę kurti papildomas roles, nekeičiant sistemos programinio kodo.
  • 9Administravimo aplinkoje turi būti galimybė kurti, redaguoti ir archyvuoti vidinius informacinius puslapius bei naujienas, skirtas tik SA tinklaveikai.
  • 10Turi būti palaikomas turinio juodraščio režimas ir publikavimo kontrolė.
  • 11Sistema turi sudaryti galimybę administratoriui valdyti forumo struktūrą: kurti, redaguoti ir archyvuoti kategorijas, perkelti ar užrakinti diskusijų temas, šalinti netinkamą turinį bei pažymėti svarbias temas.
  • 12Moderatoriniai veiksmai turi būti fiksuojami žurnale.
  • 13Administravimo aplinkoje turi būti idėjų banko valdymo mechanizmas.
  • 14Administratorius turi turėti galimybę kurti idėjas, jas redaguoti ar šalinti.
  • 15Būsenos pasikeitimai turi būti registruojami.
  • 16Administravimo aplinka turi sudaryti galimybę valdyti mokymų medžiagos turinį: kurti naujus mokymų vienetus, redaguoti esamus, keisti jų matomumo lygį, archyvuoti pasenusią medžiagą, valdyti versijų istoriją.
  • 17Sistema turi sudaryti galimybę administratoriui valdyti išteklių modulio turinį: kurti ir redaguoti kategorijas, įkelti naujus išteklius, pašalinti pasenusius, tikrinti nuorodų aktualumą, pažymėti rekomenduojamus ar svarbius resursus.
  • 18Administravimo aplinkoje turi būti galimybė peržiūrėti naudotojų aktyvumo suvestinę, apimančią prisijungimus, paskutinius veiksmus, turinio kūrimą ar redagavimą.
  • 19Ši funkcija turi būti skirta administracinei kontrolei ir veiksmų atsekamumui.
  • 20Sistema turi sudaryti galimybę konfigūruoti pranešimų nustatymus, pavyzdžiui, ar naudotojai informuojami apie naujas diskusijas, atsakymus, idėjos būsenos pasikeitimą ar naują mokymų medžiagą.
  • 21Administravimo aplinka turi būti suprojektuota taip, kad būtų aiškiai atskirtos skirtingų modulių valdymo sritys (naudotojai, forumas, idėjų bankas, mokymai, ištekliai, informaciniai puslapiai).
  • 22Sistema turi užtikrinti, kad visi administraciniai veiksmai būtų atsekami ir saugomi įvykių žurnale, nurodant veiksmą atlikusį naudotoją, datą ir pakeitimo tipą.
  • 23Administravimo aplinka turi būti realizuota naudojant standartinius turinio valdymo ir prieigos valdymo mechanizmus, užtikrinant galimybę ateityje plėsti funkcionalumą be esminių architektūrinių pakeitimų.

Bandomosios eksploatacijos reikalavimai

  • 1IS į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.

Architektūros ir programinės įrangos charakteristikos

  • 1Kuriamas komponentas turi būti sukurtas kaip nepriklausomas mikroservisas, veikiantis atskirai nuo esamos informacinės sistemos ir netrikdantis 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 SA ambasadorių 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ų.

Dokumentai13

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