Grįžti į sąrašą

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

Išanalizuota

Lietuvos neformaliojo švietimo agentūra

Skelbiama apklausaCPV: 72262000 - Programinės įrangos kūrimo paslaugos
ID: 68387972026-03-06 12:09Pasiūlymai iki: 2026-03-12 08:00
Atidaryti CVP IS

Aprašymas

Perkamos paslaugos, skirtos sukurti naują STEAM ambasadorių komponentą, kuris bus integruotas į jau veikiančią STEAM informacinę sistemą. Šis komponentas apims viešąją svetainės dalį, turinio administravimą, turinio skaitmenizavimą ir vieningą naudotojų valdymą, siekiant plėsti STEAM ugdymo veiklą ir ambasadorių tinklą.

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ų) be PVM.
  • 2Tiekėjo siūlomas informacinių technologijų specialistas (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) (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.
  • 4Tiekėjas turi pateikti užpildytą deklaraciją dėl (ne)atitikties 2014 m. liepos 31 d. Tarybos reglamento (ES) Nr. 833/2014 nuostatoms, t.y., kad tiekėjo/subtiekėjo sudėtyje nėra Rusijos dalyvavimo, viršijančio nustatytas ribas, ir jam netaikomos Lietuvos Respublikoje įgyvendinamos tarptautinės sankcijos.

Techniniai reikalavimai

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

Testavimo reikalavimai

  • 1Tiekėjas turi parengti išsamų testavimo planą, apimantį testavimo strategiją, aprėptį, naudojamas testavimo aplinkas, atsakomybes ir grafikus, taip pat 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.
  • 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.
  • 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.
  • 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.
  • 9Testavimas turi būti atliekamas izoliuotoje testavimo aplinkoje, atskirtoje nuo gamybinės sistemos.

Turinio skaitmenizavimas

  • 1Tiekėjas privalo savo lėšomis ir ištekliais atlikti visus su turinio skaitmenizavimu susijusius darbus, įskaitant tekstinės medžiagos suredagavimą ir struktūravimą, dokumentų konvertavimą į tinkamus skaitmeninius formatus, nuotraukų atranką, optimizavimą ir įkėlimą, duomenų suvedimą į nustatytus laukus, metaduomenų priskyrimą, kategorijų ir teritorinių žymų parinkimą.
  • 2Turi būti palaikomas turinio juodraščio režimas ir publikavimo patvirtinimo mechanizmas.
  • 3Tiekėjas turi užtikrinti, kad sukeliamas turinys atitiktų sistemos nustatytą turinio tipų struktūrą, būtų logiškai susietas tarpusavyje ir tinkamai atvaizduojamas viešoje dalyje.
  • 4Draudžiama turinį talpinti nesilaikant nustatytų struktūrinių laukų ar naudojant laisvo teksto sprendimus vietoje struktūrizuotų duomenų.
  • 5Jeigu PO pateiktas turinys yra popierinis, neformatuotas ar pateiktas netinkamu skaitmeniniu formatu, tiekėjas privalo jį suskaitmeninti, suformatuoti ir parengti publikavimui.
  • 6Jeigu pateiktame turinyje nustatomi techniniai ar struktūriniai trūkumai, tiekėjas turi informuoti PO ir pasiūlyti sprendimo būdą.
  • 7Tiekėjas turi užtikrinti, kad visas suvestas turinys būtų patikrintas prieš publikavimą: patikrintas kalbos taisyklingumas, nuorodų veikimas, datų tikslumas, teritorinių žymų priskyrimas, kontaktinių duomenų atvaizdavimas pagal galiojantį sutikimą.
  • 8Turi būti užtikrinta, kad skaitmenizavimo metu būtų laikomasi asmens duomenų apsaugos reikalavimų.
  • 9Baigus turinio suvedimą, tiekėjas turi pateikti PO peržiūrai užpildytą sistemą ir sudaryti galimybę atlikti turinio patvirtinimą prieš galutinį paskelbimą.

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 būti 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, 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).

IS eksploatavimo reikalavimai

  • 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čiant 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ų.
  • 4Sistema turi palaikyti planinių priežiūros darbų vykdymą, numatant priežiūros langus, atnaujinimus ir grąžinimo (rollback) galimybę.
  • 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ę (scalability) esamos platformos kontekste, didėjant turinio kiekiui ir lankytojų srautui.
  • 7Sistema turi būti suderinama su esamos platformos atsarginių kopijų (backup) politika, užtikrinant, kad SA turinys 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 ir užtikrinant incidentų identifikavimą.
  • 9Sistema turi užtikrinti konfigūracijų valdymą taip, kad visi aplinkos nustatymai būtų valdomi konfigūracijose ir nebūtų „kietai įrašyti“ (hardcode) programiniame kode.
  • 10Sistema turi užtikrinti, kad diegimo metu būtų išlaikytas esamos platformos vizualinis vientisumas, laikantis bendrų dizaino ir prieinamumo principų.
  • 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ą.

Vieningas naudotojų valdymas

  • 1Tiekėjas turi sukurti vieningo naudotojų valdymo komponentą ir integruoti jį į esamą STEAM platformą.
  • 2Komponentas turi palaikyti OpenID Connect (OIDC) 1.0, OAuth 2.0, SAML 2.0 arba lygiaverčius protokolus.
  • 3Turi būti realizuotas centralizuotas sesijų valdymas: sesijų kūrimas, atnaujinimas, galiojimo laiko konfigūravimas, priverstinis nutraukimas ir Single Logout (SLO) mechanizmas.
  • 4Komponentas turi būti apsaugotas nuo „bruteforce“ ir „credential stuffing“ atakų: bandymų ribojimas, laikinas paskyros blokavimas po N nesėkmingų bandymų, klaidų pranešimai be naudotojo egzistavimo atskleidimo.
  • 5Autorizacijos informacija turi būti perduodama per SAML atributus su konfigūruojamu atributų atvaizdavimu (mapping) kiekvienai į STEAM platformą integruojamai aplikacijai.
  • 6Visos išorinės ir vidinės sąsajos turi naudoti TLS 1.2 arba naujesnę versiją; turi būti galimybė taikyti mTLS vidinėms integracijoms.
  • 7Vieningo naudotojų valdymo administravimo sąsaja (UI ir (arba) API) turi leisti valdyti nukreipimo (Redirect) URI, sertifikatus, politikų taisykles, sesijų parametrus, MFA nustatymus ir atributų atvaizdavimą.
  • 8Kiekvienas autentifikavimo ir administravimo įvykis turi būti registruojamas audito žurnale: sėkmingi ir nesėkmingi prisijungimai, MFA įvykiai, politikų sprendimai, konfigūracijos pakeitimai.
  • 9Žurnaluose negali būti saugomi slaptažodžiai atviru tekstu, pilni prieigos žetonai, asmens duomenys. Jautrūs atributai turi būti maskuojami ar šifruojami.
  • 10Architektūra turi užtikrinti galimybę horizontaliai plėstis.
  • 11Slaptažodžių politika (jei slaptažodžiai valdomi šiame komponente) turi palaikyti minimalaus ilgio, sudėtingumo ir galiojimo termino nustatymus.
  • 12Naudotojų valdymo modulyje turi būti užtikrintas Unicode (UTF-8) palaikymas.

Turinio administravimo aplinka

  • 1Sistema turi sudaryti galimybę administratoriui valdyti turinį naudojant struktūruotus turinio tipus.
  • 2Sistema turi sudaryti galimybę valdyti viešosios svetainės turinį naudojant struktūruotą ir lengvai administruojamą turinio valdymo aplinką, atitinkančią įprastų modernių TVS veikimo principus.
  • 3Sistema turi leisti administratoriams kurti, redaguoti, skelbti ir archyvuoti turinio puslapius naudojant vizualų puslapio redagavimo įrankį (WYSIWYG), suteikiantį galimybę keisti tekstus, antraštes, nuotraukas, lenteles, nuorodas ir kitus turinio elementus be programavimo žinių.
  • 4Sistema turi palaikyti modulinį turinio komponavimo principą, kai puslapiai sudaromi iš atskirų blokų ar sekcijų.
  • 5Sistema turi leisti kurti neribotą skaičių viešųjų puslapių, įskaitant įprastus informacinius puslapius, naujienų įrašus, renginių aprašymus ir išteklių katalogus.
  • 6Sistema turi turėti naujienų publikavimo funkcionalumą, leidžiantį kurti naujienų įrašus, priskirti jiems kategorijas ir žymas, valdyti jų rodymo tvarką bei archyvą.
  • 7Sistema turi sudaryti galimybę turinį publikuoti pagal nustatytą datą ir laiką, taip pat pasirinkti turinio matomumą.
  • 8Sistema turi turėti medijos biblioteką, leidžiančią įkelti, saugoti, tvarkyti ir naudoti failus (nuotraukas, PDF failus, vaizdo įrašus, dokumentus) puslapių ir naujienų turinyje.
  • 9Sistema turi palaikyti meniu valdymą, sudarant galimybę administratoriams kurti, keisti ir pergrupuoti viešosios svetainės meniu punktus.
  • 10Administracinėje aplinkoje turi būti galimybė kurti, redaguoti, archyvuoti ir skelbti SA įrašus be programavimo darbų, naudojant standartinę turinio redagavimo sąsają.
  • 11Sistema turi turėti galimybę kurti specialias turinio kategorijas, tokias kaip „Ištekliai“, „Naujienos“, „Renginiai“, ir joms priskirti skirtingus išdėstymo šablonus.
  • 12Sistema turi palaikyti kelis turinio rodymo šablonus (pvz., puslapio šabloną, naujienų sąrašo šabloną, renginių sąrašo šabloną).
  • 13Sistema turi sudaryti galimybę kurti kelių lygių turinio redaktorius, suteikiant skirtingas teises turinio kūrimui, redagavimui ir publikavimui.
  • 14Sistema turi užtikrinti versijų valdymą: kiekvieno turinio elemento redagavimo istorija turi būti išsaugoma, suteikiant galimybę grįžti prie ankstesnių versijų.
  • 15Sistema turi palaikyti SEO metaduomenų (antraštės, aprašymo, raktažodžių, socialinių tinklų peržiūros informacijos) redagavimą kiekvienam puslapiui ir įrašui.
  • 16Sistema turi leisti į svetainę integruoti papildomus komponentus, tokius kaip naujienlaiškio registracijos formos, kontaktų formos, renginių kalendorius ar partnerių logotipų galerijos, per pridedamus valdiklius ar komponentų blokus.
  • 17Sistema turi palaikyti vidinės paieškos funkciją, leidžiančią lankytojams ieškoti pagal puslapių pavadinimus, naujienų turinį ir kitus viešai matomus informacijos šaltinius.
  • 18Sistema turi užtikrinti, kad turinio valdymo aplinka būtų pritaikyta naudoti tiek kompiuteriu, tiek mobiliuoju įrenginiu, išlaikant visą funkcionalumą visų tipų ekranams.
  • 19Sistema turi automatiškai generuoti tvarkingus URL adresus, paremtus puslapio pavadinimu, ir leisti administratoriui rankiniu būdu juos pakoreguoti.

Naujienų ir renginių valdymas

  • 1Naujienų ir renginių moduliai turi sudaryti galimybę sistemą administruojančiam naudotojui kurti, redaguoti ir skelbti naujienas bei renginius kaip atskirus struktūruotus turinio tipus be specifinių programavimo žinių.
  • 2Naujienos ir renginiai turi būti atskiriami pagal tipą, tačiau rodomi bendrose skiltyse su galimybe filtruoti pagal kategoriją.
  • 3Renginio įraše turi būti numatyti ne mažiau nei šie duomenų laukai: pavadinimas, trumpas aprašymas, išsamus aprašymas, renginio tipas, organizatorius (vienas ar keli SA), renginio data ir laikas (pradžia ir pabaiga), vieta, teritorija, registracijos informacija (jei taikoma), susiję dokumentai ar nuorodos, pagrindinė iliustracija ir nuotraukų galerija (jei taikoma).
  • 4Sistema turi automatiškai klasifikuoti renginius pagal datą į planuojamus ir įvykusius (archyvą).
  • 5Būsimi renginiai turi būti rodomi atskiroje „Planuojami renginiai“ dalyje chronologine tvarka pagal artimiausią datą.
  • 6Pasibaigus renginio datai, įrašas turi būti automatiškai perkeltas į renginių archyvą.
  • 7Renginių archyvas turi būti pasiekiamas per atskirą skiltį arba filtrą, leidžiantį peržiūrėti įvykusius renginius pagal metus, mėnesius, teritoriją ar organizatorių.
  • 8Naujienų įraše turi būti numatyti ne mažiau nei šie duomenų laukai: pavadinimas, publikavimo data, santrauka, pilnas tekstas, pagrindinė iliustracija, nuotraukų galerija, susijusios teritorijos, susiję SA, pridedami dokumentai ar nuorodos.
  • 9Naujienos turi būti rodomos chronologine tvarka pagal publikavimo datą.
  • 10Turi būti galimybė susieti naujienas su konkrečiais renginiais.
  • 11Turi būti įdiegta filtravimo ir paieškos funkcija, leidžianti naudotojui filtruoti renginius ir naujienas pagal teritoriją, metus, organizatorių (SA), renginio tipą ar raktažodžius.
  • 12Modulyje turi būti įgyvendintas nuotraukų archyvas, su galimybe sukurti nuotraukų galeriją, priskirtą konkrečiam renginiui, įkelti kelias nuotraukas, nurodyti jų aprašymus ir alternatyvius tekstus.
  • 13Turi būti galimybė peržiūrėti bendrą nuotraukų archyvą, leidžiant filtruoti nuotraukas pagal renginį, metus ar teritoriją.
  • 14Sistema turi užtikrinti, kad nuotraukų publikavimas būtų galimas tik patvirtinus, jog laikomasi asmens duomenų ir atvaizdo naudojimo reikalavimų.
  • 15Administratoriui turi būti sudaryta galimybė nustatyti renginio publikavimo būseną (juodraštis, paskelbtas, archyvuotas), taip pat planuoti publikavimo datą ir laiką.
  • 16Modulis turi būti pritaikytas mobiliesiems įrenginiams, užtikrinant patogų kalendoriaus, sąrašo ir galerijų peržiūrėjimą.
  • 17Sistema turi sudaryti galimybę ateityje plėsti funkcionalumą, įdiegiant registracijos į renginius mechanizmą, dalyvių skaičiaus ribojimą ar automatinį priminimų siuntimą, nekeičiant esminės modulio struktūros.

Bendrieji funkciniai reikalavimai

  • 1Svetainė turi būti viešai pasiekiama be registracijos ir skirta pagrindinei informacijai apie STEAM ambasadorių iniciatyvą, jos tikslus, veiklą ir dalyvius pateikti.
  • 2Pagrindinis puslapis turi aiškiai pristatyti STEAM ambasadorių programos paskirtį, tikslines grupes, veiklos kryptis ir naudą švietimo bendruomenei.
  • 3Svetainėje turi būti galimybė atvaizduoti ambasadorius sąrašo forma ir (ar) geografiniu principu – pagal teritorijas.
  • 4Filtravimo funkcionalumas turi veikti be puslapio perkrovimo arba su minimaliais navigacijos trikdžiais.
  • 5Turi būti įdiegta paieškos funkcija, leidžianti ieškoti informacijos pagal raktažodžius, apimanti visą viešai skelbiamą turinį.
  • 6Svetainė turi turėti naujienų ir renginių skiltis, kurioje būtų galima skelbti aktualią informaciją apie STEAM ambasadorių veiklas, susitikimus, iniciatyvas ar kitus su programa susijusius įvykius.
  • 7Sistema turi sudaryti galimybę įkelti ir skelbti dokumentus su atsisiuntimo galimybe (palaikomi formatai: .xlsx, .csv, .pptx, .docx, .pdf, .txt).
  • 8Svetainė turi būti pritaikyta skirtingiems įrenginiams (kompiuteriams, planšetėms, mobiliesiems telefonams) ir atitikti prieinamumo reikalavimus, užtikrinant galimybę naudotis turiniu asmenims su negalia.
  • 9Sistema turi užtikrinti daugiakalbystės galimybę, leidžiant administratoriui kurti turinio versijas skirtingomis kalbomis ir jas susieti tarpusavyje.
  • 10Svetainėje turi būti įdiegtas analitikos integravimo mechanizmas, leidžiantis stebėti lankomumą, populiariausius puslapius ir naudotojų elgseną, laikantis asmens duomenų apsaugos reikalavimų.
  • 11Sprendimas turi būti realizuotas taip, kad ateityje būtų galima plėsti funkcionalumą (pvz., registraciją į renginius, naujienlaiškių prenumeratą ar uždarą bendradarbiavimo zoną) nekeičiant esminės sistemos architektūros.

Kontaktų ir žemėlapio valdymas

  • 1Kontaktų skiltis turi būti atskira interneto svetainės dalis, kurioje SA kontaktinė informacija pateikiama geografiniu principu – pagal Lietuvos apskritis ir (ar) savivaldybes.
  • 2Skiltis turi veikti kaip interaktyvus Lietuvos žemėlapis ir kaip alternatyvus sąrašo (lentelės ar kortelių) vaizdas.
  • 3Sistema turi leisti administratoriui kurti atskirą turinio tipą kiekvieno SA kontaktinių duomenų nurodymui, įskaitant vardą, pavardę, atstovaujamą įstaigą, apskritį, savivaldybę, veiklos sritis, el. pašto adresą, telefono numerį, trumpą aprašymą, nuotrauką, papildomą informaciją.
  • 4SA profilio struktūra turi būti vienoda visiems ambasadoriams.
  • 5Žemėlapio funkcionalumas turi užtikrinti, kad pasirinkus apskritį ar savivaldybę būtų atvaizduojami toje teritorijoje registruoti SA.
  • 6Turi būti galimybė kiekvienam SA atskirai nustatyti, kurie kontaktiniai duomenys yra vieši, o kurie matomi tik vidinėje aplinkoje.
  • 7Viešas SA duomenų atvaizdavimas turi būti galimas tik esant fiksuotam SA sutikimui.
  • 8Sistema turi turėti funkcionalumą SA sutikimui valdyti.
  • 9Registruoti SA naudotojai turi turėti galimybę prisijungus matyti išplėstinę kitų SA kontaktinę informaciją, jei tai numatyta sistemos prieigos teisėmis.
  • 10Sistema turi sudaryti galimybę administratoriui filtruoti ir ieškoti SA pagal apskritį, savivaldybę, veiklos sritį, vardą ar pavardę.
  • 11Sistema turi užtikrinti, kad SA įrašai galėtų būti rūšiuojami ir filtruojami pagal kelias teritorijas.
  • 12Kontaktų skiltis turi būti pritaikyta mobiliesiems įrenginiams ir planšetėms, užtikrinant pilną funkcionalumą.
  • 13Sistema turi užtikrinti asmens duomenų apsaugą pagal galiojančius teisės aktus.
  • 14Turi būti galimybė eksportuoti SA kontaktų sąrašą struktūruotu formatu (pvz., CSV ar PDF), laikantis prieigos teisių ir duomenų apsaugos reikalavimų.
  • 15Sprendimas turi būti realizuojamas naudojant standartinius TVS plėtros mechanizmus (turinio tipai, taksonomijos, formos, rolės, leidimai).

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ą.
  • 3Visos STEAM IS veikimo klaidos ir (ar) trikdžiai klasifikuojami: Veiklą blokuojanti klaida (šalinama ne ilgiau nei per 1 darbo val.), Kritinė klaida ir (ar) trikdis (šalinama ne ilgiau nei per 6 darbo val.), Klaida ir (ar) trikdis (šalinama ne ilgiau nei per 14 dienų).
  • 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 val. nuo jos užregistravimo Tiekėjo pateiktame klaidų registre.
  • 5IS klaidos ir kritinės klaidos turi būti registruojamos šalių suderintame klaidų registre, pagal su PO suderintą incidentų sprendimo seką (workflow).
  • 6Informacija apie pašalintas (pataisytas) klaidas ir (ar) trikdžius turi būti atnaujinama ir pateikiama kartą per mėnesį.
  • 7Garantinė priežiūra turi apimti Lietuvos Respublikos Civiliniame kodekse numatomas garantinės priežiūros teises.

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

Saugumo ir konfidencialumo reikalavimai

  • 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.
  • 3Sistemos naudojamos administracinės, organizacinės ir teisinės priemonės turi užtikrinti duomenų konfidencialumą ir prieinamumą.
  • 4Duomenų sauga turi būti užtikrinama užtikrinant duomenų vientisumą ir neprieštaringumą bei suskirstant IS naudotojus į grupes pagal duomenų tvarkymo pobūdį.
  • 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ą (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 ar SQL injekcijos atakos).
  • 11IS turi būti apsaugota nuo paskirstytų ir daug resursų reikalaujančių atakų (DdoS).

Architektūros ir programinės įrangos charakteristikos

  • 1Kuriami komponentai turi būti sukurti kaip nepriklausomi mikroservisai, veikiantys atskirai nuo esamos informacinės sistemos (PHP, SystemSight TVS, MySQL) ir netrikdantys pagrindinės sistemos veikimo.
  • 2Mikroserviso veikimas, klaidos ar prieinamumo sutrikimai neturi įtakoti pagrindinės sistemos stabilumo ar veikimo.
  • 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.
  • 7Mikroserviso prieigos ir autorizavimo mechanizmai turi būti suderinti su esamos sistemos saugumo architektūra.
  • 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 (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.
  • 11Kuriamas mikroservisas turi turėti aiškiai apibrėžtas ribines sąsajas ir priklausomybes.
  • 12Visi SA ambasadorių posistemės funkciniai komponentai turi pilnai palaikyti Unicode (UTF-8) standartą.
  • 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.
  • 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.
  • 16Sistemos komponentų kūrimas turi būti atliekamas naudojant automatizuotus testus.
  • 17Informacinės sistemos programinės įrangos surinkimo, komplektavimo, diegimo ir saugojimo (deployment) priemonės turi būti tarpusavyje integruotos, nuoseklios ir lengvai valdomos.
  • 18Sistemos vidiniai parametrai turi būti prieinami stebėjimui ir keitimui.

Dokumentai13

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