DAŽNIŲ SAVITARNOS MODIFIKAVIMO PASLAUGOS
Išanalizuota
Lietuvos Respublikos ryšių reguliavimo tarnyba
Atviras konkursasCPV: 72230000 - Vartotojų programinės įrangos kūrimo paslaugos
ID: 79768352026-05-21 09:55Pasiūlymai iki: 2026-06-04 10:00
Atidaryti CVP ISAprašymas
Lietuvos Respublikos ryšių reguliavimo tarnyba (RRT) perka Radijo dažnių spektro savitarnos portalo (Dažnių savitarna) funkcionalumų modifikavimo paslaugas. Šios paslaugos apima Dažnių savitarnos analizę, projektavimą, programavimą, konfigūravimą, testavimą, diegimą ir bandomąją eksploataciją, siekiant sukurti naujus funkcionalumus ir atnaujinti esamus, ypač susijusius su sąskaitų išrašymu ir elektroninėmis formomis. Darbų tikslas – tobulinti Dažnių savitarnos elektronines paslaugas fiziniams ir juridiniams asmenims, užtikrinant efektyvesnį radijo dažnių spektro valdymą.
Kvalifikaciniai reikalavimai
- 1Tiekėjas per paskutinius 3 (trejus) metus arba per laiką nuo tiekėjo įregistravimo dienos (jei tiekėjas vykdė veiklą mažiau nei 3 (trejus) metus) yra įvykdęs ar vykdo ne mažiau kaip 1 (vieną) radijo dažnių valdymo sprendimų kūrimo ir (ar) palaikymo, ir (ar) įdiegimo paslaugų teikimo sutartį, kurios vertė ne mažesnė kaip 16 500,00 Eur be PVM. Laikoma, kad tiekėjas atitinka reikalavimą, jei sutarties (vykdomos ar kurią jis vykdė kaip subtiekėjas ar būdamas ūkio subjektų grupės narys) jam tekusi sėkmingai įvykdyta dalis yra ne mažesnė kaip šiame punkte nurodyta suma. Jei tiekėjas teikia informaciją apie vykdomą sutartį laikoma, kad jo patirtis atitinka keliamą reikalavimą, jei vykdomos sutarties įvykdyta dalis yra ne mažesnė kaip aukščiau nurodyta suma.
- 2Jeigu pasiūlymą teikia ūkio subjektų grupė, reikalavimą turi atitikti visi ūkio subjektų grupės nariai kartu, atsižvelgiant į jų prisiimamus įsipareigojimus pirkimo sutarčiai vykdyti (patirtis sumuojama).
- 3Tiekėjas gali remtis kitų ūkio subjektų pajėgumais tik tuo atveju, kai tie ūkio subjektai, kurių pajėgumais buvo pasiremta, vykdys tą pirkimo sutarties dalį, kuriai reikia jų turimų pajėgumų.
- 4Tiekėjui nedraudžiama remtis sutartimi, kurią tiekėjas vykdė ne vienas, bet kartu su kitais ūkio subjektais. Tačiau tokiu atveju vertinami būtent konkretaus ūkio subjekto, dalyvaujančio viešajame pirkime, atlikti darbai, pristatytos prekės ar suteiktos paslaugos, jų apimtis, vertė, o ne visas vykdytos sutarties objektas.
Techniniai reikalavimai
Saugumo reikalavimai
- 1Teikėjas privalo identifikuoti pagrindines saugumo rizikas bei pažeidžiamumus (CWE/SANS TOP 25 ir OWASP 10) ir imtis priemonių jų sumažinimui ir šalinimui.
- 2Teikėjas privalo pateikti visų naudojamų trečių šalių komponentų sąrašą ir užtikrinti, kad jie atitinka RRT saugumo reikalavimus.
- 3Duomenų sauga turi užtikrinti duomenų vientisumą, neprieštaringumą ir apsaugą nuo atsitiktinio ištrynimo (pvz., perspėjimai).
- 4Turi būti suderinti leidžiami prisegti failų formatai, neleidžiant prisegti potencialiai nesaugių failų.
Garantijos ir dokumentacija
- 1Teikėjas modifikuotiems funkcionalumams suteikia ne trumpesnę kaip 12 mėnesių garantiją nuo perdavimo–priėmimo akto pasirašymo dienos.
- 2Per garantijos laikotarpį nustatyti trūkumai turi būti pašalinti per 2 darbo dienas nuo Užsakovo pranešimo.
- 3Visa susijusi dokumentacija turi būti parengta lietuvių kalba, pateikta elektroninėje laikmenoje ir/ar patalpinta Užsakovo nurodytoje saugykloje.
- 4Dokumentacija turi būti aiški, nuosekli, numeruota, unikaliai identifikuojama, versijuojama, atspausdinta Užsakovo prašymu.
- 5Minimali dokumentacija apima atnaujintą techninį aprašymą, veiklų grafiką, kokybės užtikrinimo planą bei suprogramuotų funkcionalumų išeities tekstus ir vykdymo kodus (saugomus Git talpykloje).
Modifikavimo paslaugų etapai
- 1Atliekama detali Dažnių savitarnos modifikuojamų funkcionalumų analizė, rezultatai derinami su Užsakovu.
- 2Modifikuojamų funkcionalumų projektavimas, programavimas ir konfigūravimas vykdomas pagal su Užsakovu suderintą detalų veiklų grafiką.
- 3Atliekamas funkcionalumų, apkrovos, saugumo bei integracijų testavimas.
- 4Identifikuoti trūkumai taisomi pagal suderintą klaidų valdymo procesą.
- 5Testavimo rezultatai suderinami su Užsakovu.
- 6Modifikuojamų funkcionalumų diegimas testinėje ir produkcinėje aplinkose vykdomas etapais pagal sutartą procesą.
- 7Bandomoji eksploatacija vykdoma 1 mėnesį po funkcionalumų diegimo produkcinėje aplinkoje.
- 8Teikiamos konsultacijos bandomosios eksploatacijos klausimais ir šalinami nustatyti trūkumai.
- 9Bandomosios eksploatacijos rezultatai suderinami su Užsakovu.
- 10Atnaujinamas ir su Užsakovu suderinamas Dažnių savitarnos techninis aprašymas ir susijusi dokumentacija.
- 11Teikėjas per 5 darbo dienas nuo sutarties įsigaliojimo dienos parengia detalų veiklų grafiką ir kokybės užtikrinimo planą.
- 12Funkcionalumai turi būti kuriami Agile principu (iteracijomis ir inkrementais).
- 13Teikėjas privalo užtikrinti, kad Dažnių savitarna atitiktų saugumo, funkcionalumo, naudojimo patogumo bei integracijos reikalavimus.
- 14Visi dokumentai, susiję su sistemos funkcionalumų modifikavimu, turi būti pateikti prieš diegiant funkcionalumus į produkcinę aplinką.
- 15Modifikuotas funkcionalumas, įkeltas į produkcinę aplinką, neturi sutrikdyti kitų esančių funkcijų darbo. Sutrikus darbui, Teikėjas turi nedelsiant atstatyti funkcionalumus ir ištaisyti klaidas.
Integracinių sąsajų reikalavimai
- 1Duomenų mainai turi būti vykdomi naudojant žiniatinklio paslaugas ar lygiavertes technologijas, HTTP (RESTfull) ar lygiavertį protokolą, atsižvelgiant į duomenų teikimo formatų ir standartų rekomendacijas.
- 2Duomenų patikrinimas turi vykti naudojant XML ir/arba JSON schemas.
- 3Sistema turi turėti viešą Web API, kad būtų užtikrinama sąveika su kitomis informacinėmis sistemomis.
- 4Teikėjas gali siūlyti alternatyvius integracijos realizavimo būdus, užtikrinančius lygiavertę ar geresnę greitaveiką, prieinamumą, plečiamumą, palaikymą ir saugumą, suderinus su Užsakovu.
Greitaveikos ir našumo reikalavimai
- 1Turi būti galimybė vienu metu netrukdomai dirbti ne mažiau kaip 40 naudotojų.
- 2Paslaugų Teikėjas turi pateikti minimalius reikalavimus techninei įrangai ir tinklų pralaidumui, reikalingus užtikrinti minimalius sistemos našumo kriterijus.
- 3Sistemoje turi būti indikuojami ilgiau trunkantys procesai.
- 4Sistema turi veikti be sutrikimų ne mažiau 99 procentų paros laiko.
- 5Vartotojo sąsajos reakcijos laikas į mygtuko paspaudimą neturi viršyti 2 sekundžių.
- 6Integracinių sąsajų realizacija turi užtikrinti, kad scenarijai įvyks per racionalų laiką ir nedarys neigiamos įtakos naudojimo patogumui ir našumui.
- 710 naudotojų vienu metu atliekami laisvų dažnių paieškos skaičiavimai vidaus radijo ryšio tinklams (po vieną stotį kiekvienam naudotojui) neturi trukti ilgiau nei 30 minučių, naudojant 10 m raiškos žemėlapį.
- 8Taškinio objekto atvaizdavimo žemėlapyje trukmė neturi viršyti 1 sekundės.
Naudotojo sąsajos ir ergonomikos reikalavimai
- 1Naudotojo sąsaja turi atitikti šiuolaikinius ergonomikos reikalavimus, elektroninių paslaugų tinkamumo naudotojams metodinės medžiagos reikalavimus ir gerosios praktikos (pvz., ISO 9241-210) principus.
- 2Grafinė sąsaja turi būti nepriklausoma nuo platformos ir veikti Microsoft Windows, Linux, MAC OS, Android bei kitose plačiausiai naudojamose aplinkose.
- 3Sistema turi vienodai ir korektiškai funkcionuoti bei būti atvaizduojama visose gamintojų oficialiai palaikomose interneto naršyklių versijose (Google Chrome, Mozilla Firefox, Microsoft Edge, Opera, Safari), užtikrinant suderinamumą su paskutinėmis dviem pagrindinėmis versijomis viso garantinio laikotarpio metu.
- 4Naudotojui turi būti pateikiamos pagalbos priemonės (pvz., pagalbos mygtukai, naudotojo vadovas).
- 5Turi būti realizuotas loginis tikrinimas tarp formos elementų (pvz., įvedimas viename lauke įjungia/išjungia kitus laukus).
- 6Turi būti realizuotas pagalbinės informacijos (angl. hints) funkcionalumas – paaiškinamieji pranešimai.
- 7Turi būti realizuotas naudojimo patogumą užtikrinantis funkcionalumas: užuominos ant grafinių objektų (lietuvių kalba), automatinis duomenų laukų užpildymas, fone vykdomi veiksmai leidžia naudotojui naudoti kitas sistemos funkcijas.
- 8Duomenų sąrašai turi būti puslapiuojami (arba su alternatyviu ribojimu), filtruojami pagal aktualius kriterijus ir rikiuojami.
- 9Naudotojų informavimui: pranešimai turi būti aiškūs, nurodantys priežastį ir konkrečius duomenų objektus; prieš atliekant didelės įtakos veiksmus, sistema turi prašyti patvirtinimo; klaidų pranešimai turi nurodyti, kokius veiksmus atlikti; turi būti sėkmės pranešimai; klaidų, sėkmės ir informaciniai pranešimai turi būti vizualiai išskirti.
- 10Naudotojui pateikiama informacija turi būti ribojama pagal jo roles ir prieigos teises.
- 11Informacija turi būti viešinama atsižvelgiant į BDAR reikalavimus, suderinus su Užsakovu.
Bendrieji reikalavimai ir nacionalinis saugumas
- 1Pirkimo objektui taikomi LR VPĮ 37 str. 9 dalies reikalavimai, susiję su nacionaliniu saugumu. Tiekėjas privalo įrodyti, kad siūlomos paslaugos nekelia grėsmės nacionaliniam saugumui ir nėra vykdomos iš VPĮ 92 straipsnio 14 dalyje numatytame sąraše nurodytų valstybių ar teritorijų.
- 2Dokumentai, patvirtinantys atitiktį nacionalinio saugumo reikalavimams, kuriuose nenurodytas jų galiojimo terminas, turi būti išduoti ne anksčiau kaip 3 mėnesius iki prašymo pateikimo dienos.
- 3Paslaugos turi būti suteiktos per 5 mėnesius nuo sutarties įsigaliojimo datos, bet ne vėliau kaip 2026-12-15.
- 4Paslaugos teikiamos naudojant Užsakovo IT infrastruktūrą, nuotoliniu būdu. Jei nuotolinis teikimas neįmanomas, paslaugos teikiamos Užsakovo buveinėje Mortos g. 14, LT-03219 Vilnius.
- 5Sukurti sprendimai turi būti prieinami elektroninėje erdvėje, naudojant valstybės debesijos paslaugų informacinių išteklių infrastruktūrą, užtikrinant prieinamumą nepriklausomai nuo fizinės įrangos vietos ir specialistų darbo vietos.
- 6Teikėjas paslaugų teikimą ir valdymą turi atvaizduoti Teikėjo arba Užsakovo paslaugų valdymo ir stebėsenos sistemoje Jira.
Dažnių savitarnos modifikavimo funkcionalumai
- 1Sukurti integraciją su nauja Sąskaitų išrašymo informacine sistema (SIS), užtikrinant vienkartinių sąskaitų faktūrų ir išankstinių mokėjimų duomenų (kliento duomenys, paslaugos, kaina, nuolaida, suma ir kt.) perdavimą į SIS užsisakant paslaugas.
- 2Užtikrinti vienkartinių ir periodinių sąskaitų faktūrų bei išankstinių mokėjimų duomenų (data, numeris, laikotarpis, mokėtina suma, neapmokėta suma) ir bendros kliento skolos grąžinimą į Dažnių savitarną, duomenis gaunant per API atidarant Sąskaitų ir mokėjimų sąrašą.
- 3Realizuoti sąskaitų faktūrų bei išankstinių mokėjimų duomenų .pdf formatu perdavimą į Dažnių savitarną, kai klientas paspaudžia atsisiuntimo mygtuką.
- 4Sąskaitų ir mokėjimų sąraše turi būti rodomi visų išrašytų sąskaitų faktūrų ir išankstinių mokėjimų duomenys, bei bendra kliento skolos suma.
- 5Prie kiekvienos sąskaitos faktūros/išankstinio mokėjimo įrašo turi būti mygtukas atsisiųsti .pdf formatu. Turi būti galima nustatyti ir keisti sąskaitų rodomą laikotarpį.
- 6Prie kiekvienos sąskaitos faktūros įrašo turi būti mygtukas atsisiųsti mokamų sumų detalizaciją iš Mokesčių API.
- 7Realizuoti galimybę užsisakyti paslaugas (pvz., Kvalifikacinį egzaminą radijo mėgėjų veiklai), kurioms reikalingas išankstinis apmokėjimas ar apmokėjimas pagal vienkartinę sąskaitą faktūrą, duomenis paimant iš Mokesčių API.
- 8Suteikti galimybę klientui atlikti mokėjimą per VIISP pasirenkant vieną ar kelias sąskaitas.
- 9Realizuoti galimybę riboti naujų paslaugų užsakymą, kai klientas turi skolą.
- 10Realizuoti funkcionalumus, susijusius su pokyčiais dėl tarifų skaičiavimo tvarkos pakeitimo: galimybė pildyti vieną formą vidaus tinklams, apjungiant judriąją ir fiksuotą tarnybas; privačių 5G tinklų mokesčiai skaičiuojami pagal suminį signalo lygį ir aprėpties plotą naudojant Mokesčio API; mokestis už dažnį skaičiuojamas įvertinant paslaugos tipą ir trukdžių zoną naudojant Mokesčio API.
- 11Suteikti galimybę klientui apibrėžti dažnių naudojimo teritoriją administraciniais vienetais, daugybiniais poligonais (apskritimais) ar laisvai brėžiamais netaisyklingais daugiakampiais.
- 12Pakeisti formų būsenų ir saugojimo mechanizmą, įvedant naują prašymo būseną „reikalingos korekcijos“, leidžiančią RRT darbuotojui grąžinti prašymą klientui taisyti.
- 13Pakeisti žinučių/prašymų matomumo ir paskirstymo funkcionalumą: RRT administratorius gali priskirti darbuotojus paslaugoms; darbuotojai gali perskirti žinutes; darbuotojams siunčiamos žinutės, susijusios su jų kuruojamomis paslaugomis; paslaugų ir žinučių sąrašas filtruojamas pagal prisijungusį darbuotoją (su galimybe nuimti filtravimą); darbuotojams siunčiami priminimai apie nebaigtus vykdyti prašymus ir neatsakytas žinutes, administratorius gali keisti priminimų siuntimo laiko nustatymus.
- 14Realizuoti šias elektronines formas ir vedlius: Radijo mėgėjų, Laivų ir orlaivių užsakymo, Jūrų ir oreivystės, Palydovinių sistemų, Radijo ir televizijos, ir kitas bendrąsias užsakymų formas (įskaitant mobilioji ir fiksuota tarnybas, bazinių stočių registraciją, eksperimentinius tikslus, PMR, belaides vaizdo kameras, garso signalus, Wi-Fi, RFID stotis, mažojo nuotolio radijo ryšio įrenginius, radijo dažnių (kanalų) skyrimą).
- 15Patobulinti privačių 5G tinklų registravimo formą (vedlį), leidžiant gauti užimtą dažnį, jei sutinkama sinchronizuotis su kitu tinklu, įskaitant sinchronizacijos parametro realizavimą, taisyklės siūlymui, mechanizmą susitarimo patvirtinimui ir papildomą mokėjimo požymį dėl sinchronizavimo.
Programinės įrangos ir licencijų reikalavimai
- 1Teikėjas turi numatyti ir pateikti reikiamos programinės įrangos licencijas (ar leidimus), reikalingas siūlomo sprendimo realizacijai ir eksploatacijai (įskaitant standartinę licencinę programinę įrangą, aplikacijų serverius, monitoringo PĮ, programavimo karkasus).
- 2Licencijos turi būti pateikiamos visam Paslaugų teikimo sutarties galiojimo laikotarpiui (įskaitant garantinę priežiūrą) ir visoms aplinkoms (testavimo ir produkcinėms).
- 3Licencijuojama programinė įranga turi turėti gamintojo palaikymą (atnaujinimus, naujus komponentus).
- 4Jeigu PĮ licencijuojama pagal naudotojų, tarnybinių stočių parametrų kiekį, licencijos turi užtikrinti racionalų ir efektyvų veikimą visą sutarties laikotarpį. Mokama PĮ derinama su Užsakovu.
- 5Atviro kodo PĮ atveju Užsakovui turi būti suteikiamos prieigos teisės prie išeities kodų ir teisė vystyti PĮ savo resursais.
- 6Teikėjas privalo pateikti ir į pasiūlymo kainą įskaičiuoti visą reikiamą standartinę ir nestandartinę PĮ, reikalingą funkcionalumui ir našumui užtikrinti.
- 7RRT turi būti perduodamos autorių turtinės teisės į sukurtą PĮ ir parengtus dokumentus, įskaitant teisę neribotą laiką naudoti, kopijuoti, modifikuoti, tobulinti, perkelti į kitą platformą ir perduoti teises kitiems asmenims.
- 8RRT neturi būti suvaržyta teisė perduoti PĮ priežiūrą ar tobulinimą kitam paslaugų teikėjui, įskaitant prieigos prie pradinio kodo priemones.
- 9Jei Teikėjas neturi kompetencijos vystyti dabartinės PĮ komponentus, jis gali siūlyti jų pakeitimus kitais, išlaikant funkcionalumą ir integralumą, savo sąskaita ir neįtakojant sutarties vykdymo termino.
Dokumentai14
tendis.lt · Sukurta recodin.lt