Grįžti į sąrašą

LIETUVOS RESPUBLIKOS SEIMO VEIKLOS INFORMACINĖS SISTEMOS SEIMO POSĖDŽIŲ EIGOS VALDYMO POSISTEMIO ATNAUJINIMO (MODERNIZAVIMO) PASLAUGŲ PIRKIMAS

Išanalizuota

Lietuvos Respublikos Seimo kanceliarija

Rinkos konsultacijaCPV: 72262000 - Programinės įrangos kūrimo paslaugos
ID: 70581392026-03-23 14:32
Atidaryti CVP IS

Aprašymas

Lietuvos Respublikos Seimo kanceliarija vykdo rinkos konsultaciją dėl Seimo veiklos informacinės sistemos (LRS VIS) Seimo posėdžių eigos valdymo posistemio atnaujinimo (modernizavimo) paslaugų pirkimo. Šiuo pirkimu siekiama modernizuoti LRS VIS posistemius, įskaitant balsavimo ir diskusijų posistemį, pakeisti techninę ir programinę įrangą bei paruošti aplinką Seimo posėdžiams vykdyti mišriu ar nuotoliniu būdu.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas, tiekėjų grupės partneriai kartu ar pagal prisiimtus įsipareigojimus kiti ūkio subjektai, kurių pajėgumais remiasi tiekėjas, per paskutinius 3 (trejus) metus iki pasiūlymo pateikimo termino pabaigos arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas vykdė veiklą mažiau nei 3 (trejus) metus) turi būti tinkamai ir savo jėgomis suteikęs informacinės sistemos ir (ar) registro kūrimo informacinės sistemos sukūrimo ir įdiegimo paslaugas arba informacinės sistemos ir (arba) registro informacinės sistemos atnaujinimo paslaugas, kurių vertė turi būti ne mažesnė kaip 1 mln. (vienas milijonas) Eur be PVM.
  • 2Projektų vadovas (bent 1 specialistas), turintis: 1) projektų vadovo darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą projektų vadovo kvalifikaciją (PMP arba CompTIA Project+ arba PRINCE2 Practitioner sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 3Informacinių sistemų analitikas (bent 1 specialistas), turintis: 1) analitiko darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų analitiko kvalifikaciją (OMG Certified UML 2 Foundation (OCUP2) arba OMG Certified UML Professional Foundation arba BCS, Certificate in Business Analysis Foundation sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 4Informacinių sistemų architektas (bent 1 specialistas), turintis: 1) architekto darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų architekto kvalifikaciją (TOGAF Certified arba CITA-A (Associate) arba Oracle Certified Master Java EE Enterprise Architect sertifikatas, ar kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 5Programuotojas (bent 1 specialistas), turintis: 1) programuotojo darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų programuotojo kvalifikaciją (Oracle Certified Professional, Java Programmer arba Sun Certified Programmer For The Java Platform sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 6Informacinių sistemų integravimo specialistas (bent 1 specialistas), turintis: 1) integravimo specialisto darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų integracinių sąsajų (integravimo) programuotojo kvalifikaciją (Oracle Certified Expert, EE 6 Web Services Developer arba Sun Certified Developer for Java Web Services sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 7Informacinių sistemų testuotojas (bent 1 specialistas), turintis: 1) testuotojo darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų testuotojo kvalifikaciją (ISTQB / ASTQB Certified Tester Foundation arba BSC Certified Tester Foundation arba Certified Associate in Software Testing (CAST) sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 8Informacinės sistemos saugos specialistas (bent 1 specialistas), turintis: 1) informacinės sistemos saugos specialisto (užtikrinant informacinės sistemos ir (ar) duomenų saugumą) darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų saugos specialisto kvalifikaciją (CISA (Certified Information Security Auditor) arba CISSP (Certified Information Systems Security Professional) sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 9Informacinės sistemos naudotojo sąsajos ergonomikos (angl. Usability) specialistas (bent 1 specialistas), turintis: 1) informacinės sistemos naudotojo sąsajos ergonomikos (vartotojo sąsajos kokybės) (angl. Usability) specialisto darbo patirtį ne mažiau kaip 1 (viename) per paskutinius 5 (penkerius) metus* įvykdytame informacinės sistemos kūrimo ir (arba) atnaujinimo projekte (sutartyje)**; 2) tarptautiniu mastu pripažįstamą informacinių sistemų naudotojo sąsajos ergonomikos (angl. Usability) specialisto kvalifikaciją (CUA (Certified Usability Analyst) arba BCPE (Board of Certification in Professional Ergonomics) sertifikatas arba kitas kvalifikaciją įrodantis lygiavertis sertifikatas).
  • 10Tiekėjas (įskaitant kiekvieną tiekėjų grupės narį), jo subtiekėjas, ūkio subjektas, kurio pajėgumais tiekėjas remiamasi, ar juos kontroliuojantis asmuo neturi interesų, galinčių kelti grėsmę nacionaliniam saugumui.
  • 11Tiekėjas, bent vienas iš tiekėjų grupės narių (atsižvelgiant į prisiimamus įsipareigojimus pirkimo sutarčiai vykdyti), ūkio subjektas, kurio pajėgumais tiekėjas numato remtis (atsižvelgiant į prisiimamus įsipareigojimus pirkimo sutarčiai vykdyti), taiko kokybės vadybos sistemą informacinių technologijų srityje, atitinkančią LST EN ISO 9001 arba lygiavertį standartą arba lygiavertes kokybės vadybos užtikrinimo priemones.
  • 12Tiekėjas, bent vienas iš tiekėjų grupės narių (atsižvelgiant į prisiimamus įsipareigojimus pirkimo sutarčiai vykdyti), ūkio subjektas, kurio pajėgumais tiekėjas numato remtis (atsižvelgiant į prisiimamus įsipareigojimus pirkimo sutarčiai vykdyti), turi veikiančią informacijos saugumo valdymo sistemą, atitinkančią LST EN ISO/IEC 27001:2023 ar lygiaverčio standarto reikalavimus.

Techniniai reikalavimai

Mokymai

  • 1Mokymų etapo pradžioje Diegėjas turi pateikti mokymų planą, kuriame turi būti pateikiama: mokymų tvarkaraštis, aprašantis kada, kur ir kaip bus atliekami mokymai; mokymų apimtis (temos ir dalyvių skaičius); įrankiai ir medžiaga, kurie bus naudojami mokymų įgyvendinimo metu.
  • 2Diegėjas turės parengti ir pateikti savarankiško mokymosi medžiagą - administratorių ir naudotojų vadovus / instrukcijas, kurie turi apimti visus techninėje specifikacijoje nurodytus reikalavimus, būti suskirstyta pagal sukurtos programinės įrangos funkcines sritis, parengta lietuvių kalba ir iliustruota naudotojo sąsajos ekranvaizdžiais.
  • 3Diegėjas turės parengti vaizdo instrukcijas skirtas Seimo nariams, bei pristatyti sukurtus ir savarankiško mokymosi medžiagoje aprašytus funkcionalumus.
  • 4Preliminarus naudotojų, kuriems turės būti pateikta savarankiško mokymosi medžiaga ir atliktas pristatymas, kiekis – 150.

Testavimas

  • 1Paslaugų teikimo metu turi būti įgyvendintas sukurtų funkcinių komponentų vidinis testavimas ir, remiantis iš anksto suderintais Techninės priežiūros paslaugų teikėjo parengtu testavimo planu ir testavimo scenarijais, priėmimo testavimas.
  • 2Vidinį testavimą (konstravimo etapo metu) Diegėjas turi įgyvendinti savarankiškai ir pateikti tokio testavimo ataskaitą. Vidinis testavimas turi apimti tiek korektiškų, tiek ir nekorektiškų duomenų įvedimą bei reakcijos į pateiktus duomenis tikrinimą.
  • 3Testavimų metu turi būti registruojamos visos identifikuotos klaidos (problemos) ir jų būsenos. Klaidų registravimui turi būti naudojama specializuota problemų registravimo ir sekimo programinė įranga (angl. issue tracking software), pasiekiama naudojant interneto naršyklę.
  • 4Priėmimo testavimo metu nustatytos klaidos skirstomos į kritines, vidutines ir mažas. Priėmimo testavimas laikomas sėkmingai įgyvendintu tenkinant testavimo plane numatytus priėmimo kriterijus.

Plečiamumas

  • 1Sistemos architektūra ir jos realizacija turi leisti pajėgumų plėtimą horizontaliai o ne vertikaliai, prijungiant ar panaudojant papildomą techninę ar virtualią įrangą (angl. scaling).
  • 2Turi būti numatytos Sistemos plėtimo ir našumo didinimo galimybės didėjant Sistemos naudotojų skaičiui bei duomenų kiekiui, įskaitant ir galimybę pridėti naujas (papildomas) tarnybines stotis, paskirstant apkrovimą tarp jų.
  • 3Papildomų duomenų saugyklų įdiegimas, techninių resursų padidinimas neturi reikalauti esamos Sistemos programinės įrangos pakeitimų.

Architektūra

  • 1Architektūra turi būti grįsta „pirmiausia API“ (angl. API-first) principu, kuris apibrėžia du sluoksnius: aplikacijų programavimo sąsajos (angl. backend) bei naudotojo sąsajos (naršyklės, programėlių ar kt.) (angl. frontend).
  • 2Sistemos moduliai (sudedamieji elementai) turi būti sukurti taip, kad atitiktų pagrindinius „Cloud-ready“ principus.
  • 3Sistemos architektūra turi būti daugiapakopė (angl. Multi-tier, N-tier), ją turi sudaryti mažiausiai 4 hierarchiniai lygmenys (vaizdavimo, veiklos logikos, duomenų bazės, integracijų).
  • 4Visi Sistemos funkciniai komponentai privalo palaikyti Unicode (UTF – 8) standartą.
  • 5Sistemos duomenų bazės lygmuo turi būti realizuotas VSSA teikiamos Duomenų bazių valdymo sistema Oracle Database Server ar lygiavertės pagrindu.

Dokumentacija

  • 1Visa Diegėjo rengiama dokumentacija turi būti parengta lietuvių kalba ir laikantis bendrinės lietuvių kalbos taisyklių.
  • 2Dokumentų galutinės versijos turi būti pateiktos dviem formatais: redagavimui tinkamu elektroniniu (.doc, .pdf arba lygiaverčiu formatu arba informacijos rengimui ir saugojimui skirtoje programinėje įrangoje tvarkomu formatu) formatu ir pasirašytos atsakingo Diegėjo asmens parašu.
  • 3Iki bandomosios eksploatacijos etapo pabaigos turi būti atnaujinta visa esama ar parengta nauja Sistemos dokumentacija joje pateikiant informaciją apie šio Projekto metu realizuotus komponentus ir atliktus pakeitimus bei pašalinant nebeaktualią informaciją.

Duomenų mainai

  • 1Turi būti sukurtos visos šiame skyriuje aprašytos integracinės sąsajos.
  • 2Diegėjas turės konsultuoti Užsakovą derinant integracinių sąsajų specifikacijas su duomenų teikėjais ir gavėjais.
  • 3Turi būti realizuoti vidiniai duomenų mainai su LRS VIS Seimo posėdžių darbotvarkių rengimo posisteme.
  • 4Turi būti realizuoti išoriniai duomenų mainai su TAIS.
  • 5Turi būti realizuoti vidiniai duomenų mainai su LRS VIS Seimo posėdžių balsavimo ir diskusijų posisteme.
  • 6Turi būti realizuoti išoriniai duomenų mainai su LRS SIPIS.
  • 7Turi būti realizuoti duomenų mainai su LRS personalo informacine sistema.
  • 8Turi būti realizuoti duomenų mainai su Valstybės informacinių išteklių platforma (VIISP).
  • 9Diegėjas turi parengti sprendimą skirtą Sistemos duomenų ir dokumentų perdavimui kitomis IS, atitinkamai sukuriant universalų (-ius) API.

Infrastruktūra

  • 1Sistema turi būti diegiama Valstybės skaitmeninių sprendimų agentūros (toliau – VSSA) infrastruktūroje bei Perkančiosios organizacijos infrastruktūroje.
  • 2Sistemos architektūra turi būti projektuojama ir realizuojama vadovaujantis: Informacinių sistemų kūrimo ir diegimo IRT konsoliduotoje infrastruktūroje (debesijos paslaugų teikimo platformoje) baziniai reikalavimai ir rekomendacijomis; Informacinių technologijų paslaugų teikėjo centralizuotai teikiamų informacinių technologijų paslaugų katalogu; Loginę debesijos paslaugų teikimo IT infrastruktūros architektūrą.
  • 3VSSA infrastruktūroje ir Perkančiosios organizacijos infrastruktūroje esančios gamybinės aplinkos turės būti tapačios, bei turės būti užtikrinama duomenų sinchronizacija tarp šių aplinkų, kad būtų užtikrinami prieinamumo reikalavimai.

Duomenų modelis

  • 1Sistemoje tvarkomi duomenys turi būti įvedami vieną kartą ir automatiškai susiejami ar perpanaudojami ten, kur tai gali būti taikoma.

Projekto valdymas

  • 1Diegėjas iš savo pusės turi paskirti projekto vadovą, kuris būtų atsakingas už komunikaciją tarp Diegėjo Projekto komandos ir Perkančiosios organizacijos bei kitų Projektu suinteresuotų šalių.
  • 2Diegėjas turi užtikrinti, kad visa komunikacija Projekto metu vyktų lietuvių kalba.
  • 3Per 2 savaites nuo Sutarties įsigaliojimo dienos diegėjas turi pateikti Projekto reglamentą, kuriame turi būti detalizuoti Projekto etapai, jų rezultatai (pateiktys), Projekto dalyvių vaidmenys, tarpusavio komunikacijos būdai, pateikti pagrindiniai riboženkliai ir Perkančiosios organizacijos nurodytus terminus atitinkantis detalus darbų vykdymo grafikas.
  • 4Sutarties įgyvendinimo metu Diegėjas turi rengti tarpines veiklos ataskaitas, kuriose turi būti aprašomos ataskaitinio laikotarpio metu įgyvendintos veiklos, pateikiamas aktualus kalendorinis darbų vykdymo grafikas, apibrėžiantis įvykdytas, tuo metu vykdomas ir nepradėtas vykdyti veiklas, ir įvardintos aktualios Projekto rizikos. Tarpinės ataskaitos turi būti rengiamos kas mėnesį nuo Sutarties įsigaliojimo dienos.

Sistemos diegimas

  • 1Iki Sistemos diegimo pradžios Diegėjas turi parengti diegimo planą, kuriame turi būti pateikiama: diegimo dalyvių atsakomybės; diegimo veiklų aprašymai; diegimo veiklų grafikas; diegimo schema; techniniai reikalavimai debesijos paslaugoms.
  • 2Sprendimas turi būti įdiegtas Valstybės duomenų centro infrastruktūroje ir Perkančiosios organizacijos infrastruktūroje. Infrastruktūros parengimo darbai, derinant su Perkančiosios organizacijos specialistais, turi būti atliekami Diegėjo.
  • 3Diegimo schema turi būti sudaryta laikantis Perkančiosios organizacijos reikalavimų saugumui, greitaveikai, naudojamumui ir kt.
  • 4Nepriklausomai nuo sprendimo diegimo būdo, Diegėjas turi paruošti bendrą Sistemos diegimo paketą, kurį Perkančioji organizacija galėtų įdiegti savarankiškai bet kada pasibaigus Projektui.
  • 5Diegėjas turi parengti Sistemos diegimo ir eksploatavimo instrukciją, kurioje turi būti pateikiama: Sistemos diegimo ir konfigūravimo instrukcijos ir procedūros; automatinio ir rankinio informacijos apdorojimo bei tvarkymo instrukcijos; atsarginių kopijų darymo procedūros; laiko planavimo reikalavimai; klaidų ir kitų išskirtinių būsenų apdorojimo instrukcijos; pagalbos ir problemos perdavimo spręsti kitiems kontaktai; Sistemos pakartotinio paleidimo procedūros; audito sekos ir Sistemos audito žurnalo duomenų tvarkymo aprašymas; Sistemos stebėsenos procedūros.

Ataskaitų modulis

  • 1Turi būti galimybė formuoti ataskaitas. Preliminarus ataskaitų sąrašas: Registracijos protokolas; Balsavimo protokolas; Balsavimo pagal frakcijas rezultatai; Asmens balsavimo duomenys pasirinktą dieną; Posėdžio lankomumo protokolas; Seimo narių dalyvavimo Seimo posėdžiuose iš anksto numatytų balsavimų metu suvestinės ataskaitos; Detali Seimo narių nedalyvavimo Seimo posėdžiuose ataskaita.
  • 2Ataskaitų formavimo funkcionalumas turi būti prieinamas – salės operatoriaus, sekretoriato darbuotojo ir sistemos administratoriaus naudotojo rolėms.
  • 3Turi būti galimybė kiekvieną ataskaitą Sistemoje spausdinti bei eksportuoti į PDF, DOCX, XLSX ar lygiavertes rinkmenas.
  • 4Sistemos administratoriams turi būti galimybė tvarkyti Sistemoje tvarkomų ataskaitų šablonus.
  • 5Turi būti galimybė formuoti ataskaitą pagal skirtingus pjūvius / kriterijus.

Duomenų atvėrimas

  • 1Turi būti realizuota integracinė sąsaja su Valstybės duomenų valdysenos informacine sistema (VDV IS). Integracija turi leisti teikti duomenų grupes, kurios atveriamos per Lietuvos atvirų duomenų portalą.
  • 2Diegėjas turi parengti atvertinų duomenų rinkinius: Seimo posėdžių balsavimo ir registracijų rezultatų duomenys; Seimo narių dalyvavimo Seimo posėdžiuose duomenys; Seimo posėdžių protokolų duomenys.
  • 3Turi būti galimybė nuasmeninti atveriamus duomenis.

Duomenų migravimas

  • 1Pirmo Sistemos kūrimo etapo metu turės būti perkelti (migruoti) visi einamosios Seimo kadencijos su balsavimo darbotvarkės klausimais susiję duomenys.
  • 2Visus migravimui reikalingus duomenis pateiks Perkančioji organizacija.
  • 3Iki duomenų migravimo pradžios Diegėjas turi parengti Duomenų migravimo aprašą, kuriame turi aprašyti migruojamų duomenų apimtis, migravimų procedūrą ir duomenų transformacijas, jei tokių reikės.

Pakeitimų valdymas

  • 1Šioje Techninėje specifikacijoje ar kituose Paslaugų teikimo sutarties prieduose nustatyti reikalavimai gali būti keičiami Diegėjo ar Perkančiosios organizacijos iniciatyva. Reikalavimai gali būti keičiami vadovaujantis VPĮ 89 str. nurodytomis sąlygomis.
  • 2Visi pakeitimai turi būti registruojami pakeitimų registre.

Rezervinės kopijos

  • 1Diegėjas turi įvertinti VSSA teikiamas paslaugas ir apibrėžti bei realizuoti rezervinių kopijų darymo ir atstatymo procesus, priemones ir taisykles.

Papildomos paslaugos

  • 1Perkančioji organizacija turi teisę (bet neįsipareigoja) nuo Sutarties įsigaliojimo dienos užsakyti papildomų paslaugų pagal Diegėjo pasiūlyme nurodytą valandinį įkainį. Papildomų paslaugų apimtis – iki 1000 val.
  • 2Papildomų paslaugų metu kuriamam funkcionalumui taikomi šios techninės specifikacijos nefunkciniai reikalavimai, jeigu nesutariama kitaip, bei garantinės priežiūros reikalavimai.

Duomenų archyvavimas

  • 1Sistema turi turėti funkcijas, suteikiančias galimybę atlikti tvarkomų duomenų loginį archyvavimą. Realizuojant loginio duomenų archyvavimo priemones, duomenų objektui turi būti priskiriamas archyvo požymis, Sistemos funkciniams moduliams paliekant tokio paties lygio prieigą kaip ir prie nearchyvuotų duomenų.
  • 2Turi būti sukurtos priemonės archyvinių duomenų peržiūrai, ir esant poreikiui koregavimui.

Seimo nario funkcijos

  • 1Seimo nariams turi būti realizuota galimybė užsiregistruoti į Seimo posėdį nuotoliniu būdu.
  • 2Turi būti galimybė Seimo nariui užsiregistruoti kalbėti pasirinktu darbotvarkės klausimu.
  • 3Turi būti sukurtas funkcionalumas leidžiantis Seimo nariams balsuoti nuotolinio, mišraus arba gyvo (Seimo salėje) Seimo posėdžio rėžimu.
  • 4Seimo nariams balsuojant nuotoliniu būdu tapatumui patvirtinti turi būti naudojamos dviejų veiksnių tapatumo patvirtinimo priemonės.
  • 5Balsuojant turi būti galimybė Sistemoje pasirinkti balsą „už“, „prieš“ arba „susilaikau“. Jeigu vykdomas alternatyvus balsavimas turi būti galimybė rinktis balsą - „už“ arba „prieš“.
  • 6Turi būti galimybė keisti pasirinktą balsą, kol nesibaigė balsavimui skirtas laikas.
  • 7Turi būti sukurta Seimo nario užsirašymų kalbėti sritis, kurioje turi būti atvaizduojamas visų darbotvarkės klausimų, kuriais Seimo narys yra užsiregistravęs pasisakyti, sąrašas.
  • 8Turi būti realizuota galimybė atsisakyti žodžio.
  • 9Turi būti galimybė inicijuoti pagalbos iškvietimą.
  • 10Seimo nariai turi būti automatiškai informuojami apie besikeičiančius posėdžio įvykius.

Sistemos prieinamumas

  • 1Sistemos architektūra turi užtikrinti Sistemos veikimą aukšto prieinamumo (angl. High availability) principu. Aukštas prieinamumas turi būti realizuojamas paslaugų lygyje, integracijų lygyje ir duomenų lygyje.
  • 2Sistemos architektūra turi užtikrinti, kad nustojus veikti vienam Sistemos komponentui nenustotų veikti visa Sistema.
  • 3Sistemos architektūra turi užtikrinti, kad laikas, per kurį atstatomi duomenys po incidento (RTO) (skaičiavimo išteklių numatytajam mastui atkurti), neviršytų 60 min.

Saugumas ir privatumas

  • 1Sistemos programinė įranga negali turėti Open Web Application Security Project (OWASP) Top 10 periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.
  • 2Sistemos ryšys su naudotojų ir administratorių darbo vietomis (interneto naršyklėmis) turi būti šifruojamas naudojant Let‘s Encrypt TLS (angl. Transport Layer Security) arba kitas lygiavertes šifravimo priemones.
  • 3Dalis Sistemos tvarkomų duomenų turi būti šifruojami (pvz. naudotojo asmens kodas, balsavimo duomenys).
  • 4Po nustatyto neaktyvumo laikotarpio Sistemos naudotojas turi būti atjungiamas nuo Sistemos ir darbą turi galėti tęsti tik iš naujo prisijungęs.
  • 5Techninės priežiūros paslaugų teikėjui atlikus Sistemos atsparumo įsilaužimams testavimą, Diegėjas turi pašalinti testavimo metu nustatytus trūkumus iki bandomosios eksploatacijos etapo pabaigos.

Bandomoji eksploatacija

  • 1Bandomoji eksploatacija gali būti pradėta tik užbaigus Sistemos diegimo etapą bei atlikus Sistemos eksploatavimui būtinų duomenų migravimą.
  • 2Diegėjas privalo užtikrinti Sistemos veikimą visos bandomosios eksploatacijos metu.
  • 3Bandomosios eksploatacijos metu klaidų registravimui turi būti naudojama specializuota problemų registravimo ir sekimo programinė įranga (angl. issue tracking software), pasiekiama naudojant interneto naršyklę.
  • 4Bandomoji eksploatacija laikoma sėkmingai įgyvendinta, jei nėra likusių žinomų kritinių bei vidutinių klaidų ir yra ištaisyta 90 proc. mažų bandomosios eksploatacijos metu nustatytų klaidų.
  • 5Bandomosios eksploatacijos metu nustatytų klaidų ir trūkumų sprendimo trukmė: Kritinių – ne ilgiau kaip 4 valandos; Vidutinių – ne ilgiau kaip 2 darbo dienos; Mažų – ne ilgiau kaip 5 darbo dienos.

Garantinis aptarnavimas

  • 1Diegėjas po galutinio Paslaugų perdavimo-priėmimo akto pasirašymo dienos turės teikti ne trumpesnę kaip 24 mėnesių trukmės Sistemos garantinę priežiūrą.
  • 2Garantinė priežiūra turi būti teikiama: visai Diegėjo sukurtai programinei įrangai bei licencinei programinei įrangai, kuri panaudota kuriant Sistemos funkcinius sprendimus ir priklauso Diegėjui nuosavybės teisėmis; licencinės programinės įrangos konfigūracijai; visai pateiktai dokumentacijai.
  • 3Garantinės priežiūros paslaugos turi apimti: klaidų ar netikslumų registravimą; klaidų ar netikslumų taisymą, testavimą, diegimą ir atnaujintų programinių priemonių išeities tekstų pateikimą Perkančiajai organizacijai; Sistemos išeities kodo, po atliktų pataisymų, pateikimą Perkančiajai organizacijai; techninės Sistemos dokumentacijos bei administratorių ir naudotojų vadovų tikslinimą; konsultacijų apie Sistemą teikimą garantiniais klausimais.
  • 4Reakcijos į problemą laikas (problema užregistruota ir perduota sprendimui) – ne ilgiau kaip 2 darbo valandos darbo metu.
  • 5Problemos sprendimo trukmė: Kritinių sutrikimų šalinimas – ne ilgiau kaip 4 darbo valandos nuo pranešimo gavimo sutartu būdu; Svarbių sutrikimų šalinimas – ne ilgiau kaip 2 darbo dienos nuo pranešimo gavimo sutartu būdu; Neesminių sutrikimų šalinimas – ne ilgiau kaip 5 darbo dienos nuo pranešimo gavimo sutartu būdu.

Analizė ir projektavimas

  • 1Sistemos analizės ir projektavimo veiklos turės būti vykdomos lygiagrečiai.
  • 2Analizės ir projektavimo metu, turės būti parengti: Detalios analizės dokumentas; Projektavimo dokumentas; Integracines sąsajas aprašantys dokumentai; Infrastruktūros resursų poreikių sąrašas.
  • 3Detalios analizės dokumentuose išanalizuojami ir detalizuojami funkciniai ir nefunkciniai Techninės specifikacijos reikalavimai bei kiti Perkančiosios organizacijos išsakyti poreikiai, parengiami naudojimo atvejai (angl. use case), kurie pateikiami naudojimo atvejų diagramomis pagal UML (angl. Unified Modeling Language) notaciją ir detalizuojami, aprašant kiekvieno naudojimo atvejo vykdymo žingsnius (pagrindinę eigą, alternatyvią eigą, išimtinę eigą) ir kitus apribojimus.

Greitaveika ir pajėgumas

  • 1Sistema turi veikti pagal racionalius greitaveikos reikalavimus, kai vienu metu su Sistema lygiagrečiai veiksmus inicijuos ne mažiau kaip 200 naudotojų.
  • 2Sistema turi gebėti apdoroti 50 000 užklausų per dieną.
  • 390 proc. užklausų atsako laikas negali viršyti 2 sek., jei užklausos vykdymo metu kreipiamasi į išorinę sistemą, atsako laikas negali viršyti 5 sek., neskaičiuojant užklausos į išorinę sistemą vykdymo laiko.

Posėdžio protokolavimas

  • 1Turi būti sukurta Seimo posėdžių protokolavimo aplinka, skirta posėdžių eigos fiksavimui, koregavimui bei dokumentavimui.
  • 2Turi būti sukurta posėdžio darbotvarkės peržiūros sritis.
  • 3Turi būti galimybė pasirinkti Seimo posėdį, kurio įvykius norima peržiūrėti: Šiuo metu vykstantį posėdį; Kitą, jau įvykusį posėdį.
  • 4Turi būti sukurta pastabų ir formuluočių šablonų valdymo sritis su funkcinėmis galimybėmis.
  • 5Pasirinkus posėdį turi būti atvaizduojamas posėdžio įvykių sąrašas, apimantis: Posėdžio pradžia; Posėdžio pabaiga; Pertraukos pradžia; Pertraukos pabaiga; Pasikeitė pirmininkaujantis; Pasikeitė klausimas; Registracija; Registracija ir balsavimas; Balsavimas; Alternatyvus balsavimas; Registracija ir alternatyvus balsavimas; Pasisakymai.
  • 6Turi būti galimybė įvykių sąraše pažymėti įvykį apdorotu.
  • 7Pasirinkus konkretų posėdžio įvykį turi būti atvaizduojama informacija ir funkcinės galimybės: bendroji įvykio informacija; galimybė užfiksuoti / anuliuoti sprendimo priėmimo rezultatą - „Pritarta bendru sutarimu“; pirmininkaujančio Seimo nario vardas, pavardė ir frakcijos santrumpa; galimybė redaguoti nagrinėjamą klausimą, numatytus pranešėjus, darbotvarkės klausimo skubą.
  • 8Turi būti galimybė suvesti balsavimo formuluotę bei alternatyvią formuluotę (jei įvyko alternatyvus balsavimas).
  • 9Turi būti galimybė koreguoti automatiškai sistemos paskaičiuotą balsavimo rezultatą.
  • 10Apdorojus posėdžio įvykius turi būti realizuota galimybė formuoti posėdžio protokolo projektą: Sistema turi automatiškai užpildyti protokolo šabloną pasirinkto posėdžio duomenimis; Turi būti galimybė parsisiųsti suformuotą protokolo projektą .DOCX arba lygiaverčiu formatu.

Naudotojų autentifikavimas

  • 1Naudotojams turi būti galimybė prisijungti prie Sistemos naudojant autentifikavimosi priemones: Naudotojo vardą ir slaptažodį; VIISP tapatybės nustatymo paslaugą; Seimo nario darbo vietos autentifikavimo įrangą (tik Seimo nario naudotojo rolei); laikiną Sistemos tiesioginio prisijungimo nuorodą (URL) (tik Kviestinio svečio naudotojo rolei).
  • 2Turi būti galimybė administratoriams, kurie jungiasi prie Sistemos, tapatybei patvirtinti naudoti dviejų veiksnių tapatumo patvirtinimo priemones.

Salės operatoriaus funkcijos

  • 1Turi būti sukurta salės operatoriaus aplinka, skirta stebėti bei valdyti Seimo posėdžių salės techninę įrangą.
  • 2Salės operatoriui turi būti atvaizduojama dinamiškai kintanti bendroji posėdžio informacija.
  • 3Salės operatoriui turi būti peržiūros rėžimu pasiekiama Seimo posėdžio darbotvarkės sritis.
  • 4Turi būti realizuota posėdžių salės darbo vietose veikiančios įrangos stebėsenos sritis.
  • 5Turi būti realizuota sistemos klaidų fiksavimo ir peržiūros sritis.
  • 6Turi būti realizuota posėdžių salės įrangos valdymo sritis: Turi būti atvaizduojama posėdžių salės darbo vietų schema, kurioje turi būti skirtingai išskirtos darbo vietos, kuriose paleista / nepaleista veikti įranga; Turi būti atvaizduojamas salės įrangos / aplikacijų sąrašas.
  • 7Turi būti realizuota vaizdo sienų stebėsenos ir valdymo sritis apimanti: galimybę peržiūrėti vaizdo sienose vaizduojamą informaciją; keisti vaizduojamos informacijos šablonus; galimybę inicijuoti prezentacijos demonstraciją.
  • 8Salės operatoriui turi būti realizuota posėdžių salės mikrofonų valdymo sritis.
  • 9Salės operatoriui turi būti realizuota posėdžių salės mikrofonų testavimo sritis.
  • 10Turi būti sukurtas funkcionalumas leidžiantis testuoti Seimo posėdžių salės kvietimo į posėdį skambutį.

Licencinė programinė įranga

  • 1Jei Sistemos realizacijai bus naudojama licencinė programinė įranga, Diegėjas turi užtikrinti, kad Sistema galėtų naudotis 200 naudotojų ir 5 administratoriai, licencijos galiojimą iki garantinės priežiūros pabaigos, bei įtraukti visas su tuo susijusias išlaidas į savo pasiūlymą.
  • 2Jei konkretiems funkciniams reikalavimams realizuoti naudojama uždaro kodo licencinė programinė įranga, turi būti naudojama standartinė šios programinės įrangos versija, kuri projekto metu negali būti specifiškai pritaikoma funkcinių reikalavimų atitikimui.
  • 3Sistemos kūrimo pabaigoje Perkančiajai organizacijai turi būti perduodami Sistemos išeities tekstai (išeities tekstai turi būti įkelti į Perkančiosios organizacijos nurodytą GitLab paskyrą) turi tenkinti šiuos reikalavimus: išeities tekstai Perkančiajai organizacijai turi būti perduoti kompiliavimui paruoštų rinkmenų paketų forma, nurodant standartines kompiliavimo priemones, kompiliavimo eigą ir kartu su visomis kompiliavimui reikalingomis bibliotekomis; išeities tekstai turi būti su komentarais ir atitikti gerąsias programinio kodo formatavimo, kintamųjų bei funkcijų įvardinimo praktikas; bent 85% išeities tekstų turi būti ištestuota, arba kitaip padengta „unit“ testais; turi būti perduoti pilni, korektiški kuriamo arba modifikuojamo sprendimo išeities tekstai, iš kurių, naudojant standartines priemones, būtų kompiliuojama naudojimui parengta programinė įranga, atliekanti jai specifikuotas funkcijas.

Vaizdo konferencijų platforma

  • 1Vaizdo konferencijų platforma turi būti diegiama Perkančiosios organizacijos valdomame serveryje.
  • 2Tiesioginė komunikacija naudojantis vaizdo konferencijų platforma turi būti šifruojama „End-to-End“ principu.
  • 3Sistemos naudotojai turi galėti naudotis vaizdo konferencijų platforma per interneto naršyklę, be būtinybės įsidiegti papildomą programinę įrangą.
  • 4Sistemos naudotojas po prisijungimo nustatymų lango turi būti nukreipiamas į laukimo režimą, kol atitinkamas teises turintis naudotojas jo nepatvirtino.
  • 5Turi būti vykdomas viso posėdžio vaizdo įrašas, kuris turi būti saugomas kartu su posėdžio duomenimis.

Bendrosios naudotojų funkcijos

  • 1Naudotojui esant bet kuriame sistemos lange / srityje turi būti atvaizduojama dinamiškai atsinaujinanti posėdžio eigos sritis, apimanti svarstomo darbotvarkės klausimo ir posėdžio duomenis: Svarstomo klausimo numeris; Svarstomo klausimo pavadinimas; Svarstomo klausimo stadija; Klausimo svarstymui skirtas ir dinamiškai kintantis praėjęs laikas; Šiuo metu kalbančio asmens duomenys; Posėdžio tipas; Posėdžio numeris; Data, laikas ir savaitės diena; Posėdžiui pirmininkaujančio Seimo nario vardas, pavardė.
  • 2Turi būti sukurta atskira posėdžio darbotvarkės sritis, kurioje naudotojui turi būti pateikiamas bendras darbotvarkės klausimų sąrašas.
  • 3Turi būti galimybė atlikti darbotvarkės klausimo paiešką. Paieška turi būti vykdoma nurodant darbotvarkės klausimo pavadinimą, numerį (arba jo fragmentą), pranešėjo vardą ir (ar) pavardę.
  • 4Turi būti galimybė peržiūrėti visų posėdžio dieną vykusių registracijų rezultatus.
  • 5Turi būti galimybė peržiūrėti visų posėdžio dieną įvykusių balsavimų sąrašą.
  • 6Pasibaigus balsavimui skirtam laikui turi būti atvaizduojami momentiniai įvykusio balsavimo rezultatai.
  • 7Turi būti sukurta pasisakymų darbotvarkės klausimu sritis, leidžianti naudotojui peržiūrėti kalbančiųjų sąrašą (eiles) ir susijusią informaciją.
  • 8Turi būti realizuota galimybė peržiūrėti posėdžių salėje demonstruojamos prezentacijos ir vaizdo sienų informacijos langą.
  • 9Naudotojams turi būti galimybė valdyti (personalizuoti) savo naudotojo profilį Sistemoje: Konfigūruoti atvaizdavimo nustatymus.
  • 10Turi būti sukurta pagalbos naudotojui sritis apimanti: Bendrąjį portalo principų pristatymą; pagrindinių funkcionalumų aprašymą; DUK; naudotojų vadovus.

Posėdžio pirmininko funkcijos

  • 1Seimo nariui turinčiam posėdžio pirmininko teises turi būti galimybė valdyti posėdžio dalyvių kalbas: Inicijuoti kalbų pradžią; Užbaigti kalbas; Suteikti žodį posėdžio dalyviui.
  • 2Turi būti galimybė valdyti (Įjungti / išjungti) posėdžių salės mikrofonus: Šoniniai; Kairysis; Dešinysis; Centrinis; Pirmininkaujančio; Tribūna; Papildomi (svečiai, Prezidentas, Vyriausybiniai, rampa kairėje, rampa dešinėje).
  • 3Turi būti sukurtas funkcionalumas leidžiantis įjungti Seimo posėdžių salės kvietimo į posėdį skambutį.

Vaizdo sienų įrangos valdymas

  • 1Turi būti sukurtas komponentas skirtas valdyti Seimo posėdžių salės vaizdo sienų įranga ir vaizduojamą turinį.
  • 2Diegėjas vadovaudamasis prototipu turi sukurti iki 10 vaizdo sienų šablonų skirtų skirtingai atvaizduoti vykstančio Seimo posėdžio informaciją.
  • 3Vaizdo sienų šablonuose pateikiama Seimo posėdžių informacija turi būti dinamiškai kintanti.
  • 4Vaizdo sienų šablonuose, neapsiribojant turi būti atvaizduojama: Posėdžio statusas; Prisijungusių Seimo narių duomenys ir schema; Pirmininkaujančio Seimo nario duomenys; Registracijos progresas; Registracijos rezultatai; Darbotvarkės klausimo duomenys; Balsavimų progresas; Įvykusių balsavimų rezultatai; Bendroji kalbų informacija; Kalbančiojo Seimo narios duomenys.

Vaizdo transliacijų titravimas

  • 1Turi būti sukurtas komponentas skirtas formuoti titrus iš Sistemos duomenų bei juos perduoti į Seimo posėdžių vaizdo transliacijas.
  • 2Turi būti suformuojami titrai iš šių Seimo posėdžio įvykių: Posėdžio būsenos pasikeitimai; Svarstomo darbotvarkės klausimo pasikeitimai; Posėdžio pirmininko pasikeitimas; Diskusijų eiga; Registracijos eigos pasikeitimai; Balsavimo eigos pasikeitimai.
  • 3Turi būti realizuota galimybė kurti titrus. Funkcionalumas turi leisti įvesti ir parodyti laisvu tekstu sukurtą titrą.

Sekretoriato darbuotojo funkcijos

  • 1Turi būti realizuotas darbotvarkės klausimų administravimo funkcionalumas skirtas sekretoriato darbuotojams (funkcionalumas turi būti prieinamas prieš posėdį, posėdžio metu ir pasibaigus posėdžiui).
  • 2Turi būti galimybė jungiantis prie Sistemos pasirinkti posėdį, prie kurio informacijos, duomenų nori prisijungti.
  • 3Turi būti galimybė pridėti komentarą / pastabą darbotvarkės klausimui.
  • 4Turi būti galimybė tvarkyti pasirinkto darbotvarkės klausimo kalbų sąrašą (eilę): Nurodyti / koreguoti tipą (Klausti, Diskusija, Pataisų svarstymas, Motyvai dėl viso, Motyvai dėl straipsnių); Sukurti papildomas eiles; Atidaryti / uždaryti eilę; Redaguoti / nurodyti eilės pavadinimą; Pridėti į eilę / pašalinti iš eilės norintį pasisakyti Seimo narį; Įtraukti į eilę naują norintįjį pasisakyti (ne Seimo narį).
  • 5Turi būti realizuotas funkcionalumas skirtas sekretoriato darbuotojams administruoti registracijos duomenis. Funkcionalumas turi leisti: Peržiūrėti registracijos duomenis; koreguoti registracijos duomenis.
  • 6Sekretoriato darbuotojui turi būti galimybė priskirti posėdžio pirmininką.
  • 7Turi būti realizuota galimybė valdyti posėdžio salės darbo vietas.
  • 8Turi būti realizuotas funkcionalumas skirtas sekretoriato darbuotojams administruoti posėdžio balsavimus. Funkcionalumas turi leisti: Peržiūrėti posėdžio dieną įvykusių balsavimų rezultatus; Sukurti naują įvykusio balsavimo įrašą; Trinti balsavimą; Perkelti balsavimą; Inicijuoti slaptą balsavimą; Inicijuoti balsavimą renginio rėžimu.
  • 9Turi būti realizuotas pagalbos (techninės pagalbos) administravimo funkcionalumas. Funkcionalumas turi leisti: Peržiūrėti gautų prašymų sąrašą; Užfiksuoti pagalbos suteikimą.
  • 10Turi būti realizuotas administravimo funkcionalumas skirtas sekretoriato darbuotojui. Funkcionalumas neapsiribojant turi leisti valdyti šiuos parametrus: Kalbų tipus; Kalbų trukmes; Skubų stadijas; Frakcijas; Priskirti kalbų tipus stadijoms.
  • 11Sekretoriato darbuotojui turi būti realizuota galimybė valdyti naudotojus (Seimo narių).
  • 12Turi būti sukurta langų tarp balsavimų valdymo sritis.

Paslaugų teikimo etapai ir terminai

  • 1Sistemos kūrimas turi būti įgyvendinamas dviem etapais (iteraciniu-inkrementiniu informacinės sistemos kūrimo būdu), jau po pirmo etapo pabaigos pradedant realiai eksploatuoti Sistemą.
  • 2Visi Sistemos sukūrimo etapai turės būti įgyvendinti per 20 mėnesių nuo Paslaugų teikimo sutarties įsigaliojimo dienos.
  • 3Pirmo Sistemos kūrimo etapo detalios analizės ir projektavimo etapo rezultatai turi būti suderinti per 6 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.
  • 4Pirmo Sistemos kūrimo etapo kūrimo ir vidinio testavimo etapo rezultatai turi būti suderinti per 11 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.
  • 5Pirmo Sistemos kūrimo etapo priėmimo testavimo etapo rezultatai turi būti suderinti per 12 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.
  • 6Pirmo Sistemos kūrimo etapo bandomosios eksploatacijos trukmė negali būti trumpesnė kaip 1 mėn. ir baigtis vėliau nei 14 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.
  • 7Antro Sistemos kūrimo etapo detalios analizės ir projektavimo etapo rezultatai turi būti suderinti per 16 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.
  • 8Antro Sistemos kūrimo etapo kūrimo ir vidinio testavimo etapo rezultatai turi būti suderinti per 18 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.
  • 9Antro Sistemos kūrimo etapo priėmimo testavimo ir diegimo gamybinėje aplinkoje etapo rezultatai turi būti suderinti per 20 mėn. nuo Paslaugų teikimo sutarties įsigaliojimo datos.

Sistemos administratoriaus funkcijos

  • 1Turi būti sukurta atskira sistemos administratoriaus valdymo sritis.
  • 2Turi būti realizuota posėdžių salės darbo vietose veikiančios įrangos stebėsenos sritis.
  • 3Turi būti realizuota sistemos klaidų fiksavimo ir peržiūros sritis.
  • 4Turi būti realizuota posėdžių salės įrangos valdymo sritis: Turi būti atvaizduojama posėdžių salės darbo vietų schema, kurioje turi būti skirtingai išskirtos darbo vietos, kuriose paleista / nepaleista veikti įranga; Turi būti atvaizduojamas salės įrangos / aplikacijų sąrašas.
  • 5Sistemos administratorius turi būti realizuota posėdžių salės mikrofonų testavimo / valdymo sritis.
  • 6Turi būti realizuota galimybė valdyti naudotojus (Seimo narius): Valdyti frakcijos duomenis; Valdyti autentifikavimo priemones; Pažymėti priesaikos priėmimo faktą; Aktyvuoti / deaktyvuoti naudotoją.
  • 7Turi būti realizuota parametrų (pvz. balsavimo, registracijos trukmė, tipai ir kt.) konfigūravimo sritis.
  • 8Turi būti sukurta sistemos veiksmų žurnalo peržiūros ir archyvavimo sritis.
  • 9Turi būti galimybė formuoti įrangos vykdymo ataskaitą.
  • 10Turi būti realizuota galimybė stebėti sistemoje prisijungusių naudotojų sąrašą / salės schemą.
  • 11Turi būti galimybė administruoti slaptažodžių sudarymo parametrus: slaptažodžio ilgį; reikalavimus slaptažodžio struktūrai; terminą po kurio reikia pakeisti slaptažodį; skaičių prieš tai naudotų slaptažodžių, kurių negalima panaudoti kuriant naują slaptažodį; neteisingai įvedamų slaptažodžių skaičių, po kurio Sistemos naudotojas turi būti užblokuojamas.
  • 12Turi būti galimybė nustatyti Seimo posėdžio rėžimą: Nuotolinį; Gyvą (Seimo salėje); Mišrų.

Kviestinių posėdžio dalyvių funkcijos

  • 1Kviestiniams posėdžio dalyviams turi būti prieinami visi bendrieji funkcionalumai aprašyti skyriuje 6.2.1.
  • 2Turi būti galimybė inicijuoti pagalbos iškvietimą.

Naudotojo sąsaja, patogumas naudoti ir prieinamumas

  • 1Sistemos dizainas turi būti kuriamas taikant geriausias UX (angl. User experience) ir UI (angl. User interface) praktikas, siekiant naudotojo sąsają padaryti kiek labiau įmanoma intuityvią ir suprantamą, vengiant visų perteklinių veiksmų.
  • 2Sistemos naudotojo sąsaja turės būti kuriama pagal naudotojo sąsajos prototipus.
  • 3Naudotojo sąsaja turi būti pritaikyta darbui mobiliuose įrenginiuose.
  • 4Kuriamų komponentų naudotojo sąsaja turi būti prieinama naudojant interneto naršykles (bent metų paskutines jų versijas nuo priėmimo testavimo pradžios): Microsoft Edge; Mozilla Firefox; Google Chrome; Safari; Opera.
  • 5Naudotojo sąsaja turi būti tinkamai atvaizduojama įvairios rezoliucijos ekranuose, t. y. turi būti realizuojamos taikant prisitaikančio dizaino (angl. Responsive design) principus.
  • 6Naudotojo sąsaja turi būti parengta laikantis bendrinės lietuvių kalbos taisyklių.
  • 7Seimo nario, posėdžio pirmininko ir kviestinio svečio rolėms kuriama naudotojo sąsaja turi būti orientuota į darbą su pirštu (planšetės ir mobilūs įrenginiais) tačiau jos valdymas turi būti pritaikytas ir naudojimui pelės ir klaviatūros pagalba.

Posėdžio pirmininkui asistuojančio darbuotojo funkcijos

  • 1Posėdžio pirmininkui asistuojančiam darbuotojui turi būti galimybė priskirti posėdžio pirmininką.
  • 2Posėdžio pirmininkui paskelbus posėdžio pradžią turi būti galimybė inicijuoti posėdžio pradžią pasirenkant posėdį iš sąrašo.
  • 3Turi būti realizuotas posėdžio dalyvių registracijos valdymo funkcionalumas. Funkcionalumas turi leisti: Inicijuoti posėdžio dalyvių registracijos pradžią; Nutraukti posėdžių dalyvių registraciją; Peržiūrėti registracijos rezultatus.
  • 4Turi būti realizuota posėdžio eigos valdymo sritis (skirta greitai pasiekti pagrindinius veiksmus): Inicijuoti pertrauką; Užbaigti posėdį; Pradėti registraciją; Inicijuoti balsavimą.
  • 5Turi būti realizuotas darbotvarkės klausimų administravimo funkcionalumas. Funkcionalumas turi leisti: Inicijuoti / atšaukti klausimo svarstymą; Baigti klausimo svarstymą; Atidėti klausimą; Grupuoti / atskirti klausimus; Nustatyti klausimo skubą.
  • 6Turi būti realizuotas funkcionalumas leidžiantis inicijuoti darbotvarkės tvirtinimą.
  • 7Turi būti realizuotas balsavimo darbotvarkės klausimu valdymo funkcionalumas. Funkcionalumas turi leisti: Paskelbti balsavimo pradžią; Atšaukti balsavimą; Peržiūrėti balsavimo rezultatus; koreguoti automatiškai sistemos paskaičiuotą balsavimo rezultatą.
  • 8Turi būti realizuota galimybė valdyti kalbėjimo funkcijas. Funkcionalumas turi leisti: Atidaryti / uždaryti eilę; Pašalinti dalyvį eilėje; Tvarkyti kalbų trukmes; Suteikti žodį posėdžio dalyviui; Pratęsti tuo metu kalbančiam posėdžio dalyviui skirtą kalbėjimo laiką; Įjungti perspėjimo pranešimą kalbančiajam.
  • 9Turi būti sukurta balsavimų langų peržiūros sritis.

Dokumentai6

  • 3_2 priedas. Techninė specifikacija.docx
  • 4_3 priedas. Kvalifikacijos ir standartų reikalavimai.docx
  • 5_4 priedas. Pasiūlymų vertinimo kriterijai.docx
  • 1_Rinkos konsultacija.docx
  • 2_1 priedas. Klausimynas.docx
  • 1735_7058139.pdf