Grįžti į sąrašą

LR Ryšių reguliavimo tarnybos elektroninių paslaugų portalo kūrimo, diegimo, garantinio palaikymo ir modifikavimo paslaugos

Išanalizuota

Lietuvos Respublikos ryšių reguliavimo tarnyba

410 000 €
Atviras konkursasCPV: 72262000 - Programinės įrangos kūrimo paslaugos
ID: 68373262026-03-13 05:31
Atidaryti CVP IS

Aprašymas

Perkamas integruotas Ryšių reguliavimo tarnybos (RRT) elektroninių paslaugų portalas su low-code/no-code platforma, skirtas klientų savitarnai ir vidiniam administravimui. Projektas apima 20 paslaugų formų ir procesų sukūrimą, Radijo trukdžių tyrimų registro modulio modernizavimą, bei portalo priežiūros, palaikymo ir modifikavimo paslaugas. Tikslas – skaitmenizuoti ir automatizuoti RRT paslaugų teikimo procesus, leidžiant RRT darbuotojams savarankiškai plėtoti paslaugų katalogą.

Kvalifikaciniai reikalavimai

  • 1Tiekėjo arba tiekėjų grupė/ partneriai kartu per paskutinius 3 metus iki pasiūlymų pateikimo termino pabaigos pagal vieną ar daugiau sutarčių yra savo jėgomis tinkamai įvykdęs bent vieną informacinių sistemų, elektroninių paslaugų portalo arba savitarnos sprendimo sukūrimo ir (ar) diegimo sutartį, kurios vertė ne mažesnė kaip 100 000,00 Eur be PVM. Sutartis (-ys) turi apimti procesų, paslaugų skaitmenizavimą ir integracijas su išorinėmis informacinėmis sistemomis, low-code/ no-code metodologija paremtų platformų taikymą, Microsoft Power Platform pagrindu arba lygiavečiu sukurtas portalas.
  • 2Spredimo architektas (Enterprise Architects) turi TOGAF Enterprise Architecture Foundation arba lygiavertį sertifikatą.
  • 3Spredimo architektas (Enterprise Architects) turi ne trumpesnę kaip 2 metų informacinių sistemų architektūros projektavimo patirtį per paskutinius 3 metus.
  • 4Microsoft viešosios debesijos paslaugų architektas turi Microsoft Certified: Azure Solutions Architect Expert arba lygiavertį sertifikatą.
  • 5Microsoft viešosios debesijos paslaugų architektas turi ne trumpesnę kaip 2 metų patirtį per paskutinius 3 metus viešosios debesijos paslaugų projektavimo ar diegimo srityje.
  • 6Programuotojas / konfigūruotojas turi ne mažesnę kaip 2 metų darbo patirtį su Power Platform arba lygiaverčiu sprendimų kūrimu per paskutinius 3 metus. Praktinė patirtis formų kūrime, veiklos procesų/sekos (workflow) automatizavime, Dataverse duomenų modeliavime.
  • 7Programuotojas / konfigūruotojas turi dalyvauti bent viename projekte per paskutinius 3 metus, kuriame sukurtas paslaugų teikimo savitarnos portalas arba procesų skaitmenizavimo sprendimas.
  • 8UX/UI dizaineris turi ne mažesnę kaip 2 metų patirtį per paskutinius 3 metus kuriant vartotojo sąsajas web sprendimams / portalams, pritaikant dizainą pagal esamą Perkančiosios organizacijos vizualinio identiteto (stiliaus knygą).
  • 9UX/UI dizaineris turi dalyvauti bent 1 projekte per paskutinius 3 metus, kuriame sukurtas web sprendimas / portalas.
  • 10Integracijų / sistemų inžinierius turi ne mažesnę kaip 2 metų darbo patirtis per paskutinius 3 metus integruojant informacines sistemas, kuriant API integracijas.
  • 11Integracijų / sistemų inžinierius per paskutinius 3 metus turi dalyvauti bent 1 informacinės sistemos kūrimo projekte, kuriame buvo sukurta bent viena integracija su išorine informacine sistema.
  • 12Programinės įrangos kūrimo ir IT sistemų diegimo bei eksploatavimo procesų automatizavimo (DevOps) inžinierius turi ne trumpesnę kaip 2 metų per paskutinius 3 metus patirtį programinės įrangos kūrimo ir IT sistemų diegimo bei eksploatavimo procesų automatizavimo (DevOps) paslaugų teikimo srityje.
  • 13Projekto vadovas turi ne trumpesnę kaip 3 metų vadovavimo sistemų kūrimo ar analogiškiems diegimo projektams patirties per pastaruosius 5 (penkerius) metus.
  • 14Projekto vadovas turi IT ar projektų valdymo kvalifikaciją (COBIT, CGEIT, arba PMP arba CompTIA Project+, arba Prince2, sertifikatas arba kitas lygiavertis dokumentas).
  • 15Projekto vadovas arba sistemų ir veiklos analitikas turi turėti patirties dirbant Agile (Scrum, Kanban ar lygiaverte) projektų vykdymo metodika, pagrįstą dalyvavimu bent viename informacinės sistemos kūrimo projekte per paskutinius 3 metus.
  • 16Duomenų inžinierius turi Microsoft Certified: Azure Data Engineer Associate arba lygiavertį sertifikatą.
  • 17Sistemų testuotojas turi ne mažesnę kaip 2 metų per paskutinius 3 metus informacinių sistemų funkcionalumų testavimo patirtį.
  • 18Sistemų testuotojas yra dalyvavęs bent viename informacinės sistemos ar savitarnos portalo kūrimo projekte, kuriame atliko sistemos testuotojo rolę, per paskutinius 3 metus.
  • 19Tiekėjas turi būti įsidiegęs ir savo veikloje taikyti IT paslaugų kokybės valdymo sistemą, atitinkančią ISO/IEC 20000-1 (lietuviška versija – LST EN ISO 20000-1) arba lygiaverčio standarto reikalavimus informacinių technologijų paslaugų teikimo srityje.
  • 20Tiekėjas turi būti įsidiegęs ir savo veikloje taikyti Informacijos saugumo valdymo sistemą, atitinkančią ISO/IEC 27001 (lietuviška versija – LST EN ISO 27001) arba lygiaverčio standarto reikalavimus informacinių technologijų paslaugų teikimo srityje.

Techniniai reikalavimai

Duomenų migracija

  • 1Parengiamas duomenų migravimo planas ir suderinamas su Užsakovu.
  • 2Atliekamas bandomasis ir galutinis duomenų migravimas iš esamos RSKD duomenų bazės.
  • 3Parengiama duomenų migravimo ataskaita ir suderinama su Užsakovu.

RRT Paslaugų katalogas

  • 1Portale turi būti įgyvendintas paslaugų katalogas, prieinamas tik prisijungusiems naudotojams.
  • 2Vidiniame kataloge kiekvienai paslaugai turi būti saugoma ir valdoma bent ši informacija: oficialus paslaugos pavadinimas ir kodas; detalus aprašymas; teikimo terminai; kaina (jei taikoma); reikalingi dokumentai / priedai; susiję teisės aktai; kontaktai konsultacijoms; DUK; kategorija(-os), raktiniai žodžiai ir (ar) sinonimai paieškai.
  • 3Portale turi būti įgyvendinta galimybė grupuoti paslaugas pagal temas (teminės grupės/kategorijos, galimai hierarchinės), o paslaugų katalogo naršymui turi būti naudojama „breadcrumb“ (kelio) navigacija, aiškiai rodanti naudotojo buvimo vietą katalogo struktūroje ir leidžianti vienu paspaudimu grįžti į bet kurį aukštesnį lygį.
  • 4Turi būti įgyvendinta API sąsaja, per kurią išorinė sistema (pvz., RRT interneto svetainė) galės paimti ir atvaizduoti paslaugų katalogo turinį. API turi sudaryti galimybę: gauti konkrečios paslaugos detalę informaciją pagal kodą; gauti tik aktyvias paslaugas; filtruoti pagal kategoriją ir (ar) raktinius žodžius.

Nefunkciniai reikalavimai (bendri)

  • 1Vienu metu dirbančių naudotojų skaičius ne mažiau kaip 200.
  • 2Puslapio atsako laikas vidutiniškai ≤ 3 sekundės 95 % atvejų esant normaliai apkrovai.
  • 3Sistemos pasiekiamumas (SLA) ne mažesnis nei 99%.
  • 4Atstatymas avarijos atveju: RPO – 4 val., RTO – 4 val.
  • 5Integracinių sąsajų vėlinimas ≤ 100 ms esant 50 transakcijų per sekundę.
  • 6Apkrovos testavimas turi patvirtinti ≥ 200 vienalaikių naudotojų be atsako laiko kritimo.
  • 7Tiekėjas privalo identifikuoti pagrindines portalo saugumo rizikas bei saugumo pažeidžiamumus (CWE/SANS TOP 25 ir OWASP Top 10) ir imtis priemonių rizikų sumažinimui bei pažeidžiamumų šalinimui.
  • 8Visi duomenų mainai tarp portalo ir išorinių sistemų vyksta šifruotu ryšiu (HTTPS / TLS 1.3 ar naujesniu).
  • 9Portalas turi atitikti Lietuvos Respublikos kibernetinio saugumo įstatymo ir Organizacinių ir techninių kibernetinio saugumo reikalavimų aprašo reikalavimus.
  • 10Prisijungimas prie portalo vykdomas per VIISP, užtikrinant patikimą autentifikaciją, arba Portalo priemonėmis.
  • 11Turi būti registruojami visi reikšmingi administraciniai ir naudotojų veiksmai (auditas ir atsekamumas).
  • 12Numatoma apsaugos nuo atsitiktinio duomenų ištrynimo priemonė (pvz., perspėjimai prieš ištrynimą).
  • 13Naudotojo sąsaja turi atitikti šiuolaikinius ergonomikos reikalavimus ir būti projektuojama vadovaujantis gerosios praktikos principais (pvz., ISO 9241-210).
  • 14Portalo naudotojo sąsaja turi vienodai funkcionuoti šiose interneto naršyklėse (gamintojų palaikomose naujausėse versijose): Microsoft Edge, Mozilla Firefox, Google Chrome arba kitose lygiavertėse naršyklėse.
  • 15Portalas turi būti realizuotas lietuvių kalba. Anglų kalbos palaikymas turi būti užtikrinamas kaip papildoma kalbos versija, naudojant portale įdiegtą vertimo sprendimą, naršyklės teikiamas vertimo funkcijas arba kitus lygiaverčius techninius sprendimus.
  • 16Portalo dizainas turi būti suderintas su RRT interneto svetainės (www.rrt.lt) vizualine aplinka.
  • 17Portalas turi atitikti WCAG 2.1 lygmens AA prieinamumo standartus. Prieinamumo atitiktis turi būti patvirtinta automatiniais ar rankiniais testavimo ir pateikta Prieinamumo atitikties ataskaita.
  • 18Sistemos aukštas prieinamumas (High Availability) ne mažesnis nei 99%.
  • 19Architektūra turi palaikyti savitarnos pajėgumų plėtros galimybes prijungiant papildomą techninę įrangą arba virtualią infrastruktūrą.
  • 20Pajėgumų didinimas turi būti atliekamas nestabdant sistemos darbo.
  • 21Platformos low-code sprendimas turi leisti RRT pačiai kurti naujas paslaugų formas ir procesus.
  • 22Savitarnos architektūra turi būti kuriama vadovaujantis daugiapakopės (Multi-tier, N-tier) architektūros principais; ją turi sudaryti mažiausiai 4 hierarchiniai lygmenys (vaizdavimo, veiklos logikos, duomenų bazės, integracijų).
  • 23Low-code platforma turi leisti RRT darbuotojams administruoti ir plėsti sprendimą be priklausomybės nuo tiekėjo kasdieniniams pakeitimams.
  • 24Turi būti įgyvendintas centralizuotas srautų stebėjimas apimantis visą sistemą ir platformą, įskaitant puslapių apkrovimo laikų ir klaidų stebėsena.
  • 25Srautų klaidų ir ilgesnio nei nustatyta vykdymo laiko perspėjimai per automatines taisykles.
  • 26Auditavimo žurnalas – visų duomenų sukūrimo, pakeitimo, ištrynimo operacijų žurnalas pildomas automatiškai.
  • 27Portalo išeities kodas turi būti saugomas ir valdomas RRT turimoje programinio kodo ir versijų valdymo platformoje GitHub (VSSA GOVGIT).
  • 28Alternatyvios platformos kodo versijų valdymas turi būti suderintas su RRT GIT platforma.
  • 29Diegimo platforma: Microsoft Power Platform (Azure) arba VITC valdomoji debesijos infrastruktūra (taikant konteinerizavimą) arba Kita viešojo debesies platforma.
  • 30Portalas turi būti kuriamas vadovaujantis Bendrojo duomenų apsaugos reglamento (BDAR) (ES) 2016/679 reikalavimais ir Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymo nuostatomis.
  • 31Tiekėjas turi pateikti duomenų tvarkymo veiklų registrą (jei taikoma) ir duomenų apsaugos poveikio vertinimą, jei apdorojami specialių kategorijų asmens duomenys.
  • 32Portale turi būti įdiegtos techninės ir organizacinės priemonės, užtikrinančios duomenų apsaugos ir privatumo principus.

Paslaugų teikimo formos ir procesai

  • 1Kiekvienai paslaugai turi būti sukurta atskira interaktyvi forma (iš viso 20 formų), realizuojama kaip žingsnis po žingsnio vedlys, leidžiantis išsaugoti juodraštį bet kuriame žingsnyje, automatiškai užpildyti naudotojo duomenis.
  • 2Kiekviena forma turi būti orientuota į konkretų paslaugos tipą ir turėti individualiai pritaikytą laukų struktūrą, logiką bei vartotojo sąsajos elementus.
  • 3Vedlys turi palaikyti dinaminę žingsnių seką ir logiką, kuri adaptuojasi pagal pasirinktą paslaugos tipą, vartotojo įvestus duomenis ar specialius paslaugų scenarijus.
  • 4Turi būti skaitmenizuoti 39 procesai, kurie privalo būti įgyvendinti pagal vieningą paslaugų portalo architektūrą ir bendrą veikimo logiką.
  • 5Portalas turi suteikti galimybę RRT darbuotojams sukurti naujas paslaugų formas, procesus ir automatizacijas naudojant low-code įrankius – be programuotojo pagalbos kasdieniniams pakeitimams, įskaitant formų laukų redagavimą.
  • 6Paslaugų gavėjui užbaigus paslaugą, portale turi būti sudaryta galimybė pateikti atsiliepimą apie paslaugą (įvertinimą ir komentarą), o atsiliepimų duomenys turi būti prieinami ataskaitoms.
  • 7Pagrindinės skaitmenizuojamų paslaugų grupės apima: radijo ryšio keliamų trikdžių tyrimą ir pašalinimą; incidentų dėl ryšio infrastruktūros gedimų šalinimą; paslaugų teikėjų registravimą ir išregistravimą; kreipinių, skundų ir ginčų nagrinėjimą; skaitmeninių paslaugų teikimą ir sertifikavimą.

Paslaugų teikimo apimtys ir terminai

  • 1Portalo kūrimo ir įdiegimo paslaugos turi būti suteiktos per 12 (dvylika) mėnesių nuo sutarties įsigaliojimo datos, su galimybe pratęsti vieną kartą iki 3 mėnesių laikotarpiui dėl objektyvių priežasčių.
  • 2Garantinė priežiūra teikiama 12 (dvylika) mėnesių nuo Portalo kūrimo ir įdiegimo paslaugų perdavimo–priėmimo akto pasirašymo dienos.
  • 3Portalo priežiūros ir palaikymo paslaugos teikiamos 12 (dvylika) mėnesių su galimybe pratęsti dar 12 (dvylika) mėnesių nuo Portalo perdavimo–priėmimo akto pasirašymo dienos.
  • 4Portalo modifikavimo paslaugos teikiamos 12 (dvylika) mėnesių, su galimybe pratęsti dar 12 (dvylika) mėnesių, arba atitinkamai mažiau mėnesių nuo perdavimo–priėmimo akto pasirašymo dienos. Preliminari apimtis – 1 000 (tūkstantis) darbo valandų per 24 mėnesius.

Integracija su išorinėmis sistemomis

  • 1Pilna integracija su VIISP (Tapatybės nustatymas, Mokėjimų paslauga).
  • 2Integracija su GoSign per REST API (Dokumentų pasirašymas; automatinis grąžinimas į portalą po pasirašymo).
  • 3Dvikryptė integracija su SIS (Sąskaitų kūrimas, mokėjimo statusų gavimas, skolų tikrinimas).
  • 4API specifikacijos turi atitikti OpenAPI v3.0 standartą; visoms sąsajoms rengiamos ir palaikomos OpenAPI specifikacijos.
  • 5Visos integracinės sąsajos turi turėti būsenos/gyvybingumo tikrinimo (health-check) taškus, skirtus stebėsenai.
  • 6Taikomas API-first principas – sąsajos projektuojamos ir derinamos prieš realizuojant procesus ir UI.
  • 7Integracija su SIS turi užtikrinti sėkmingą sąskaitų kūrimą, mokėjimų statusų atnaujinimą ir sąskaitų apskaitą, bei sudaryti galimybę paslaugų gavėjui portale matyti sąskaitų sąrašą, atsisiųsti sąskaitos PDF, inicijuoti apmokėjimą.
  • 8Mokamos paslaugos palaiko du modelius: Mokėti prieš atlikimą (sąskaita generuojama iškart po prašymo pateikimo, vykdymas pradedamas tik gavus apmokėjimą) ir Mokėti po atlikimo (sąskaita sugeneruojama tik baigus paslaugą / pateikus sprendimą).
  • 9Klientas „Mano sąskaitos“ skiltyje mato visas sąskaitas su statusu (neapmokėta / apmokėta), PDF atsisiuntimu ir mygtuku „Apmokėti“.
  • 10Jei mokėjimas vėluoja (pvz., viršija terminą) – automatinis priminimas klientui.

Integruotas užduočių valdymo modulis

  • 1Paslaugų portalo sprendimas turi būti vieningas tiek paslaugų gavėjui, tiek RRT darbuotojams.
  • 2Vietoj integracijos su išoriniais užduočių valdymo įrankiais, portale turi būti sukurtas integruotas užduočių valdymo modulis, analogišas Jira Service Management, kurį RRT gali savarankiškai konfigūruoti ir plėsti.
  • 3Paslaugų gavėjas užsisako paslaugą, automatiškai sukuriama užduotis atsakingo skyriaus laukiančių darbų eilėje (angl. – backlog).
  • 4RRT paslaugų administratoriai priskiria vykdytoją ir mato viso proceso eigą.
  • 5Paslaugų gavėjas ir RRT darbuotojas mato tas pačias paslaugos būsenas realiuoju laiku.
  • 6Komunikacija vyksta komentarais toje pačioje paslaugos kortelėje – be el. pašto.
  • 7Dokumentai įkeliami ir atsiunčiami tiesiogiai paslaugos kortelėje.
  • 8Modulis turi palaikyti Agile principus: paslaugų grupės (Epics) - Paslauga arba paslaugų kategorija, užduotys (Tasks) - Kiekvienas paslaugų gavėjo užsakymas = atskira užduotis, laukiančių darbų eilė (Backlog) - Naujų neapdorotų paslaugų eilė, Sprintų (Kanban) lenta - Aktyvių užduočių valdymo sritis su būsenų stulpeliais, našumo (Velocity)/terminų (SLA) stebėsena - Paslaugų įvykdymo laiko ir kiekio ataskaita.
  • 9Paslaugos metaduomenų struktūra: Vidinis Paslaugos identifikatorius, Oficialus Paslaugos kodas / identifikatorius, Paslaugos pavadinimas ir detalusis aprašas, Paslaugą teikiančio struktūrinio vieneto pavadinimas, Paslaugą tvirtinančio (-ių) skyriaus (-ių) pavadinimas (-ai), Požymis, ar paslauga mokama / nemokama, Kaina, jeigu paslauga mokama, Paslaugos sistemos peradresavimo nuoroda, Požymis, ar paslauga palaiko autentifikavimą per VIISP tapatybės, Susijusių paslaugų kategorijų sąrašas (neprivalomas), Paslaugos vertinimas balais (neprivalomas).
  • 10Paslaugos būsenos: Gauta / Backlog, Vykdoma, Peržiūra / Vertinimas, Paslaugų gavėjų patvirtinimas, Dokumentų pasirašymas, Baigta, Grąžinta korekcijai, Atmesta.
  • 11Priskyrimo logika: automatinis priskyrimas pagal paslaugos tipo taisykles (paslaugų grupė → skyrius → eilės metodas) ir rankinis priskyrimas – administratorius konkrečiai pasirenka vykdytoją.
  • 12Komunikacija ir skaidrumas: Kiekvienas paslaugos prašymas turi komentarų juostą; komentarai matomi abiem pusėm realiuoju laiku; RRT darbuotojai gali žymėti komentarą kaip "Vidinį"; dokumentų pridėjimas prie komentarų ir prie paslaugos kortelės; el. pašto ir portalo pranešimai apie būsenos pasikeitimą; automatiniai pranešimai apie artėjančią leidimo / sertifikato / dokumento galiojimo pabaigą (pvz., 30, 14 ir 7 dienos prieš) su tiesiogine nuoroda „Pratęsti“.
  • 13Dokumentų valdymas ir pasirašymas: Paslaugų gavėjas gali įkelti dokumentus prie paslaugos prašymo (leistini formatai: PDF, DOCX, XLSX, JPEG, PNG; maksimalus dydis: iki 50 MB per failą); RRT darbuotojas gali pridėti ir atsiųsti dokumentus paslaugų gavėjui; integruotas elektroninio pasirašymo sprendimas (GoSign arba alternatyvus parašas); pasirašytas dokumentas automatiškai susiejamas su paslaugos kortele ir saugomas sistemoje.
  • 14Ataskaitų ir SLA stebėsena: Realaus laiko ataskaitos RRT administratoriams (aktyvių prašymų skaičius pagal skyrius, paslaugas, statusus); SLA stebėsena (automatinis perspėjimas, kai prašymo vykdymo laikas viršija nustatytą ribą); eksportas (CSV/Excel) ataskaitų tikslais.
  • 15Techniniai reikalavimai moduliui: Modulis turi būti integruotas portalo platformoje; visi duomenys saugomi Užsakovo valdomoje duomenų bazėje; modulio funkcionalumas turi būti konfigūruojamas RRT administratoriams per low-code sąsają; Paslaugų būsenų sąrašas, paslaugų grupių struktūra, priskyrimo taisyklės – konfigūruojamos RRT pačiai.

Bendrieji Portalo funkciniai reikalavimai

  • 1Portalas turi būti sukurtas kaip centralizuotas vieno langelio principu veikiantis savitarnos portalas, kuriame paslaugų gavėjai (fizinis ir juridinis asmuo) gali peržiūrėti paslaugų katalogą, pateikti prašymus, stebėti eigą, gauti sprendimus, pasirašyti dokumentus, apmokėti sąskaitas ir bendrauti su RRT, bei naudotis paslaugų gavėjo erdve su pagrindiniu skydeliu (dashboard), prašymų sąrašu su filtrais.
  • 2Tiek paslaugų gavėjas, tiek RRT darbuotojai mato paslaugos būsenas ir turi prieigą prie to paties komunikacijos kanalo (komentarų ir dokumentų), naudodami integruotą procesų valdymo modulį.
  • 3Portalas turi užtikrinti low-code galimybes – RRT darbuotojas (turintis atitinkamas administravimo teises) gali pats kurti ir redaguoti naujas formas, procesus ir automatizacijas be tiekėjo pagalbos kasdieniniams pakeitimams.
  • 4Portalas turi būti pasiekiamas per RRT svetainę (rrt.lt), Portalo vartotojo sąsajos dizainas turi būti suvienodintas su RRT svetainės dizainu.
  • 5Portalas turi būti visiškai pritaikytas mobiliesiems įrenginiams (responsive design) – optimaliai veikiantis telefonu ir planšete be atskiros mobiliosios aplikacijos.
  • 6Visi duomenų pakeitimai registruojami audito žurnale, užtikrinant veiksmų atsekamumą ir istorinių duomenų peržiūrą, įskaitant kiekvieno prašymo būsenų istoriją, veiksmų laikus ir naudotojų veiksmus.
  • 7Portalo paslaugų gavėjo erdvė turi apimti bent šiuos elementus: pagrindinį paslaugų gavėjo skydelį (dashboard) su „Reikia dėmesio“ informacija, paskutiniais prašymais ir greitomis nuorodomis; prašymų sąrašą su filtravimu, paieška ir rikiavimu; juodraščių sąrašą su galimybe tęsti nebaigtus prašymus; detalią prašymo kortelę su istorija, dokumentais ir susirašinėjimu; pranešimų/įvykių skiltį su neperžiūrėtų pranešimų skaitikliu; juridinio asmens atstovams – visų su įmone susijusių prašymų ir dokumentų matomumą.
  • 8Portale turi būti įgyvendinta informacinio turinio valdymo funkcija (CMS), leidžianti RRT administratoriui savarankiškai tvarkyti viešą informaciją: naujienas, DUK, pranešimus ir banerius.

Prisijungimas ir Prieigos teisių valdymas

  • 1Portalas turi įgyvendinti dvi prisijungimo alternatyvas: Prisijungimas per VIISP (pagrindinis būdas, stipri autentifikacija – prisijungimas per bankus, mobilusis parašas, asmens tapatybės kortelė ir kiti VIISP palaikomi būdai) ir Alternatyvus prisijungimas be VIISP (naudotojams, kurie negali autentifikuotis per VIISP, pvz., užsieniečiams), pagal RRT nustatytą formą ir teikėjo įgyvendinta saugų prisijungimą portale.
  • 2Po sėkmingo prisijungimo portalas turi automatiškai sukurti naują naudotojo paskyrą arba susieti prisijungusį naudotoją su jau esama paskyra, naudojant unikalius identifikatorius.
  • 3Prisijungiant per VIISP susiejimas atliekamas pagal asmens kodą, o kai taikoma – papildomai pagal juridinio asmens kodą.
  • 4Prisijungimo per VIISP metu portalas turi gauti ir panaudoti šiuos duomenis: vardas, pavardė, asmens kodas, juridinio asmens pavadinimas, juridinio asmens kodas (kai taikoma).

RSKD modulis (Radijo trukdžių tyrimų registras)

  • 1Radijo trukdžių tyrimo ir registravimo funkcionalumo sukūrimas naujame Paslaugų portale, apimantis: tyrimo prašymo pateikimą savitarnos kanalu, tyrimo eigos stebėseną paslaugų gavėjui, dokumento (ataskaitos) gavimą portale, pilną tyrimo administravimą RRT darbuotojams.
  • 2Duomenų migracija iš esamos RSKD duomenų bazės į naująją platformą pagal suderintą migravimo planą.
  • 3RSKD modulis realizuojamas naudojant lokalius (duomenų bazėje saugomus) klasifikatorius (dažnių sąrašai, tyrimo priežasčių kodai, sukėlėjų sąrašai). Klasifikatoriai administruojami RRT administratorių per low-code sąsają.
  • 4Kiekvienas RSKD įrašas (trukdžių tyrimo byla) turi apimti šiuos duomenų laukus: Dokumento numeris (generuojamas automatiškai), Registracijos data (užpildoma automatiškai), Vykdantysis skyrius (pasirinkimas), Pranešėjas (vardas, pavardė), Telefono numeris, El. paštas, Trukdžių vieta (adresas ir koordinatės), Dažnis arba kanalo numeris (iš klasifikatoriaus), Kam trukdo (iš klasifikatoriaus), Trukdžių aprašymas, Kas registravo (automatiškai užpildoma), Tyrimo pradžia, Tyrimo terminas, Tyrimo būsena, Priskirtas vykdytojas, Tyrimo išvada – priežasties kodas (iš klasifikatoriaus), Tyrimo išvada – sukėlė objektas (iš klasifikatoriaus), Tyrimo baigimo data (automatiškai), Prisegti dokumentai, Tyrimo istorija / veiklos žurnalas, Dokumentų skaičius (automatiškai).
  • 5Pagrindinis sąrašo langas (suvestinė) turi turėti filtravimą pagal metus, skyrių, tyrimo būseną, vykdytoją, paiešką pagal dokumento numerį (TR-XXX), pranešėją, trukdžių vietą ar dažnį.
  • 6Tyrimo kortelė (detalus vaizdas) turi rodyti visus įrašo duomenis struktūrizuota forma, tyrimo istoriją / veiklos žurnalą, komentarų juostą (vidinius ir išorinius komentarus), dokumentų sąrašą su įkėlimo ir atsisiuntimo galimybe, žemėlapio miniatiūrą, būsenos keitimo mygtukus ir tyrimo išvadų sekciją.
  • 7Naujo pranešimo pateikimas (pareiškėjas – savitarna) turi apimti: pranešėjo duomenų užpildymą (iš VIISP arba rankiniu būdu), trukdžių aprašymą (vietą rankiniu būdu arba per žemėlapį, dažnį/kanalą iš klasifikatoriaus arba laisvu tekstu, kam trukdo iš klasifikatoriaus, laisvo teksto aprašymą), formos pateikimą (automatiškai generuojamas unikalus dok. Nr., išsiunčiamas el. pašto patvirtinimas).
  • 8RRT darbuotojas gali pildyti naują pranešimą portale kito asmens vardu (telefonu gauto skambučio atveju).
  • 9Užbaigus tyrimą, darbuotojas tyrimo kortelėje užpildo išvadų sekciją, pasirinkdamas priežasties kodą (pvz., 'Radijo trukdžius sukėlė [objektas]', 'Išnyko', 'Įrangos gedimas' ir kt.) ir, jei aktualu, konkrečius trukdžių sukėlėjo kategoriją ir objektą.
  • 10Kiekvienam RSKD įrašui automatiškai vedamas chronologinis veiklos žurnalas, fiksuojantis pranešimo registraciją, tyrimo pradėjimą, būsenos pakeitimus, dokumentų įkėlimą, komentarų pridėjimą, tyrimo uždarymą.
  • 11RSKD modulis naudoja bendrą portalo užduočių valdymo modulio būsenų mechanizmą su rekomenduojamomis būsenomis: Gauta / Registruota, Peržiūra, Tyrimas pradėtas, Išvykta į vietą, Laukiama papildomos informacijos, Tyrimo vertinimas, Tyrimas baigtas – priežastis nustatyta, Tyrimas baigtas – priežastis nenustatyta, Uždaryta.
  • 12Automatiniai pranešimai generuojami apie: pranešimo gavimą, tyrimo pradžią, prašymą pateikti papildomą informaciją, tyrimo rezultatus, artėjantį terminą, viršytą terminą, naują komentarą iš RRT, pareiškėjo pridėtą dokumentą/komentarą.
  • 13Ataskaitų ir statistikos funkcionalumas apima: paprastą ataskaitą (filtruojama, eksportuojama), kryžminę ataskaitą (pagal du parametrus, eksportuojama), statistikos vizualizaciją (diagramos, SLA rodiklis), žemėlapio ataskaitą (pageidautina, su grupavimu ir spalviniu kodavimu).
  • 14Žemėlapio komponentas turi būti tiekėjo pasirinkto sprendimo, su koordinačių tikslumu ne mažiau kaip 10 metrų (gatvės lygmuo), veikiantis visose naršyklėse ir mobiliuosiuose įrenginiuose.
  • 15Pranešimo formos žemėlapis turi būti interaktyvus, leidžiantis naudotojui pažymėti trukdžių vietą arba automatiškai ieškoti koordinačių pagal adresą (geocoding), su galimybe naudoti naršyklės Geolocation API mobiliuosiuose įrenginiuose.
  • 16Lokalūs klasifikatoriai (Vykdančiojo skyriaus, Dažnių / kanalų, Sutrikusio dažnio, Tyrimo išvadų – priežasties kodas, Trukdžių sukėlėjo (2 lygiai)) turi būti realizuojami kaip lentelės DB, administruojamos RRT per low-code sąsają.
  • 17RSKD duomenys (asmens duomenys ir informacija apie trukdžių šaltinį) yra jautrūs, prieigos lygmenys diferencijuoti: Pareiškėjas mato tik savo pranešimus; RRT darbuotojas mato savo skyriaus įrašus; RRT administratorius mato visus įrašus; tik skaitymo prieiga mato visas bylas ir ataskaitas.

Dokumentai35

  • Suteikti patikimo pranešėjo statusą ir Subjekto, norinčio tapti ne teismo tvarka nagrinėjančių ginčus įstaiga, sertif.pdf
  • Užregistruoti naują paslaugų teikėją ir išduoti patvirtinimą.pdf
  • Užtikrinti incidento dėl fiksuotojo ryšio infrastruktūros gedimo ar praradimo pašalinimą.pdf
  • 1.2 priedas 2. RSKD Modulio Reikalavimai.docx
  • espd-request.xml
  • espd-request.pdf
  • README.txt
  • 8 priedas Atviro konkurso bendrosios pirkimo sąlygos.docx
  • 0 Atviro konkurso Specialiosios sąlygos.docx
  • 2_c4t_6837326_1.xml
  • 6837326_Contract notice - general directive, standard regime_0.pdf
  • 1258_6837326.pdf
  • 1 priedas Techninė specifikacija.docx
  • Informuoti pareiškėją apie trukdžių tyrimo rezultatus.pdf
  • Išnagrinėti tarpininkavimo paslaugų teikėjo pranešimą apie paskirtą teisinį atstovą.pdf
  • Išregistruoti paslaugų teikėją (2).pdf
  • Ištirti pranešimą ir pašalinti trukdžius.pdf
  • Įvertinti kvalifikuotų PUP pakeitimus.pdf
  • Kreipimųsi klasifikacija ir nagrinėjimo procesai.pdf
  • Pakeisti saugumo užtikrinimo lygį eID priemonei.pdf
  • Paskirti saugumo lygi arba atlikti periodinį eID saugumo užtikrinimo lygio atitikties patikrinimą.pdf
  • Savitarnos Procesu Lentele.pdf
  • Suteikti kvalifikuotų PUP teikėjų ir kvalifikuotų PUP statusą_Atlikti PUP Vertinimą.pdf
  • Išnagrinėti skundą ir priimti sprendimą(Geležinkeliai).pdf
  • Išnagrinėti skundą dėl SPA pažeidimų.pdf
  • Panaikinti kvalifikuotą PUP statusą.pdf
  • Išnagrinėti pranešimą dėl galimo incidento, įvykusio dėl PUP teikėjo.pdf
  • Aprobuoti filtravimo priemonę (FP).pdf
  • 3 priedas Pasiūlymo forma.docx
  • 4 priedas Paslaugų sutarties specialiosios sąlygos.docx
  • 4.3 Sut priedas Nr. 3 Perdavimo - priėmimo aktas.docx
  • 4.4 Sut priedas Nr. 4 Bendrosios sutarties sąlygos.docx
  • 5 priedas Pasiūlymų vertinimo metodika.docx
  • 6 priedas Nacionalinio saugumo reikalavimų atitikties deklaracija.docx
  • 7 priedas Forma dėl kvalifikacijos.docx
tendis.lt · Sukurta recodin.lt