Teksti suurus

Reavahe

Kontrastsus
Seaded

 

Mobiilsete teenuste infrastruktuuri arendamise riigihanke lihtmenetlus

Riigi Infosüsteemide Arenduskeskus viib läbi riigihanke lihtmenetluse "Mobiilsete teenuste infrastruktuuri arendamine". Pakkumise kutse dokumendid (.pdf, 171 KB). Kuni 6. oktoobrini on võimalik saata küsimusi e-posti aadressile ria@ria.ee. Pakkumiste esitamise tähtaeg on 10. oktoober 2006 kell 11:00. Pakkumine tuleb saata aadressile Tallinn Rävala 5 V korrus või e-posti aadressile ria@ria.ee.

Küsimused ja vastused

Vastused lähtuvad PKD kontekstist (sh mõisted).

1. PKD p 4.1.1.2: "kasutatavate tehnoloogiate, tehniliste platvormide ning nende võimalike asendusvariante kirjeldus". Küsimus: Kas siin mõeldakse seda, et kui oleme planeerinud kasutada koodi kirjutamisel üht tehnoloogiat, et loetleda üles tehnoloogiad, milles saaks antud koodi kirjutada eesmärgiks oleva funktsionaalsuse saavutamiseks?

Vastus: Tehnoloogia valikul peab arvestama PKD lisa 1 p 4.8 – 4.11 loetletud piirangutega. Juhul, kui pakkumine sisaldab kõrvalekaldeid loetletud piirangutest, peab piirangutega arvestamise võimatust põhjendama. Tehniliste platvormide all on mõeldud süsteemset tarkvara, riistvara ja mobiilsidespetsiifiliste komponentide tarkvara ning riistvara.

2. PKD p 4.1.1.2: "Üleandmise ja vastuvõtmise tingimused:täitja annab ostjale üle mobiilsete teenuste infrastruktuuri riistvara ja tarkvara CD –l ning installeerituna ostja poolt määratud keskkonnas ning dokumentatsiooni ja juhendid. Töö üleandmise kohta vormistatakse ja allkirjastatakse üleandmise-vastuvõtmise akt". Küsimus: Kas sellest võib järeldada, et pakkumine peab sisaldama ka riistvarahanget?

Vastus: Pakkumine peab sisaldama mobiilsidespetsiifilist riistvara (nt GSM-modem) ja tarkvara. Pakkumine ei pea sisaldama PKD lisa 1 p 4.10 viidatud Ostja IT-profiilis sisalduvaid üldotstarbelisi komponente (süsteemset tarkvara, serverite ning võrguseadmete riistvara jm üldotstarbelisi või mitte-mobiilsidespetsiifilisi infrastruktuurikomponente)

3. Küsimus: Kui suur on planeeritud eelarve (vt PKD pt VI, p 6.6)? Kas üle või alla 300 000 EEK

Vastus: Ostja ei avalikusta planeeritud eelarvet

4. Küsimus: Kas PKD lisa 1, punktis 3.1.3. nõue eeldab, et teenuse kasutaja poolt esitatatav taotlus teenusepakkujale teenuse kasutajaks registreerimiseks peaks toimuma veebiliidese, SMS-i, MMS-i või kõigi ellpool loetletud kanalite vahendusel? Kas Teenuse kasutaja registreerimise taotlus sisaldab andmeid, mis on taotleja ise sisestanud või eeldab see ka liidestusi riigi teiste infosüsteemidega sisestatud andmete kontrollimiseks, täiendamiseks? Mida tähendab kasutajaks registreerimine? Kas see tähendab mingite informatiivsete sõnumite vastuvõtmist või õigust saata mingeid päringuid SMS-i MMS-i teel?

Vastus: Eeldatud on ainult veebiliidese kasutamist. Registreerimine sisaldab ainult tahteavaldust ja ütluspõhiseid andmeid, mida ei täiendata ja sisu ei kontrollita teiste riigi infosüsteemide andmete alusel. Kasutajaks registreerimine tähendab seose loomist isiku (isikukoodi) ja teenuse vahel. Info seose kohta on vajalik teenusepakkujale selleks, et teada, kellele peaks infrastruktuuri kaudu saatma SMS teavitusi. SMS päringute teostamine ei ole hanke skoobis.

5. Küsimus: Kuidas peaks PKD lisa 1 p 3.2.3 taotlusete edastamine toimuma? Kust tuleb ametnike loetelu, kellele taotlust edasi anda saab?

Vastus: Taotlused peaks olema menetletavad portaali veebiliidese vahendusel. Ametnike loetelu tuleb portaali kasutajate registrist.

6. Küsimus: Millist funktsionaalsust on silmas peetud PKD lisa 1, punktis 3.2.2? Kas mingi sündmuse toimumise põhist teadet SMS-i vahendusel? SMS-i, MMS-i saatmist teenuse kasutajale? Kas saatmine oleks automaatne, manuaalne või mõlemad? Kas teavituse saatmine toimub automaatselt või eeldab see teenusepakkuja töötaja sekkumist?

Vastus: Silmas on peetud manuaalset SMS-teavituse saatmist korraga kõigile teenuse kasutajaks registreerunutele.

7. Küsimus: Mida mõeldakse PKD lisa 1, punktiga 3.7? Kas päringut, millega saab kontrollida, milliste riigiametnike mailikontod omavad mailide suunamist mobiiltelefonile? Millised võiksid olla veel teenused, mida peaks saama suunata telefonile? Kas antud päringu tulemus peaks kuvatama ostetavas keskkonnas?

Vastus: Mõeldud on päringut, mis näitab, kas isik (kodanik) on lubanud endale SMS-teadete saatmise ja kinnitanud aktiviseerimisvõtme kättesaamist. Sisuliselt näitab see sidusteenus toimiva seose olemasolu isikukoodi ja mobiiltelefoni numbri vahel analoogselt ametliku @eesti.ee e-posti teenusega Kodanikuportaalis. Kuna päring peab olema realiseeritud X-tee päringuna, on tulemus automaatselt kasutatav nii sidusteenusena, kui ka X-tee päringute portaali kasutajaliidese kaudu.

8. Küsimus: Mida mõeldakse PKD lisa 1, punktiga 3.9? Kas SMS-i, MMS-i saatmiseks sõnumite vastuvõtjate grupeerimist elukoha aadressite alusel teenuse interfaces? Kui detailseks peab grupeerimist planeerima? Asula? Tänav? Maja? Korter? Kust võetakse andmed sõnumi saajate elukohaandmed? Kas andmed võetakse taotlusest, mille esitab teenuse kasutajaks registreerimisel? Kui jah, siis palun loetlege vajalikud andmed, mis Teenuse kasutaja peab sisestama Teenuse kasutajaks registreerimistaotluses. Kas andmed võetakse mingist riigi infosüsteemist? Kui jah, siis millisest? Milliseid algandmeid kasutatakse kasutaja elukoha määramiseks?

Vastus: Mõeldud on sidusteenuse kaudu saadetavat teavitust korraga mitmele SMS-teadete saajale. Saajate nimekiri selgitatakse välja päringuga, mille filtriteks on aadressi komponendid (vastavalt riigi keskse aadressandmete süsteemi määruse eelnõule) ja teenuse nimetus. Pakkuja võib eeldada aadresside olemasolu portaali andmebaasis ja kättesaadavust SQL päringuga (aadressandmete sisestamine ja haldamine ei ole hanke skoobis).

9. Küsimus: Kes on PKD lisa 1 punktis 3.10 kirjeldatud võrguoperaator ning kes on punktis 3.11 kirjeldatud „suurem mobiilsideoperaator”?

Vastus: PKD lisa 1 p 3.10 on mõeldud kõiki Eestis tegutsevaid mobiilsideoperaatoreid, p 3.11 on mõeldud vähemalt 5 % -lise turuosaga Eestis tegutsevaid mobiilsideoperaatoreid.

10. Küsimus: Kas PKD lisa 1, p 3.14 kirjeldatud funktsionaalsus peab saatma teavituse: E-maili saatjale? E-maili saajale? Mõlemale?

Vastus: Mõeldud on ametliku @eesti.ee e-posti süsteemi koosseisus oleva isikukoodi alusel e-posti saatmise X-tee päringu laiendamist SMS saatmise võimalusega (täiendav parameeter). Täiendav info olemasoleva päringu sisu kohta on leitav www.riik.ee/arr -> "Riigi Infosüsteemide Arenduskeskus" -> Infosüsteem "epost" -> päring "epost.sendsmimemail". Teavitus saadetakse isikukoodi alusel sidusteenuse kaudu ja parameetriga määratakse, kas teade edastatakse ametlikule e-posti aadressile või mobiiltelefonile.

11. Küsimus: Mida mõeldakse PKD lisa 1, p 3.15 kirjeldatud funktsionaalsusega? Kas eesmärgiks on saata SMS-iga kogu e-mail (ühe SMS-i pikkus on 160 sümbolit) või on eesmärgiks SMS-iga saata ainult teade e-maili kohta, näidates SMS-is ära e-maili päise? Mida teha e-mailiga kaasa tulnud manustega? Eemaldada? Lisada link manuse asukohaga? Mida peetakse silmas e-kirja teisendamise all SMS jaoks sobivale kujule? Kas peab teisendama e-kirja kogu pikkuses (inimene võib siis saada näiteks 100 SMS-i korraga???)? Kas peab teisendama e-kirjas sisalduda võivad manused? Või tähendab see seda, et inimene saab SMS-ga teate e-kirja saabumise kohta, kus võib olla mainitud ka subjekt ning väike osa sisust ning link e-kirja juurde? Kas saadud e-kiri peab lingi abil olema loetav ka WAP-ist ehk otse telefonist või toksib inimene sisse SMS-s olnud veebiaadressi ja loeb kirja veebist?

Vastus: Optimaalne lahendus peab selguma analüüsi käigus. Analüüsi käigus peaks kaaluma peaks vähemalt järgmisi võimalusi: saadetava teksti lühendamine 160 märgini, teksti tükeldamine, ainult teemarea edastamine, asukohale viitava veebilingi edastamine. Lingi saatmisel peab kiri olema loetav WAP-brauseriga ja tavapäraselt portaali sisenenuna.

12. Küsimus: Mida mõeldakse PKD lisa 1, punktis 4.2 toodud lõigus "mobiilsidespetsiifilise” riistvara all?

Vastus: GSM-modemit (modemeid), terminale jms riistvara, mida eeldab Pakkuja pakutava tehnilise lahenduse kasutuselevõtmine ning mis ei sisaldu Ostja IT profiilis.

13. Küsimus: Mida mõeldakse PKD lisa 1 p 4.9 toodud lausega: „pakutav arhitektuurne lahendus peab olema kooskõlas mobiilside valdkonnas enimkasutatavate standarditega”?

Vastus: Lause väljendab Ostja eeldust, et Pakkuja omab oskusteavet mobiilsidevaldkonna kohta ja on võimeline välja pakkuma/töötama hanke objektiks oleva infrastruktuuri arhitektuuri.

14. Küsimus: Kas ostetav lahendus peab võimaldama saata MMS-e? Kui jah, kas on nõutav, et ostetav lahendus peab võimaldama MMS-i koostamist erinevate kontenti tüüpide osas (tekst, pilt, video, audio). Palun täpsustage millised eelpool loetletud kontenti tüübid peavad olema toetatud.

Vastus: Jah. Lahendus peab võimaldama MMS saatmist kõigi nimetatud sisu tüüpide osas. Formaatide adapteerimise võimalus pole nõutav, kuid eelistatud on lahendused, mis võimaldavad sisu adapteerimist või selle toe hilisemat lisamist.

15. Küsimus: Kas on nõutav küsida operaatori SMSC-st, MMSC-st sõnumi kohaletoimetamise kinnitust (delivery note)

Vastus: Jah. Peaks olema võimalus küsida kohaletoimetamise kinnitust.

16. Küsimus: Kas X-tee süsteemil on liidestus numbrikuuluvuse andmebaasi, et saaks kontrollida, millises võrgus kasutaja asub?

Vastus: Numbriliikuvuse andmebaasil on olemas vastav sidusteenus, mida ei käesoleval ajal ei osutata X-tee vahendusel.

17. Küsimus: Kas süsteem peab toetama nn liidetud sõnumite saatmist (concatenated messaging)?

Vastus: Peab toetama.

18. Küsimus: Kas on nõutav, et süsteem peab toetama kirillitsas sõnumite saatmist?

Vastus: Ei ole nõutav

19. Küsimus: Kui pikk oleks nõutav aeg, mille kestel tuleb sõnumite logi süsteemis aktiivne hoida (nähtav kasutajale)?

Vastus: Määramata tähtajaga

20. PKD lisa 1 p 3.1.6: "saadetud ja saadud SMS teadete logi vaatamine." Küsimus: Milline funktsionaalsus tuleb teostada saabunud SMSi käsitlemiseks? Kas lihtsalt selline, et saabunud SMS salvestatakse baasis vastava telefoninumbri (Isikukoodi/kasutaja) juurde - või tuleb samas teostada ka mingeid sündmustekäsitlusi. Kas pakutav süsteem peab võimaldama sõnumeid vastu võtta? SMS? MMS? PKD lisa 1 "Üldkirjelduses" on öeldud, et: „Infrastruktuuri abil peab olema võimalik ühesuunaliselt edastada infot SMS ja MMS kujul asutuselt mobiiltelefoni kasutajale.” Samas punktis 3.12 on nõutud saadetud ja saadud SMS-ide logi.

Vastus: SMS vastuvõtmine mobiilsideoperaatorilt ja selle tegevuse logimine ei kuulu ülesande skoopi. Kõik infrastruktuuri kaudu saadetud SMS saatmise toimingud logitakse. SMS saajal peab olema võimalik vaadata veebiliideses, millised SMS –d on talle infrastruktuuri vahendusel saadetud ("saadud SMS teadete logi") ja millised SMS –d on tema poolt infrastruktuuri vahendusel saadetud ("saadetud SMS teadete logi"). Saadetud SMS teadete logi on ekslikult "Teenuse kasutaja" veebiliidese funktsionaalsuse jaotises. Peaks olema jaotises "Teenusepakkuja (asutuse ja ametniku) veebiliidese funktsionaalsus".

21.PKD lisa 1 p 3.10-3.11: "SMS-lüüs: 3.10 SMS saatmine, kasutades võrguoperaatori sidusteenust; 3.11 SMS vahetu saatmise teenus suuremate mobiilsideoperaatorite võrkudes." Küsimus: Arusaamatuks jääb punktis 3.11 ja joonisel 1 näidatud "vahetu SMS"-i mõiste. Palume lahti seletada "SMS saatmine" ja "SMS vahetu saatmise" mõistete erinevused.

Vastus: SMS lüüsi all on mõeldud SMS saatmise funktsiooni vahendavat sidusteenust. Soovitavalt üks ühine teenus kõigi operaatorite võrkudesse saatmiseks. Soovitavalt kasutades X-tee või SOAP protokolli. Vahetu saatmise all on mõistetud seda, et mobiilsideoperaatori SIM kaart asub Ostja GSM-modemis ja on liidestatud otseselt Ostja riistvaraga.

22. Küsimus: Palume lahti seletada "võrguoperaator" ja "mobiilsideoperaator" erinevus antud kontekstis.

Vastus: Ei olegi erinevust. Neid sõnu peaks käsitlema sünonüümidena.

23. Küsimus: Milline on prognoositav SMS maksimaalne ja keskmine edastamise maht (kuus, päevas, tunnis, minutis, sekundis)? Milline peaks olema keskmine sõnumi kättetoimetusaeg "Mobiilse teenuse kasutajale" hetkest millal ta jõuab "SMS lüüsi". Millise kriitilisusega on planeeritavad teenused? Milline on ostja ootus sõnumi kiirusele (alates saatmise hetkest kuni sõnumi termineerimiseni lõpp-kasutaja terminalis). Millised on planeeritud saadetavate sõnumite mahud kuus? SMS? MMS? Väga oluline küsimus, millest sõltub pakutava riistvara hulk, võimalik high-availability, load balancing, kasutajatoe operatiivsus jms. Kui suureks prognoosite ligikaudu sellise SMS infrastruktuuri koormust (SMS-i/päevas)? Kui kriitiline see SMS teenus oleks skaalal 1-5 (1 väheoluline, 5 – ülikriitiline, peab töötama isegi üldises kriisiolukorras (sõda, üldine voolukatkestus jne jne))

Vastus: Esialgne hinnang vajalikule jõudlusele oleks 10 SMS (MMS)/sekundis, kuid riistvara ja tarkvara peaks olema skaleeritavad ka suurematele mahtudele. Kättetoimetamisaeg peaks olema võrreldav tavapärase SMS edastamise teenusega. SMS/MMS teadete keskmist mahtu kuu ja päeva jooksul ei oska Ostja käesoleval ajal hinnata. Pakutava lahenduse arhitektuur peab võimaldama skaleerimist. 5-palli skaalal on kriitilisus 3-4.

24. PKD lisa 1 p 4.5: "Pakkuja korraldab vajalike lepingute sõlmimise mobiilsideoperaatorite ja teiste seotud osapooltega." Küsimus: Nimetatud lepingud seovad rahalisi kohustusi. Kas lepingu "teise" poolega sõlmib Ostja või Pakkuja?

Vastus: Lepingu pooleks on Ostja. Pakkuja ülesandeks on lepingute sisu ettevalmistus ja osalemine lepingute _sisu_ kooskõlastamisel mobiilsideoperaatorite ja teiste osapooltega. Kuna lepingute sisu sõltub infrastruktuuri toimimise loogikast, peaks see tingimus vältima olukorda, kus Pakkuja muidu suurepärast tehnilist lahendust pole võimalik kasutusele võtta, kuna lahendus eeldab sellise teenuse kasutamist, mida ükski mobiilsideoperaator ei paku.

Küsimus: Kulud mis sellistest lepingutest tulenevad on vähemalt järgmised:- Operaatorite liitumis ja kuutasud- Riigilõiv saatmiseks kasutatava numbri eest- Saadetava SMS-i tükihindKas Ostja sõlmib Pakkujaga lisalepingu nende kulude kompenseerimiseks või Ostja teeb lepingud otse nii operaatorite kui teiste osapooltega?

Vastus: Ostja teeb lepingud otse operaatorite jt osapooltega. Pakkuja ülesanne piirdub arendusprojekti läbiviimisega.

Küsimus: Kui Ostja sõlmib lepingud otse, siis milline on Pakkuja juriidiline staatus antud protsessis (esindades Ostjat volikirja alusel)?

Vastus: Operaatorite jt osapoolte seisukohast on Pakkuja Ostja poolt kaasatud eksperdi / konsultandi staatuses.

Küsimus: Palume täpsustada millised on Pakkuja kohustused antud korraldaja rollis?

Vastus: Lepingute sõlmimine peab toimuma Pakkuja initsiatiivil ja tagama Pakkuja esitatud tehnilise lahenduse kasutuselevõtu.

25. Küsimus: Kas käesoleva kutse üheks vältimatuks tingimuseks on Pakkuja poolne kohustus luua tehniline valmidus, mis võimaldab Ostja otsest ühendamist kõigi Eesti mobiilioperaatorite SMSC ja MMSC keskustega protokollide tasandil? Kas on võimalik pakkuda lahendust, kus Pakkuja juures asuv infosüsteem tegeleb mobiilioperaatorite ühendustega ning SMS/MMS sõnumite kahesuunalise vahendamisega ning paikneks "Operaatori sidusteenuse" asemel - Joonisel 1. Kas pakkuja peab pakkuma ostjale ka sideteenust (st sõlmima vastavad lepingud operaatoritega) või sõlmib ostja operatoritega ise otse lepingud? Kas siin on võimalik pakkuda ka alternatiivset lahendust? Tänapäeval on olemas end iga operaatoriga otsesidumise asemel efektiivsemaid ning paindlikumaid lahendusi nii integratsiooni ja edasise-arenduse kui ka monitooringu ning kasutajatoe osas.

Vastus: Pakutav lahendus peab võimaldama Ostja otsest ühendamist mobiilsideoperaatorite keskustega. Pakkuja teenuse (vahendusteenuse) kasutamine ühendumiseks mobiilsideoperaatoritega pole lubatud ja pole antud hanke puhul ka võimalik. Ühendumiseks vajalikust tehnilisest infrastruktuurist kuulub pakkumise skoopi ainult mobiilsidespetsiifiline osa. Mobiilsideoperaatoritega sõlmitavate lepingu osapooleks on Ostja. Sellegipoolest on eelistatud lahendused, mis võimaldavad edaspidi (väljaspool antud hanke skoopi) vahendatud teenuse kasutamisele ümberorienteerumist.

26. Küsimus: Kas ja kui jäigalt on nõutud, et SMS infrastruktuuri veebiliidese osad peavad olema rajatud samadele alustele nagu “Teise Eesti” portaali dokument seda sätestab?

Vastus: Veebiliidesed ja infrastruktuuri tööks vajalik andmekiht peavad olema realiseeritud kooskõlas PKD lisa 1 p 4.8 nimetatud portaali arendusraamistikuga. X-tee sidusteenused ja SMS lüüs võivad olla realiseeritud muus RIA IT-profiiliga kooskõlas olevas tehnoloogias

27. Küsimus: PKD lisa 1 p 3.2.1: kus hoitakse “teenuse” kirjeldust – kas antud lahenduse raames loodavas andmebaasis või on mõni ühine teenuste register? Millest koosneb “teenuse” kirjeldus?

Vastus: teenuse kirjeldusi hoitakse portaali ja tellitava infrastruktuuri jaoks ühises andmebaasis. Teenuse metaandmete loetelu selgitatakse välja analüüsietapi käigus. Ostja esialgse ettekujutuse kohaselt on see minimalistlik: teenuse identifikaator, teenusepakkuja identifikaator, teenuse nimetus ja teenuse kirjeldus.

28. Küsimus: Mida mõeldakse mõiste teavitamine all? Kas see on kodanikule soovitud info saatmine või teavitamine info liikumisest mingi muu kanali (e-maili, tähtkirja etc) kaudu?<

Vastus: See on kodanikule ühepoolselt info saatmine (st tegemist pole päringuga, mis eeldab samal viisil vastuse saamist).

29. Küsimus: Punkt 3.12 – kas aruanne kuvatakse veebiliidese kaudu või on eeldatud väljavõtete saatmist SMS kaudu?

Vastus: Aruande filtrite määramine ja kuvamine toimub portaali veebiliidese kaudu.

30. Küsimus: Kas punktis 4.11 mainitus arenduskeskkond on sama, mis “Teise Eesti” veebiportaali dokumendis mainitud arenduskeskkond? St et PostgreSQL serverid ainult?

Vastus: Veebiliideste osas on arenduskeskkond kirjeldatud PKD lisa 1 p 4.8 viidatud portaali arendusraamistikus. Muude komponentide osas peab arendus toimuma Ostja kontrolli all olevas arenduskeskkonnas, mis luuakse (vajadusel) Ostja poolt tööde teostamise käigus ja mis jääb arenduse perioodiks ja edaspidi paralleelsesse kasutusse koos infrastruktuuri avaliku keskkonnaga.

31. Küsimus: Kui pikk ajavahemik jääb 10. oktoobri kui pakkumiste esitamise päeva ning lepingu sõlmimise vahele? Seega kui pikk aeg jääb reaalselt implementatsiooniks?

Vastus: Leping sõlmitakse nii kiiresti, kui võimalik.

Küsimused ja vastused 2

6.10.2006

Vastused lähtuvad PKD kontekstist (sh mõisted).

1. Küsimus: Profiilis (.doc, 1.2 MB) p 4.1.6 lg 1 öeldakse, et: "Programmeerimiskeelte valikul lähtutakse vastava arendusraamistiku kirjeldusest (kui see on olemas), eraldiseisva rakendusserveri puhul eelistatakse Javat, muudel juhtudel eelistatakse Perli". Kas antud hanke korral loetakse rakenduse eelistuskeeleks Perli või Javat ning kas tohib kasutada pre-kompileeritud lahendusi UNIX platvormile tingimusel, et need on realiseeritud nt C/C++ keeles?"

Vastus: Veebiliidesed peavad olema realiseeritud kooskõlas PKD lisa 1 p 4.8 viidatud arendusraamistikuga. Muud komponendid võivad olla realiseeritud muudes tehnoloogiates, kuid olema kooskõlas IT-profiiliga. Muude komponentide puhul on eelistatud samuti PKD lisa 1 p 4.8 viidatud arendusraamistik, eelistuselt järgmine on Java. C/C++ vms kompileeritavad lahendused on kasutatavad eeldusel, et tegemist on vähemalt mobiilsete teenuste valdkonnas üldkasutatava tootega (mitte käimasoleva hanke spetsiifilise tootega), millele selle tootja tagab kommertstoe toote kasutamisel IT-profiilis sisalduvatel UNIX-laadsetel operatsioonisüsteemidel (Debian GNU/Linux ja Solaris)

2. Küsimus: Mis platvormil peab olema realiseeritud pakkutav veebilahendus? Millist veebiserver, tehnoloogia ja serveri OS eelistatakse? Kas eelistatus ASP, JSP, CGI, FastCGI, jne.?

Vastus: Vastavalt p 4.8 peavad veebiliidesed olema realiseeritud kooskõlas samas punktis viidatud arendusraamistikuga. Arendusraamistiku kirjeldus sisaldab viidet veebiserverile, operatsioonisüsteemidele ja veebiserveri rakendusega liidestamise tehnoloogiale.

3. Küsimus: PKD lisa 3 p 10.1 ("Intellektuaalne vara") öeldakse: "Käesoleva lepinguga annab täitja tellijale üle töö tegemise käigus loodud teoste varalised autoriõigused. Täitja loovutab varalised õigused tellijale töö üleandmise hetkest, loobudes sellega lepingu alusel üle antud töö osas varaliste õiguste kasutamisest. Tasu autoriõiguste loovutamise eest sisaldub lepingu hinnas." Seoses sellega palume täpsustada, kas antud tingimus peab kehtima mistahes lahenduse komponentidele või ainult antud PKD hanke raames ainult konkreetsele tellijatele ettevalmistatud komponentidele eeldusega, et pakkutav lahendus sisaldab mõlemaid liiki komponente? Kui nõutakse loodud teoste varaliste autoriõiguste üle andmine täies ulatuses, kas see tingimus automaatselt välistab GPL/LGPL, BSD, Microsoft kommerts- ja Mozilla litsentsitüüpiga lähtekoodi- ja komponentide rakendamise tööde teostamisel või "eeldatakse" eespool toodud lähtekoodi litsentsitingimuste rikkumist?

Vastus: Antud tingimus laieneb ainult käimasoleva hanke raames loodud teostele (komponentidele). Pakkumises peavad sisalduma muude komponentide litsentsitingimused või viited nendele, et Ostja saaks hinnata tervikuna pakkumise majanduslikku soodsust. Pakkumise hinnas peab sisalduma muude komponentide ühekordne litsentsitasu selles ulatuses, mis tagab hanke eesmärkide saavutamine.

4. Küsimus: Mis andmebaasisüsteeme eelistatakse andmebaasi hoidmiseks vastavalt RIA profiilile ja mis versioonid (vähemalt) peavad olema? Mis versiooni PostrgreSQL, MySQL, Orcale, Progress jne. eelistakse, missugune on andmebaasisüsteemide pingerida koos versioonidega?

Vastus: Andmebaasiplatvorm peab olema kooskõlas PKD lisa 1 p 4.10 viidatud IT-profiiliga. Eelistatud on PostgreSQL vähemalt versioon 8.1, eelistuselt järgmine on Oracle versioon 10.

5. Küsimus: Mis nimelis(t)ele turvastandardi(te)le peab vastama pakutav lahendus (ISKE, BSI, Common Criteria, jne) ja kas pakutav lahendus peab olema sertifitseeritud ning kas normatiivdokumendid on avalikult kättesaadavad?

Vastus: Pakutava lahenduse turvameetmed peavad olema kooskõlas ISKE etalonmeetmete süsteemiga. Lahenduse sertifitseerimine pole käimasoleva hanke skoobis, kuid edaspidise auditeerimise käigus tuvastatavad turvavead kuuluvad Pakkuja poolt kõrvaldamisele ilma täiendava tasuta. ISKE rakendamis juhend ja viide turvameetmed kehtestavale õigusaktile (www.ria.ee -> Valdkonnad -> Turvalisus -> ISKE rakendamine -> Vajalikud dokumendid)

6. Küsimus: PKD lisa 1 joonis 1 kohaselt peab infrastruktuuri abil olema võimalik ühesuunaliselt edastada infot SMS ja MMS kujul asutuselt mobiiltelefoni kasutajale. Samas joonisel 1 on vahetu SMS ja SMS sõnum operaatori kaudu sidemed kahepoolsed ehk mobiilse teenuse kasutajalt liigub info ka tagasi. Millise info liikumist mobiilse teenuse kasutajalt infrastruktuuri poole silmas peetud on?

Vastus: Suunas kasutajalt SMS lüüsini liigub SMS kättesaamise kinnitus

7. PKD lisa 1 p 3.1.1: Mobiiltelefoni numbrite seostamine isikuga. Küsimus: Kas näete ette, et üks number võib olla samaaegselt seotud mitme isikuga?

Vastus: Võimalus siduda sama numbrit samaaegselt mitme isikuga peab olema. Samas peab olema võimalus kehtestada reeglit, mille kohaselt uus seos uue isikuga lõpetab varasema seose teise isikuga.

8. PKD lisa 1 p 3.2.5: Piiratud kasutajate grupile suunatud teenuste õiguste määramine ja kasutajagruppide kirjeldamine. Küsimus: Palun kirjeldage mõningaid kasutajate gruppe, et saaks aimu, millised on kasutajagrupi peamised tunnused?

Vastus: Kasutajagrupi kohta peab olema määratud vähemalt grupi identifikaator, grupi nimi, kirjeldus, omanik (grupi moodustaja) ja viited grupi liikmetele. SMS –i peab olema võimalik saata lisaks üksikule kasutajale ka kasutajate grupile. Grupi moodustajaks on teenusepakkuja. Gruppi peab saama liikmeid lisada (kustutada, muuta) teenuse kasutajaks registreerumise (registreerimise tühistamise) käigus ja vahetult teenusepakkuja poolt. Teenuse kasutajaks võib olla isik või grupp. Grupi liikmeks võib olla isik või teine grupp.

9. Küsimus: Punktid 3.13 - 3.16 kirjeldavad ametliku e-posti süsteemi täiendusi. PKD lisas pole viidet ametliku e-posti süsteemi tehnilisele kirjeldusele. Samas nõutakse, et pakkuja on võimeline ametlikku e-posti süsteemi täiendama. Palun edastage ametliku e-posti süsteemi tehniline platvorm, arendusraamistiku ja lahenduse tehniline dokumentatsioon või viide dokumentidele, mis neid kirjeldavad. Kui leiate, et nimetatud dokumentatsiooni pole pakkumise koostamiseks tarvis, siis põhjendage palun miks.

Vastus: Ametliku e-posti süsteem on realiseeritud kooskõlas PKD lisa 1 p 4.8 viidatud arendusraamistikuga. Süsteemi tehniline kirjeldus (.zip, 2.1 MB).

10. PKD lisa 1 p 4.1 seab nõudeks ühe ostja poolt määratud teenusepakkuja mobiilse teenuse juurutamist. Küsimus: Millise teenusega on tegemist?

Vastus: Juurutatav teenus ja teenusepakkuja kooskõlastatakse Ostja ja pilootasutuse vahel analüüsietapi jooksul. Võimalikud pilootasutused on Riiklik Eksami- ja Kvalifikatsioonikeskus, ARK, Politseiamet. Pakkuja jaoks sisaldab juurutamine teenusepakkuja konsulteerimist teenuse kasutuselevõtmise käigus, infrastruktuuri konfigureerimist, kasutajatuge teenusepakkujale ja Ostjale juurutusperioodil ja infrastruktuuri kasutuselevõtu käigus ja infrastruktuuri toimimisega seotud probleemide jooksvat lahendamist.

11. Küsimus: PKD lisa 1 p 4.11 näeb ette, et arendus peab toimuma ostja arenduskeskkonnas. Palun edastage ostja arenduskeskkonna spetsifikatsioon (riist- ja tarkvaraline platvorm). Kui ostja eeldab, et mobiilsete teenuste infrastruktuur peab olema realiseeritud riigiportaali arendusraamistikul ja kõik tarkvaralised (k.a SMS Gateway ja asutuste IS-dele mõeldud X-tee sidusteenused) komponendid paigutatakse selle serveritesse, siis pole arenduskeskkonna spetsifikatsiooni tarvis

Vastus: Olemasoleva arenduskeskkonna kasutamise nõue kehtib veebiliideste kohta. Muude komponentide osas valmistab Ostja arenduskeskkonna ette vastavalt PKD lisa 1 p 4.10 viidatud IT-profiilile ja Pakkuja poolt valitud tehnilisele platvormile (kooskõlas IT-profiilis esitatud alternatiividega).

12. PKD lisa 1 p 4.11 näeb ette, et arendus peab toimuma ostja arenduskeskkonnas. Küsimus: Kas võime eeldada, et ostja arenduskeskkonda on võimalik tema IT-profiiliga kooskõlas oleva riist- ja tarkvaraga server(eid) lisada, mis hakkavad loodava süsteemi komponente jooksutama?

Vastus: IT-profiiliga kooskõlas oleva riist- ja tarkvaraga serveri(d) lisab Ostja vastavalt vajadusele ja Pakkuja poolt valitud tehnoloogiale (kooskõlas IT-profiilis esitatud alternatiividega). IT-profiilile vastava riist- ja tarkvara paigaldamine pole hanke skoobis.

Lisatud 24.10.2006

Tagasi lehele "Riigihanked"