Teksti suurus

Reavahe

Kontrastsus
Seaded

 

Küsimused/vastused riigiportaali www.eesti.ee hajusa sisuhaldusfunktsionaalsuse arenduse hankes

1. Küsimus: Kas on praegu süsteemis olemas keelte tugi? Kui ei ole, see tähendab, et süsteemile peab tegema täieliku "refactoring"-u.

Vastus: Keelte tugi on olemas. Hetkel toetab portaal ja selle sisuhaldus kolme keelt.

2. Küsimus: Sõnade otsing ja asendamine üle kogu portaali. See funktsionaalsus ei saa alluda reeglile, et "responce time" kolme (3) sekundi jooksul. Faile võib olla suurusjärgus gigabait ja üle. Seega seda saab realiseerida ainult tausta protsessiga.

Vastus: Meie hoiame andmeid andmebaasides. Meie andmekogud pole gigabaitide suurusjärgus, pigem mõned megabaidid.

3. Küsimus: Mille põhjal koostatakse aruanded? Siin räägime PHP rakendusest, aga iText ja muud on java framework.

Vastus: Meie raamistik on PL/PgSQL keele põhine. Me ei kasuta PHP-d.

4. Küsimus: Mozilla Firefox 3.0, Internet Explorer 7.0, Safari 3 - tänaseks on juba vastavalt 3.5, 8.0 ja 4-s versioonid.

Vastus: Hankes on välja toodud minimaalsed nõuded.

5. Küsimus: Kas on võimalik saada arendusserverisse ligipääsu antud osale, kus asub olemasolev CMS-i kood? Sooviks tutvuda koodiga, et hinnata muudatuste ulatust.

Vastus: Ligipääsud on võimalik saada, kuid selleks peab avaldama soovi ja siis taotleme vastavad ligipääsud.

6. Küsimus: Kas on välja selgitatud, millised olemasoleva CMS-i osad on halvasti käsitletavad ja mis vajaks parandamist?

Vastus: See on üheks analüüsietapi töö osaks.

7. Küsimus: Portaalis on palju alamosi, millistele osadele täpselt tuleb RSS voog luua?

Vastus: Kõikidele osadele, mis toodetakse sisuhaldusega. Täpsemalt: Teemad, alamteemad. Täpsustamine analüüsi käigus.

8. Küsimus: Kas mallide süsteem on mõeldud WYSWYG editori juurde või mõeldakse selle all üldist mallide süsteemi?

Vastus: Mallides süsteemi hakkab kasutama toimetaja. Selle toimimise visioon näeb välja järgmiselt: 1. Toimetaja avaldab soovi toota uut artiklit. 2. Toimetaja valib malli, mille alusel ta soovib artiklit koostada. 3. Toimetaja sisestab informatsiooni vastavalt mallile.

9. Küsimus: Kas antud CMS-il on välised liidesed?

Vastus: Väliseid liideseid ei ole.

10. Küsimus: Kas CMS-is on hetkel osi, mis avanevad serveri normaalkoormusel kauem kui 3 sekundit? Kui jah, kas Te oskate nimetada need osad?

Vastus: Sellised osad puuduvad serveri normaalkoormusel töötamisel.

11. Küsimus: Kas olemasolev CMS vastab HTML 4.0 ja XHTL nõuetele?

Vastus: CMS vastab hetkel 4.01 nõuetele.

12. Küsimus: Kas olemasolev CMS on jälginud WCAG 2.0 nõudeid?

Vastus: Hetkel on kogu portaal vastavuses WCAG 1.0 nõuetele.

13. Küsimus: Kas hetkel on CMS-is kasutusel html tabelid?

Vastus: Jah, kasutame HTML tabeleid.

14. Küsimus: Kas olemasoleva CMS-i kohta on dokumentatsiooni, andmebaasi skeeme, üldise ülesehituse skeeme, USE CASE analüüsi, nõuete dokumentatsiooni, administreerimise juhendit, testiplaane ja süsteemi spetsifikatsiooni? Kui on, kas neid edastatakse pakkujatele?

Vastus: Eraldiseisvat CMS dokumentatsiooni ei eksisteeri. Osa CMS-i on dokumenteeritud arendusraamistiku dokumendis.

15. Küsimus: Palun kirjeldage lähemalt kasutajate töölaual kuvatavaid „tööriistu“. Kas nende all mõeldakse erinevaid liste tegelemist vajavatest tööülesannetest (Lähiajal aeguvad artiklid, Lähiajal uuendamist vajavad artiklid, Kinnitamiseks saadetud artiklid, Kinnitajalt tagasi saadetud artiklid jne)? Kas midagi veel?

Vastus: Kirjeldan meie visiooni, mida ei pea jälgima ja võib pakkuda parema lahenduse. Meie visiooniks on töölaud, kus vastavalt toimetaja õigustele kuvatakse mooduleid. (Kogu töölaud koos moodulitega näeb välja nagu iGoogle.com, mis omakorda ei tähenda, et mooduleid peab saama ümber tõsta, nagu seda võimaldab Google.) Kõik moodulid toimivad ühe loogika alusel. Ühes moodulis kuvatakse näiteks TOP10 artikli pealkirja. Pealkirjad on klikitavad. Klikates pealkirjale avaneb artikkel. Avatud artiklit saab redigeerida.

16. Küsimus: Palun kirjeldage lähemalt planeeritavat töövoogude protsessi. Kas töövoogude reeglid peavad olema dünaamilised (et näiteks mingis temaatikas on vaja kinnitamine nii peatoimetaja kui ka administraatori poolt, aga teises temaatikas ainult peatoimetaja poolt)? Kas töövoogudele on vaja kehtestada ka keerukamaid reegleid, et mingis teemas näiteks peab enne avalikustamist artikli kinnitama nii peatoimetaja kui ka administraator? Kas rollide määramine töövoos on dünaamiline (et sama isik võib olla ühe teema artiklite juures määratud kaastoimetajaks (kellel on siis ainult ettevalmistamise ja kinnitamiseks edastamise õigused?) ning teises teemas peatoimetajaks (kellel on siis lisaks ka kinnitamise/tagasi lükkamise õigus))?

Vastus: Keerukamaid reegleid kehtestada pole tarvis. Artikli kinnitajaks on alati peatoimetaja. Peatoimetajad on jäigalt paigas ja ei saa olla üheaegselt nii peatoimetaja ja kaastoimetajana.

17. Küsimus: Kas WYSIWYG redaktoris nõutav speller tähendab, et arendaja üleandeks on leida WYSIWYGi redaktor, millega on võimalik panna ühilduma eesti, vene ja inglise keele sõnaraamatud ning pakkuda spelleri funktsionaalsust WYSIWYGi aknas? Või mõeldakse pigem uuemate brauserite endi poolt pakutava keeletoe säilimist WYSIWYGi aknas (nagu FF3 näiteks joonib textarea välja sisestatavat eestikeelset teksti automaatselt alla)? Kas Hankija omab eelistusi WYSIWYGi regaktori ja/või spellersüsteemide valikul? Kui soovitud lahenduse pakkumises osutub vajalikuks tasulise tarkvaralitsentsi (spellerid ja/või WYSIWYG redaktor) hankimine (sest käesoleva projekti skoobis eesti keele spellerit looma hakata pole ilmselt mõistlik), teeb Pakkuja Hankijale vastavasisulise ettepaneku ning kui Hankija ei pea vajalike litsentside hankimist võimalikuks, langeb ka kõnealune nõue ära? Kas vabavaraliste lahenduste kasutamise puhul (ei ole hetkel veendunud, et on olemas kokkusobiv pakett vabavaralistest spelleritest/keeltest/WYSIWYG redaktorist) on Pakkuja vabastatud vastutusest spellerite töökindluse ja sisukuse eest?

Vastus: Arendaja pakub WYSIWYG redaktori ja sellega kokkusobiva spelleri. Hankija ei oma eelistust WYSIWYG redaktori ega spelleri valikul ja neid võib pakkuda ka tasulise litsentsiga. Litsentsi tasu peab olema kajastatud pakkumuse maksumuses. Tellija jaoks on oluline, et speller toimiks sõltumata brauserist, seega loodava komponendi sisene speller on eelistatum.

18. Küsimus: On esitatud nõue, et peab olema funktsionaalsus sõnade otsimiseks ja asendamise üle terve portaali. Palun kirjeldage sellise asendamise tööprotsessi lähemalt: õigused (kes ja mida tohib asendada), töövoog (kas muudatused peab üle vaatama, kas muudetud artiklid peab keegi uue versioonina vastavalt töövoogude süsteemile kinnitama) jne.

Vastus: Sõnu otsida ja asendada võib ainult peatoimetaja. Otsing ja asendamine ei käi tagataustal. Iga leitud artikkel otsitava sõnaga väljastatakse nagu tavalise otsinguga, kuid enne asendamist peab peatoimetaja veenduma, kas selles artiklis kasutatav sõna on mõistlik asendada. Asendust vajavad artiklid märgistatakse ja lastakse ära asendada.

19. Küsimus: Mõistete peatükis on toodud välja kasutaja, kaastoimetaja ja peatoimetaja. Hilisemas nõuete osas räägitakse tavatoimetajatest, peatoimetajatest ja administraatoritest. Kas tavatoimetaja nõuete peatükis tähendab kaastoimetajat?

Vastus: Selgituseks tavatoimetaja = kaastoimetaja.

20. Küsimus: Kas kõikidele sisuelementidele määratakse alati sisu aegumistähtaeg ja uuendamistähtaeg. Mis on nendel kuupäevadel vahet ning mis tegevusi eeldab süsteem kasutajatelt enne nende kuupäevade saabumist?

Vastus: Igale artiklile pole tarvis sätestada aegumise ega uuendamise tähtaega. Seda sätestab toimetaja iga artiklile individuaalselt. Aegumise tähtaeg, on tähtaeg, millal artikli sisu aegub ja edaspidiselt ei anna mingit lisaväärtus kasutajale, vaid pigem viib eksitusse. Uuendamise tähtaeg, on tähtaeg, millal oleks tarvis artikkel üle vaadata ja vajadusel uuendused sisse viia.

21. Küsimus: Nõuetes on kirjeldatud, et peab toetama täiendavate keelte lisamist. Samas täiendava keele lisamine eesti.ee raamistikule eeldab läbivaid muudatusi terves eesti.ee tarkvaras ja andmemudelis (näiteks rakenduste tekstid, mis ei ole ju sisuhalduse arenduse skoobis). Kirjeldage seega palun lähemalt, mida peetakse selle nõudega antud arenduse kontekstis silmas (sh. ka WYSIWYGi spellerite osas).

Vastus: Uue keele lisamine portaali üldjuhul ei peaks olema väga keeruline. Juhul, kui programmeerimisel tekstide väljastamiseks on kasutatud "gettext" ning artiklite väljastamiseks spetsiaalset VIEW'd, siis väljund sõltub täielikult keskkonnamuutujast "LANG". Uue keele lisamiseks piisab väikesest andmemudeli täiendamisest ning mõnede funktsioonide/view'de muutmist. Seega me tegelikult ei nõua, et uue keele lisamine oleks teostatav konfiguratsiooni parameetri muutmisega. Meie soov on selline, et vajadusel saaks lisada uute keelte tuge võimalikult väikese arendustööga. Spellerid võiksid sarnasel moel sõltuda keskkonnamuutuja väärtusest ning kindlasti mitte koodi sisse kirjutatud keelte nimekirjast.

22. Küsimus: Kas w3 valideerimisele lubatakse siiski ka põhjendatud erisusi? Kuivõrd on nõutud kolme erineva brauseri täielik toetus, näitab praktika, et teatud probleemide lahendamisel on vajalik minna mööda w3org validaatori nõuetest.

Vastus: Jah, põhjendatud erisusi lubame, kuid iga erisust tuleb eelnevalt kooskõlastada hankijaga.

23. Küsimus: Palun seletage lähemalt nõuet „Artikli mallide loomine“. Kas Pakkuja peab tegelema disainimallide väljatöötamisega või on Pakkuja ülesandeks siiski luua tehnilised lahendused, mis võimaldavad neid kirjeldatud malle süsteemi sisestada? Kas mallide süsteem on hierarhiline või ühe-tasandiline (ehk et kas peab saama luua malle, mis on kasutatavad ainult talle määratud artiklite hierarhia osas (mingi ühe teema all), või on kõik loodud mallid kasutatavad kõikide artiklitega üle kogu portaali)?

Vastus: Luuakse teatud kogus malle. Täpne arv täpsustatakse analüüsi käigus, kuid see jääb vahemikku viis kuni kümme malli. Eraldi süsteemi, mis võimaldab malle luua, pole tarvis. Kõiki malle peab saama kasutada üle kogu portaali.

Lisatud 02.04.2012

Tagasi lehele "Riigihanked"