Sistemos techninė ir funkcinė specifikacija bei reikalavimai techninei įrangai

1. Pirkimo objektas...........................................................................................................................31.1. Pagrindinės sąvokos ir apibrėžimai......................................................................................31.2. Pirkimo tikslas ir uždaviniai.................................................................................................41.3. Pirkimo objekto apimtis.......................................................................................................4

1.3.1. E-demokratijos informacinės sistemos sukūrimas ir įdiegimas...................................41.3.2. Techninės įrangos įsigijimas........................................................................................4

1.4. Tiekėjo įsipareigojimai.........................................................................................................41.5. Licencijavimo tvarka............................................................................................................41.6. Sistemos dokumentacija.......................................................................................................41.7. Sistemos naudotojų mokymai..............................................................................................51.8. Sutarties vykdymo ir garantinio aptarnavimo terminai........................................................5

2. Funkciniai ir technologiniai reikalavimai.....................................................................................52.1. Bendrieji realizavimo principai............................................................................................52.2. Sistemos architektūra...........................................................................................................62.3. Bendrieji sistemos reikalavimai...........................................................................................62.4. Identifikavimo posistemės funkciniai reikalavimai.............................................................8

2.4.1. Bendrieji reikalavimai ir naudotojų grupės..................................................................82.4.2. Identifikavimo ir atpažinimo funkciniai reikalavimai..................................................82.4.3. Išorinio naudotojo personalinė dalis.............................................................................92.4.4. E-demokratijos sistemos navigacija...........................................................................102.4.5. Identifikavimo posistemės administravimas..............................................................102.4.6. Identifikavimo posistemės integracija su kitomis sistemomis...................................10

2.5. Apklausų posistemės funkciniai reikalavimai....................................................................102.5.1. Bendrieji reikalavimai ir naudotojų grupės................................................................102.5.2. Identifikavimas ir atpažinimas...................................................................................112.5.3. Apklausų organizavimas............................................................................................122.5.4. Balsavimas..................................................................................................................132.5.5. Apklausos rezultatų skaičiavimas..............................................................................142.5.6. Apklausos rezultatų skelbimas...................................................................................152.5.7. Apklausų posistemės administravimas.......................................................................152.5.8. Apklausų posistemės auditas......................................................................................162.5.9. Semantinės analizės modulis......................................................................................162.5.10. Apklausų posistemės integracija su kitomis sistemomis............................................17

2.6. Vaizdo konferencijų posistemės funkciniai reikalavimai..................................................182.6.1. Bendrieji reikalavimai ir naudotojų grupės................................................................182.6.2. Identifikavimas ir atpažinimas...................................................................................182.6.3. Vaizdo konferencijų organizavimas...........................................................................192.6.4. Dalyvavimas vaizdo konferencijoje...........................................................................20

2.6.4.1. Pirmas būdas.......................................................................................................212.6.4.2. Antras būdas.......................................................................................................21

2.6.5. Vaizdo konferencijų valdymas...................................................................................232.6.6. Vaizdo konferencijų posistemės administravimas.....................................................242.6.7. Vaizdo konferencijų posistemės integracija su kitomis sistemomis..........................24

2.7. Posėdžių valdymo ir transliavimo posistemės funkciniai reikalavimai.............................252.7.1. Bendrieji reikalavimai................................................................................................252.7.2. Posėdžių valdymo dalis..............................................................................................25

2.7.2.1. Administravimo modulis....................................................................................262.7.2.2. Valdymo modulis...............................................................................................272.7.2.3. Atvaizdavimo funkciniai reikalavimai...............................................................29

1

2.7.3. Transliavimo dalis......................................................................................................312.7.3.1. Transliavimo valdymas......................................................................................312.7.3.2. Transliacijų peržiūra...........................................................................................31

2.7.4. Posėdžių valdymo ir transliavimo posistemės integracija su kitomis sistemomis.....312.8. Teisės aktų ir jų projektų posistemės funkciniai reikalavimai...........................................32

2.8.1. Bendrieji reikalavimai ir naudotojų grupės................................................................322.8.2. Identifikavimas ir atpažinimas...................................................................................322.8.3. Dokumentų valdymas.................................................................................................33

2.8.3.1. Bendrieji reikalavimai........................................................................................332.8.3.2. Dokumentų tvarkymas.......................................................................................342.8.3.3. Dokumentų rengimas.........................................................................................342.8.3.4. Dokumentų archyvavimas..................................................................................352.8.3.5. Dokumentų paieška ir peržiūra...........................................................................362.8.3.6. Darbotvarkės ir protokolai..................................................................................372.8.3.7. Išorinių naudotojų funkcionalumas....................................................................372.8.3.8. Gautų duomenų iš išorinių naudotojų valdymas................................................39

2.8.4. Teisės aktų ir jų projektų posistemės administravimas..............................................402.8.5. Teisės aktų ir jų projektų posistemės integracija su kitomis sistemomis...................41

2.9. Teritorijų planavimo dokumentų posistemės funkciniai reikalavimai...............................422.9.1. Bendrieji reikalavimai, posistemės struktūra ir realizavimas.....................................422.9.2. Teritorijų planavimo dokumentų posistemės kiekvieno žingsnio detalus aprašymas43

2.10. Problemų žemėlapio posistemės funkciniai reikalavimai..............................................502.10.1. Bendrieji reikalavimai ir naudotojų grupės................................................................502.10.2. Identifikavimas ir atpažinimas...................................................................................502.10.3. Problemų pateikimas..................................................................................................512.10.4. Informacijos pateikimas.............................................................................................522.10.5. Problemų peržiūra......................................................................................................522.10.6. Problemų valdymas....................................................................................................532.10.7. Problemų žemėlapio posistemės administravimas.....................................................542.10.8. Problemų žemėlapio posistemės integracija su kitomis sistemomis..........................55

2.11. Bendri Sistemos administravimo reikalavimai...............................................................553. Reikalavimai techniniai įrangai..................................................................................................56

3.1. Vaizdo konferencijų posistemės techninė įranga...............................................................563.1.1. Vaizdo kamera............................................................................................................56

3.2. Posėdžių valdymo ir transliavimo posistemės techninė įranga..........................................563.2.1. Registracijos kortelė...................................................................................................563.2.2. Kortelių programavimo įrenginys..............................................................................573.2.3. Vaizdo kamera............................................................................................................573.2.4. Vaizdo kamerų stebėjimo monitorius.........................................................................583.2.5. Vaizdo kamerų valdymo procesorius su kamerų vaizdo signalo komutatoriumi......593.2.6. Kompiuterinė vaizdo bei garso signalo kodavimo plokštė........................................603.2.7. Kompiuteris vaizdo bei garso signalo kodavimui, su operacine sistema...................60

2

1. Pirkimo objektas

1.1. Pagrindinės sąvokos ir apibrėžimai

Sutrumpinimas AprašymasProjektas Kauno miesto viešojo administravimo sektoriaus veiklos

skaidrumo didinimas informacinių ir ryšių technologijų priemonėmis įtraukiant savivaldybės bendruomenę“, santrumpa – „E-demokratijos plėtra Kauno mieste“

Savivaldybė Kauno miesto savivaldybė administracija (KMSA)Sistema Projekto metu sukurta ir įdiegta Savivaldybės E-demokratijos

informacinė sistemaIdentifikavimo posistemė Sistemos dalis skirta vykdyti gyventojų identifikavimo

funkcijas.Apklausų posistemė Sistemos dalis skirta vykdyti bendruomenės apklausas.Vaizdo konferencijų posistemė

Sistemos dalis skirta Tarybos narių ir Administracijos atstovų bendravimui vaizdo konferenciniu būdu su gyventojais.

Posėdžių valdymo ir transliavimo posistemė

Sistemos dalis skirta Tarybos posėdžių ir juose priimamų sprendimų viešinimo modernizavimui.

Teisės aktų ir jų projektų posistemė

Sistemos dalis skirta teisės aktų publikavimui, jų paieškai, projektų svarstymui ir nuomonės pareiškimui dėl jų.

Teritorijų planavimo dokumentų posistemė

Sistemos dalis skirta teritorijų planavimo dokumentų viešam svarstymui.

Problemų žemėlapio posistemė

Sistemos dalis skirta gyventojams teikti pasiūlymus miesto aplinkos gerinimo klausimais.

E-bilieto sistema Kauno miesto E-bilieto vartotojo portalas (Card User Portal - CUP)

VAIISIS Viešojo administravimo institucijų informacinių sistemų interoperabilumo sistema

VK Vaizdo konferencijaCSV Kableliais atskirtos reikšmėsHTML Hiperteksto ženklinimo kalbahttp Hipertekstų persiuntimo protokolashttps Saugaus hipertekstų persiuntimo protokolasPDF Universalus dokumentų vaizdavimo formatasUTF „Unicode“ keitimo formatasXML XML (Extensible Markup Language) kalbaLDAP Supaprastintos kreipties į katalogus protokolasEPS Savivaldybės Elektroninių paslaugų sistemaDVS Savivaldybės Dokumentų valdymo sistema („Kontora“)US Savivaldybės Urbanistikos skyriusDPOS Savivaldybės Detaliojo planavimo organizavimo skyriusPO Planavimo organizatoriusAD Savivaldybės Administracijos direktoriusDP Detalusis planasNSK Nuolatinė statybos komisija

1.2. Pirkimo tikslas ir uždaviniai

Pirkimo tikslas – Pagal techninėje ir funkcinėje specifikacijoje suformuluotus reikalavimus įsigyti ir įdiegti Sistemą, jos funkcionavimo užtikrinimui techninę įrangą Projekto įgyvendinimui, kurio tikslas stiprinti Kauno miesto bendruomenės ir viešojo administravimo sektoriaus sąveiką, įtraukti bendruomenę į viešųjų klausimų svarstymą, didinti Savivaldybės veiklos skaidrumą.

Pirkimo tikslo įgyvendinimui keliamas toks uždavinys – Kauno miesto E-demokratijos informacinės sistemos sukūrimas, jos įdiegimas ir reikiamos techninės įrangos įsigijimas.

1.3. Pirkimo objekto apimtis

1.3.1. E-demokratijos informacinės sistemos sukūrimas ir įdiegimas

Pagal pateiktus techninius ir funkcinius reikalavimus Tiekėjas turi sukurti ir įdiegti Sistemą KMSA. Visos Sistemos posistemės turi būti sujungtos į vieną visumą, tarp posistemių turi vykti duomenų mainai (kaip nurodyta techninėje ir funkcinėje specifikacijoje), posistemių dizainas ir vartotojų sąsajos turi būti suderintos tarpusavyje.

1.3.2. Techninės įrangos įsigijimas

Pagal pateiktus techninius reikalavimus Teikėjas turi pristatyti techninę įrangą, kuri yra būtina Sistemos funkcionalumui užtikrinti.

1.4. Tiekėjo įsipareigojimai

Teikėjo įsipareigojimai yra apibrėžti Sutarties projekte (Konkurso sąlygų 8 priedas).

1.5. Licencijavimo tvarka

Tiekėjas turi pateikti KMSA visas Sistemai eksploatuoti reikalingas licencijas. Licencijos turi būti nuolatinės ir įsigyjamos, o ne nuomos ar panašiu teisiniu pagrindu ar kitaip laiku apribotos: jų galiojimas turi būti nuolatinis ir neterminuotas. Pateikiamų licencijų skaičius turi užtikrinti Konkurso dokumentuose nurodytą Sistemos funkcionavimą. Sistemos Vidaus naudotojams licencijų kiekis neturi būti mažesnis nei 800 vnt. o Išorės naudotojams Sistema licencijomis neturi būti ribojama.

1.6. Sistemos dokumentacija

Tiekėjas turi perduoti perkančiosios organizacijos nuosavybėn pilną su Sistema susijusią dokumentaciją, Sistemos išeities tekstus (kodus). Turi būti pateiktos Sistemos dokumentacijos kiekvienam Sistemos funkciniam komponentui. Sistemos dokumentacija turi apimti funkcijų ir funkcinių komponentų aprašus, duomenų modelio ir struktūrų bei sistemos sąsajų aprašus. Sistemos dokumentacija turi būti pateikta lietuvių kalba. Sistemos komponentams, kurie pateikiami kaip standartiniai ir licencijuoti programinės įrangos paketai, pakanka pristatyti gamintojo teikiamą dokumentaciją anglų kalba. Visa medžiaga turi būti įrašyta į laikmenas. Taip pat turi būti pateikti ir suderinti Sistemos naudotojų vadovus elektroninių dokumentų pavidalu:

Naudotojų vadovai Sistemos administratoriamso Sistemos aprašymas (modulių aprašymai, komponentai, duomenų struktūros,

sąsajos su išorinėmis sistemomis) lietuvių kalba;o Sistemos programinės įrangos eksploatavimo instrukciją (lietuvių kalba);o Sistemos ir atskirų komponentų įdiegimo vadovas (angl. installation guide),

kuriame turi būti pateiktas Sistemą sudarančių komponentų diegimo eiliškumas bei jų integravimas į vientisą Sistemą (lietuvių kalba).

4

Visų likusių vidaus naudotojų vadovai (vartotojo sąsajos lygmenyje) lietuvių kalba.Suderinti Sistemos naudotojų vadovai turi būti prieinami interaktyvios pagalbos pavidalu

(angl. on-line help).

1.7. Sistemos naudotojų mokymai

Tiekėjas privalo organizuoti apmokymus (iki 8 val.) naudotis perkama ir diegiama įranga bei apmokyti iki 20 KMSA specialistų, kuriuos nurodys KMSA.

Mokymai turi būti organizuoti atskirai kiekvienai grupei, t.y. mokymai Sistemos administratoriams ir naudotojams pagal Sistemos modulius. Mokymo grafiką tvirtina KMSA.

Tiekėjas privalo paruošti detalų vartotojo vadovą ir specializuotą instrukciją lietuvių kalba bei pateikti popierine ir elektronine forma.

1.8. Sutarties vykdymo ir garantinio aptarnavimo terminai

Sutarties galiojimo trukmė – iki projekto įgyvendinimo pabaigos, t.y. iki 2011-09-01. Pratęsus projekto įgyvendinimo terminą, Sutarties trukmė abiejų šalių susitarimu gali būti pratęsta, bet ne ilgesniam laikui, nei numatyta projekto įgyvendinimo termino pabaiga.

Ne mažiau kaip 12 mėnesių Sistemai (nuo Sistemos perdavimo – priėmimo akto pasirašymo dienos) ir netrumpiau nei nurodyta šiame Konkurso sąlygų priede Techninei įrangai (nuo Techninės įrangos perdavimo – priėmimo aktų pasirašymo dienos), teikiamos Sistemos ir Techninės įrangos garantinio aptarnavimo paslaugos. Sistemos ir Techninės įrangos garantinio aptarnavimo paslaugos pradedamos teikti nuo Sistemos ir Techninės įrangos perdavimo – priėmimo aktų pasirašymo dienos. Sistemos ir Techninės įrangos garantinio aptarnavimo paslaugos apibrėžtos Sutarties projekte. Tiekėjas įsipareigoja pilnai įdiegti Sistemą per 12 mėn. nuo sutarties įsigaliojimo. Šis terminas, suderinus su Klientu gali būti pratęstas, bet neviršijant projekto įgyvendinimo termino pabaigos datos, t.y. 2011-09-01, o pratęsus projekto įgyvendinimo terminą, Sistemos įdiegimo terminas gali būti pratęstas papildomai, bet ne ilgesniam laikui, nei numatyta projekto įgyvendinimo termino pabaiga.

Pilnas Sistemos įdiegimas reiškia, kad kad pristatyta ir įdiegta visa Techninė įranga, įdiegtos visos posistemės, jos apjungtos ir funkcionuoja taip, kaip nurodyta šiame Konkurso sąlygų priede.

2. Funkciniai ir technologiniai reikalavimai

2.1. Bendrieji realizavimo principai

Nr. Aprašymas

1. Patogumas naudotis (angl. usability) – Sistema turėtų būti paprasta ir ja turi būti patogu naudotis. Svarbu, kad besikreipiantis Išorinis naudotojas atliktų kuo mažiau žingsnių.

2. Prieinamumas (angl. accessibility) – prieiga prie Sistemos turėtų būti užtikrinama 24 valandas per parą, 7 dienas per savaitę. Taip pat turėtų būti galimybė neįgaliesiems naudotis sistema.

3. Privatumas ir saugumas (angl. privacy and security) – naudotojų duomenų privatumas bei konfidencialumas turėtų būti užtikrinamas tinkamomis technologinėmis priemonėmis.

4. Sistemos programinė architektūra ir jos realizacija turi palaikyti Sistemos pajėgumų plėtimą, prijungiant papildomą techninę įrangą (angl. scaling).

5. Sistema turi būti atspari programiniams ir aparatiniams trikdžiams.

6. Sistemos programinė įranga neturi būti ribojantis veiksnys didinant Sistemos našumą. Kitaip tariant Sistemos našumui padidinti užtenka pridėti reikalingos aparatinės įrangos, tuo pačiu nekeičiant Sistemos programinės įrangos išeities tekstų.

5

Nr. Aprašymas

7. Sistema turi veikti realizuota taip, kad naudotojui nereikėtų diegti jokios papildomos programinės įrangos.

8. Sistema turi veikti interneto naršyklės lange. Sistema turi būti pasiekiama ir veikti stabiliai su visomis populiariausiomis naršyklėmis (Internet Explorer, Mozilla Firefox, Google Chrome, Opera ir kt.).

2.2. Sistemos architektūra

Nr. Aprašymas

9. Sistema turi būti suvokiama, kaip kompiuterinių priemonių visuma, realizuojanti žemiau pateikiamas funkcijas. Sistemą turi sudaryti šios posistemės:

Identifikavimo posistemė Apklausų posistemė Vaizdo konferencijų posistemė Posėdžių valdymo ir transliavimo posistemė Teisės aktų ir jų projektų posistemė Teritorijų planavimo dokumentų posistemė Problemų žemėlapio posistemė

10. Sistemos posistemės turi būti apjungtos bendru dizainu, tačiau Išorės naudotojai turi aiškiai matyti, kurioje posistemėje jie yra.

11. Sistemos ir posistemių susiejimai aprašyti prie kiekvienos posistemės funkcinių reikalavimų.

2.3. Bendrieji sistemos reikalavimai

Nr. Aprašymas

12.Sistemos diegimo metu turi būti vadovaujamasi rekomendacijomis dėl atvirųjų elektroninių dokumentų standartų naudojimo teikiant viešąsias paslaugas gyventojams, valstybės institucijoms ir įstaigoms elektroninėmis priemonėmis keičiantis informacija.

13. Užpildytos elektroninės formos ar jų dalys turi būti traktuojamos kaip dokumentiniai įrašai ir turi būti saugomi Sistemoje, kaip juridinę galią turintys dokumentai.

14. Sistema turi palaikyti SSL per HTTP protokolą.

15. Tarp Sistemos posistemių apsikeičiami duomenys turi būti aprašomi naudojant XML (angl. Extensible Markup Language, http://www.w3.org/TR/REC-xml) schemas.

16. Sistema duomenų ir pranešimų apsikeitimui bei saugojimui turi naudoti Unicode (UTF-8) koduotę.

17. Sistemos atpažinimo (autorizacijos) mechanizmas turi būti realizuotas remiantis rolių modeliu (angl. role-based model).

18. Kuriant naujus komponentus ar jos plėtinius, analizei, projektavimui bei dokumentacijai turi būti naudojamas Unified Modeling Language ar lygiavertis standartas (UML, http://www.omg.org/technology/uml/index.htm).

19. Sistema turi užtikrinti, kad naudotojų veiksmų – dokumentinių įrašų įterpimo, keitimo ir šalinimo – vidutinė atlikimo trukmė būtų ne ilgesnė nei 3 sekundės (specifinių, didelius duomenų kiekius apimančių veiksmų trukmė gali būti ilgesnė, tačiau turi būti suderinta).

20. Sistemos sąsajoje pateikiamas funkcionalumas turi būti ribojamas autorizacijos pagalba, pagal apibrėžtas naudotojo roles. Tokiu būdu naudotojui suteikiama galimybė naudotis tik tam tikromis funkcijomis, priklausomai nuo jam suteiktų vaidmenų (rolių).

6

Nr. Aprašymas

21. Sistemos grafinė sąsaja Išoriniams naudotojams turi būti pritaikyta neįgaliesiems.

22. Sistemos Išorinis naudotojas turi turėti galimybę užsisakyti arba atsisakyti Sistemos priemonėmis jam siunčiamos informacijos.

23. Sistema turi palaikyti konfigūruojamą sesijų veikimo periodo nustatymą, kuriam pasibaigus naudotojas yra priverstas iš naujo įsiregistruoti Sistemoje.

24. Sistemos naudotojas turi turėti galimybę užsisakyti arba atsisakyti Sistemos priemonėmis jam siunčiamos informacijos. Pranešimai apie prašymą balsuoti turi būti siunčiami elektroniniu paštu.

25. Sistemos naudotojo sąsaja turi atitikti W3C XHTML specifikaciją.

26. Turi būti naudojama ne žemesnė kaip 2 lygio CSS2 (Cascading Style Sheets Language 2, http://www.w3.org/Style/CSS/).

27. Turi būti naudojama ne žemesnė kaip 3.2 HTML (Hypertext Markup Language, http://www.w3.org/MarkUp/) versija.

28. Sistemoje turi būti galimybė patikrinti įvedamų duomenų logikos korektiškumą (jei įmanomas toks tikrinimas) lauko lygmenyje duomenų įvedimo languose.

29. Siūloma Sistema turi atitikti reikalavimus pateiktus Lietuvos Respublikos Vyriausybės 2007-04-25 nutarime Nr. 410 „Dėl elektroninės informacijos saugos valstybės institucijų ir įstaigų informacinėse sistemose”.

30. Sistema turi atitikti valstybės informacinės sistemos saugumo reikalavimus, nustatytus Valstybės institucijų ir įstaigų informacinių sistemų elektroninės informacijos techniniuose saugos reikalavimuose, patvirtintuose Lietuvos Respublikos vidaus reikalų ministro 2008 m. spalio 27 d. įsakymu Nr. 1V-384 (Žin., 2008, Nr. 127-4866, toliau - Reikalavimai) ir kituose Lietuvos Respublikos teisės aktuose, reglamentuojančių saugų informacijos tvarkymą, ir nustatytus reikalavimus, užtikrinant nustatyto lygio informacijos konfidencialumą, vientisumą ir prieinamumą.

31. Sistema ir jos kūrimas turi atitikti Lietuvos standartus ir įstatymus, Kauno miesto savivaldybės nutarimus ir nuostatas.

32. Sistema turi užtikrinti duomenų konfidencialumą. Tai reiškia, kad Sistema turi leisti naudotojams matyti tik tuos duomenis, kuriuos jie gali matyti. Konfidencialumas yra siejamas su komunikavimo privatumu, svarbių duomenų saugiu saugojimu, naudotojų identifikavimu bei ribotu duomenų matomumu.

33. Duomenų tvarkymas turi atitikti tarptautinį standartą ISO 15489-1:2001 bei Lietuvos Respublikos raštvedybos taisykles (skaitmenų formatas, datos ir laiko formatai).

34. Sistema turi būti kuriama moduliniu principu. Toks Sistemos realizacijos modelis turi užtikrinti Sistemos vientisumą, lankstumą, lengvas plėtimo galimybes.

35. Kuriant ir diegiant Sistemą turi būti naudojami reikiami architektūriniai bei technologiniai sprendimai, užtikrinantys įvedamų ir saugomų duomenų autentiškumą, nepakeičiamumą ir integralumą.

36. Sistema turi palaikyti siunčiamų, gaunamų ir laikomų duomenų užšifravimą ir iššifravimą.

37. Klaidų pranešimai teikiami Sistemos naudotojams turi būti informatyvūs, ir suteikti pakankamos informacijos tolimesniems veiksmams klaidai pašalinti ar jos išvengti.

38. Turi būti užtikrinta galimybė leisti įvesti duomenis, jų neužregistruojant iškarto ir užregistruoti tik patvirtinus naudotojui.

39. Sistema turi dirbti su dokumentais pagal Lietuvos archyvų departamento prie Lietuvos Respublikos Vyriausybės generalinio direktoriaus 2006 m. sausio 11 d. įsakymą Nr. V-12 „Dėl elektroninių dokumentų valdymo taisyklių patvirtinimo“ (Žin., 2006, Nr. 7-268).

7

Nr. Aprašymas

40. Sistema vykdydama veiksmus susijusius su elektroniniu parašu turi vadovautis Lietuvos archyvų departamento prie Lietuvos Respublikos Vyriausybės generalinio direktoriaus 2009 m. rugsėjo 7 d. įsakymu Nr. V-60 „Dėl elektroninių parašu pasirašyto elektroninio dokumento specifikacijos ADOC-V1.0 patvirtinimo“.

2.4. Identifikavimo posistemės funkciniai reikalavimai

2.4.1. Bendrieji reikalavimai ir naudotojų grupės

Nr. Aprašymas

41.

Identifikavimo posistemėje turi būti tokios dalys: Identifikavimo ir atpažinimo dalis Išorinio naudotojo personalinė dalis Sistemos navigacija

42.

Identifikavimo posistemė turi būti pritaikyta šioms naudotojų grupėms (naudotojų vaidmenims):Išoriniai naudotojai: Išoriniai neidentifikuoti naudotojai – asmenys, kurie nori susipažinti su Sistemos

dalimis ir jose teikiama informacija. Išoriniai identifikuoti naudotojai – fiziniai asmenys, kurie gali naudotis Sistemos

funkcionalumu skirtu Išoriniams identifikuotiems naudotojams.Vidiniai naudotojai: Posistemės administratorius – savivaldybės darbuotojas, kuris atlieka posistemės

administravimo darbus.

43.Posistemė turi būti suprantama kaip Sistemos vartai, per kuriuos išoriniai naudotojai gali pasiekti visas posistemes, sužinoti kokią informaciją gali gauti ir kokius veiksmus gali atlikti kiekvienoje posistemėje.

2.4.2. Identifikavimo ir atpažinimo funkciniai reikalavimai

Nr. Aprašymas

44. Vidaus naudotojų identifikavimas (tapatumo patikrinimas) turi būti atliekamas tradiciniu (vartotojo vardas/ slaptažodis) identifikavimo būdu. Turi būti sudaryta galimybė identifikuoti Vidaus naudotojus naudojant LDAP (Supaprastintos kreipties į katalogus protokolą).

45. Posistemėje turi būti realizuotas identifikavimo duomenų gavimas iš šių išorinių sistemų: Viešojo administravimo institucijų informacinių sistemų interoperabilumo

sistemos – VAIISIS (www.epaslaugos.lt) Kauno miesto E-bilieto vartotojo portalo (Card User Portal - CUP).

46. VAIISIS techninės architektūros aprašymas pateikiamas internete šiuo adresu:https://www.epaslaugos.lt/egovportal/egovimg/e-Valdzia/failai/docs/naudinga_informacija/vaiisis_tech_architektura/VAIISIS_tech_architektura.pdf

47. Techniniai reikalavimai identifikavimo paslaugai per VAIISIS pateikiami adresu: https://www.epaslaugos.lt/egovportal/egovimg/e-Valdzia/failai/docs/naudinga_informacija/identifikavimas/identifikavimo_per_VAIISIS_sutartis__tipine.DOC

48. Techniniai reikalavimai identifikavimo paslaugai per E-bilieto sistemą: Tiekėjui bus suteikta prieiga prie E-bilieto sistemos duomenų bazės (MS SQL) ir

8

Nr. Aprašymassuteiktos „tik skaityti“ teisės;

Bus nurodytas serverio vardas (arba IP adresas), duomenų bazės pavadinimas, vartotojo vardas ir slaptažodis;

Posistemė išorinio naudotojo identifikavimo metu gautus duomenis turės tikrinti su E-bilieto sistemos duomenų bazėje esančiais duomenimis;

Duomenų patikrinimui Tiekėjas privalės suformuoti saugų duomenų kanalą. Tiekėjas privalės naudotis ryšiu su MS SQL serveriu per apsaugotą (šifruotą) ryšio kanalą naudojant IPSec arba SSLv3/TLS technologijas.

Duomenų bazės struktūra bus pateikta Sistemos diegimo metu.

49. Identifikavimo duomenys turi būti perduodami į šias Sistemos posistemes: Apklausų Vaizdo konferencijų Teisės aktų ir jų projektų Teritorijų planavimo dokumentų Problemų žemėlapio

50. Priklausomai nuo pasirinktos išorinės identifikavimo sistemos (VAIISIS, E-bilieto sistema) Išoriniams naudotojams turi būti ribojamas posistemių funkcionalumas.

51. Atlikus identifikavimą per VAIISIS, Išoriniai naudotojai turi turėti galimybę naudotis visomis Sistemos posistemių funkcijomis, skirtomis Išoriniams identifikuotiems naudotojams.

52. Jeigu Išorinis naudotojas identifikacijai naudoja E-bilieto sistemą, tai jis gali naudotis šiomis Sistemos posistemėmis ir jų funkcijomis skirtomis Išoriniams identifikuotiems naudotojams:

Vaizdo konferencijų, Problemų žemėlapio.

53. Išoriniui naudotojui turi būti aiškiai nurodoma, kokios identifikacijos reikia norint pasinaudoti kiekvienos iš Sistemos posistemės suteiktomis funkcijomis Išoriniams identifikuotiems naudotojams.

54. Jeigu Išorinis naudotojas atliko identifikaciją per E-bilieto sistemą ir nori pasinaudoti E-bilieto sistemai nepriskirta E-demokratijos posisteme jis turi būti informuojamas ir nukreipiamas atlikti identifikaciją per VAIISIS.

55. Išoriniam naudotojui atlikus identifikaciją jis turi būti grąžinamas į tą puslapį (posistemės dalį) iš kurio buvo reikalaujama atlikti identifikaciją (pvz.: Jeigu naudotojas nori pateikti prašymą Teritorijų planavimo dokumentų posistemėje ir iš jos yra nukreipiamas identifikacijai tai po identifikacijos procedūros jis turi būti grąžinamas į prašymo pateikimo puslapį. Jeigu Išorinis naudotojas atlieka identifikaciją pirmame Sistemos puslapyje tai į jį ir turi būti grąžinamas).

56. Atlikus identifikaciją Sistemoje turi būti rodoma Išorinio identifikuoto naudotojo vardas ir pavardė. Turi būti galimybė atsijungti nuo Sistemos.

2.4.3. Išorinio naudotojo personalinė dalis

Nr. Aprašymas

57. Posistemėje turi būti realizuota personalinė dalis Išoriniams identifikuotiems naudotojams.

58. Išorinio naudotojo personalinėje dalyje turi būti toks funkcionalumas: Galimybė nurodyti kontaktinę informaciją:

o Telefono numeriaio Gyvenamasis adresaso El. pašto adresaso Ir kita informacija.

9

Nr. Aprašymas Įkelti savo nuotrauką. Užsisakyti naujienų siuntimą el. paštu. Matyti informaciją iš Sistemos posistemių (nuorodos į pateiktus pranešimus

apie problemas ir pan.).Tiksli nurodoma informacija ir pildomi laukai galės būti tikslinama Sistemos diegimo metu.

2.4.4. E-demokratijos sistemos navigacija

Nr. Aprašymas

59.

Iš Identifikavimo posistemės turi būti galima pasiekti visas Sistemos posistemes: Apklausų, Vaizdo konferencijų, Posėdžių valdymo ir transliavimo posistemės Transliavimo dalį, Tesės aktų ir jų projektų, Teritorijų planavimo dokumentų, Problemų žemėlapio.

2.4.5. Identifikavimo posistemės administravimas

Nr. Aprašymas

60.Posistemės administratorius turi turėti galimybė nurodyti kokio dydžio ir kokių išmatavimų Išorinių identifikuotų naudotojų nuotraukos yra tinkamos taip pat šalinti netinkamas nuotraukas, valdyti kitus pateiktus duomenis.

61. Posistemei galioja bendri Sistemos administravimo reikalavimai, kurie pateikiami 2.11 skyriuje.

2.4.6. Identifikavimo posistemės integracija su kitomis sistemomis

Nr. Aprašymas

62.

Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemomis: LDAP (Supaprastintos kreipties į katalogus protokolas), skirtas Sistemos

Vidaus naudotojų identifikavimui; Su visomis Sistemos posistėmis.

2.5. Apklausų posistemės funkciniai reikalavimai

2.5.1. Bendrieji reikalavimai ir naudotojų grupės

Nr. Aprašymas

63.

Apklausų posistemė turi būti suvokiama kaip kompiuterinių priemonių visuma, realizuojanti šias funkcijas:

Identifikavimas ir atpažinimas; Apklausų organizavimas; Balsavimas; Balsavimo rezultatų skaičiavimas; Apklausos rezultatų skelbimas; Posistemės administravimas; Posistemės auditas.

10

Nr. Aprašymas

64. Sąrašai posistemėje turi būti išskaidyti puslapiais. Posistemės administratorius turi turėti galimybę nustatyti įrašų kiekį puslapyje.

65.Posistemėje turi būti galimybė keisti ir šalinti įvestus ir neužregistruotus įrašus bei neleisti keisti ir šalinti užregistruotų įrašų reikiamų teisių neturintiems naudotojams. Turi būti galimybė apriboti šias funkcijas atskiroms naudotojų grupėms.

66.Posistemėje realizuotas funkcionalumas turi atitikti Lietuvos respublikos vietos savivaldos įstatymo (Nr. X-1722, 2008-09-15, Žin., 2008, Nr. 113-4290 (2008-10-01) devintojo skirsnio „Vietos gyventojų apklausa“ nuostatus.

67. Turi būti galimybė pildyti ir redaguoti Posistemės klasifikatorius.

68.Posistemė turi sugebėti priimti Posistemės išorinių naudotojų siunčiamus duomenis pasirašytus saugiu elektroniniu parašu bei patikrinti elektroninio parašo bei siunčiamų duomenų autentiškumą. Posistemė turi vykdyti elektroninio parašo tikrinimą.

69.Posistemė turi užtikrinti galimybę pasirašyti el. dokumentus (el. balsą) el. parašu naudojant kvalifikuotą skaitmeninį sertifikatą, išduotą įregistruoto kvalifikuotus sertifikatus sudarančio sertifikavimo paslaugų teikėjo.

70.

Dokumento aprašas Posistemėje turi atitikti Lietuvos archyvų departamento prie Lietuvos Respublikos Vyriausybės generalinio direktoriaus 2008 m. spalio 9 d. įsakyme Nr. V-119 „Dėl elektroniniu parašu pasirašyto elektroninio dokumento specifikacijos reikalavimų aprašo patvirtinimo“ (Žin., 2006, Nr. 7-268) patvirtintą el. dokumento aprašą.

71.

Posistemė turi būti pritaikyta šioms naudotojų grupėms (naudotojų vaidmenims):Išoriniai naudotojai:

Išoriniai neidentifikuoti naudotojai – asmenys, kurie nori susipažinti su Posistemės teikiama informacija.

Išoriniai identifikuoti naudotojai – fiziniai asmenys, kurie gali prisijungti prie Posistemės ir balsuoti pateiktais klausimais.

Vidaus naudotojai: Apklausų tvarkytojai – savivaldybės darbuotojai, kuriems suteikta teisė

naudotis Posistemės ištekliais atliekant Apklausų tvarkytojui priskirtas funkcijas (kurti, redaguoti, registruoti apklausas ir kt.).

Semantikos tvarkytojai – savivaldybės darbuotojai, kuriems suteikta teisė naudotis Posistemės ištekliais atliekant Semantikos tvarkytojui priskirtas funkcijas (pildyti, redaguoti ontologijas, analizuoti tekstus ir kt.)

Posistemės administratorius – savivaldybės darbuotojas, kuris atlieka Posistemės administravimo darbus.

2.5.2. Identifikavimas ir atpažinimas

Nr. Aprašymas

72. Vidaus naudotojų identifikavimas (tapatumo patikrinimas) turi būti atliekamas tradiciniu (vartotojo vardas/ slaptažodis) identifikavimo būdu.

73.

Vidaus naudotojų slaptažodžiai ir vardai turi būti saugomi naudotojų registre, su tinkamu prieigos kontrolės užtikrinimu ir informacijos šifravimu (slaptažodžiai turi būti šifruojami ir pan.). Sistema turi naudoti naudotojų tapatybės nustatymo informaciją iš naudotojų registro. Turi būti sudaryta galimybė Vidiniams naudotojams prisijungti naudojant LDAP (Supaprastintos kreipties į katalogus protokolą).

74. Registravimosi į Posistemę galimybė turi būti realizuota pirmame Posistemės puslapyje.

75. Naudotojų autorizacijos (leidimas naudotis resursais) funkcionalumas turi būti apibrėžtas pagal naudotojo roles. Tokiu būdu naudotojui suteikiama galimybė naudotis

11

Nr. Aprašymastik tam tikromis funkcijomis, priklausomai nuo jam suteiktų vaidmenų (rolių).

76. Turi būti sudaryta galimybė Išoriniams naudotojams identifikuotis per Sistemos Identifikavimo posistemę.

2.5.3. Apklausų organizavimas

Nr. Aprašymas

77. Informacijos, t.y. įregistruotų apklausų paieška/filtravimas Posistemėje turi būti atliekamas nurodant/pasirenkant vieną ar kelis metaduomenų atributus:

apklausos pavadinimą (žodį, jo dalį), apklausos kodą, apklausos temą, apklausos būdą, apklausos klausimą/klausimus, apklausos teritoriją, apklausos iniciatorių.

Apklausos registravimo metaduomenų atributai gali būti patikslinti Sistemos diegimo metu.Apklausų paieška/filtravimas turi būti vykdomi operatyviuoju būdu (angl. online).

78. Posistemė paieškos rezultatą turi formuoti tame pačiame ekrane, kuriame pasirenkami paieškos/filtravimo kriterijai.

79. Paieškos rezultatas turi būti formuojamas lentelės pavidalu. Posistemė rezultatus turi išskaidyti puslapiais (puslapiuoti) pagal Posistemės administratoriaus nustatytą paieškos rezultatų kiekį.

80. Posistemė įvestą apklausos formą turi sumaketuoti pagal iš anksto nustatytas taisykles, t.y. Apklausos įvedimo/redagavimo forma turi skirtis nuo peržiūrai ir eksportavimui į PDF formato failą paruoštos apklausos formos.

81. Turi būti sudaryta galimybė Apklausų tvarkytojui, pasirinkus apklausą, peržiūrėti sumaketuotą apklausos formą.

82. Turi būti sudaryta galimybė Išoriniam naudotojui peržiūrėti registruotas ir paskelbtas apklausas.

83. Turi būti įgyvendintas Apklausų formų automatinis sumaketavimas pagal numatytas taisykles ir įrašymas į failą PDF formatu.

84. Galimybė atsispausdinti Apklausos formą (automatiškai sumaketuotą).

85. Galimybė parsisiųsti Apklausos formą (automatiškai sumaketuotą PDF formatu).

86. Turi būti sukurta lanksti naujos apklausos pildymo forma. Galimybė Apklausų tvarkytojams kurti ir pildyti duomenys apie naują apklausą.

87. Naujos apklausos formoje turi būti įgyvendinti: duomenų tikrinimas, duomenų užkrovimas iš klasifikatorių.

88. Apklausa gali būti įvesta etapais. Tai yra įvedus apklausos duomenis ir išsaugojus, Apklausa turi būti patalpinama į sąrašą „Pildomos apklausos“. Apklausų tvarkytojas šiame sąraše turi matyti tik savo pildytas apklausas. Atsidarius nebaigtą pildyti Apklausą iš sąrašo „Pildomos apklausos“, galima pratęsti duomenų apie Apklausą pildymą.

12

Nr. Aprašymas

89. Suvedus visus duomenis, Apklausų tvarkytojas turi turėti galimybę apklausą registruoti apklausų registre.

90. Apklausos pildymo formoje, turi būti galimybė įrašyti apklausos pavadinimą, klausimą ar klausimus, pasirinkti apklausos vykdymo teritoriją, apklausos vykdymo būdą, apklausos iniciatorių. Taip pat turi būti galimybė nustatyti nuo kurios datos ir kiek dienų truks apklausa.

91. Apklausos pildymo formoje numatomi informacijos pildymo/pasirinkimo laukai: Pavadinimas; Kodas, Tema, Apklausos būdas, Klausimas/klausimai, Apklausos teritorija, Apklausos iniciatorius, Apklausos vykdymo pradžia, Apklausos vykdymo pabaiga.

Apklausos pildymo forma ir maketavimo (atvaizdavimas peržiūros režimu) taisyklės gali būti papildytos Sistemos diegimo metu.

92. Turi būti sudaryta galimybė vykdyti atrankines apklausas. Atrankinės apklausos metu apklausiami gyventojai turi būti parenkami taip, kad kiekvienas, kuris galėtų būti apklausiamas, turėtų vienodas galimybes patekti tarp apklausiamųjų. Vertinant atrankinių apklausų rezultatus, turi būti nurodomi jų patikimumo duomenys.

93. Apklausų tvarkytojas pasirinkęs savo pildomą Apklausą iš sąrašo „Pildomos apklausos“ gali ją atsidaryti peržiūrai, redagavimui, spausdinimui ir pašalinimui.

94. Apklausų tvarkytojui užregistravus apklausą, Sistema automatiškai priskiria apklausai numerį, pagal Posistemės administratoriaus nustatytas taisykles. Po to apklausa patalpinama į „Registruotų apklausų sąrašą“. Posistemė šiame sąraše patalpintas apklausas turi neleisti koreguoti. Apklausų tvarkytojas šiame sąraše turi matyti visas registruotas apklausas.

95. Atėjus dienai, kai pradedamas apklausos vykdymas (sutampa apklausos vykdymo pradžia su einama data), Posistemė automatiškai turi išpublikuoti apklausą viešai peržiūrai į tam skirtą internetinį puslapį.

96. Atėjus dienai, kai apklausos vykdymas baigtas (sutampa apklausos vykdymo pabaiga su einama data), Posistemė automatiškai turi apklausą perkelti į baigtų vykdyti apklausų puslapį, kur kitos Posistemės dalys atlieką apklausos balsavimo skaičiavimus.

97. Atlikus balsų skaičiavimą, Posistemė turi paskelbti apklausos rezultatus internetiniame puslapyje.

98. Apklausų tvarkytojas turi turėti galimybę susieti apklausą su kitomis Sistemos posistemėmis. Tikslūs susiejimai įvardinti 2.5.10 skyriuje.

99. Turi būti sudaryta galimybė Apklausų tvarkytojui pratęsti balsavimą, tai yra nustatyti naują balsavimo pabaigos datą. (Posistemė šį pakeitimą turi registruoti Apklausos vykdymo žurnale).

100. Apklausų organizavimo funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

2.5.4. Balsavimas

13

Nr. Aprašymas

101. Pagrindiniai balsavimai posistemėje turi būti numatyti tik Kauno miesto savivaldybės gyventojams, tačiau taip pat turi būti numatyta galimybė išplėsti balsuoti galinčių asmenų sąrašą iki rajono ar apskrities lygio.

102. Pasirinkus apklausos vykdymą seniūnijos (kelių seniūnijų) aptarnaujamoje teritorijoje (aptarnaujamose teritorijose) arba gyvenamosios vietovės (kelių gyvenamųjų vietovių) teritorijoje, Sistemoje turi būti leidžiama balsuoti tik tos teritorijos gyventojams.

103. Turi būti galimybė vienu metu vykdyti balsavimą vienu ar daugiau klausimų.

104. Kiekvieną kartą identifikuojant Išorinį naudotoją, turi būti sukuriamas naujas ryšys.

105. Turi būti sukurta galimybė Posistemės administratoriui nurodyti balsavimo laiką, t.y. kuriomis valandomis bus galimas balsavimas. Kitu metu balsavimas nebus galimas.

106. Jei Išorinis identifikuotas naudotojas bandys balsuoti ne balsavimui skirtu laiku, Posistemė turi jį išsamiai informuoti apie balsavimui skirtą laiką.

107. Jei Išorinis naudotojas identifikavosi prieš balsavimo pabaigą, Posistemė jam turi leisti pabaigti balsavimą iki balsų skaičiavimo pradžios.

108. Turi būti sudaryta galimybė Išoriniams identifikuotiems naudotojams elektroniniu būdų balsuoti kiek nori kartų, kad eliminuoti balsų pirkimo atvejus.

109. Išorinių identifikuotų naudotojų balsai turi būti užšifruojami ir užkuoduoti iki balsų skaičiavimo pradžios. Tai yra gyventojų balsai iki balsų skaičiavimo pradžios turi būti niekam (įskaitant Sistemos ir Posistemės administratorius) neprieinami.

110. Turi būti suteikta įprastinio balsavimo galimybė. Tai yra turi būti suteikta galimybė vykdyti gyventojų apklausą savivaldybės patalpose.

111. Vykdant gyventojų apklausą savivaldybės patalpose, turi būti galimybė Apklausų tvarkytojui pažymėti gyventojus, kurie balsavo savivaldybės patalpose.

112. Vykdant gyventojų apklausą savivaldybės patalpose, turi būti galimybė Apklausų tvarkytojui pasibaigus balsavimui ir suskaičiavus balsus, įvesti ir registruoti balsų skaičiavimo protokolą (įvedamos piliečių balsų sumos).

113. Balsavimas turi būti paremtas RSA (viešojo rakto kriptosistema). Tai yra balsų šifravimas turi būti pagrįstas kodavimo viešuoju rakto technologija.

114. Turi būti sudarytą galimybė privatų raktą, kuriuo bus šifruojami gyventojų balsai, skaidyti fragmentais ir išdalinti keliems už balsavimus atsakingiems savivaldybės darbuotojams, taip užtikrinant didesnį saugumą.

115. Turi būti sudaryta galimybė kiekvienam balsavimui generuoti naują raktų porą ir privataus rakto fragmentų išdalinimą atsakingiems už balsavimą savivaldybės darbuotojams. (Balsų iššifravimas bus įmanomas tik pateikus Posistemei visus privataus rakto fragmentus).

116. Posistemė turi automatiškai atpažinti ar bent vienas balsas buvo pakeistas išoriškai. (Dėl administratorių įsikišimo ir kt.) Tokie balsai turės būti neskaičiuojami.

117. Balsavimo funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

2.5.5. Apklausos rezultatų skaičiavimas

Nr. Aprašymas

118. Elektroninio balsavimo atveju Posistemė turi pripažinti paskutinį Išorinio identifikuoto naudotojo balsą.

119. Paskelbus apklausos balsavimo balsų skaičiavimo pradžią, Posistemė turi pareikalauti pateikti visus privataus rakto fragmentus.

14

Nr. Aprašymas

120. Jei gyventojas balsavo elektroniniu ir įprastiniu būdų (savivaldybės patalpose), Posistemė turi skaičiuoti įprastinio balsavimo balsą (elektroninio balsavimo balsas atmetamas).

121. Posistemė turi automatiškai susumuoti elektroninio ir įprastinio balsavimo balsus (jeigu toks balsavimas buvo vykdomas) ir pateikti rezultatus atskirame internetiniame puslapyje Apklausų tvarkytojui.

122. Po elektroninio balsavimo balsų suskaičiavimo elektroninių raktų pora turi būti sunaikinta.

123. Apklausos rezultatų skaičiavimo funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

2.5.6. Apklausos rezultatų skelbimas

Nr. Aprašymas

124. Po balsu skaičiavimo Apklausų tvarkytojui turi būti sudarytą galimybė publikuoti apklausos rezultatus.

125. Apklausų rezultatų publikavimas turi būti atliekamas į Savivaldybės ir į atskirą apklausų rezultatų internetinius puslapius. Publikavimas turi būti suderintas Sistemos diegimo metu.

126. Turi būti sukurtas atskiras internetinis puslapis skirtas apklausų rezultatų atvaizdavimui, kurio dizainas turi būti suderintas su visos Sistemos dizainu.

127. Atskirame internetiniame apklausų rezultatų puslapyje turi būti išskirtos sritys: aktualių, populiariausių, einamų, peržiūrėtų apklausų rezultatų ir apklausų rezultatų archyvas.

128. Apklausos rezultatų skelbimo funkcinis komponentas turi suteikti Apklausų tvarkytojui galimybę tvarkyti šiuos apklausos rezultato publikavimo atributus:

Laikotarpis iki kada turi būti publikuojama skyriuje „aktualios apklausos“, Komentaras, Publikavimo žyma.

Atributai gali būti papildomi Sistemos diegimo metu.

129. Turi būti sudaryta galimybė Apklausų tvarkytojui susieti apklausas su Sistemos posistemėmis taip kaip nurodyta 2.5.10 skyriuje. Taip pat turi būti galimybė prie apklausos įvesti arba pridėti bylą (failą) su kita papildoma informacija.

130. Turi būti galimybė riboti prieigą Apklausų tvarkytojui suteikiant galimybę tvarkyti tik jam priskirtus apklausų rezultatus.

131. Apklausų rezultatų skelbimo funkcinis komponentas turi teikti galimybę publikuoti turinį pateiktą: failų, vaizdų, struktūrizuotų įrašų ar dokumentų pavidalu.

132. Apklausos rezultatų skelbimo funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

2.5.7. Apklausų posistemės administravimas

Nr. Aprašymas

133. Posistemės administratorius turi turėti galimybę suteikti teises Vidaus naudotojams atlikti kitų Vidaus naudotojų funkcijas (turi būti realizuotas darbuotojų pavadavimas).

134. Posistemės administratorius turi turėti galimybę registruoti, koreguoti, ištrinti Apklausų tvarkytojus.

135. Posistemės administratorius turi turėti galimybę priskirti Apklausų tvarkytojui apklausas, kurių duomenis (apklausų rezultatus, apklausų valdymą) jis galės tvarkyti.

15

Nr. Aprašymas

136. Posistemės administratorius turi turėti galimybę archyvuoti įvykdytas ir paskelbtas apklausas.

137. Posistemės administratorius turi turėti galimybę nustatyti terminą po kurio Posistemė automatiškai atliks įvykdytų apklausų archyvavimą.

138. Posistemės administratorius turi turėti galimybę nustatyti laiką tarp balsavimo pabaigos ir balsų skaičiavimo pradžios.

139. Posistemėje turi būti galimybė peržiūrėti prisijungimų apklausų peržiūrai, balsavimui kontrolės (istorijos) ataskaitas.

140. Posistemės administratoriui turi būti suteikta galimybė atlikti pilną Posistemės auditavimą.

141. Posistemei galioja bendri Sistemos administravimo reikalavimai, kurie pateikiami 2.11 skyriuje.

2.5.8. Apklausų posistemės auditas

Nr. Aprašymas

142. Posistemės audito komponentas turi būti susietas su Posistemės administravimo komponentu.

143. Posistemės audito komponente turi būti registruojami apklausų peržiūros, balsavimo ataskaitos. Posistemės klaidų žurnalai. Taip pat turi būti galimybė stebėti Posistemės išorinių naudotojų srautą.

144. Klaidų įvykiai turi būti registruojami audito informacijos žurnaluose.

145. Turi būti galimybė perskaičiuoti į Posistemę atsiųstus ir įrašytus balsus.

146. Iš aprašančios balsą informacijos auditorius neturi matyti informacijos apie rinkėją, kad nebūtų pažeistas gyventojo privatumas.

147. Turi būti galimybė iškoduotus balsus be gyventojų asmeninės informacijos perduoti trečiai šaliai balsų skaičiavimo patikrinimui. Duomenų eksportavimas turi būti atliekamas XML ir CSV formatais.

2.5.9. Semantinės analizės modulis

Nr. Aprašymas

148. Semantinės analizės modulis (toliau - modulis) turi būti priemonė tekstinių duomenų semantinės analizės vykdymui, rezultatų atvaizdavimo Posistemės vidiniams naudotojams ir ontologijų (arba teminių žemėlapių) pildymui.

149. Automatiniu būdu atliekamos modulio funkcijos turi būti realizuotos kaip WEB servisai (angl. web services) bei turi būti pasiekiamos ir panaudojamos pagal WEB servisų pasiekimo specifikacijas (http://www.w3.org/2002/ws/ra/).

150. Tekstų analizės ir ontologijų (teminių žemėlapių) tvarkymo priemonės Semantikos tvarkytojams turi būti pasiekiamos per grafinę modulio sąsają. Grafinės vartotojo sąsajos turi būti realizuotos lietuvių kalba.

151. Teksto metaduomenų žymėjimui turi būti naudojami XML (angl. Extensible Markup Language, http://www.w3.org/TR/REC-xml) ir RDF (angl. Resource Description Framework, http://www.w3.org/TR/rdf-syntax-grammar/) standartai.

152. Ontologija (teminis žemėlapis) turi būti aprašyta, naudojant ontologijų arba teminių žemėlapių aprašymo standartus RDF (angl. Resource Description Framework, http://www.w3.org/TR/rdf-syntax-grammar/), OWL (angl. The Web Ontology Language, http://www.w3.org/2004/OWL/#specs), DAML+OIL (angl. DARPA Agent Markup Language + Ontology Interchange Language,

16

Nr. Aprašymashttp://www.w3.org/TR/daml+oil-axioms), ISO Topic Maps (ISO/IEC 13250:2003), XTM (angl. XML Topic Maps, http://www.isotopicmaps.org/sam/sam-xtm/), LTM (angl. Linear Topic Map Notation, http://www.ontopia.net/download/ltm.html).

153. Modulis turi būti suvokiamas kaip programinių priemonių visuma, realizuojanti šias funkcijas:

Automatiškai klasifikuoti tekstus pagal nurodytas temines kategorijas. Analizuojamuose tekstiniuose dokumentuose išskirti ir pažymėti objektus,

kurie:o Įvardinti srities ontologijoje (arba teminiame žemėlapyje),o Nurodyti Sistemos naudotojų,o Dominuoja pagal pasirodymų dažnumą.

Pagal kontekstą įvertinti išskirtų objektų tarpusavio ryšius bei jų stiprumą. Identifikuoti emocinį informacijos atspalvį pagal kontekstą, kuriame

pasirodo objektas. Atlikti objektų kitimo analizę laike. Atvaizduoti objektų dominavimo, objektų ryšių, objektų kitimo ir kitas

analizuojamas savybes tekstinėmis (lentelės, sąrašai) ir grafinėmis (diagramos, tinklinės struktūros, žodžių debesys ir t.t.) priemonėmis.

Aprašyti ontologiją (teminį žemėlapį) su svarbiausiomis srities sąvokomis, objektais, jų tarpusavio sąryšiais, įtraukiant informaciją, susijusi su savivaldybės įmonių, įstaigų darbo sritimis, susijusiais asmenimis, politinėmis nuomonėmis.

Rankiniu bei pusiau automatiniu būdu papildyti/koreguoti ontologijas (teminius žemėlapius).

Atvaizduoti ontologijas (teminius žemėlapius) tekstine ir grafine forma.

154. Semantikos tvarkytojai modulyje turi turėti galimybę nurodyti kelią iki analizuojamo dokumento arba jį importuoti (suderintu .xml formatu).

155. Semantikos tvarkytojai modulyje turi turėti galimybę sugeneruotą informaciją (lenteles, sąrašus, diagramas ir kt.) atvaizduoti Posistemės išoriniams naudotojams.

156. Turi būti realizuotas patogus įrankis ontologijos (teminio žemėlapio) aprašymui skirtas Semantikos tvarkytojams.

157. Semantikos analizės funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

2.5.10. Apklausų posistemės integracija su kitomis sistemomis

Nr. Aprašymas

158. Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemom: Kauno savivaldybė interneto puslapis. Turi būti publikuojama informacija

apie skelbiamas apklausas ir apie įvykdytų apklausų rezultatus; LDAP (Supaprastintos kreipties į katalogus protokolas), skirtas Vidaus

naudotojų identifikavimui; E-demokratijos sistemos posistėmis:

o Identifikavimo posisteme – jeigu norima dalyvauti organizuojamoje Apklausoje Išoriniai naudotojai turi būti nukreipiami į Identifikavimo posistemę o atlikęs identifikaciją turi būti grąžinami į tą vietą iš kurios buvo nukreipti.

o Teisės aktų ir jų projektų posisteme – jeigu organizuojama Apklausa susijusi su teisės aktu ar jo projektu turi būti galimybė Apklausą susieti su reikiamu dokumentu.

17

Nr. Aprašymaso Problemų žemėlapio posisteme – jeigu organizuojama Apklausa

susijusi su problema ar informacija žemėlapyje turi būti galimybė Apklausą susieti su reikiamu tašku žemėlapyje ir į jį patekti.

o Posėdžių valdymo ir transliavimo posistemės Transliavimo dalimi – jeigu dėl Apklausos rezultatų buvo balsuojama taryboje arba apklausa susijusi su Tarybos sprendimu turi būti galimybė Apklausą susieti su konkrečiu tarybos posėdžiu ir jo klausimu.

2.6. Vaizdo konferencijų posistemės funkciniai reikalavimai.

2.6.1. Bendrieji reikalavimai ir naudotojų grupės

Nr. Aprašymas

159. Vaizdo konferencijas turi būti galima organizuoti iš bet kurio kompiuterio turinčio interneto prieigą, vaizdo kamerą ir mikrofoną.

160.

Posistemė turi būti suvokiama kaip kompiuterinių priemonių visuma, realizuojanti šias funkcijas:

Identifikavimas ir atpažinimas; VK organizavimas; Dalyvavimas VK; VK valdymas; Posistemės administravimas.

161. Posistemėje vykstančios VK turi būti indeksuojamos, kad būtu galima vykdyti paieškas pagal pasirinktus kriterijus.

162.

VK Išoriniams naudotojams turi būti galimybė pasirinkti iš kelių vaizdo kokybės tipų: Pirmas – 176 x 144 (prastesnė kokybė). Antras – 352 x 288 (geresnė kokybė). Trečias – 704 x 576 (geriausia kokybė)

163. Transliuojamas vaizdas ir garsas turi būti imami iš VK valdytojo kompiuterio ir transliuojami Posistemės Išoriniams naudotojams.

164. Vaizdo ir garso srautas turi būti transliuojamas „multicast“ būdu. Tai yra kai vienas srautas dalinamas daugeliui naudotojų.

165. Posistemė turi būti pritaikyta šioms naudotojų grupėms (naudotojų vaidmenims):Išoriniai naudotojai:

Išoriniai neidentifikuoti naudotojai – asmenys, kurie nori susipažinti su Posistemėje teikiama informacija bei dalyvauti VK (jeigu VK nustatymai leidžia dalyvauti neidentifikuotiems naudotojams).

Išoriniai identifikuoti naudotojai – fiziniai asmenys, kurie gali prisijungti prie Posistemės ir dalyvauti rengiamoje VK.

Vidaus naudotojai:

VK organizatoriai – savivaldybės darbuotojai, kuriems suteikta teisė naudotis Posistemės ištekliais atliekant VK organizatoriui priskirtas funkcijas (kurti, redaguoti, registruoti VK ir kt.).

VK valdytojai – Tarybos nariai, Savivaldybės administracijos vadovai ir kiti asmenys, kurie bendrauja su gyventojais (valdymo funkcijas gali atlikti ir savivaldybės administracijos darbuotojai padedantys vadovams naudotis

18

Nr. Aprašymas

Posisteme).

Posistemės administratorius – savivaldybės darbuotojas, kuris atlieka Posistemės administravimo darbus.

2.6.2. Identifikavimas ir atpažinimas

Nr. Aprašymas

166. Vidaus naudotojų identifikavimas (tapatumo patikrinimas) turi būti atliekamas tradiciniu (vartotojo vardas/ slaptažodis) identifikavimo būdu.

167.

Vidaus naudotojų slaptažodžiai ir vardai turi būti saugomi naudotojų registre, su tinkamu prieigos kontrolės užtikrinimu ir informacijos šifravimu (slaptažodžiai turi būti šifruojami ir pan.). Sistema turi naudoti naudotojų tapatybės nustatymo informaciją iš naudotojų registro. Turi būti sudaryta galimybė Vidiniams naudotojams prisijungti naudojant LDAP (Supaprastintos kreipties į katalogus protokolą).

168. Registravimosi į Posistemę galimybė turi būti realizuota pirmame Posistemės puslapyje.

169.Naudotojų autorizacijos (leidimas naudotis resursais) funkcionalumas turi būti apibrėžtas pagal naudotojo roles. Tokiu būdu naudotojui suteikiama galimybė naudotis tik tam tikromis funkcijomis, priklausomai nuo jam suteiktų vaidmenų (rolių).

170. Turi būti sudaryta galimybė Išoriniams naudotojams identifikuotis per Sistemos Identifikavimo posistemę.

171.Posistemėje turi būti galimybė gauti Išorinių identifikuotų naudotojų personalinę informaciją iš Sistemos Identifikavimo posistemės Išorinio naudotojo personalinės dalies (vardas, pavardė, foto ir pan.).

2.6.3. Vaizdo konferencijų organizavimas

Nr. Aprašymas

172. VK registravimui turi būti paruošta forma, kurioje prašoma užpildyti laukus, kurie yra būtini norint pradėti VK. Pildymo formoje numatomi informacijos pildymo/pasirinkimo laukai:

Pavadinimas; Tema, VK būdas, Klausimas/klausimai, VK pradžia (data, valanda), VK pabaiga (data, valanda). VK identifikavimas (reikia/nereikia)

VK pildymo forma, dizainas, papildomi laukai galės būti patikslinti Sistemos diegimo metu.

173. Įregistruotų VK paieška/filtravimas Posistemėje turi būti atliekamas nurodant/pasirenkant vieną ar kelis metaduomenų atributus: VK pavadinimą (žodį, jo dalį), VK temą, VK būdą, VK iniciatorių.

VK registravimo metaduomenų atributai gali būti patikslinti Sistemos diegimo metu.VK paieška/filtravimas turi būti vykdomi operatyviuoju būdu (angl. online).

174. Posistemė paieškos rezultatą turi formuoti tame pačiame ekrane, kuriame pasirenkami paieškos/filtravimo kriterijai.

19

Nr. Aprašymas

175. Turi būti sudaryta galimybė Išoriniam naudotojui peržiūrėti registruotas ir paskelbtas VK.

176. VK gali būti įvesta etapais. Tai yra įvedus VK duomenis ir išsaugojus, VK turi būti patalpinama į sąrašą „Ruošiamos VK“. VK organizatorius šiame sąraše turi matyti tik savo paruoštas VK. Atsidarius nebaigtą pildyti VK iš sąrašo „Ruošiamos VK“ galima pratęsti duomenų apie VK pildymą.

177. Suvedus visus duomenis, VK organizatorius turi turėti galimybę konferenciją registruoti konferencijų registre.

178. VK organizatorius pasirinkęs savo pildomą konferenciją iš sąrašo „Ruošiamos VK“ gali ją atsidaryti peržiūrai, redagavimui, spausdinimui ir pašalinimui.

179. VK organizatoriui užregistravus konferenciją, Posistemė automatiškai priskiria konferencijai numerį, pagal Posistemės administratoriaus nustatytas taisykles. Po to konferencija patalpinama į „Registruotų VK sąrašą“. Posistemė šiame sąraše patalpintas konferencijas turi leisti koreguoti o atliktos korekcijos turi būti matomos visiems t.y. turi būti pranešama kas ir kurią vietą keitė (pvz.: Pavardenis keitė „Pradžios datą“ ir pan.). Formuluotės gali būti patikslintos Sistemos diegimo metu.VK organizatorius šiame sąraše turi matyti visas registruotas konferencijas.

180. Posistemės Išoriniams identifikuotiems naudotojams turi būti sudaryta galimybė užsakyti pranešimų siuntimą apie rengiamas VK. Taip pat turi būti galimybė užsisakyti priminimą dėl konkrečios VK. Dieną prieš numatytą VK datą sistema turi siųsti priminimus visiems, kurie užsiregistravo VK priminimą taip pat jiems turi būti siunčiama informacija jeigu buvo atlikti pakeitimai registruotoje VK.

181. Pasibaigus VK, Posistemė automatiškai turi konferenciją perkelti į pasibaigusių konferencijų sąrašą, kur VK tvarkytojai gali atlikti konferencijos redagavimą ir jos publikavimą Sistemoje. Redaguojamos funkcijos galės būti patikslintos Sistemos diegimo metu.

182. VK organizavimo funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

2.6.4. Dalyvavimas vaizdo konferencijoje

Nr. Aprašymas

183. Posistemėje turi būti leidžiama dalyvauti VK visiems Išoriniams naudotojams. Priklausomai nuo konferencijos būdo Išoriniams naudotojams gali reikėti atlikti identifikaciją.

184. Sistemoje turi būti galimybė organizuoti dviejų skirtingų tipų VK: Pirmas būdas – Posistemės Išoriniams naudotojams suteikiama galimybė

pateikti klausimus tik raštu o VK valdytojo pasirinktų klausimų atsakymai pateikiami vaizdu ir garsu, raštu.

Antras būdas – tai Pirmo būdo papildymas suteikiant galimybę Posistemės Išoriniams naudotojams užduoti klausimus vaizdo konferenciniu būdu t.y. naudojant WEB kamerą ir mikrofoną.

185. Posistemėje turi būti galimybė organizuoti VK abiem būdais kartu arba kiekvienu būdu atskirai. Jeigu organizuojama abiem būdais Išoriniui naudotojui turi būti suteikiama galimybė pasirinkti, kuriuo būdu jis nori jungtis.

186. Jeigu VK organizuojama be identifikacijos, tai Išorinio naudotojo, kuris jungiasi prie VK turi būti prašoma įvesti Vardą ir Pavardę. Įvesti duomenys turi būti rodomi prisijungusių Išorinių naudotojų sąraše. Jeigu vykdoma identifikacija – prisijungusių Išorinių naudotojų sąraše turi būti rodomi duomenys (Vardas, Pavardė) gaunami identifikavimo metu.

20

Nr. Aprašymas

187. VK valdytojas turi turėti galimybę pašalinti iš VK nepageidaujamus Išorinius naudotojus. Pašalintam Išoriniui naudotojui turi būti parodomas pranešimas dėl kokių priežasčių jis buvo pašalintas ir kada vėl galės prisijungti.

188. Vieno dalyvio pateikiamų klausimų skaičius neturi būti ribojamas, tačiau turi būti numatytos galimybės reguliuoti klausimų srautus. Turi būti galimybė nustatyti, kas kiek laiko galima užduoti klausimus, kiek klausimų galima pateikti ir pan. Reguliavimo parametrai gali būti patikslinti Sistemos diegimo metu.

189. Turi būti rodomas bendras prisijungusių prie VK Išorinių naudotojų skaičius. Turi būti vedama statistika kiek buvo užduota klausimų, kiek atsakyta, kiek netinkamų ir pan. Statistikos kriterijai gali būti patikslinti Sistemos diegimo metu.

190. Turi būti numatyta galimybė sustabdyti VK ir ją pratęsti kitą dieną. Sustabdytos VK turi būti talpinamos į nebaigtų VK sąrašą. Pratęsiant VK turi būti galimybė perkelti pateiktus klausimus raštu išlaikant jų pateikimo eilę ir informaciją kas juos pateikė.

191. Dalyvavimo VK funkcinis komponentas turi būti valdomas ir konfigūruojamas naršyklės pagalba ir turi būti paremtas vartotojo sąsaja (t.y. nereikalaujant jokios specifinės įdiegtos programinės įrangos kliento pusėje).

1.1.1.1. Pirmas būdas

Nr. Aprašymas

192. Išoriniams naudotojams prisijungusiems prie VK turi būti rodoma: Vaizdo grotuvas – su galimybe padidinti ar sumažinti garsą, sustabdyti ar

paleisti vaizdą, išdidinti vaizdą per visą ekraną (grotuvas turi būti lengvai suderinamas su populiariausiomis naršyklėmis, iš Išorinio naudotojo neturi būti reikalaujama įdiegti jokios specifinės, mokamos ar kitaip ribojamos programinės įrangos).

Paklausimo forma – tai standartinė forma kurios pagalba Išorinis naudotojas gali užduoti klausimus. Turi būti teksto įvedimo laukas, įvesto teksto peržiūros galimybė ir patvirtinimo galimybė. Formos maksimalus simbolių skaičius galės būti patikslintas Sistemos diegimo metu.

Neatsakytų klausimų sąrašas – Išoriniam naudotojui patvirtinus klausimą jis turi būti matomas visiems naudotojams ir atsirasti klausimų sąraše.

Atsakytų klausimų sąrašas – atsakyti klausimai turi būti perkeliami iš neatsakytų klausimų sąrašo ir patalpinami į atsakytų klausimų sąrašą. Šį sąrašą peržiūrėti gali visi naudotojai.

Dalyvių sąrašas – turi būti pateikiamas visas prisijungusių Išorinių naudotojų sąrašas, kuriame prie kiekvieno dalyvio vardo ir pavardės turi būti rodomas skaičius kiek dalyvis uždavė klausimų. Paspaudus ant dalyvio turi būti matoma dalyvio personalinė informacija (el. pašto adresas, nuotrauka jeigu įkelta ir kita informacija gaunama iš Sistemos Identifikavimo posistemės Išorinio naudotojo personalinės dalies).

Taip pat turi būti rodoma – VK tema ir pavadinimas, Tarybos nario ar Administracijos vadovo vardas ir pavardė, planuojama VK trukmė ir likęs laikas iki konferencijos pabaigos ir pan.

Tikslus dalių išdėstymas ir dizainas galės būti patikslintas Sistemos diegimo metu.

193. Klausimų atsakymo vykdymas: Iš Neatsakytų klausimų sąrašo pasirenkamas klausimas. Pažymėtas klausimas turi būti išskiriamas iš kitų, Išoriniams naudotojams turi

būti aiškiai parodoma į kurį klausimą dabar vyksta atsakymas. Atsakančiajam į klausimus turi būti galimybė pažymėti klausimą, kaip

netinkamą. 21

Nr. Aprašymas Netinkamas klausimas turi būti perkeliamas iš Neatsakytų klausimų sąrašo į

Pašalintų klausimų sąrašą.Klausimų atvaizdavimas, šalinimas ir kiti dizaino elementai turės būti suderinti Sistemos diegimo metu.

1.1.1.2. Antras būdas

Nr. Aprašymas

194. Techninės įrangos tikrinimui ir prisijungimui turi būti toks funkcionalumas: Prieš jungiantis į VK Išoriniam naudotojui, Posistemėje turi būti galimybė

patikrinti ar jo turima vaizdo kamera ir mikrofonas veikia. Atliekant įrangos testavimą Posistemė turi paprašyti po signalo atlikti vaizdo ir

garso perdavimą. Atlikus testavimą turi būti galimybė peržiūrėti ir perklausyti testavimo

rezultatus. Išoriniam naudotojui peržiūrėjus testavimo rezultatus turi būti rodomas

pranešimas, kuriame būtų pasirinkimas:o Įeiti į VK su WEB kamera (pvz.: „Jeigu girdėjote ir matėte savo žinutę

prašome užeiti“)o Tikrinti techninę įrangą (pvz.: „Jeigu nematote savo vaizdo ir negirdite

savo žinutės prašome patikrinti savo įrangą ir bandyti dar kartą“) o Įeiti į VK įprastiniu būdu.

Išoriniam naudotojui prisijungus prie VK, testavimo rezultatai (vaizdas ir garsas) turi būti ištrinami iš Posistemės.

Jeigu Išoriniai naudotojai prisijungė prie VK su WEB kamera ir atėjus klausimo eilei jų vaizdas ir garsas neperduodamas turi būti galimybė išjungti klausiantįjį. Išjungus, jam turi būti pranešama, kad nėra gaunamas vaizdas ir garsas ir siūloma prisijungti įprastiniu būdu.

195. Išoriniams naudotojams prisijungusiems prie VK turi būti rodoma: Vaizdo grotuvas – su galimybe padidinti ar sumažinti garsą, sustabdyti ar

paleisti vaizdą, išdidinti vaizdą per visą ekraną (grotuvas turi būti lengvai suderinamas su populiariausiomis naršyklėmis, iš naudotojo neturi būti reikalaujama įdiegti jokios specifinės, mokamos ar kitaip ribojamos programinės įrangos).

Dalyvio vaizdo grotuvas – pagal nutylėjimą grotuve turi būti rodomas sutartas paveikslėlis (administratorius turi turėti galimybę jį keisti), atėjus dalyvio klausimo eilei turi būti įjungiamas jo vaizdas ir garsas.

Paklausimo forma – tai standartinė forma kurios pagalba Išorinis naudotojas gali užduoti klausimus. Turi būti teksto įvedimo laukas, įvesto teksto peržiūros galimybė ir patvirtinimo galimybė. Formos maksimalus simbolių skaičius galės būti patikslintas Sistemos diegimo metu.

Neatsakytų klausimų sąrašas – Išoriniam naudotojui patvirtinus klausimą jis turi būti matomas visiems naudotojams ir atsirasti klausimų sąraše.

Atsakytų klausimų sąrašas – atsakyti klausimai turi būti perkeliami iš neatsakytų klausimų sąrašo ir patalpinami į atsakytų klausimų sąrašą. Šį sąrašą peržiūrėti gali visi naudotojai.

Dalyvių sąrašas – turi būti pateikiamas visas prisijungusių Išorinių naudotojų sąrašas, kuriame prie kiekvieno dalyvio vardo ir pavardės turi būti rodomas skaičius kiek dalyvis uždavė klausimų. Paspaudus ant dalyvio turi būti matoma dalyvio personalizuota informacija (el. pašto adresas, nuotrauka jeigu įkelta ir kita informacija gaunama iš E-demokratijos sistemos identifikavimo dalies).

Taip pat turi būti rodoma – VK tema ir pavadinimas, Tarybos nario ar 22

Nr. AprašymasAdministracijos vadovo vardas ir pavardė, planuojama VK trukmė ir likęs laikas iki konferencijos pabaigos ir pan.

Tikslus dalių išdėstymas ir dizainas galės būti patikslintas Sistemos diegimo metu.

196. Klausimų atsakymo vykdymas: VK valdytojai turi galėti pasirinkti į kuriuos klausimus atsakinėti pirmiau:

o Įprastinius;o Užduodamus VK būdu.

Visi norintys paklausti VK būdu, turi registruotis į eilę spausdami registracijos mygtuką.

Turi būti rodomas VK būdu klausti užsiregistravusių dalyvių sąrašas. Įprastų klausimų atsakymai vyksta analogiškai kaip ir pirmuoju VK būdu. VK valdytojui turi būti suteikta galimybė riboti klausiančiųjų VK būdu laiką

t.y. VK nustatymuose turi būti galimybė nurodyti klausimui skirtą laiką, įjungti ar išjungti šią funkciją. Jeigu ši funkcija įjungiama apie klausimui skirtą laiką ir laiką iki klausimo pabaigos turi būti informuojami visi VK dalyviai.

VK valdytojui turi būti galimybė nutraukti klausimą ir išjungti klausiančiojo dalyvio vaizdą ir garsą. Išjungus turi būti pranešama, kad klausiantysis buvo išjungtas ir nurodoma priežastis. Priežasčių formuluotės galės būti tikslinamos Sistemos diegimo metu.

Klausimų atvaizdavimas, šalinimas ir kiti dizaino elementai galės būti patikslinti Sistemos diegimo metu.

2.6.5. Vaizdo konferencijų valdymas

Nr. Aprašymas

197. Vaizdo konferencijų valdymui turi būti numatytas toks funkcionalumas: VK pradėjimas, VK pabaigimas, VK publikavimas, VK susiejimas, Multimedios rodymas VK metu, Apklausų vykdymas VK metu, VK testavimas.

198. Vaizdo konferencijos pradėjimas – Pradedant VK turi būti galimybė pasirinkti: Pradėti naują VK (pasirenkant ją iš registruotų VK sąrašo). Pratęsti sustabdytą VK (pasirenkant ją iš nebaigtų VK sąrašo).

199. Vaizdo konferencijos pabaigimas – Pabaigiant VK turi būti galimybė pasirinkti: Užbaigti VK ir ją paruošti publikavimui. Užbaigti VK su galimybe ją pratęsti.

200. Vaizdo konferencijos publikavimas – turi būti galimybė pasirinkti: Redaguoti pabaigtą VK. Publikuoti įvykusią VK ir ją patalpinti į publikuojamų VK sąrašą. VK esančios

šiame sąraše negali būti redaguojamos. Neberodyti VK publikuojamų VK sąraše. Neberodomos VK neturi būti

ištrinamos iš Posistemės. Archyvuoti neberodomas VK (pagal mėnesius, ketvirčius, metus) Kiekviename punkte turi būti galimybė atlikti paieškas.

201. Vaizdo konferencijos susiejimas – turi būti galimybė susieti planuojamas, įvykusias ir publikuojamas VK su kitomis Sistemos posistemėmis taip, kaip tai yra nurodyta 2.6.7 skyriuje.

23

Nr. Aprašymas

202. Multimedios rodymas vaizdo konferencijų metu – VK metu turi būti galimybė rodyti multimedios elementus:

Nuotraukas (JPG, BMP, GIF ir kitais formatais); Dokumentus (PDF, doc, docx ir kitais formatais); Prezentacijas (PPT ir kitais formatais). Nuorodos į internetinius puslapius (puslapiai turi atsidaryti naujuose languose.)

203. Apklausų vykdymas vaizdo konferencijų metu – Esant poreikiui VK valdytojas turi turėti galimybę paskelbti apklausą. Apklausos paskelbimui turi būti tokios galimybės:

Paskelbti ar sustabdyti apklausą. Pasirinkti apklausos tipą („Taip/Ne“; „Už/Prieš/Susilaikau“). Įvesti apklausos (klausimo) pavadinimą (tekstą). Nustatyti apklausos trukmę. Rezultatų atvaizdavimas. Pasibaigus nustatytam laikui visiems dalyviams turi

būti pateikiami apklausos rezultatai. Jeigu apklausa buvo nutraukta rezultatai neatvaizduojami. Rezultatų atvaizdavimas galės būti patikslintas Sistemos diegimo metu.

Paskelbus apklausą išoriniams naudotojams turi būti sudaromos galimybės atlikti balsavimą.

204. VK testavimas – prieš pradedant VK turi būti galimybė atlikti techninės įrangos testavimą. VK valdytojas turi galėti patikrinti ar posistemė gauną vaizdą ir garsą iš naudojamos techninės įrangos.

2.6.6. Vaizdo konferencijų posistemės administravimas

Nr. Aprašymas

205. Posistemės administratorius turi turėti galimybę suteikti teises Vidaus naudotojams atlikti kitų Vidaus naudotojų funkcijas (turi būti realizuotas darbuotojų pavadavimas).

206. Posistemės administratorius turi turėti galimybę registruoti, koreguoti, ištrinti VK organizatorius.

207. Posistemės administratorius turi turėti galimybę priskirti VK organizatoriui konferencijas, kurių duomenis jis galės tvarkyti.

208. Posistemės administratorius turi turėti galimybę archyvuoti įvykusias ir paskelbtas konferencijas.

209. Posistemės administratorius turi turėti galimybę nustatyti terminą po kurio Posistemė automatiškai atliks įvykusių konferencijų archyvavimą.

210. Posistemės administratoriui turi būti suteikta galimybė atlikti pilną Posistemės testavimą.

211. Posistemės administratorius turi turėti galimybę nustatyti laiką, po kurio pašalintas VK dalyvis vėl gali prisijungti. Taip pat turi turėti galimybę formuoti, redaguoti pašalinio priežasčių sąrašą.

212. Posistemei galioja bendri Sistemos administravimo reikalavimai, kurie pateikiami 2.11 skyriuje.

2.6.7. Vaizdo konferencijų posistemės integracija su kitomis sistemomis

Nr. Aprašymas

213. Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemom: LDAP (Supaprastintos kreipties į katalogus protokolas), skirtas Vidaus naudotojų

identifikavimui; E-demokratijos sistemos posistėmis:

Identifikavimo posisteme – norint dalyvauti VK (priklausomai nuo VK būdo),

24

Nr. Aprašymasturi būti galimybė atlikti identifikaciją.

Teisės aktų ir jų projektų posisteme – jeigu VK organizuojama dėl Teisės akto ar jo projekto, turi būti galimybė susieti VK su teisės aktu ar projektu, nukreipiant išorinį naudotoją tiesiai į reikiamą dokumentą.

Problemų žemėlapio posisteme – jeigu VK organizuojama dėl problemos ar informacijos žemėlapyje, turi būti galimybė susieti VK su problema ar informacija žemėlapyje, nukreipiant išorinį naudotoją tiesiai į reikiamą tašką žemėlapyje.

2.7. Posėdžių valdymo ir transliavimo posistemės funkciniai reikalavimai

2.7.1. Bendrieji reikalavimai

Nr. Aprašymas

214. Posistemė turi būti suderinta ir stabiliai veikti su DIS DCS-6000 balsavimo-diskusijų sistemos technine įranga, kuri detalizuojama Sistemos techninės ir funkcinės specifikacijos priedėlyje.

215. Posistemė turi būti suvokiama kaip kompiuterinių priemonių visuma, realizuojanti dvi pagrindines funkcijų grupes:

Posėdžių valdymo dalis. Transliavimo į internetą dalis, kuri skirstoma į:

o Transliavimo valdymą,o Transliacijų peržiūrą.

216. Posistemė turi būti realizuota taip, kad Posėdžių valdymą ir Transliavimo valdymą būtu galima atlikti iš skirtingų kompiuterių.

217. Pagrindiniai reikalavimai Posistemei: Vartotojo sąsaja turi būti lietuvių kalba;

Reikalavimai Posėdžių valdymo daliai: Naudojama architektūra turi būti – klientas/serveris; Visi duomenys turi būti saugomi reliacinėje duomenų bazėje; Galimybė daryti duomenų bazės kopijas ir atstatymą iš kopijų (backup);

Reikalavimai Transliavimo valdymo daliai: Galimybė transliuoti realiu laiku vaizdą ir garsą (angl. live streaming); Balsavimo rezultatų atvaizdavimas internete realiu laiku; Automatinis vaizdo ir garso indeksavimas (pagal laiką, datą, kalbėtoją,

klausimą ir kt.). Posėdžių publikavimas ir jų šalinimas;

Reikalavimai Transliacijų peržiūros daliai: Posėdžių paieškos galimybės (pagal Kalbėtoją, posėdžio datą,

pavadinimą, klausimą ir kt.); Posėdžių peržiūros galimybės (viso posėdžio ar pasirinktų klausimų).

218. Posėdžių valdymo dalis turi veikti MS WINDOWS aplinkoje. Balsavimo ir diskusijų techninė įranga valdoma per RS232 sąsają naudojant COM1 ir COM2 jungtis. Vartotojo sąsają turi sudaryti du atskiri langai, kurie (vaizdo plokštės turinčios du video išėjimus pagalba) yra išvedami į kelis skirtingus monitorius:

Programos valdymo langas išvedamas į sekretoriato monitorių (Nr. 1); Posėdžio eigos langas atvaizduojamas sieniniuose ir pirmininkaujančiojo

monitoriuose (Nr. 2-3-4)

219. Transliacijų peržiūra turi veikti interneto naršyklės lange bei turi būti pasiekiama ir veikti stabiliai su visomis populiariausiomis naršyklėmis (Internet Explorer, Mozilla Firefox, Google Chrome, Opera ir kt.).

25

2.7.2. Posėdžių valdymo dalis

Nr. Aprašymas

220. Posėdžių valdymo dalis turi būti sudaryta iš tokių modulių: Administravimo modulis. Valdymo modulis.

1.1.1.3. Administravimo modulis

Nr. Aprašymas

221. Administravimo modulyje turi būti realizuotas toks funkcionalumas: Posistemės valdymas:

o Konfigūravimas,o Testavimas,

Darbo vietų paruošimas, Tarybos narių informacijos įvedimas, saugojimas, redagavimas, Posėdžio parametrų nustatymas, Darbotvarkės sudarymas, Posėdžių ataskaitos.

222. Administravimo modulyje turi būti galimybė atlikti pilną Posistemės konfigūravimą ir testavimą. Turi būti galimybė patikrinti ar visi mikrofonai veikia.

223. Darbo vietų paruošimo dalyje turi būti realizuotas toks funkcionalumas:Jeigu registracija vykdoma įprastiniu būdu: Šioje Posistemės dalyje turi būti galimybė kiekvienam tarybos nariui priskirti

darbo vietą. Turi būti galimybė patikrinti koks tarybos narys priskirtas kokiai darbo vietai. Turi būti galimybė padaryti neaktyvia darbo vietą (neaktyvi darbo vieta negali

registruotis (kalbėjimui, balsavimui) ir salės schemoje turi būti rodoma kita spalva).

Jeigu registracija vykdoma kortelių pagalba: Turi būti galimybė kiekvienam tarybos nariui priskirti registracijos korteles. Tarybos nariui darbo vieta nepriskiriama jis gali registruotis kortele bet

kurioje darbo vietoje. Turi būti galimybė patikrinti kokia yra tarybos nario paskutinė darbo vieta. Jeigu darbo vietoje nėra įstatyta kortelė tokia vieta turi būti neaktyvi (neaktyvi

darbo vieta negali registruotis (kalbėjimui, balsavimui) ir salės schemoje turi būti rodoma kita spalva)

Turi būti galimybė importuoti paruoštą failą su tarybos nariais priskiriant jiems darbo vietas ir/arba kortelių numerius.

224. Tarybos narių informacijos dalyje turi būti realizuotas toks funkcionalumas: Naujų narių įtraukimas.

o Identifikacinio numerio priskirimas.o Vardo ir pavardės įvedimas.o Statuso suteikimas (pirmininkaujantis ar narys).o Kortelės numerio priskirimas.o Nuotraukos įkėlimas.o Ir kt.

Esamų narių redagavimas ir šalinimas.Turi būti galimybė importuoti paruoštą failą su tarybos nariais.

225. Posėdžio parametrų nustatymuose turi būti galimybė keisti šiuos parametrus: Kvorumas – minimalus narių skaičius, kad būtų vykdomas balsavimas. Dauguma atviram arba slaptam balsavimui – nurodoma reikšmė.

26

Dauguma pritarimui – nurodoma reikšmė. Registracijos balsavimui rėžimas – pasirenkama paprastas ar kortelėmis. Registracijos balsavimui laikas (paprastas rėžimas) – laikas skirtas

užsiregistravimui balsavimui (sekundės). Balsavimo laikas – laikas skirtas balsavimui (sekundės). Diskusijos laikas – laikas skirtas diskusijoms (pagal Tarybos darbo

reglamentą 3 minutės). Klausimo laikas – laikas skirtas klausimams (pagal Tarybos darbo reglamentą

1 minutė). Registracijos diskusijai laikas – nurodomas sekundėmis. Registracijos klausimams laikas – nurodomas sekundėmis. Maksimalus narių skaičius diskusijai – nurodomas maksimalus skaičius kiek

gali užsiregistruoti diskusijoms. Diskusijos/klausimų registracijos sąrašo atvaizdavimo laikas – nurodomas

laikas (sekundės). Automatinis mikrofono išjungimo diskusijų/klausimų rėžime laikas – turi būti

galimybė išjungti šią funkciją, laikas nurodomas sekundėmis.

226. Posėdžio darbotvarkės paruošimui turi būti realizuoti du būdai: Naudoti Teisės aktų ir jų projektų posistemėje parengtą darbotvarkę, kuri turi

būti automatiškai įkeliama, kai ji suformuojama Teisės aktų ir jų projektų posistemėje. Turi būti galimybė redaguoti šią darbotvarkę.

Rankiniu būdu sukurti darbotvarkę.

227. Posėdžių ataskaitų dalyje turi būti toks funkcionalumas: Ataskaitų formavimas, Ataskaitų spausdinimas, Ataskaitų eksportavimas.

228. Posėdžių ataskaitos turi būti skirstomos į tokius tipus: Balsavimų ataskaitos, Registracijų ataskaitos, Narių dalyvavimo posėdžiuose ataskaita.

229. Balsavimų ir registracijų ataskaitas turi būti galimybė sudaryti kiekvienam posėdžio klausimui. Balsavimų ir registracijų ataskaitos turi būti sudaromos pagal su KMSA suderintą formą. Slaptų balsavimų ataskaitose neturi matytis koks narys kaip balsavo, turi būti rodoma tik suvestinė informacija.

230. Turi būti galimybė suformuoti narių dalyvavimo posėdžiuose ataskaitą (vieno arba kelių posėdžių):

Jeigu narys dalyvavo svarstant ne mažiau kaip 1/2 visų vieno posėdžio darbotvarkės klausimų, laikoma, kad jis dalyvavo posėdyje. Jeigu nevykdoma ši sąlyga toks narys ataskaitoje turi būti paryškinamas.

Nariai privalo dalyvauti ne mažiau kaip 1/2 posėdžių. Jeigu nevykdoma ši sąlyga toks tarybos narys ataskaitoje turi būti paryškinamas.

Turi būti galimybė suformuoti Klausimų ir Diskusijų (kartu ir atskirai) rėžime kalbėto laiko suvestinę t.y. kiek laiko kuris narys kalbėjo.

231. Visas suformuotas ataskaitas turi būti galimybė atspausdinti, eksportuoti į .pdf, .doc, .xls, .xml formatus. Turi būti realizuota galimybė vienu paspaudimu atspausdinti visas vieno posėdžio balsavimų ataskaitas.

1.1.1.4. Valdymo modulis

Nr. Aprašymas

232. Valdymo modulis turi būti naudojamas: Posėdžio eigos valdymui (pradėjimas, sustabdymas, pratęsimas). Išrinkti svarstomą darbotvarkės klausimą.

27

Valdyti diskusijas, klausimus, balsavimus. Valdyti atvaizdavimą monitoriuose (rezultatų išvedimas, klausimų, diskusijų

eilės atvaizdavimas, posėdžio dalyvių informacijos išvedimas ir kt.).

233. Posėdžio pradėjimas – Pasirinkus šią funkciją turi būti galimybė pasirinkti iš Administravimo modulyje sukurtų posėdžių. Pradėjus posėdį, jo valdymui turi būti tokios funkcijos:

Registracijos rėžimas, Balsavimo rėžimas, Klausimų rėžimas, Diskusijų rėžimas, Posėdžio pabaigimo, Posėdžio pratęsimo, Pasisakymų rėžimas.

234. Registracijos rėžimo funkcijos: Pasirinkus šią funkciją turi būti vykdoma registracija (būdas ir laikas skirtas

registracijai nurodomas Posėdžio parametrų nustatymuose). Registracijos metu monitoriuose Nr. 2-3-4 turi būti parodomas salės planas,

turi būti pranešama, kad vyksta registracija ir rodomas likęs laikas iki registracijos pabaigos.

Registracijos vykdymas:o Jeigu registracijos būdas paprastas – tai nariui paspaudus registracijos

mygtuką salės plane jo darbo vieta turi pakeisti spalvą į „žalią“. o Jeigu registracijos būdas kortelėmis – tai sistema turi iš karto parodyti

įstatytas korteles ir tų narių darbo vietas pažymėti „žalia“ spalva. Turi būti rodomas bendras užsiregistravusiųjų narių skaičius. Turi būti galimybė nutraukti registraciją. Pasibaigus registracijai turi būti pranešama, kad laikas registracijai baigėsi. Jeigu užsiregistravusių narių skaičius nesudaro kvorumo turi būti parodomas

pranešimas „Nėra kvorumo“. Neesant kvorumui neturi būti galimybės įjungti Balsavimo rėžimo.

235. Balsavimo rėžimo funkcijos: Turi būti galimybė pasirinkti klausimą iš darbotvarkės. Turi būti galimybė papildyti darbotvarkę posėdžio metu. Pasirinkti rėžimą galima tik tada, jeigu prieš tai buvo atlikta Registracijos

procedūra (vienai registracijai galimas tik vienas balsavimas) ir užsiregistravo reikiamas narių skaičius kvorumo užtikrinimui.

Kitu atveju į visus monitorius turi būti išvedamas pranešimas:o „Reikia registracijos“ (kai neatlikta registracijos procedūra) o „Nėra kvorumo“ (kai užsiregistravo per mažai narių).

Jeigu šios sąlygos įvykdytos galima tęsti balsavimo procedūrą. Turi būti galimybė pasirinkti vieną iš balsavimo tipų:

o Atviras balsavimas, o Slaptas balsavimas, o Pritarimas

236. Klausimų rėžimo funkcijos: Pasirinkus šį rėžimą visi tarybos nariai gali registruotis klausimams, tam jie

turi spausti mygtuką „mikrofonas“. Registracijai skirtas laikas yra nurodomas nustatymų skiltyje. Pasibaigus registracijos laikui patekti į kalbėtojų sąrašą nebegalima. Užsiregistravus į kalbėtojų sąrašą ir paspaudus mygtuką „mikrofonas“ galima

pasišalinti iš sąrašo, jeigu tai padaroma iki registracijos laiko pabaigos vėl galima spausti mygtuką ir patekti į kalbėtojų sąrašą.

Vienu klausimu kalbėti galima tik vieną kartą. Jeigu nario mikrofonas yra 28

įjungiamas daugiau jis patekti į eilę šiuo klausimu nebegali. Maksimalus kalbėjimo laikas nurodomas nustatymų skiltyje. Turi būti galimybė įjungti pasirinktą mikrofoną iš neesančių mikrofonų

kalbėtojų sąraše. Įjungus pasirinktą mikrofoną užregistruotas kalbėtojų sąrašas neturi pasikeisti o įjungtam mikrofonui turi galioti toks pats kalbėjimo laiko limitas kaip ir visiems esantiems kalbėtojų sąraše.

Pasibaigus registracijos laikui turi būti pranešama apie registracijos laiko pabaigą.

Pasibaigus kalbėtojo laikui (nurodytam nustatymų skiltyje) turi būti pranešama apie tai o praėjus nustatytam laikui (nurodytam nustatymų skiltyje) mikrofonas turi būti automatiškai išjungiamas. Automatinį mikrofono išjungimo rėžimą turi būti galima išjungti.

Savivaldybės kontrolieriaus, Vyriausybės atstovo ir Administracijos direktoriaus mikrofonams registracijos ir kalbėjimo laiko apribojimai neturi galioti. Jų mikrofonus turi būti galimybė įjungti bet kuriuo metu.

Pirmininkaujančiajam klausimams ir diskusijoms registruotis nereikia, jis savo mikrofoną gali įjungti, bet kuriuo metu.

237. Diskusijų rėžimas vyksta analogiškai kaip ir Klausimų rėžimas, tik registracijos ir kalbėjimo laikai nurodomi skirtingi Nustatymų skiltyje.

238. Posėdžio pabaigimo funkcijos: Pabaigus posėdį turi būti fiksuojama posėdžio pabaigos data ir tikslus laikas. Jeigu posėdis buvo pratęstas tai posėdžio pabaigos data yra paskutinė

posėdžio pabaigimo data.

239. Posėdžio pratęsimo funkcijos: Posėdžių pratęsimo skaičius neturi būti ribojamas. Pratęsus posėdžius ir vykdant balsavimus turi būti fiksuojama tiksli balsavimo

data.

240. Pasisakymų rėžimo funkcijos: Šis rėžimas įjungiamas, kai suteikiamas posėdžio svečiams žodis nuo šoninio

mikrofono, kuris nėra valdomas posistemės pagalba. Bet kurioje posėdžio vietoje turi būti galimybė įjungti Pasisakymų rėžimą. Turi būti galimybė nustatyti kalbėjimo laiką, jį paleisti ir sustabdyti. Ekranuose turi būti rodomas kalbėtojo laikas. Pasibaigus kalbėjimo laikui turi būti apie tai pranešama. Įjungus šį rėžimą prieš tai buvę rėžimai (Klausimai, Diskusijos) turi

nesimatyti tačiau neturi išsijungti (pvz.: esant diskusijų rėžime įjungus pasisakymų rėžimą nebeturi matytis užsiregistravusių narių eilės o išjungus pasisakymų rėžimą eilė turi pasirodyti nepakitus).

1.1.1.5. Atvaizdavimo funkciniai reikalavimai

Nr. Aprašymas

241. Neutrali padėtis – kai nėra įjungtas joks rėžimas, tuo metu ekranuose turi būti rodomas skaitmeninis laikrodis.

242. Registracijos balsavimams atvaizdavimas: Pradėjus registraciją ekranuose turi būti pranešama apie registracijos pradžią. Turi būti rodomas likęs laikas iki registracijos pabaigos. Vykstant registracijai turi būti rodomas salės planas, kuriame

užsiregistravusių narių pakeitimai turi būti atvaizduojami iškarto arba atnaujinami kas 2 s.

Pasibaigus registracijos laikui turi būti pranešama kiek narių užsiregistravo, jeigu nesusidaro kvorumas turi būti pranešama, kad nėra kvorumo.

Turi būti galimybė nutraukti registraciją.29

Nutraukus registraciją turi būti grįžtama į Neutralią padėtį.

243. Balsavimo eigos atvaizdavimas: Pradėjus balsavimo procedūrą ekrane turi būti rodoma, kad vyksta

balsavimas. Turi būti rodomi duomenys iš darbotvarkės (Klausimo nr., pavadinimas ir

pan.) Kiek laiko likę iki balsavimo pabaigos. Turi būti galimybė nutraukti balsavimą. Nutraukus balsavimą turi būti grįžtama į neutralią padėtį. Naujam balsavimui turi būti vykdoma nauja registracija.

244. Balsavimo rezultatų atvaizdavimas: Pasibaigus balsavimui ekrane turi būti pranešama, kad balsavimas baigtas. Turi būti galimybė pasirinkti tarp dviejų skirtingu rezultatų atvaizdavimo

būdų:o A būdas – salės schema su visomis darbo vietomis, pažymėtomis, kaip

kuris narys balsavo (Už – žalia, Prieš – raudona, Susilaikė – geltona, Registravosi, bet nebalsavo – mėlyna). Šis būdas nerodomas įvykus slaptam balsavimui.

o B būdas – skaitinė išraiška rodoma kiek Registravosi, Balsavo, Už, Prieš, Susilaikė.

Turi būti galimybė pasirinkti kiekvieną atskirai arba abu būdus kartu. Abiem atvejais turi būti informuojama koks balsavimo rezultatas (priimta,

nepriimta, balsai pasiskirstė po lygiai). Jeigu balsuojant balsai pasiskirstė po lygiai turi būti tikrinama ar balsavo

Meras (pirmininkaujantis), jeigu balsavo tai sprendimas toks kaip balsavo Meras (Už – priimtas, Prieš, Susilaikė – nepriimtas), jeigu nebalsavo tai sprendimas nepriimtas.

Balsavimo rezultatų skaičiavimo būdai: o Atviram balsavimui – Klausimas priimtas, jeigu „Už“ balsavo daugiau

nei „dauguma atviram balsavimui“ (reikšmė nurodoma Nustatymų skiltyje)

o Slaptam balsavimui – Klausimas priimtas, jeigu „Už“ balsavo daugiau nei „dauguma slaptam balsavimui“

o Pritarimui – Klausimas priimtas, jeigu „Už“ balsavo daugiau nei „dauguma pritarimui“

Turi būti galimybė nutraukti balsavimo rezultatų rodymą. Nutraukus balsavimo rezultatų rodymą turi būti grįžtama į neutralią padėtį. Esant Neutraliai padėčiai turi būti galimybė atvaizduoti paskutinio balsavimo

rezultatus pasirenkant tarp A ir B būdų arba rodyti abu kartu.

245. Klausimų ir diskusijų atvaizdavimas: Prasidėjus registracijai klausimams ar diskusijoms turi būti rodomas laikas

likęs iki registracijos pabaigos. Ekranuose turi būti rodoma klausimams ar diskusijoms užsiregistravusių

narių eilė (eilės nr., vardas ir pavardė). Įjungus nario mikrofoną ekranuose turi būti rodoma kas kalba ir kiek laiko

lieka iki kalbėjimo pabaigos. Turi būti galimybė:

o Išjungti Klausimų ar Diskusijų rėžimą.o Įjungti sekantį (pirmą) narį esantį eilėje.o Įjungti pasirinktą narį eilėje.o Išjungti kalbančiojo mikrofoną.o Pašalinti pasirinktą narį iš eilės.

30

o Įjungti nario, neesančio sąraše, mikrofoną. Klausimų ir diskusijų rėžimai skiriasi tik kalbėjimo ir registracijos laikais.

246. Pasisakymų atvaizdavimas: Įjungus pasisakymų rėžimą į ekranus turi būti išvedamas kalbėtojo laikas,

pasibaigus skirtam laikui jis turi pakeisti spalvą, bet tęstis toliau. Turi būti galimybė:

o Nurodyti kalbėjimo laiko trukmę.o Pradėti kalbėjimo laiko skaičiavimą.o Sustabdyti kalbėjimo laiką.o Išjungti pasisakymų rėžimą.

2.7.3. Transliavimo dalis

1.1.1.6. Transliavimo valdymas

Nr. Aprašymas

247. Posistemėje iš posėdžių salės turi būti galimybė transliuoti vaizdą ir garsą internetu realiu laiku.

248. Transliavimo valdymo dalies funkcijos turi būti tokios: Vaizdo ir garso transliavimas internetu

o Pradėjimas,o Sustabdymas,o Pabaigimas.

Darbotvarkės ir klausimo atvaizdavimas. Kalbančiojo vardo ir pavardės atvaizdavimas. Balsavimo rezultatų atvaizdavimas realiu laiku. Posėdžių įrašų talpinimas / šalinimas. Automatinis vaizdo ir garso indeksavimas.

249. Transliavimo į internetą dalis turi veikti kartu su Posėdžių valdymo dalimi arba atskirai (tik garso ir vaizdo transliavimas kai nevyksta tarybos posėdžiai).

250. Transliavimo į internetą dalis turi indeksuoti vaizdą ir garsą pagal numatytus parametrus (dalyvio vardą, pavardę, klausimo numerį, laiką ir datą, ir pan.).

251. Posistemėje turi būti numatyta galimybė įjungti papildomą kamerą skirta vertimui į gestų kalbą. Šios kameros sukuriamas vaizdas turi būti rodomas pagrindiniame salės vaizdo apatiniame kairiame kampe ir turi užimti ¼ viso vaizdo arba rodomas šalia atskirai.

1.1.1.7. Transliacijų peržiūra

Nr. Aprašymas

252. Transliacijų peržiūros dalyje visiems naudotojams turi būti sudaryta galimybė stebėti transliaciją iš posėdžių salės realiu laiku (galimas atvaizdavimo vėlavimas ne didesnis kaip 15 sekundžių).

253. Transliacijų peržiūros dalyje (tarp įvykusių posėdžių) turi būti galimybė ieškoti pagal:

dalyvio vardą, pavardę; posėdžio pavadinimą; klausimo numerį, pavadinimą, datą.

254. Atlikus paiešką Posistemėje pagal norimą kriterijų ir paspaudus ant norimo įrašo automatiškai turi būti nustatomas (atsukamas) posėdžio įrašo laikas, kurio metu įvyko įvykis.

31

2.7.4. Posėdžių valdymo ir transliavimo posistemės integracija su kitomis sistemomis

Nr. Aprašymas

255. Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemom: E-demokratijos sistemos posistėmis:

Teisės aktų ir jų projektų posisteme – turi būti galimybė naudoti Teisės aktų ir jų projektų posistemėje parengtą darbotvarkę, kuri turi būti automatiškai įkeliama, kai ji suformuojama Teisės aktų ir jų projektų posistemėje. Taip pat turi būti automatiškai susiejami balsavimo rezultatai ir vaizdo įrašai su Teisės aktų ir jų projektų posistemėje esančiais sprendimo projektais.

2.8. Teisės aktų ir jų projektų posistemės funkciniai reikalavimai

2.8.1. Bendrieji reikalavimai ir naudotojų grupės

Nr. Aprašymas

256. Posistemė turi būti suvokiama kaip kompiuterinių priemonių visuma, realizuojanti šias funkcijas:

Identifikavimas ir atpažinimas; Dokumentų valdymas; Posistemės administravimas.

257. Posistemė turi sugebėti priimti dokumentus, pasirašytus saugiu elektroniniu parašu bei patikrinti elektroninio parašo bei duomenų autentiškumą. Posistemė turi vykdyti elektroninio parašo tikrinimą.

258. Posistemė turi užtikrinti galimybę pasirašyti el. dokumentus el. parašu naudojant kvalifikuotą skaitmeninį sertifikatą, išduotą įregistruoto kvalifikuotus sertifikatus sudarančio sertifikavimo paslaugų teikėjo.

259. Dokumento aprašas Posistemėje turi atitikti Lietuvos archyvų departamento prie Lietuvos Respublikos Vyriausybės generalinio direktoriaus 2008 m. spalio 9 d. įsakyme Nr. V-119 „Dėl elektroniniu parašu pasirašyto elektroninio dokumento specifikacijos reikalavimų aprašo patvirtinimo“ (Žin., 2006, Nr. 7-268) patvirtintą el. dokumento aprašą.

260. Posistemė turi būti pritaikyta šioms naudotojų grupėms (tipams):Išoriniai naudotojai: Neidentifikuoti naudotojai – turintys prieigą tik prie viešų savivaldybės

dokumentų (susipažinimui). Identifikuoti naudotojai – turintys prieigą tik prie viešų savivaldybės

dokumentų (susipažinimui). Jiems suteikiama galimybė pareikšti savo nuomonę dėl teisės aktų projektų ir pateikti peticijas dėl teisės aktų.

Vidaus naudotojai (identifikuoti ir autorizuoti): Dokumentų tvarkytojai – savivaldybės darbuotojai, turintys prieigą prie

nustatytų Sistemos išteklių ir atliekantys sistemoje registravimo, redagavimo, saugojimo ir kt. funkcijas.

Dokumentų skaitytojai – savivaldybės darbuotojai, turintys prieigą prie nustatytų sistemos išteklių (susipažinimui).

Posistemės administratorius – savivaldybės darbuotojas, kuris atlieka Posistemės administravimo darbus.

2.8.2. Identifikavimas ir atpažinimas

32

Nr. Aprašymas

261. Vidaus naudotojų identifikavimas (tapatumo patikrinimas) turi būti atliekamas tradiciniu (vartotojo vardas/ slaptažodis) identifikavimo būdu.

262.

Vidaus naudotojų slaptažodžiai ir vardai turi būti saugomi naudotojų registre, su tinkamu prieigos kontrolės užtikrinimu ir informacijos šifravimu (slaptažodžiai turi būti šifruojami ir pan.). Posistemė turi naudoti naudotojų tapatybės nustatymo informaciją iš naudotojų registro. Turi būti sudaryta galimybė Vidiniams naudotojams prisijungti naudojant LDAP (Supaprastintos kreipties į katalogus protokolą).

263. Registravimosi į Posistemę galimybė turi būti realizuota pirmame Posistemės puslapyje.

264.Naudotojų autorizacijos (leidimas naudotis resursais) funkcionalumas turi būti apibrėžtas pagal naudotojo roles. Tokiu būdu naudotojui suteikiama galimybė naudotis tik tam tikromis funkcijomis, priklausomai nuo jam suteiktų vaidmenų (rolių).

265. Turi būti sudaryta galimybė Išoriniams naudotojams identifikuotis per Sistemos Identifikavimo posistemę.

2.8.3. Dokumentų valdymas

1.1.1.8. Bendrieji reikalavimai

Nr. Aprašymas

266. Posistemė turi automatizuoti popierinių dokumentų skaitmeninių kopijų ir elektroninių dokumentų tvarkymo ir valdymo procesus.

267. Turi tapti popierinių dokumentų skaitmeninių kopijų ir elektroninių dokumentų registrų saugykla.

268. Turi būti galimybė aprašyti arba importuoti įstaigos (struktūrinio padalinio) struktūrą (padalinių hierarchija ir darbuotojai).

269. Turi būti galimybė ieškoti informacijos, naudojant paprastą, vieno paieškos langelio, funkcionalumą.

270.

Dokumentų valdymas turi apimti šiuos dokumentų tipus: Teisės aktų projektai, Teisės aktai, Protokolai, Darbotvarkės, Peticijos.

271.

Teisės aktai ir jų projektai turi apimti: Tarybos sprendimus. Institucijų sprendimus (Administracijos direktoriaus įsakymai ir Mero

potvarkiai).

272. Sudaryti Protokolus turi būti galimybė visoms institucijoms, turi skirtis tik šablonai, kuriuos turi būti galimybė įkelti į Posistemę.

273.

Institucijų sprendimų (potvarkių, įsakymų) rūšys turi būti skirstomos į: Tvarkomieji (veiklos klausimai). Personaliniai (priėmimas, atleidimas iš darbo, perkėlimas į kitas pareigas ir

pan.). Atostogų ir komandiruočių klausimai.

274. Prieiga prie dokumentų ir jų viešinimas: Išoriniams naudotojams turi būti prieinami tik vieši dokumentai. Viešiems dokumentams turi būti galimybė priskirti:

o Visą registrą (prieiga pagal dokumento rūšį),o Atskirą dokumentą.

Dokumentas turi būti viešinamas su visais jam priklausančiais objektais ir

33

Nr. Aprašymasrekvizitais (pavedimais, rezoliucijomis ir pan.)

Turi būti galimybė pasirinkti kokius dokumentus, dokumento objektus, rekvizitus viešinti o kokių ne.

275.Posistemėje turi būti galimybė prenumeruoti informacinius el. laiškus apie naujus viešus teisės aktų projektus ir priimtus teisės aktus. Ši funkcija turi būti prieinama tik Išoriniams identifikuotiems naudotojams.

276. Posistemėje turi būti realizuotas teisės akto pakeitimų ir aktualios redakcijos atvaizdavimas tiek Vidiniams tiek Išoriniams naudotojams.

1.1.1.9. Dokumentų tvarkymas

Nr. Aprašymas

277. Posistemėje turi būti realizuotas dokumentų tvarkymas su tokiu funkcionalumu: Turi būti įgyvendinta dokumentų registravimo funkcija, kurią naudojant galima

užfiksuoti visus dokumentą identifikuojančius duomenis. Kiekvienam užregistruotam dokumentui turi būti sukuriamas veiksmų su

dokumentu žurnalas, kuriame būtų įrašomi tvarkymo veiksmai (tvarkytojas, data, laikas, tvarkymo informacija).

Registracijos duomenys turi būti perduodami į paruoštą .xml šabloną. Turi būti galimybė atspausdinti šabloną su užpildytais registracijos

duomenimis. Registruojant dokumentą turi būti realizuota galimybė jį išskaidyti į straipsnius

ar punktus. Turi būti galimybė suformuoti ir atspausdinti užregistruoto dokumento

metaduomenis. Turi būti galimybė susieti Posistemėje užregistruotus dokumentus tarpusavyje

arba registruojant naują dokumentą susieti jį su Posistemėje jau užregistruotu dokumentu.

Turi būti galimybė registruojant dokumentą į Posistemę įkelti rinkmenas (failus) visais populiariausiais formatais (formatai galės būti patikslinti Sistemos diegimo metu).

Taip pat turi būti galimybė registruojant dokumentą atlikti skenavimą iš dokumento registravimo lango Posistemėje.

Dokumentai turi būti registruojami į pasirinktus dokumentų registrus. Turi būti įgyvendinta funkcija automatiškam dokumento registracijos numerio

generavimui. Turi būti užtikrintas registracijos numerio unikalumas Posistemės ribose, pagal

registrų galiojimo terminą, kurį turi būti galima nurodyti. Turi būti galimybė naudoti nustatyto termino arba tęstinius registrus.

o Nustatyto termino registruose metu pradžioje registracijos numeriai turi prasidėti iš naujo (turi būti numatyta galimybė metų pradžioje registruoti praeitų metų dokumentus, turi būti galimybė automatiniu arba rankiniu būdu nustatyti numerius iš pradžių).

o Tęstiniuose registruose metų pradžioje registracijos numeracija ne turi prasidėti iš naujo.

Jeigu teisės akte yra informacijos, kuri negali būti skelbiama viešai turi būti galimybė automatiškai tą informaciją pakeisti specialiais simboliais (nuasmeninti).

Parsisiuntimui skirtuose failuose esanti informacija taip pat turi būti nuasmeninta.

34

1.1.1.10. Dokumentų rengimas

Nr. Aprašymas

278. Posistemėje turi būti realizuotas dokumentų rengimas, derinimas, tvirtinimas, pasirašymas, registravimas su tokiu funkcionalumu:

Įgyvendinta galimybė visiems Vidaus naudotojams rengti dokumentų projektus. Turi būti galimybė iš anksto nurodyti projekto derinimo kelią (workflow),

nurodant konkrečius darbuotojus (padalinius, institucijas, grupes) Turi būti galimybė kurti, išsaugoti ir peržiūrėti dokumentų projektų versijas

Neturi būti ribojamas kuriamų ir saugomų dokumentų projektų versijų skaičius. Turi būti galimybė nustatyti, ar senesnės versijos turi būti automatiškai

šalinamos iš Posistemės. Turi būti neleidžiama vienu metu redaguoti tą patį dokumento projektą keliems

vartotojams (check-in/check-out funkcija). Turi būti parengtų dokumentų projektų perdavimo derinimui funkcija nuosekliu

ir lygiagrečiu būdu. Dokumentų derinimo funkcija turi būti įgyvendinta taip, kad leistų rengėjui:

o nurodyti darbuotojus (padalinius, institucijas, grupes), su kuriais reikia suderinti parengtą dokumentą,

o nurodyti derinimo tipą (lygiagretus, nuoseklus),o pažymėti derinimo teisę:

derinimo metu galimas dokumento turinio keitimas, tik komentarų rašymas.

Turi būti galimybė informuoti elektroniniu paštu derintoją (ar grupę – kiekvieną grupės narį atskirai, nuoseklaus derinimo atveju) ar derintojus (grupes, lygiagretaus derinimo atveju).

Derintojo galimi veiksmai:o rašyti komentarus paskirtam derinti dokumentui ir/arba keisti derinamo

dokumento turinį (priklausomai nuo rengėjo pažymėtos derinimo teisės); o įvesti derinimo rezultatus (suderinta, atmesta ir pan.); o suderinimo atveju Derintojas turi galėti uždėti vizą: ,,suderinta“, autorius,

data ir laikas.o Derintojui suvedus derinimo rezultatus apie tai el. paštu turi būti

informuojamas rengėjas. Dokumento rengėjas turi turėti galimybę nutraukti rengiamo dokumento

derinimo procesą. Turi būti įgyvendinta dokumentų pateikimo pasirašymui ir registravimui

funkciją. Dokumentų perdavimo pasirašymui funkcija turi leisti galimybę nurodyti

darbuotoją, kurie turi pasirašyti suderintą dokumentą. Turi būti galimybė informuoti el. paštu pasirašantį asmenį apie dokumento

pateikimą pasirašyti. Turi būti galimybė automatizuoti pasirašytų (priimtų) dokumentų registravimą jų

pasirašymo metu (automatizavimas galės būti patikslintas Sistemos diegimo metu).

Turi būti galimybė atmesti pateiktą pasirašymui dokumentą (pateikiant pastabas) ir apie tai el. paštu informuoti rengėją.

Registruojant pasirašytą dokumentą (jei tai elektroninis dokumentas – jis registruojamas prieš pasirašant) turi būti galimybė automatiškai perkelti dokumento kūrimo, derinimo, pasirašymo cikle suformuoto dokumento ir jo priklausinių rekvizitus.

35

1.1.1.11. Dokumentų archyvavimas

Nr. Aprašymas

279. Posistemėje turi būti realizuota dokumentų perkėlimo į saugojimo dalį (archyvavimo galimybė) su tokiu funkcionalumu:

Turi būti įgyvendinta galimybė automatizuoti vykdomą skaitmeninių dokumentų kopijų ir elektroninių dokumentų archyvavimą, archyvuotų dokumentų saugojimo valdymą, kuris vykdomas Lietuvos archyvų departamento prie LRV nustatyta tvarka (Lietuvos archyvų departamento prie Lietuvos Respublikos Vyriausybės generalinio direktoriaus 2006 m. sausio 11 d. įsakymu Nr. V-12 ,,Elektroninių dokumentų valdymo taisyklės“) .

Turi būti įgyvendinta automatinio elektroninių dokumentų perkėlimo į elektroninį dokumentų archyvą funkcija, turi būti galimybės:

o Posistemei nustatytu laiku pačiai suarchyvuoti nurodytus dokumentus (konkretų registrą ir pan.).

o Vartotojui pažymėti konkrečius dokumentus (registrus, bylas ir pan.), kurie turi būti suarchyvuoti.

Turi būti galimybė atrinkti ir suformuoti archyvavimui skirtas bylas. Turi būti galimybė tai padaryti automatiškai.

Turi būti galimybė atrinkti ir suformuoti naikinimui skirtas bylas. Turi būti galimybė aprašyti dokumentų archyvavimo ir jų naikinimo (šalinimo iš

archyvo) taisykles. Turi būti įgyvendinta dokumentų (bylų) naikinimo iš archyvo funkcija.

1.1.1.12. Dokumentų paieška ir peržiūra

Nr. Aprašymas

280. Paieška turi apimti visus Posistemėje esančius dokumentus (ir jų rekvizitus, objektus ir kitas dalis):

Teisės aktų projektus. Priimtus teisės aktus. Kolegijos, komisijų, tarybų protokolus. Darbotvarkes

281. Posistemės Vidaus naudotojams paieška turi būti ribojama pagal Posistemės administratoriaus nustatytus vaidmenis (roles).

282. Paieška turi būti vykdoma pagal tokius parametrus: Dokumento numerį. Datą ar datos intervalą. Instituciją (Taryba, Administracijos direktorius ir pan.) Dokumento tipą (sprendimas, potvarkis ir pan.) Antraštę Tekstą dokumente.

Turi būti įgyvendinta pilnatekstės paieškos funkcija tiek tarp rekvizitų, tiek ir dokumentų turinyje.

Paieška turi būti vykdoma pagal įvestą žodžio dalį, nepriklausomai nuo raidžių registro (didžiosios ar mažosios), ignoruojant lietuviškas raides, įvesto fragmento turi būti ieškoma visame pavadinime ar dokumento tekste, paieška turi būti vykdoma ir įvedus specialius simbolius (*,+ ir pan.)

Turi būti galima pasirinkti ar vykdyti paiešką dokumento tekste ar tik antraštėje. Turi būti galimybė pasirinkti kokios institucijos teisės akto ar jo projekto

36

ieškoma. Turi būti rodoma kiek iš viso rasta rezultatų. Rasti rezultatai turi būti numeruojami. Turi būti galimybė pasirinkti paieškos rezultatų atvaizdavimą surikiuojant

pagal:o Institucijąo Metuso Dokumento tipą (projektas, sprendimas ir pan.).

283. Turi būti ataskaitų (dokumentų sąrašai ir statistinės ataskaitos) formavimo galimybė.

284. Turi būti ataskaitų eksportavimo galimybė į MS Word, MS Excel, XML, PDF formatus.

1.1.1.13. Darbotvarkės ir protokolai

Nr. Aprašymas

285. Posistemėje turi būti galimybė sudaryti darbotvarkes ir registruoti protokolus.

286. Darbotvarkės: Turi būti sudaryta galimybė sieti darbotvarkės klausimus su teisės aktų

projektais (įkeliant projekto informaciją). Darbotvarkės turi būti sudaromos „sąrašo“ pavidalu. Kiekvieną sudarytą (pasirašytą) darbotvarkę turi būti galimybė atspausdinti ir

išsaugoti (kompiuteryje) pagal iš anksto paruoštą šabloną. Tarybos darbotvarkę turi būti galimybė parengti tokiu formatu, kad ji

automatiškai būtų patalpinama į Posėdžių valdymo ir transliavimo posistemę.

287. Protokolai: Paruoštus protokolus turi būti galimybė atspausdinti pagal iš anksto parengtus

protokolų šablonus. Protokolus turi būti galimybė išskaidyti punktais (pastraipomis ar atskirais

įrašais protokole). Turi būti galimybė kiekvieną protokolo punktą susieti su (vienu ar daugiau)

registruotu dokumentu ir atvirkščiai – registruotą dokumentą susieti su protokolo punktu, bei galimybė įkelti papildomos informacijos rinkmenas (failus).

1.1.1.14. Išorinių naudotojų funkcionalumas

Nr. Aprašymas

288.

Išoriniams Posistemės naudotojams turi būti pateikiamas toks funkcionalumas: Paieška. Teisės akto arba jo projekto peržiūra. Balsavimas dėl teisės aktų projektų. Priimtų teisės aktų komentavimas. Peticijos rengimas. Naujienų užsisakymas.

289. Paieška turi apimti visus publikuojamus dokumentus: Teisės aktų projektus. Priimtus teisės aktus. Kolegijos, komisijų, tarybų protokolus. Darbotvarkes

37

Paieška turi būti vykdoma pagal tokius parametrus: Dokumento numerį. Datą ar datos intervalą. Instituciją (Taryba, Administracijos direktorius ir pan.). Dokumento tipą (sprendimas, potvarkis ir pan.). Antraštę Tekstą dokumente.

Turi būti įgyvendinta pilnatekstės paieškos funkcija tiek tarp rekvizitų, tiek ir dokumentų turinyje.

Paieška turi būti vykdoma pagal įvestą žodžio dalį, nepriklausomai nuo raidžių registro (didžiosios ar mažosios), ignoruojant lietuviškas raides, įvesto fragmento turi būti ieškoma visame pavadinime ar dokumento tekste, paieška turi būti vykdoma ir įvedus specialius simbolius (*,+ ir pan.)

Turi būti galima pasirinkti ar vykdyti paiešką dokumento tekste ar tik antraštėje. Turi būti galimybė pasirinkti kokios institucijos teisės akto ar jo projekto

ieškoma. Turi būti rodoma kiek iš viso rasta rezultatų. Rasti rezultatai turi būti numeruojami. Turi būti galimybė pasirinkti paieškos rezultatų atvaizdavimą surikiuojant

pagal:o Institucijąo Metuso Dokumento tipą (projektas, sprendimas ir pan.).

290. Teisės akto arba jo projekto peržiūra. Prie kiekvieno teisės akto ar jo projekto turi būti pateikiama tokia informacija ir funkcionalumas:

Pavadinimas. Numeris. Data:

o Jeigu projektas – Registracijos ir planuojamo svarstymo data.o Jeigu teisės aktas – Priėmimo data.

Tipas:o Jeigu projektas – Projektaso Jeigu teisės aktas – Įsakymas, sprendimas, protokolas ir pan.

Institucija (Administracijos direktorius, Taryba, Tarybos kolegija, Tarybos komitetai, Komisijos ir Tarybos)

Papildoma informacija ir dokumentai:o Jeigu projektas – turi būti rodoma, kokiems Tarybos komitetams buvo

paskirtas svarstymas, kokie komitetų svarstymo rezultatai ir susiejimas su komitetų posėdžių protokolais. Taip pat visi prie projekto pateikiami papildomi dokumentai. Balsavimo rezultatai Taryboje ir svarstymo vaizdo įrašas. Jeigu Tarybos sprendimo projektas Tarybos posėdyje buvo atmestas, nepatvirtintas, išbrauktas iš darbotvarkės tokia informacija taip pat turi būti rodoma.

o Jeigu teisės aktas – turi būti rodoma visi prie teisės akto pateikiami dokumentai, susiejimas su teisės akto projektu, jeigu teisės aktas keičia kitą teisės aktą ar jo dalį turi būti nuoroda į keičiamą teisės aktą, turi būti nurodomi rengėjai, iniciatoriai ir su rengimu susiję dokumentai (Iniciatyviniai raštai, protokoliniai pavedimai ir pan.), taip pat balsavimo rezultatai:

Jeigu teisės aktas Tarybos sprendimas – Tarybos narių ir Išorinių naudotojų balsavimo rezultatai.

Jeigu teisės aktas ne Tarybos sprendimas – tik Išorinių 38

naudotojų balsavimo rezultatai. Nuoroda į peticijos rengimą Failo parsisiuntimas Raktiniai žodžiai Greita dokumento peržiūra, kai dokumento tekstas pateikiamas WEB puslapyje.

291.

Balsavimas dėl teisės aktų projektų: Prie kiekvieno teisės akto projekto Išoriniams identifikuotiems naudotojams turi

būti sudaryta galimybė atlikti balsavimą (už, prieš, susilaikė) dėl sprendimo projekto.

Balsuoti gali tik identifikuoti naudotojai. Balsavimo rezultatai turi būti matomi visiems Išoriniams naudotojams. Turi būti sudaryta galimybė ne atliekant balsavimo peržiūrėti balsavimo

rezultatus.

292.

Priimtų teisės aktų komentavimas: Komentuoti gali tik Išoriniai identifikuoti naudotojai. Turi būti galimybė komentuoti visą dokumentą arba atskiras jo dalis. Pateikti teisės aktų komentarai turi būti matomi visiems Posistemės

naudotojams arba siunčiami tik teisės akto rengėjui. Išoriniams naudotojams turi būti galimybė pranešti apie netinkamus komentarus

(jeigu įjungtas komentarų rodymas). Pranešimai apie ne tinkamus komentarus turi būti siunčiami Posistemės

administratoriui.

293.

Peticijos rengimas vyksta vadovaujantis Lietuvos Respublikos Peticijų įstatymu (1999-07-07 Nr. VIII-1313)). http://www3.lrs.lt/pls/inter3/dokpaieska.showdoc_l?p_id=316592&p_query=&p_tr2=Peticija – rašytinis arba elektroninis pareiškėjo kreipimasis į <..> savivaldybės institucijas su reikalavimais ar siūlymais spręsti <…> klausimus, kai tam reikia priimti naują teisės aktą, pakeisti, papildyti ar pripažinti netekusiu galios galiojantį teisės aktą ir kai peticijų komisijos tokį kreipimąsi pripažįsta peticija.

Peticijas gali pateikti tiktai Išoriniai identifikuoti naudotojai. Peticijos pateikimui reikia užpildyti tokią formą:

pareiškėjo vardas, pavardė, asmens kodas (šie duomenys gaunami identifikacijos metu ir jų neturi būti prašoma įvesti), gyvenamoji vieta;

prašymas pripažinti kreipimąsi peticija, kreipimosi padavimo priežastys ir tikslai;

pareiškėjo reikalavimai ir siūlymai; pareiškėjo atstovo vardas, pavardė, asmens kodas, gyvenamoji vieta ir, jeigu

yra, telefono, telefakso numeriai (jeigu pareiškėjas neturi atstovo turi būti perkeliami pareiškėjo duomenys gauti identifikacijos metu);

peticija privalo būti pasirašyta elektroniniu parašu. prie kreipimosi gali būti pridėti įvairūs dokumentai ar jų kopijos, siūlomo teisės

akto projektas ir kita medžiaga.

Prie kiekvieno teisės akto ar teisės akto straipsnio turi būti galimybė pateikti peticiją. Pareiškėjui turi būti aiškiai nurodomi keliami reikalavimai peticijos pateikimui.

Jeigu peticijų komisija pateiktą kreipimąsi pripažįsta peticija jis turi būti rodomas visiems Išoriniams naudotojams.

Išoriniams identifikuotiems naudotojams turi būti sudaryta galimybė pasirašyti (palaikyti) prie pateiktų peticijų.

Turi būti rodomas bendras pasirašiusių (palaikančių) asmenų skaičius. Pasirašyti (palaikyti) peticiją gali tik identifikuoti asmenys.

39

294.

Naujienų užsisakymas. Išoriniams identifikuotiems naudotojams turi būti sudaryta galimybė užsisakyti informacijos siuntimą el. paštu. Informacija, kuri gali būti užsakoma:

Pasirinkto teisės akto projekto svarstymo data Taryboje ar Tarybos kolegijoje. Pasirinkto teisės akto projekto svarstymo rezultatas Taryboje ar Tarybos

kolegijoje. Informavimas apie naujus komentarus prie pasirinkto teisės akto. Informavimas apie sudarytas darbotvarkes.

1.1.1.15. Gautų duomenų iš išorinių naudotojų valdymas

Nr. Aprašymas

295. Peticijų valdymui turi būti toks funkcionalumas: Gautos peticijos Posistemėje turi būti registruojamos, kaip gauti dokumentai. Posistemėje turi būti galimybė patikrinti el. parašą, kuriuo yra pasirašyta

peticija. Posistemėje turi būti galimybė užregistruoti gautą dokumentą kaip prašymą

pripažinti peticija, tokie prašymai turi būti matomi visiems Išoriniams naudotojams.

Turi būti galimybė atsispausdinti pateiktas peticijas su visais meta duomenimis. Metaduomenys galės būti patikslinti Sistemos diegimo metu.

296. Balsavimo rezultatų valdymui turi būti toks funkcionalumas: Posistemėje turi būti galimybė atspausdinti Išorinių naudotojų balsavimo

rezultatų suvestinę. Turi būti galimybė išjungti balsavimo rezultatų rodymą.

297. Gautų komentarų valdymui turi būti toks funkcionalumas: Apie pateiktus komentarus, prie teisės akto projekto, el. paštu turi būti

informuojamas teisės akto rengėjas. Turi būti galimybė atspausdinti visus pateiktus komentarus.

2.8.4. Teisės aktų ir jų projektų posistemės administravimas

Nr. Aprašymas

298. Posistemės administratorius turi turėti galimybę registruoti, koreguoti, ištrinti Dokumentų tvarkytojus, nurodyti jų el. pašto adresus ir kitą informaciją.

299.

Posistemės administratorius turi turėti galimybę nustatyti naudotojo roles t.y. suteikti Vidaus naudotojams vaidmenis (roles) pagal, kuriuos jiems bus pateikiamas (ribojamas) Posistemės funkcionalumas. Rolės turi apimti ir Vidaus naudotojų paiešką.

300. Posistemės administratorius turi turėti galimybę suteikti teises Vidaus naudotojams atlikti kitų Vidaus naudotojų funkcijas (turi būti realizuotas darbuotojų pavadavimas).

301.Posistemės administratorius turi turėti galimybė Dokumentų skaitytojams suteikti tik dokumentų peržiūros galimybes, nurodant, kuriuos dokumentus ar dokumentų tipus galima peržiūrėt.

302. Posistemės administratorius turi turėti galimybę importuoti ir tvarkyti įstaigos struktūrą (padalinių hierarchija ir darbuotojai).

303. Posistemės administratorius turi turėti galimybę aprašyti automatiškai generuojamų dokumentų registracijos numerių taisykles ir kitus automatinius procesus.

304. Posistemės administratorius turi turėti galimybę aprašyti dokumento projekto derinimo kelią (workflow).

305. Posistemės administratorius turi turėti galimybę koreguoti dokumentų archyvavimo taisykles.

40

Nr. Aprašymas

306. Posistemės administratorius turi turėti galimybę nurodyti paieškos atvaizdavimo parametrus.

307. Posistemės administratorius turi turėti galimybę nurodyti peticijos registravimo parametrus (registrus, bylas ir pan.).

308. Posistemės administratorius turi turėti galimybę kurti, redaguoti ir šalinti dokumentų klasifikatorius (dokumentų tipus, institucijų sprendimų rūšis ir kt.).

309.Posistemės administratorius turi turėti galimybę įjungti arba išjungti komentarų rodymą. Išjungus komentarų rodymą, pateikti komentarai turi būti siunčiami atsakingui Dokumentų tvarkytojui.

310.Posistemės administratorius turi turėti galimybę nurodyti dėl kurių teisės aktų projektų Išoriniai naudotojai galės atlikti balsavimą (už, prieš, susilaikė) dėl sprendimo projekto arba išjungti balsavimo funkciją.

311. Posistemės administratorius turi turėti galimybė nurodyti kokios, teisės aktų ir jų projektų, rūšys bus atvaizduojamos Išoriniams naudotojams.

312. Posistemės administratorius turi turėti galimybę priskirti Dokumentų tvarkytojui dokumentų rūšis, kurių duomenis jis galės tvarkyti.

313. Posistemėje turi būti galimybė pašalinti netinkamus komentarus.

314. Posistemės administratorius turi turėti galimybę parengti ir įkelti į Sistemą visus naudojamus šablonus (protokolų, darbotvarkių, siunčiamų el. laiškų ir kt.).

315. Posistemei galioja bendri Sistemos administravimo reikalavimai, kurie pateikiami 2.11 skyriuje.

2.8.5. Teisės aktų ir jų projektų posistemės integracija su kitomis sistemomis

Nr. Aprašymas

316. Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemomis: Kauno savivaldybės LDAP serveris. Skirtas Vidaus naudotojų identifikavimui; E-demokratijos informacinės sistemos posistėmis:

Apklausų posisteme – jeigu dėl Teisės akto ar jo projekto buvo (bus) organizuojama apklausa tai turi būti galimybė teisės aktą ar jo projektą susieti su apklausa.

Vaizdo konferencijų posisteme – jeigu dėl Teisės akto ar jo projekto buvo (bus) organizuojama vaizdo konferencija tai turi būti galimybė teisės aktą ar jo projektą susieti su vaizdo konferencija.

Posėdžių valdymo ir transliavimo posisteme – turi vykti kelių tipų susiejimas (duomenų mainai):

o Pirmiausia pagal Tarybos sprendimo projekto numerį turi būti galimybė patekti į tarybos posėdžio vaizdo įrašo tikslią vietą, kur buvo svarstytas sprendimo projektas.

o Tarybos sprendimų projektai turi būti automatiškai susiejami su balsavimo rezultatais iš Posėdžių valdymo ir transliavimo posistemės.

o Tarybos darbotvarkę turi būti galimybė parengti tokiu formatu, kad ji automatiškai būtų patalpinama į Posėdžių valdymo ir transliavimo posistemę.

Problemų žemėlapio dalimi – jeigu dėl Teisės akto ar jo projekto buvo pažymėta problema žemėlapyje tai turi būti galimybė teisės aktą ar jo projektą susieti su tiksliu žemėlapio tašku.

Identifikavimo dalimi – jeigu dėl Teisės akto ar jo projekto norima pateikti komentarą, peticiją, balsuoti tai Išorinis naudotojas turi būti nukreipiamas į identifikavimo posistemę o atlikęs identifikaciją turi būti grąžinamas į tą vietą

41

Nr. Aprašymasiš kurios buvo nukreiptas.

Teritorijų planavimo dalimi – jeigu Teisės aktas ar jo projektas yra susijęs su teritorijų planavimo dokumentais tai turi būti galimybė teisės aktą ar jo projektą susieti su teritorijų planavimo dokumentų posisteme.

Turi vykti informacijos apsikeitimas su Savivaldybės DVS: Visi Posistemėje registruojami dokumentai automatiškai turi būti registruojami

ir DVS. Visi DVS suformuoti pavedimai ar kiti dokumento objektai turi būti matomi ir

Posistemėje. Turi būti realizuotas Teisės aktų ir jų projektų automatiškas talpinimas LRS

dokumentų bazėje (TAPIS).

2.9. Teritorijų planavimo dokumentų posistemės funkciniai reikalavimai

2.9.1. Bendrieji reikalavimai, posistemės struktūra ir realizavimas

Nr. Aprašymas

317. Posistemė turi būti suvokiama, kaip procesas susidedantis iš 14 žingsnių, kuris seka vienas paskui kitą.

318. Posistemė turi sugebėti priimti dokumentus, pasirašytus saugiu elektroniniu parašu bei patikrinti elektroninio parašo bei duomenų autentiškumą. Posistemė turi vykdyti elektroninio parašo tikrinimą.

319. Posistemėje Planavimo organizatoriumi gali būti: KMSA Fiziniai ar juridiniai asmenys.

320. Posistemė turi būti sudaryta iš: Vidinės dalies – skirta tik KMSA darbuotojams. Išorinės ir informacinės dalies – skirtų išoriniams vartotojams.

321. Išorinė dalis turi būti skirstoma į: Informacinę dalį. Identifikuotiems DP rengėjams skirtą dalį.

322. Kiekviename proceso etape turi būti galimybė nurodyti: Atsakingus vykdytojus ir jų kontaktinius duomenis. Kiekvieno etapo vykdymo maksimalią trukmę darbo dienomis. Pagal maksimalią trukmę turi būti apskaičiuojama etapo įvykdymo terminas

(paskutinė diena). Etapo įvykdymo datą. Etapo vykdymo pastabas. Visi etapų vėlavimai turi būti išskiriami spalvomis (Viena spalva kai vėluoja

KMSA, kita kai vėluoja rengėjas). Taip pat turi būti galimybė archyvuoti (atvaizduoti) visus dokumentus pagal

mėnesius, ketvirčius, metus. Paieška turi būti vykdoma visoje Posistemėje ir archyvuose. Turi būti galimybė nurodyti etapus ir etapo žingsnius, kuriuose Posistemė turi

automatiškai siųsti pranešimus el. paštu išoriniams PO bei valdyti pačius pranešimus (keisti pranešimų formas, siuntimo laikus ir pan.).

323. Detalus kiekvieno žingsnio aprašymas pateikiamas 2.9.2 skyriuje.

324. Sistemos diegimo metu bus pateikta EPS aplikacijų programavimo sąsaja (API), reikalinga duomenų apsikeitimui tarp Posistemės ir EPS.

325. Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemomis:

42

LDAP (Supaprastintos kreipties į katalogus protokolas), skirtas KMSA darbuotojų identifikavimui;

Turi vykti informacijos apsikeitimas su Savivaldybės DVS ir EPS; E-demokratijos Sistemos posistėmis:

Teisės aktų ir jų projektų posisteme – turi būti galimybė susieti Posistemėje esančius dokumentus su Teisės aktų ir jų projektų posistemėje esančiais dokumentais (teisės aktais, jų projektais, darbotvarkėmis, protokolais ir kitais).

Identifikavimo posisteme – norint pateikti prašymus Posistemėje, turi būti galimybė atlikti identifikaciją.

43

2.9.2. Teritorijų planavimo dokumentų posistemės kiekvieno žingsnio detalus aprašymas

Eil. Nr. Etapai Išorinė sistemos dalis Vidinė sistemos dalis Informacinė

sistemos dalisJeigu PO išorinis Jeigu PO KMSA Jeigu PO išorinis Jeigu PO KMSA1. Prašymas arba

Administracijos direktoriaus įsakymas dėl PO teisių perdavimo.

Prašymai turi būti pateikiami per EPS.

1.1. Gauti prašymai automatiškai turi būti registruojami DVS.

Posistemėje turi būti galima atlikti AD įsakymų paiešką Teisės aktų ir jų projektų posistemėje ir reikiamą AD įsakymą priskirti prašymui dėl PO teisių perdavimo.

Bendra informacija apie pateiktus prašymus ir AD įsakymus (Data, Reg. Nr.).

1.2. Jeigu prašymas buvo pateiktas ne elektroniniu būdu, Posistemėje turi būti galimybė užregistruoti gautą prašymą, prie jo pridėti skenuotus ar kitus pateiktus dokumentus. Užregistruoti prašymai automatiškai turi būti registruojami DVS.

2. Administracijos direktoriaus įsakymas dėl PO teisių perdavimo

Trukmė – per 20d.d. nuo prašymo pateikimo

Automatinis informavimas el. paštu dėl svarstymo datos

Pereinama prie 4 punkto.

2.1. Parengtas AD įsakymo projektas dėl PO teisių suteikimo turi būti įtraukiamas į Tarybos kolegijos darbotvarkę Teisės aktų ir jų projektų posistemėje

Pereinama prie 4 punkto.

Tarybos kolegijos posėdžio data ir jeigu paskelbta darbotvarkė (nuoroda į Teisės aktų ir jų projektų sistemą).

44

Automatinis informavimas el. paštu apie svarstymo rezultatą.

2.2. Po svarstymo Tarybos kolegijoje AD įsakymo projektas susiejamas su Tarybos kolegijos protokolo konkrečiu punktu.

Tarybos kolegijos posėdžio protokolo išvada ir pats protokolas (nuoroda į Teisės aktų ir jų projektų sistemą).

2.3. Jeigu sprendimas netvirtinti turi būti galimybė pateikti pastabas2.4. Jeigu sprendimas tvirtinti, AD įsakymas registruojamas Teisės aktų ir jų projektų posistemėje.

3. Sutarties dėl PO teisių perdavimo rengimas ir pasirašymas.

Trukmė – per 20 d.d. nuo AD įsakymo

Trukmė – Per 10 k.d. paskelbti interneto tinklapyje.

3.1. Turi būti galimybė pakeisti atsakingus asmenis už sutarties rengimą.

Turi būti pateikiama informacija kas rengia sutartį ir koks jos parengimo terminas.

Automatinis informavimas el. paštu dėl sutarties parengimo ir jos pasirašymo.

3.2. Vykdytojas parengęs sutartį registruoja ją Posistemėje ir pateikia informaciją dėl sutarties pasirašymo. Iki kada reikia pasirašyti ir kur reikia atvykti.

Informacija apie sutarties parengimą ir data iki kada turi būti pasirašyta.

3.3. Turi būti galimybė nurodyti informaciją, kada pasirašyta sutartis.

Informacija apie pasirašytą sutartį.

45

4. Skelbimas Nr. 1

Trukmė – per 10 k.d. nuo sutarties sudarymo

Siunčiama informacija apie paskelbimą el. paštu.

4.1. Skelbimas talpinamas tik tuo atveju jeigu PO išreiškė norą jį talpinti. Šios informacijos iš PO turi būti reikalaujama pateikiant pirmą prašymą.

Posistemėje turi būti galimybė suformuoti ir patalpinti www.kaunas.lt (ar kitoje sutartoje vietoje) informacinį skelbimą.

Informacinis skelbimas ir jo paskelbimo data.

5. Prašymo pateikimas planavimo sąlygų sąvado išdavimui.

Prašymai turi būti pateikiami per EPS.

Pereinama prie 6 punkto.

5.1.Gauti prašymai automatiškai registruojami DVS.

Pereinama prie 6 punkto.

Bendra informacija apie pateiktus prašymus (Data, Reg. Nr.).5.2. Gautus prašymus

dėl planavimo sąlygų sąvado išdavimo turi būti galimybė susieti su sutartimi dėl PO teisių perdavimo.5.3. Jeigu prašymas buvo pateiktas ne elektroniniu būdu Posistemėje turi būti galimybė užregistruoti gautą prašymą, prie jo pridėti skenuotus ar kitus pateiktus dokumentus ir susieti su sutartimi dėl PO teisių perdavimo.

6. Planavimo sąlygų sąvado rengimas ir išdavimas.

Trukmė – per 20 d.d. nuo

Automatinis informavimas el. paštu apie parengtą planavimo sąlygų sąvadą.

6.1. Posistemėje turi būti galimybė suformuoti prašymus institucijoms dėl planavimo sąlygų sąvado.

Bendra informacija iki kada turi būti parengtas planavimo sąlygų sąvadas ir kas atsakingas už jo rengimą.

6.2.Parengti prašymai turi būti registruojami DVS ir turi būti galimybė juos susieti su prašymais dėl planavimo sąlygų sąvado

46

prašymo sąlygų sąvadui pateikimo

išdavimo (5.1. punktas).6.3. Prašymai turi būti formuojami taip, kad turima informacija Posistemėje būtų užpildoma automatiškai.6.4. Iš kitų institucijų gautos sąlygos registruojamos DVS ir turi būti galimybė susieti su 6.2. punkto prašymais.

Pateikiama bendra informacija, kada parengtas planavimo sąlygų sąvadas.6.5. Parengtas planavimo sąlygų sąvadas

registruojamas Teritorijų planavimo registre ir susiejamas su 5.1. prašymu.6.6. Posistemėje turi būti galimybė pateikti failus su planavimo sąlygų sąvadu, planavimo sąlygomis ir papildomais failais.6.7. Prie kiekvieno failo turi būti galimybė pateikti aprašymus ir komentarus.6.8. Turi būti galimybė pateikti informaciją kur ir kada galima atsiimti planavimo sąlygų sąvadą.

7. Skelbimas Nr. 2 Siunčiama informacija apie paskelbimą el. paštu.

7.1. Skelbimas talpinamas tik tuo atveju jeigu PO išreiškė norą jį talpinti. Šios informacijos iš PO turi būti reikalaujama pateikiant pirmą prašymą.

Posistemėje turi būti galimybė suformuoti ir patalpinti www.kaunas.lt (ar kitoje sutartoje vietoje) informacinį skelbimą apie DP rengimo pradžią ir rengimo tikslus, būdus, pobūdžius, planuojamas viešo svarstymo procedūras, plano rengimo terminus,

Informacinis skelbimas ir jo paskelbimo data.

47

susipažinimo su plano sprendiniais ir pasiūlymų teikimo tvarka, informacija apie tai ar bus atliekamas SPAV.

8. Skelbimas Nr. 3

Trukmė – ne mažiau 10 d.d. iki viešo susipažinimo ir svarstymo

8.1. Skelbimas talpinamas tik tuo atveju jeigu PO išreiškė norą jį talpinti. Šios informacijos iš PO turi būti reikalaujama pateikiant pirmą prašymą.

Posistemėje turi būti galimybė suformuoti ir patalpinti www.kaunas.lt (ar kitoje sutartoje vietoje) informacinį skelbimą apie parengtą DP, viešo svarstymo procedūras.

Informacinis skelbimas ir jo paskelbimo data.

9. Viešo svarstymo procedūra.

Trukmė – BENDRĄJA TVARKAne trumpesnis kaip 20 d. d., tuo metu surengiama vieša ekspozicija, trunkanti ne mažiau kaip 10 d. d.

Automatinis informavimas el. paštu apie pateiktas pastabas dėl DP.

9.1. Turi būti galimybė paskelbti parengtą DP su visais susijusiais dokumentais, nurodyti viešojo svarstymo terminą, DP rengėjus ir kt. informaciją.

Pateikiamas parengtas DP ir sudaroma galimybė pareikšti savo pastabas.

9.2. Turi būti galimybė gauti informaciją apie pateiktas pastabas el. paštu.

Pastabas gali pateikti tik save identifikavę Posistemės lankytojai.

9.3. Turi būti galimybė nurodyti DP rengėjo el. pašto adresą, kuriuo bus siunčiamos pastabos dėl DP.

Pateikiant pastabas turi būti galimybė pridėti dokumentus.

48

Trukmė – SUPAPRASTINTA TVARKA ne trumpesnis kaip 10 d. d.

9.4. Pasibaigus viešąjam svarstymui turi būti automatiškai suformuojama pateiktų pastabų suvestinė.

Visiems Posistemės lankytojams pateikiamos visos pateiktos pastabos ir visi pateikti dokumentai.

9.5. Turi būti galimybė atsispausdinti pastabų suvestinę.

10. Prašymo pateikimas dėl DP svarstymo NSK ir jo svarstymas.

Trukmė – 15 d.d. nuo prašymo pateikimo

Prašymai turi būti pateikiami per EPS. 10.1. Gauti prašymai automatiškai registruojami DVS.

Bendra informacija apie pateiktus prašymus (Data, Reg. Nr.).

10.2. Gauti prašymai dėl svarstymo NSK turi būti susiejami su 6.5. punkte parengtu planavimo sąlygų sąvadu.

Bendra informacija apie svarstymus NSK (Data, posėdžio Nr., darbotvarkė).

Automatinis informavimas el. paštu dėl NSK posėdžio datos.

10.3. Jeigu prašymas buvo pateiktas ne elektroniniu būdu Posistemėje turi būti galimybė užregistruoti gautą prašymą, prie jo pridėti skenuotus ar kitus pateiktus dokumentus.

Svarstymo NSK rezultatai.

10.4. NSK įtraukus prašymą į darbotvarkę turi būti galimybė apie tai informuoti DP rengėją.10.5. Atlikus svarstymą NSK, Posistemėje turi būti galimybė paskelbti svarstymo rezultatus.

11. Pateikiamas prašymas dėl DP tvirtinimo

Prašymai turi būti pateikiami per EPS. 11.1. Gauti prašymai automatiškai registruojami DVS.

Bendra informacija apie pateiktus prašymus (Data, Reg. Nr.).

11.2. Gauti prašymai dėl DP tvirtinimo turi būti susiejami su parengtu planavimo sąlygų sąvadu ir NSK išvada.11.3. Jeigu prašymas buvo pateiktas ne elektroniniu būdu Posistemėje turi būti galimybė užregistruoti gautą prašymą, prie jo pridėti skenuotus ar kitus pateiktus dokumentus

49

12. DP tvirtinimo procesas.

Trukmė – 20 d.d.

12.1. Posistemėje turi būti galimybė nurodyti atsakingą asmenį ir telefono numerį, kuriuo reikia kreiptis dėl informacijos gavimo apie DP tvirtinimo procesą.

Kontaktinė informacija ir planuojama DP tvirtinimo trukmė.

12.2. Jeigu DP tvirtinimo procesas DVS vyktų rezoliucijų būdu turi būti galimybė jas atvaizduoti Posistemėje išoriniams vartotojams.

13. Patvirtinto DP įregistravimas Teritorijų planavimo registre.

Trukmė – per 15 k.d. nuo patvirtinimo

Siunčiama informacija apie įregistravimą Teritorijų planavimo registre el. paštu.

13.1. Nurodoma bendra informacija apie įregistravimą Teritorijų planavimo registre.

Bendra registravimo informacija (Data, Nr.)

14. Skelbimas Nr. 4 Siunčiama informacija apie paskelbimą el. paštu.

14.1. Skelbimas talpinamas tik tuo atveju jeigu PO išreiškė norą jį talpinti. Šios informacijos iš PO turi būti reikalaujama pateikiant pirmą prašymą.

Posistemėje turi būti galimybė suformuoti ir patalpinti www.kaunas.lt (ar kitoje sutartoje vietoje) informacinį skelbimą apie patvirtintą DP ir nuorodą į DP teisės aktų ir jų projektų posistemėje, bei informacija kur ir kada galima atsiimti DP.

Informacinis skelbimas ir jo paskelbimo data ir nuoroda į DP Teisės aktų ir jų projektų sistemoje.

50

2.10. Problemų žemėlapio posistemės funkciniai reikalavimai

2.10.1. Bendrieji reikalavimai ir naudotojų grupės

Nr. Aprašymas

326. Posistemė turi būti suvokiama kaip kompiuterinių priemonių visuma, realizuojanti šias funkcijas:

Identifikavimas ir atpažinimas; Problemų pateikimas; Informacijos pateikimas; Problemų peržiūra; Problemų valdymas Posistemės administravimas;

327. Posistemė turi būti integruota į: Savivaldybės turimą GIS duomenų bazę sukuriant problemų ir informacijos

sluoksnį. Kauno miesto skaitmeninių žemėlapių svetainę (http://maps.kaunas.lt),

nepakenkiant esamos GIS sistemos integralumui ir nestabdant jos pagrindu nuolatos vykdomus duomenų atnaujinimo procesus.

328. Posistemė turi būti suderinama su Savivaldybės naudojama programine įranga, kuri veikia ArcInfo ir ArcGIS programų pagrindu. Jeigu siūloma Posistemė nėra suderinama su Savivaldybės turimomis taikomosiomis programomis, kaštai, kurie bus reikalingi sukurti iš naujo arba konvertuoti Savivaldybės įmonėje naudojamas taikomąsias programas dengiami Tiekėjo sąskaita.

329. Posistemė turi būti pritaikyta šioms naudotojų grupėms (naudotojų vaidmenims):Išoriniai naudotojai: Išoriniai neidentifikuoti naudotojai – fiziniai ir juridiniai asmenys, kurie nori

susipažinti su Posistemės teikiama informacija. Išoriniai identifikuoti naudotojai – fiziniai asmenys, kurie gali prisijungti prie

Posistemės ir pranešti apie problemas mieste arba palaikyti (pritarti) jau pateiktoms problemoms.

Vidaus naudotojai (identifikuoti ir autorizuoti): Informacijos registratoriai – savavaldybės darbuotojai, kurie yra atsakingi už

miesto gyventojams aktualios informacijos pateikimą žemėlapyje ir kuriems suteiktos teisės naudotis Posistemės ištekliais atliekant Informacijos registratoriui priskirtas funkcijas (registruoti, šalinti, keisti ir pan.).

Problemų sprendimų vykdytojai – savivaldybės darbuotojai, kurie yra atsakingi už pateiktos problemos sprendimo vykdymą ir kuriems suteiktos teisės naudotis Posistemės ištekliais atliekant Problemų sprendimų vykdytojui priskirtas funkcijas (keisti būsenas, nurodyti terminus ir kt.).

Sistemos administratorius – savivaldybės darbuotojas, kuris atlieka Posistemės administravimo darbus.

2.10.2. Identifikavimas ir atpažinimas

Nr. Aprašymas

330. Vidaus naudotojų identifikavimas (tapatumo patikrinimas) turi būti atliekamas tradiciniu (vartotojo vardas/ slaptažodis) identifikavimo būdu.

331. Vidaus naudotojų slaptažodžiai ir vardai turi būti saugomi naudotojų registre, su

51

Nr. Aprašymastinkamu prieigos kontrolės užtikrinimu ir informacijos šifravimu (slaptažodžiai turi būti šifruojami ir pan.). Posistemė turi naudoti naudotojų tapatybės nustatymo informaciją iš naudotojų registro. Turi būti sudaryta galimybė Vidiniams naudotojams prisijungti naudojant LDAP (Supaprastintos kreipties į katalogus protokolą).

332. Registravimosi į Posistemę galimybė turi būti realizuota pirmame Posistemės puslapyje.

333.Naudotojų autorizacijos (leidimas naudotis resursais) funkcionalumas turi būti apibrėžtas pagal naudotojo roles. Tokiu būdu naudotojui suteikiama galimybė naudotis tik tam tikromis funkcijomis, priklausomai nuo jam suteiktų vaidmenų (rolių).

334. Turi būti sudaryta galimybė Išoriniams naudotojams identifikuotis per Sistemos Identifikavimo posistemę.

2.10.3. Problemų pateikimas

Nr. Aprašymas

335. Tik Išoriniai identifikuoti naudotojai turi turėti galimybę užregistruoti naują problemą Posistemėje.

336. Bandant užregistruoti problemą neatlikus identifikacijos, Posistemė Išorinį naudotoją turi nukreipti į Identifikavimo posistemę. Atlikus identifikaciją Išorinis naudotojas turi būti grąžinamas į problemos pateikimo vietą Posistemėje.

337. Posistemėje turi būti galimybė: Užregistruoti naują problemą Palaikyti (pritarti) esamai problemai.

338. Norint užregistruoti naują problemą naudotojas turi nurodyti (pasirinkti): Gatvę Namo numerį Problemos tipą Problemos aprašymą.

Problemą pateikiančio asmens vardas ir pavardė turi būti gaunama identifikacijos metu o kontaktinė informacija (telefono numeris, el. pašto adresas ir kt.) turi būti imama iš Identifikavimo posistemės, Išorinio naudotojo personalinės dalies (jeigu ji yra užpildyta kitu atveju turi būti prašoma nurodyti reikiamus duomenis arba užpildyti personalinę dalį).

339. Adreso pasirinkimas problemos registracijoje turi būti realizuotas dviem būdais: Pasirenkant adresą iš adresų sąrašo. Nurodant vietą žemėlapyje.

340. Išoriniams identifikuotiems naudotojams problemos pateikimui Pasirenkant adresą iš adresų sąrašo turi būti toks funkcionalumas:

Turi būti suteikiama galimybė įvesti gatvės pavadinimo fragmentą. Vedant (arba įvedus) gatvės pavadinimo fragmentą Posistemė turi vykdyti

paiešką (arba turi būti spaudžiamas paieškos mygtukas) gatvių registre ir pateikti sąrašą Išoriniui identifikuotui naudotojui.

Pateikiamas rastų gatvių sąrašo ilgis neturi būti ribojamas. Gatvės paieška turi būti vykdoma pagal įvestą žodžio dalį, nepriklausomai nuo

raidžių registro (didžiosios ar mažosios), ignoruojant lietuviškas raides, įvesto fragmento turi būti ieškoma visame pavadinime (pvz.: įvedus „sap“ turi būti randamos „L. Sapiegos“ ir „A. Šapokos“ gatvės ).

Turi būti suteikta galimybė pasirinkti surastą gatvę.

52

Nr. Aprašymas

341. Išoriniams identifikuotiems naudotojams problemos pateikimui Nurodant vietą žemėlapyje turi būti toks funkcionalumas:

Turi būti sudaryta galimybė žemėlapio navigacijos įrankiais (didinimas, mažinimas, žingsninis mastelio keitimas, perstūmimas, centravimas) pasirinkti norimą adresą (konkretų namą arba gatvę).

342. Užpildžius visus duomenis ir juos patvirtinus, duomenys Posistemėje neturi būti registruojami o pateikiami Išorinio identifikuoto naudotojo peržiūrai. Peržiūros metu Išoriniui identifikuotui naudotojui turi būti galimybė grįžti atgal arba užregistruoti problemą.

343. Išoriniams identifikuotiems naudotojams turi būti sudaryta galimybė palaikyti (pritarti) kitų Išorinių identifikuotų naudotojų pateiktoms problemoms. Kuo daugiau Išorinių identifikuotų naudotojų palaiko (pritaria) problemą tuo ji tampa svarbesnė (aukštesnis problemos lygis) ir ryškiau (aiškiau) turi būti matoma žemėlapyje.

344. Išoriniams identifikuotiems naudotojams turi būti suteikiama galimybė užsisakyti informaciją el. paštu apie jų pateiktų problemų sprendimo vykdymą.

2.10.4. Informacijos pateikimas

Nr. Aprašymas

345. Informaciją Posistemėje gali pateikti (registruoti) tik Informacijos registratoriai pagal jiems suteiktas teises.

346. Informacijos registracijai turi būti pateikiama forma su tokiais pasirenkamais (pildomais) laukais:

Informacijos kategorija (Planiniai darbai, Numatomi darbai) Darbų vieta (tikslus adresas, gatvė arba rajonas) Darbų pradžios data Planuojama darbų pabaigos data Darbų tipas Darbų aprašymas Kontaktinė informacija

Informacijos registracijos laukai galės būti patikslinti Sistemos diegimo metu.

347. Pateikta informacija Išoriniams naudotojams turi būti grupuojama pagal informacijos kategorija. Skirtingos kategorijos informacija turi būti atvaizduojama skirtingomis spalvomis žemėlapyje.

348. Informacijos registratorius turi turėti galimybę atlikti paiešką tarp jau pateiktos (užregistruotos) informacijos ir peržiūrėti paieškos rezultatus.

349. Redaguoti arba pašalinti pateiktą informaciją gali tik tos Informacijos registratorius.

2.10.5. Problemų peržiūra

Nr. Aprašymas

350. Pateiktų problemų ir miesto informacijos peržiūrai identifikacija nereikalinga.

351. Turi būti galimybė atlikti paiešką, naudojant paprastą, vieno paieškos langelio, funkcionalumą.

352. Išoriniui naudotojui turi būti suteikiama galimybė pasirinkti kokią informaciją jis nori matyti:

Pateiktas Išorinių identifikuotų naudotojų problemas;

53

Nr. Aprašymas Savivaldybės informaciją.

Turi būti galimybė pasirinkti kiekvieną sluoksnį atskirai arba matyti visus vienu metu.

353. Problemų paieška turi būti vykdoma pagal tokius kriterijus: Įvedant adresą.

Paieška Įvedant adresą turi būti vykdoma analogiškai, kaip registruojant problemą Pasirenkant adresą iš adresų sąrašo. Turi būti galimybė ieškoti pagal tikslų adresą (gatvės pavadinimas ir namo numeris) arba visoje gatvėje (gatvės pavadinimas ir visi joje esantys namai).

Problemos tipą. Problemos svarbumo lygį. Problemos registracijos datą (arba datos intervalą).

Paieškos rezultatai turi būti atvaizduojami skaitmeniniame žemėlapyje ir suteikiama galimybė naudotis žemėlapio navigacijos įrankiais (didinimas, mažinimas, žingsninis mastelio keitimas, perstūmimas, centravimas).

354. Išoriniam naudotojui pasirinkus problemą žemėlapyje (užvedus pelę ar paspaudus ant jos) turi būti pateikiama visa informacija:

Registracijos data Adresas Problemos aprašymas Problemos svarbumo lygis arba Problemą palaikančių Išorinių identifikuotų naudotojų skaičius

355. Išoriniam naudotojui taip pat turi būti suteikiama žemėlapio fragmento spausdinimo galimybė.

356. Išoriniam naudotojui atlikus identifikaciją turi būti pateikiami jo užregistruoti problemų pranešimai. Pasirinkus problemą Išorinis identifikuotas naudotojas turi matyti jos vykdymo eigą taip pat turi būti rodoma kiek kitų Išorinių naudotojų palaiko jo problemą.

357. Išoriniams identifikuotiems naudotojam turi būti suteikiama galimybė užsisakyti informaciją el. paštu apie juos dominančios problemos sprendimo vykdymą.

2.10.6. Problemų valdymas

Nr. Aprašymas

358. Posistemėje Problemų sprendimų vykdytojai turi matyti tik jiems priskirtas problemas, pagal problemos tipą.

359. Gauti pranešimai apie problemas turi būti registruojami Posistemėje. Visa pranešimo informacija turi būti perkeliama į XML šabloną.

360. Problemų valdymas turi būti dviejų tipų: Paprastas – kai Problemų sprendimų vykdytojas rankiniu būdu keičia

informaciją Automatizuotas – kai yra vykdomas susiejimas su savivaldybės DVS.

361. Paprastas problemų valdymo būdas turi turėti tokį funkcionalumą: Turi būti galimybė Posistemėje kiekvienam Problemos tipui priskirti atsakingą

Problemos sprendimo vykdytoją. Posistemėje užregistravus naują problemą atsakingas Problemos sprendimo

vykdytojas turi būti informuojamas el. paštu. Problemos sprendimo vykdytojui turi būti galimybė atspausdinti pateiktą

54

Nr. Aprašymaspranešimą apie problemą ir jį užregistruoti DVS.

Problemos sprendimo vykdytojui turi būti sudarytos galimybės pateikti informaciją apie sprendimo vykdymo eigą (pas kokį savivaldybės darbuotoją yra pranešimas, kada jam perduota ir pan.).

Problemos sprendimo vykdytojui turi būti galimybė keisti problemos sprendimo būseną (pateikta, užregistruota, atlikta ir pan.).

Problemos sprendimo vykdytojui turi būti sudaryta galimybė siųsti pranešimą el. paštu Išoriniam naudotojui kuris pateikė problemos pranešimą.

362. Automatizuotas problemų valdymo būdas turi turėti tokį funkcionalumą: Posistemėje pateiktos problemos pranešimo duomenys automatiškai turi būti

perduodami į DVS ir ten užregistruojami, kaip gautas dokumentas. Iš DVS į Posistemę automatiškai turi būti perduodami pranešimo registracijos

duomenys. Iš DVS į Posistemę turi būti perduodama pavedimų, rezoliucijų ir kita su

vykdymu susijusi informacija. Atlikus problemos pranešimo vykdymą Problemos sprendimo vykdytojui turi

būti galimybė pakeisti problemos sprendimo būseną (baigta vykdyti ar pan.). Turi būti realizuota galimybė pasirinktoje sistemoje (DVS arba Problemų

žemėlapio posistemėje) peržiūrėti visą su pranešimu susijusią informaciją, įskaitant nuorodą į pranešimo vietą žemėlapyje ir susijusius DVS dokumentus.

363. Pasikeitus problemos sprendimo būsenai turi būti siunčiami informaciniai pranešimai Išoriniams identifikuotiems naudotojams (jeigu jie šią paslaugą užsisakė).

364. Problemos sprendimo vykdytojui turi būti suteikiama galimybė formuoti suvestines ir ataskaitas jas pateikiant skaitmeniniame žemėlapyje ir tekstiniu pavidalu. Ataskaitas turi būti galima formuoti pagal visus reikšminius duomenų laukus.

2.10.7. Problemų žemėlapio posistemės administravimas

Nr. Aprašymas

365. Posistemės administratorius turi turėti galimybę registruoti, koreguoti, ištrinti Problemų sprendimų vykdytojus ir Informacijos registratorius.

366. Posistemės administratorius turi turėti galimybę Problemų sprendimų vykdytojams priskirti Problemų tipus, kurių duomenis jie galės tvarkyti.

367. Posistemės administratorius turi turėti galimybę Informacijos registratoriams priskirti Informacijos kategorijas, kurių duomenis jie galės tvarkyti.

368. Posistemės administratorius turi turėti galimybė keisti (pridėti, pašalinti, redaguoti) Informacijos kategorijų sąrašus.

369. Posistemės administratorius turi turėti galimybę keisti (pridėti naujus, redaguoti ir šalinti esamus) informacijos registracijos formos laukus.

370. Posistemės administratorius turi turėti galimybę pildyti ir redaguoti darbų tipų sąrašus.

371. Posistemės administratorius turi turėti galimybę suteikti teises Vidaus naudotojams atlikti kitų Vidaus naudotojų funkcijas (turi būti realizuotas darbuotojų pavadavimas).

372. Posistemės administratorius turi galėti aprašyti problemų tipus.

373. Posistemės administratorius turi turėti galimybė nustatyti problemos svarbumo lygius ir kiek Išorinių identifikuotų naudotojų turi palaikyti problemą, kad jos svarbumas padidėtų vienu lygiu.

55

Nr. Aprašymas

374. Posistemės administratorius turi turėti galimybę nurodyti kokiu problemų valdymo būdu veikia Posistemė (paprastu ar automatizuotu).

375. Posistemės administratorius turi turėti galimybę įkelti paruoštą XML šabloną.

376. Posistemės administratorius turi turėti galimybę aprašyti problemos sprendimo būsenas.

377. Posistemei galioja bendri Sistemos administravimo reikalavimai, kurie pateikiami 2.11 skyriuje.

2.10.8. Problemų žemėlapio posistemės integracija su kitomis sistemomis

Nr. Aprašymas

378. Posistemė turi būti integruota ar būti susieta su šiom Kauno savivaldybės sistemomis: Kauno miesto savivaldybės skaitmeninių žemėlapių sistema (http://maps.kaunas.lt) Kauno miesto savivaldybės LDAP serveris, skirtas Vidaus naudotojų

identifikavimui; E-demokratijos informacinės sistemos posistėmis:

Teisės aktų ir jų projektų posisteme – skelbiant informaciją turi būti galimybė susieti ją su teisės aktu ar jo projektu.

Apklausų posisteme – skelbiant informaciją turi būti galimybė susieti ją su vykdoma (įvykusia) apklausa.

Vaizdo konferencijų posisteme – skelbiant informaciją turi būti galimybė susieti ją su vyksiančia (įvykusia) vaizdo konferencija.

Identifikavimo posisteme – norint pranešti apie problemą Išoriniai naudotojai turi būti nukreipiami atlikti identifikaciją ir grąžinami atgal į tą posistemės vietą iš kurios jie buvo nukreipti.

2.11. Bendri Sistemos administravimo reikalavimai

Nr. Aprašymas

379.Sistemoje turi būti galimybė atlikti pilną Išorinių naudotojų analizę arba Sistema turi būti suderinta su išorine analitine sistema (pvz.: Google Analytics ar pan.). Jeigu bus naudojama Google Analytics sistema tai turi būti suderinta prieš jos naudojimą.

380. Klaidų įvykiai turi būti registruojami administratoriaus informacijos žurnaluose.

381. Sistemoje turi būti registruojami visi naudotojų veiksmai, kiekvienas prisijungimas

382.Sistemos administratorius turi turėti galimybę valdyti Sistemos siunčiamus el. pašto pranešimus, keisti jų formas, siuntimo laikus ir pan. Siųsti pranešimus į Išorinių identifikuotų naudotojų el. paštus (jeigu nurodytas adresas) .

383. Sistemos administratorius turi turėti galimybę nustatyti sesijų veikimo periodą, kuriam pasibaigus Išoriniai naudotojai yra priversti iš naujo įsiregistruoti Sistemoje.

56

3. Reikalavimai techniniai įrangai

Siekiant, kad būtų užtikrintas aukščiau aprašytas Sistemos funkcionalumas bus įsigyjama techninė įranga.

3.1. Vaizdo konferencijų posistemės techninė įranga

3.1.1. Vaizdo kameraGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

384. Konstrukcija Pastatoma

385. Vaizdo signalas PAL

386. Raiška Ne prasčiau nei 752 x 582

387.

Lęšis Ne prasčiau nei 10x Optinis artinimas, 40x su Skaitmeniniu priartinimu

388. Skaitmeninis artinimas

Ne prasčiau nei 4x (72x su optiniu artinimu)

389. Minimalus apšvietimas

Ne prasčiau nei 3.5 lux (F1.8)

390.

Pakėlimas/pasukimas

Ne prasčiau nei: Horizontaliai ± 100 laipsnių (Maksimalus greitis 300 laipsnių/s),Vertikaliai ± 25 laipsniai (Maksimalus greitis 125 laipsniai/s)

391. Numatytos pozicijos

Ne mažiau nei 6 pozicijos

392. Valdymas per nuosekliąją jungtį

VISCA (RS-232C, 9600bps)

393. Garantinė techninė priežiūra

Nemažiau 2 metai.

3.2. Posėdžių valdymo ir transliavimo posistemės techninė įranga

3.2.1. Registracijos kortelėGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

57

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

394. Suderinamumas Suderinama su ISO 7816-1/2/3, T=0 arba lygiaverčiu standartu

395. Kortelės nuskaitymo sparta

Ne mažiau nei 9,6 Kbps

396. Kortelės darbinė įtampa

5V (ISO7816-3 Klasė A)

397. Fizinės charakteristikos

Išmatavimai ne didesni:85.6 x 53.98 x 0.76 mm

3.2.2. Kortelių programavimo įrenginysGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

398. Sąsaja Ne prasčiau nei USB v1.1

399. Įtampa Reguliuojama 5V DC

400. Standartai/Sertifikatai ISO 7816-1/2/3, PC/SC, CE, FCC, NETS arba lygiaverčiai

401. Operacinės sistemos Suderinama su Windows 2000 ir XP

402. Garantinė techninė priežiūra

Nemažiau 1 metai.

3.2.3. Vaizdo kameraGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

403. Konstrukcija Tvirtinama prie sienos

404. Vaizdo signalas PAL

405. Raiška Ne prasčiau nei 752 x 582

406.

Lęšis Ne prasčiau nei 10x Optinis artinimas, 40x su Skaitmeniniu priartinimu

58

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

407. Skaitmeninis artinimas

Ne prasčiau nei 4x (72x su optiniu artinimu)

408. Minimalus apšvietimas

Ne prasčiau nei 3.5 lux (F1.8)

409.

Pakėlimas/pasukimas

Ne prasčiau nei: Horizontaliai ± 100 laipsnių (Maksimalus greitis 300 laipsnių/s),Vertikaliai ± 25 laipsniai (Maksimalus greitis 125 laipsniai/s)

410. Numatytos pozicijos Ne mažiau nei 6 pozicijos

411. Valdymas per nuosekliąją jungtį

VISCA (RS-232C, 9600bps)

412. Garantinė techninė priežiūra

Nemažiau 2 metai.

3.2.4. Vaizdo kamerų stebėjimo monitoriusGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametraiBendra informacija

413. Ekrano dydis Ne mažiau nei 20 colių

414. Ekrano tipas LCD arba lygiavertis

415. Konstrukcija Turi būti komplektuojamas su stovu.

416. Skiriamoji geba Ne prasčiau nei 1680x1050

417. Šviesis (cd/m2) Ne prasčiau nei 300

418. Kontrasto santykis Ne prasčiau nei 20000:1

419. Atsako laikas (ms) Ne prasčiau nei 5

420. Žiūrėjimo kampas Ne prasčiau nei 160/160

421. Spalvų gylis (spalvų skaičius)

Ne prasčiau nei 16.7M

422. Paviršiaus apdorojimas

Ne blizgus

Įvadai/Išvadai

59

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

423. D-Sub Turi būti

424. DVI-D Turi būti

425. Komponentinis vaizdas

Turi būti

426. SCART Turi būti

427. HDMI Turi būti

Garantiniai įsipareigojimai

428. Garantinė techninė priežiūra

Nemažiau 2 metai.

3.2.5. Vaizdo kamerų valdymo procesorius su kamerų vaizdo signalo komutatoriumiGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

429.

Paskirtis Programuojamas valdymo įrenginys, skirtas valdyti vaizdo kameras, vaizdo projektorių, ekraną, bendrą garsumą bei komutuoti vaizdo kamerų signalus.

430. Valdymas Programuojamas bei valdomas kompiuterio pagalba per LAN

431.

Valdymo sąsajos Ne mažiau kaip: 1x RS232 – kamerų valdymui, 1x RS232 – balsavimo/diskusijų sistemos valdymui, 1x RS232 – vaizdo projektoriaus valdymui, 2x rėliniai – vaizdo ekrano valdymui.

432. Jungtys Integruotas LAN prievadas: 10/100Mbit

433.

Vaizdo signalo komutatorius

Ne mažiau kaip dvi S-Video įvestys, Ne mažiau kaip viena S-Video išvestis

434. Garso signalo procesorius

Garsumo bei tembro reguliavimas, ne mažiau kaip 1 simetrinė audio įvestis bei ne mažiau kaip 1 simetrinė audio

60

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametraiišvestis

435. Garantinė techninė priežiūra

Nemažiau 2 metai.

3.2.6. Kompiuterinė vaizdo bei garso signalo kodavimo plokštėGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

436.Paskirtis Skirta realiame laike koduoti

analoginius vaizdo bei garso signalus transliacijai internetu

437. Minimalus įvesčių kiekis

Video, S-Video, Audio.

438. Garantinė techninė priežiūra

Nemažiau 1 metai.

3.2.7. Kompiuteris vaizdo bei garso signalo kodavimui, su operacine sistemaGamintojas: Pavadinimas: Tiksli nuoroda į gamintojo interneto puslapį: * Gamintoją, pavadinimą ir nuorodą turi pateikti Tiekėjas.

Nr. Pavadinimas Reikalaujami parametrai Tiekėjo siūlomi parametrai

439. Operacinė sistema Microsoft Windows XP arba lygiavertė

440.CPU Ne mažiau dviejų branduolių,

išleistas ne anksčiau nei 2009 m.

441. Operatyvioji atmintis

Ne mažiau 4GB,

442. Kietasis diskas Ne mažiau 500GB,

443. Optinis įrenginys DVD-RW,

444. LAN adapteris 10/100/1000Mbit

445. Komplektuojami priedai

Klaviatūra, pelė.

446. Garantinė techninė priežiūra

Nemažiau 2 metai.

61