DAŽNIŲ SAVITARNOS SISTEMOS PLĖTRA
Išanalizuota
Lietuvos Respublikos ryšių reguliavimo tarnyba
Rinkos konsultacijaCPV: 72262000 - Programinės įrangos kūrimo paslaugos
ID: 69791812026-03-18 08:58
Atidaryti CVP ISAprašymas
Perkamos Radijo dažnių spektro valdymo informacinės sistemos (RDSVIS) Radijo dažnių spektro savitarnos portalo (Dažnių savitarna) modifikavimo paslaugos. Jos apima naujų funkcionalumų kūrimą ir diegimą, integraciją su nauja Sąskaitų išrašymo informacine sistema, tarifų skaičiavimo tvarkos pakeitimų įgyvendinimą ir naudotojo sąsajos tobulinimą, siekiant efektyvesnio radijo dažnių spektro valdymo ir geresnės paslaugų kokybės vartotojams.
Kvalifikaciniai reikalavimai
- 1Tiekėjas per paskutinius 3 (trejus) metus arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas vykdė veiklą mažiau nei 3 (trejus) metus) yra suteikęs radijo dažnių valdymo sprendimų kūrimo ir (ar) palaikymo, ir (ar) įdiegimo paslaugų pagal 1 (vieną) ar daugiau sutarčių, kurių vertė yra ne mažesnė kaip 25 000,00 (dvidešimt penki tūkstančiai) Eur be PVM.
Techniniai reikalavimai
Saugumo reikalavimai
- 1Teikėjas privalo identifikuoti pagrindines Dažnių savitarnos saugumo rizikas bei pažeidžiamumus (CWE/SANS TOP 25 ir OWASP 10) ir imtis priemonių rizikų sumažinimui bei šalinimui.
- 2Teikėjas privalo pateikti visų Dažnių savitarnai naudojamų trečių šalių komponentų sąrašą ir užtikrinti jų atitiktį RRT saugumo reikalavimams.
- 3Duomenų sauga turi būti užtikrinama duomenų vientisumu, neprieštaringumu ir apsaugos priemonėmis nuo atsitiktinio duomenų ištrynimo (pvz., perspėjimai).
- 4Teikėjas turi suderinti failų formatus, kuriuos leidžiama prisegti Dažnių savitarnoje, neleidžiant prisegti potencialiai nesaugių failų.
Dokumentacijos reikalavimai
- 1Dokumentacija turi būti parengta lietuvių kalba ir pateikta Užsakovui elektroninėje laikmenoje ir (ar) patalpinta Užsakovo nurodytoje saugykloje, o Užsakovo prašymu, atspausdinta.
- 2Minimali pateiktina dokumentacija apima: atnaujintą Dažnių savitarnos techninį aprašymą, funkcionalumų kūrimo planą, analizės rezultatus, testavimo scenarijus ir rezultatus, diegimo planą, bandomosios eksploatacijos rezultatus.
- 3Teikėjas privalo visą modifikuoto Dažnių savitarnos programinio kodo išeities tekstą saugoti Užsakovo nurodytoje Git talpykloje.
- 4RRT sutartimi turi būti perduodamos autorių turtinės teisės į sukurtą Dažnių savitarnos programinę įrangą ir parengtus dokumentus, įskaitant teisę neribotą laiką naudoti, kopijuoti, modifikuoti, plėtoti, perkelti į kitą platformą, suteikti teises kitiems asmenims ir keisti pradinį kodą.
Integracinių sąsajų reikalavimai
- 1Duomenų mainai turi būti vykdomi naudojant žiniatinklio paslaugas ar lygiavertes technologijas, HTTP (RESTfull) ar lygiavertį protokolą, išskyrus pagrįstas išimtis.
- 2Jei integracija realizuota žiniatinklio paslaugų pagrindu, duomenų patikrinimas turi vykti naudojant XML ir/arba JSON schemas.
- 3Dažnių savitarna turi turėti viešą Web API, kad būtų lengvai užtikrinama sąveika su kitomis informacinėmis sistemomis.
Greitaveikos ir našumo reikalavimai
- 1Dažnių savitarnoje turi būti galimybė vienu metu netrukdomai dirbti ne mažiau kaip 40 naudotojų.
- 2Teikė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, kad naudotojui būtų aišku, jog Dažnių savitarna veikia.
- 4Dažnių savitarna turi veikti be sutrikimų ne mažiau 99 procentų paros laiko.
- 5Dažnių savitarnos vartotojo sąsaja turi veikti taip, kad reakcijos laikas į mygtuko paspaudimą neviršytų 2 sekundžių.
- 6Integracinių sąsajų realizacija turi užtikrinti, kad apibrėžti integraciniai scenarijai įvyks per racionalų laiko tarpą 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, kai kiekvieno tinklas sudarytas iš vienos stoties, neturi trukti ilgiau nei 30 minučių, atsižvelgiant į realiai naudojamą žemėlapį ir skaičiavimo žingsnį, kuris neturi būti didesnis už žemėlapio raišką.
- 8Taškinio objekto atvaizdavimo žemėlapyje trukmė neturi viršyti 1 sekundės.
Bendrieji paslaugų teikimo reikalavimai
- 1Dažnių savitarnos funkcionalumų modifikavimo paslaugos turi būti suteiktos per 5 (penkis) mėnesius, bet ne vėliau kaip 2026-12-15.
- 2Paslaugos teikiamos nuotoliniu būdu, o jei to neįmanoma – Užsakovo buveinėje adresu: Mortos g. 14, LT-03219 Vilnius.
- 3Sukurti sprendimai prieinami elektroninėje erdvėje, panaudojant valstybės debesijos paslaugų informacinių išteklių infrastruktūrą.
- 4Teikėjas paslaugų teikimą ir valdymą atvaizduoja Teikėjo arba Užsakovo paslaugų valdymo ir stebėsenos sistemoje Jira.
- 5Teikėjas modifikuotiems Dažnių savitarnos funkcionalumams suteikia ne trumpesnę kaip 12 (dvylikos) mėnesių garantiją.
- 6Teikėjas įsipareigoja savo jėgomis ir lėšomis pašalinti per garantijos laikotarpį nustatytus trūkumus per 2 (dvi) darbo dienas nuo Užsakovo pranešimo apie trūkumus išsiuntimo dienos.
- 7Modifikuotas Dažnių savitarnos funkcionalumas, įkeltas į produkcinę aplinką, neturi sutrikdyti kitų esančių funkcijų darbo.
Naudotojo sąsajos ir ergonomikos reikalavimai
- 1Naudotojo sąsaja turi atitikti šiuolaikinius ergonomikos reikalavimus, Elektroninių paslaugų tinkamumo naudotojams metodinės medžiagos reikalavimus ir būti projektuojama vadovaujantis gerosiomis praktikomis (pvz., ISO 9241-210 ar lygiavertėmis).
- 2Naudotojų grafinė sąsaja turi būti nepriklausoma nuo platformos ir veikti Microsoft Windows, Linux, MAC OS, Android ir kitose plačiausiai naudojamose aplinkose.
- 3Dažnių savitarna turi vienodai ir korektiškai funkcionuoti bei būti tinkamai atvaizduojama paskutinėse dvejose pagrindinėse „Google Chrome“, „Mozilla Firefox“, „Microsoft Edge“, „Opera“, „Safari“ naršyklių versijose be funkcionalumo apribojimų.
- 4Naudotojui turi būti pateikiamos pagalbos priemonės, padedančios greičiau išmokti naudotis Dažnių savitarna (pvz., pagalbos mygtukai, naudotojo vadovas).
- 5Turi būti realizuotas pagalbinės informacijos (angl. hints) funkcionalumas, pateikiant paaiškinamuosius pranešimus lietuvių kalba.
- 6Duomenų įvedimo formose duomenų laukai turi būti užpildomi automatiškai, jeigu Sistemoje yra saugomi atitinkami duomenys.
- 7Sistemos veiksmai, kurie gali būti vykdomi fone, turi būti realizuojami taip, kad naudotojas galėtų naudoti kitas sistemos funkcijas.
- 8Duomenų sąrašai turi būti puslapiuojami arba atvaizduojami begalinės slinkties būdu, su galimybe nurodyti, kiek eilučių rodyti, arba taikant alternatyvų vienu metu įkeliamų ir matomų duomenų kiekio ribojimą.
- 9Duomenų sąrašai turi būti filtruojami pagal sąrašui aktualius kriterijus ir rikiuojami pagal rikiuotinus elementus.
- 10Naudotojui pateikiami pranešimai turi būti suformuluoti taip, kad būtų aiški pranešimo priežastis, nurodant konkrečius Sistemos duomenų objektus (pvz., laukų pavadinimus).
- 11Prieš atliekant veiksmą, kurio rezultatai turės didelės įtakos, Dažnių savitarna turi pateikti pranešimą ir paprašyti naudotojo patvirtinti.
- 12Klaidų pranešime privalo būti nurodoma, kokius veiksmus naudotojas privalo atlikti, kad galėtų pašalinti pranešimo priežastis ir tęsti darbą.
- 13Naudotojui turi būti pateikiami sėkmės pranešimai, nurodantys, kad atlikti veiksmai yra sėkmingi.
- 14Klaidų, sėkmės ir informaciniai pranešimai turi būti išskirti skirtingomis spalvomis ar simboliais.
- 15Naudotojui pateikiama informacija turi būti ribojama pagal jam suteiktas roles bei prieigos teises prie konkretaus objekto informacijos.
- 16Informacija turi būti viešinama atsižvelgiant į Bendrojo duomenų apsaugos reglamento reikalavimus, suderintus su Užsakovu.
Funkcionalumo modifikavimai: Prašymų valdymas
- 1Turi būti pakeistas formų būsenų ir saugojimo mechanizmas, įvedant naują prašymo būseną, pvz., „reikalingos korekcijos“, leidžiančią RRT darbuotojui grąžinti prašymą klientui taisyti.
- 2RRT darbuotojui pakeitus prašymo būseną, klientui turi būti siunčiamas pranešimas apie poreikį koreguoti dokumentą.
- 3Klientui atlikus korekcijas, jo pakeitimai turi būti pažymėti, kad RRT darbuotojai matytų, kas buvo pakeista.
- 4Kol dokumentas yra pateiktas RRT darbuotojui, klientui neturi būti galima jo koreguoti.
Programinės įrangos ir licencijų reikalavimai
- 1Standartinė licencinė programinė įranga turi būti pateikiama su visomis reikiamomis licencijomis visam Paslaugų teikimo sutarties galiojimo laikotarpiui (įskaitant garantinę priežiūrą).
- 2Licencijuojama programinė įranga turi turėti gamintojo palaikymą (atnaujinimų, naujų komponentų pateikimą) visam Paslaugų teikimo sutarties laikotarpiui.
- 3Jeigu naudojama ir vystoma atviro kodo licencinė programinė įranga, turi būti suteikiamos Užsakovui prieigos teisės prie išeities kodų ir teisė vystyti šią programinę įrangą savo resursais.
- 4Teikėjas turi pateikti ir į pasiūlymo kainą įskaičiuoti visą reikiamą standartinę ir nestandartinę programinę įrangą, reikalingą funkcionalumui ir našiam darbui užtikrinti.
- 5RRT neturi būti suvaržyta teisė perduoti modifikuotos Dažnių savitarnos programinės įrangos priežiūros ar tolesnio tobulinimo kitam paslaugų teikėjui, įskaitant prieigos prie pradinio kodo priemones.
Funkcionalumo modifikavimai: Tarifų skaičiavimas
- 1Klientui turi būti galimybė pildyti vieną formą vidaus tinklams, apjungiant šiuo metu turimas formas judriajai ir fiksuotai tarnyboms.
- 2Privačių 5G tinklų mokesčiai turi būti skaičiuojami apskaičiuojant visų tinklo stočių suminį signalo lygį ir gautą signalo aprėpties plotą naudojant Mokesčio API (RDSVIS komponentas).
- 3Mokestis už naudojimąsi dažniu(-iais) turi būti skaičiuojamas įvertinant paslaugos tipą ir trukdžių zoną, pasinaudojus Mokesčio API (RDSVIS komponentas).
- 4Klientui turi būti galimybė apibrėžti teritoriją, kurioje bus naudojami jo pasirinkti dažniai, šiais būdais: administraciniais vienetais (savivaldybėmis); daugybiniais poligonais (apskritimais); laisvai brėžiamais netaisyklingais daugiakampiais.
Funkcionalumo modifikavimai: Sąskaitos ir mokėjimai
- 1Turi būti sukurta Dažnių savitarnos integracija su nauja Sąskaitų išrašymo informacine sistema (SIS), užtikrinanti vienkartinių sąskaitų ir išankstinių mokėjimų duomenų perdavimą į SIS, kai klientas užsisako paslaugas.
- 2Integracija su SIS turi užtikrinti vienkartinių ir periodinių sąskaitų, išankstinių mokėjimų bei bendros kliento skolos sumos grąžinimą į Dažnių savitarną, kai klientas atidaro Sąskaitų ir mokėjimų sąrašą.
- 3Integracija su SIS turi užtikrinti sąskaitų ir išankstinių mokėjimų duomenų .pdf formatu perdavimą į Dažnių savitarną tiesiogiai, kai klientas paspaudžia mygtuką atsisiųsti .pdf.
- 4Dažnių savitarnoje sąskaitų duomenys neturi būti saugomi, bet gaunami per API pagal kliento užklausas.
- 5Są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 (datos, numeriai, laikotarpiai, sumos) bei bendra kliento skolos suma.
- 6Prie kiekvienos sąskaitos faktūros ar išankstinio mokėjimo įrašo turi būti mygtukas atsisiųsti .pdf formatu.
- 7Turi būti galima nustatyti ir keisti laikotarpį, už kurį Dažnių savitarnoje bus rodomos sąskaitos faktūros.
- 8Prie kiekvienos sąskaitos įrašo turi būti mygtukas atsisiųsti už leidimus ar registracijas mokamų sumų detalizaciją, paimant duomenis iš Mokesčių API.
- 9Turi būti realizuota galimybė užsisakyti paslaugas, kurioms reikalingas išankstinis apmokėjimas ar apmokėjimas pagal vienkartinę sąskaitą faktūrą, paimant duomenis mokėjimui iš Mokesčių API.
- 10Turi būti galimybė klientui atlikti mokėjimą per VIISP pasirenkant vieną ar kelias norimas apmokėti sąskaitas ar išankstinius mokėjimus.
- 11Turi būti galimybė riboti naujų paslaugų užsakymą, kai klientas turi skolą pagal visas RRT suteiktas paslaugas.
Funkcionalumo modifikavimai: Elektroninės formos ir vedliai
- 1Radijo mėgėjams: išduoti leidimą užsiimti radijo mėgėjų veikla; laikyti radijo mėgėjų kvalifikacinį egzaminą; pratęsti radijo ryšio stočių registracijos terminą (bendras); mėgėjų radijo šaukinio registracija; radijo ryšio stoties registravimas.
- 2Laivų ir orlaivių užsakymo vedliai: prašymas registruoti laivo stotį; prašymas registruoti orlaivio stotį.
- 3Jūrų ir oreivystės vedliai: radijo ryšio stoties registravimas.
- 4Palydovinių sistemų: žemės stoties registracija (anglų ir lietuvių kalba); žemės stočių tinklo registracija (anglų ir lietuvių kalba); leidimas naudoti radijo dažnius (kanalus) GNSS kartotuvui (anglų ir lietuvių kalba); leidimo išdavimas orbitiniams ištekliams; naujienų rinkimo Žemės stoties (SNG) registracija.
- 5Radijo ir televizijos: radijo dažnių (kanalų) skyrimas radijo ir televizijos programoms transliuoti (retransliuoti); antžeminio transliavimo radijo ryšio stoties radiotechninės dalies projekto suderinimas; antžeminio transliavimo radijo ryšio stoties registracija.
- 6Kitos užsakymų formos ir vedliai: radijo dažnių skyrimas mobiliosios tarnybos ir fiksuotosios tarnybos viešiesiems tinklams; bazinių stočių registracija; radijo dažnių naudojimas eksperimentiniams tikslams; vidaus radijo ryšio tinklo (PMR) stočių registracija trumpalaikiams renginiams; belaidžių vaizdo kamerų registracija; radijo ryšio stočių registracija garso signalų perdavimui artimu nuotoliu renginių metu; Wi-Fi (WAS/RLAN (BFWA)) registracija; RFID stoties registracija; mažojo nuotolio radijo ryšio įrenginių tinklo registracija; radijo dažnių (kanalų) skyrimas.
- 7Informacijos apie naudojimą be atskiro leidimo ir registracijos atvaizdavimas.
Funkcionalumo modifikavimai: Privačių 5G tinklų registracija
- 1Patobulinti privačių 5G tinklų registravimo formą (vedlį), kad naujo tinklo naudotojas galėtų gauti jau užimtą dažnį, jei sutiktų sinchronizuotis su kitu tinklu, t. y., naudoti tokį patį duomenų siuntimo/priėmimo santykį.
- 2Realiai realizuoti sutikimo sinchronizuotis parametrą registracijos formoje (vedlyje).
- 3Realiai realizuoti taisyklę, kada vartotojui siūlomas būtent toks dažnis, kuris reikalauja sinchronizacijos (dėl geografinių apribojimų, laisvų dažnių trūkumo, prioritetinių dažnių ir pan.).
- 4Realiai realizuoti mechanizmą, kurio pagalba tinklų savininkai patvirtintų susitarimą dėl tinklų sinchronizacijos.
- 5Realiai realizuoti mokėjimo už dažnius papildomą požymį dėl tinklų sinchronizavimo (gali būti taikomos mokesčių nuolaidos).
Funkcionalumo modifikavimai: Pranešimų ir užduočių valdymas
- 1Turi būti galimybė RRT administratoriui priskirti RRT darbuotojus prie paslaugų.
- 2Turi būti galimybė RRT darbuotojui perskirti žinutę/prašymą kitam RRT darbuotojui.
- 3RRT darbuotojams turi būti siunčiamos žinutės, susijusios su jų kuruojamomis paslaugomis.
- 4Paslaugų ir žinučių sąraše turi būti automatiškai filtruojamos paslaugos ir žinutės pagal prisijungusį darbuotoją, su galimybe nuimti filtravimą.
- 5Turi būti galimybė kelis kartus per dieną RRT darbuotojams siųsti priminimus apie nebaigtus vykdyti prašymus ir neatsakytas žinutes, su galimybe administratoriui keisti priminimų siuntimo laiko nustatymus.
tendis.lt · Sukurta recodin.lt