SPECIFIKACE POŽADAVKŮ NA VÝBĚR ŘEŠENÍ CMS – REDAKČNÍHO SYSTÉMU

SPECIFIKACE POŽADAVKŮ NA VÝBĚR ŘEŠENÍ CMS – REDAKČNÍHO SYSTÉMU

1. PŘEDMĚT VEŘEJNÉ ZAKÁZKY

• Předmětem plnění veřejné zakázky je implementace a uživatelská customizace CMS (Content Management System, dále jen „CMS“) určeného pro správu obsahu a jeho publikování na webových stránkách zadavatele, které budou obsluhovány pomocí RS (redakční Systém pro veřejnou i neveřejnou část webu). Instalovaný CMS bude spravovat množství objektů na různých uživatelských a strukturálních úrovních. Musí zajistit přístup desítek uživatelů do mnoha sekcí vzájemně provázaných databází jednotlivých objektů (články, fotografie, rejstříky, audiovizuální soubory). Systém musí umět zpracovávat výstupy z dynamických i statických modulů typu anketa, formuláře, on-line rozhovory a reportáže. Musí nabízet možnost uploadu a využití uživatelského obsahu při dalším automatizovaném zpracování (např. rozesílání newsletterů atp).

• Předmětem plnění je servisní podpora celého řešení po dobu 5 let od předání díla.

• Předmětem plnění je migrace obsahu stávajících veřejných webových prezentací a návrh web designu včetně vytvoření kompletní neveřejné webové prezentace.

• Analýza a vymezení funkcionalit CMS budou doplněny v průběhu jednání na základě aktuálních informací předávaných ve fázi analýzy.

• Zadavatel požaduje po Dodavateli naprogramování funkcionality exportu čistě statického HTML 5 pro vybrané projekty přímo na zadavatelem využívaný hosting .

• Hosting veřejných webových prezentací je a bude provozován u společnosti Active 24. Zadavatel pronajímá jeden fyzický server u společnosti Active24 (služba fyzický managed server). Současně máme k dispozici neomezený počet virtuálních serverů. Společnost Active24 poskytuje zároveň službu DNS.

• Zadavatel požaduje možnost vytvoření 1 až N webových projektů (samostatných webových stránek/aplikací), kdy Dodavatel zajistí veškeré náležitosti ve spolupráci se zadavatelem (např. šablony, styly, apod.).

• Zadavatel požaduje, aby bylo možné stránky otevřít na všech používaných platformách (PC, tablety, smartphone a další mobilní komunikační zařízení)

• Zadavatel požaduje kontrolu integrity dat stránek pro všechny projekty, které budou v rámci CMS provozované.

• Zadavatel požaduje po Dodavateli vyhotovení kompletní provozní, bezpečnostní a uživatelské Dokumentace k CMS. Zároveň požaduje Zadavatel předání Dokumentace s popisem předávaného stavu. Předání se provede formou Akceptace Zadavatelem.

• Zadavatel požaduje od Dodavatele poskytnutí zdrojových kódů CMS včetně jejich aktualizace při každém upgradu CMS. Zadavatel se zavazuje, že nebude tyto kódy měnit ani používat po dobu trvání servisní podpory.

• Zadavatele požaduje od Dodavatele takové řešení CMS, které bude na základě požadavků zadavatele rozšiřitelné.

• Zadavatel požaduje od Dodavatele spolupráci při doprogramování nové funkcionality.

Součástí plnění zakázky jsou tyto činnosti a dodávky:

• Analýza stávajícího prostředí, navržení základní logiky datové struktury a vzájemných vazeb mezi objekty. V průběhu fáze analýzy bude kompletně specifikována struktura i funkcionalita CMS. Zadavatel požaduje možnost připomínkovat řešení CMS, kolikrát bude nutné pro správnou specifikaci všech služeb a funkcionalit.

• Dodavatel ve fázi analýzy v součinnosti se zadavatelem provede aktualizaci obsahu a struktury jednotlivých webových projektů.

• Analýza musí reflektovat zadávací dokumentaci. Analýza bude obsahovat integrační vazby, jaká bude implementační část, cílový koncept, struktura webu, návrh grafické podoby, návrh navigace a jak bude probíhat migrace. V analýze musí být definováno, jaká bude míra integrace.

• Projekt implementace Systému do SW a HW prostředí zadavatele. Implementační fáze nemůže začít dříve, než bude zadavatelem schválena analýza bez připomínek.

• Implementace do testovacího prostředí, optimalizace pracovních postupů.

• Customizace Systému podle potřeb zadavatele, definice struktury obsahu a vzájemných vazeb mezi jednotlivými objekty, uživateli a oprávněními.

• Návrh způsobu indexace pro různé vyhledávací úlohy.

• Spolupráce při definování požadavků na optimální HW infrastrukturu (základní dimenzování, postupné požadavky na škálovatelnost atp.).

• Implementace Systému do navrženého SW a HW prostředí zadavatele.

• Spolupráce při migraci stávajícího obsahu do prostředí nového CMS, nastavení potřebných pravidel pro automatizované převody.

1.1 STÁVAJÍCÍ STAV

V současnosti jsou veřejné webové stránky xxx.xx a xxxxxxx.xx provozovány separátně mimo infrastrukturu Zadavatele. Hosting je u společnosti Active24 a správu obsahu řeší společnost ICZ na základě požadavků Zadavatele. Neveřejný web není v současnosti dosud realizován, přičemž Zadavatel požaduje jeho kompletní realizaci v infrastruktuře Zadavatele. Zadavatel plánuje vlastní implementaci webových stránek s novou strukturou a designem. Domény xxx.xx a xxxxxxx.xx používají sdílený SSL certifikát (Subject Alternative Names). Web server EV SSL certifikát poskytuje společnost Thawte.

1.2 TESTOVÁNÍ

Zadavatel požaduje testování provozu CMS včetně testovacího scénáře. Pro testování zadavatel zajistí vlastní infrastrukturu, která bude identická s cílovou infrastrukturou.

Dodaný software bude dodán jako RPM balíček nebo jako více balíčků, který bude splňovat RPM specifikaci a bude možné je zařadit do vlastního repozitáře NBÚ, který spravuje NBÚ. NBÚ poskytne součinnost při tvorbě rpm balíčku.

Každá aktualizace nebo změna software bude dodáván jako rpm balíček včetně označení verze a vydání.

Pro release nových verzí software používá Zadavatel tento cyklus:

Library -> NBU_Testing -> NBU_Stable

Library

• Obsahuje všechny rpm repozitáře a veškerý dodaný software

• Synchronizace se provádí každý večer automaticky z dodaných zdrojů

• Do tohoto prostředí nejsou přiřazeny žádné servery

NBU_Testing

• Tato verze vychází z Library a obsahuje stejný software

• Defacto se jedná o "Library" zmražený v čase

• Do tohoto prostředí jsou zařazeny testovací servery, na kterých se mohou nacházet produkční data, nicméně k nim má přístup pouze NBÚ a Dodavatel pro účely ověření dopadu nasazení nových verzí

NBU_Stable

• Tato verze vychází z NBU_Testing a obsahuje stejný software

• Defacto se jedná o "NBU_Testing" zmražený v čase, otestovaný na testovacích serverech a plně funkční

• Do tohoto prostředí jsou zařazeny produkční servery s produkčními daty

• Do tohoto prostředí není možné nasadit žádný software, který neprojde přes

NBU_Testing

• V případě kritických bezpečnostních oprav je možné testovací cyklus zrychlit, nicméně né přeskočit

Všechny servery jsou spravovány centrálním managementem RedHat Satellite 6. Více informací zde:

• xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxxxxxxx/xx-XX/Xxx_Xxx_Xxxxxxxxx/

1.3 AKCEPTAČNÍ PODMÍNKY

Akceptační podmínky jsou podstatnou složkou VZ. V případě této VZ jsou umístěny na konec Etapy A – Analýza a tvorba projektové Dokumentace. Jsou složeny z AK (Akceptačních kritérií). Na jejich základě bude hodnocen finální předložený návrh CMS buď jako:

- Akceptovaný

Všechny náležitosti jsou v pořádku. Nic není potřeba dolaďovat.

- Akceptovaný s výhradami

V návrhu na CMS se nachází pár drobných problémů, které Dodavatel ve spolupráci se Zadavatelem opraví.

- Neakceptovaný

V návrhu CMS se nachází velké množství závažných chyb, kvůli kterým není možné předložené CMS přijmout ze strany Zadavatele.

Níže popsaná Akceptační kritéria jsou vybrána Zadavatelem a vycházejí z dále v dokumentu popsaných funkcionalit CMS.

Akceptační kritéria

• Fungují oddělené instance CMS tak, aby bylo zajištěno dostatečné bezpečné oddělení správy obsahu veřejného a neveřejného webu. Úroveň bezpečného oddělení bude předmětem fáze analýzy.

• Nativní režim úprav v RS funguje správně a bez chyb.

• WYSIWYG editor pro úpravy v Systému funguje správně a bez chyb.

• Správa více domén formou projektů (xxx.xx, xxxxxxx.xx, atd…) funguje správně, bez chyb.

• Systém je schopen vést záznamy o tom, že dokument byl do Systému nahrán, upraven, byl změněn jeho obsah, tzv. verzování. Příklad: Uživatel nahraje dokument. Systém o tom má záznam. Uživatel změní parametry dokumentu. Systém o tom má záznam. Uživatel změní obsah textového dokumentu. Systém o tom má záznam. V případě textového dokumentu je Systém schopen vyvolat předchozí uložené verze dokumentu. Systém je schopen zobrazit rozdíl mezi jednotlivými verzemi textových dokumentů, článků, souborů, příspěvků.

• Systém dokáže vyhledávat články podle různých parametrů: data publikace, názvu, autora, sekce, v které je uložen a další.

• Modul Aktuality správně a bez chyb zobrazuje nadpis s krátkým úryvkem z nově publikovaného článku. Po kliknutí na aktualitu dojde k přesměrování na příslušný článek.

• Modul Kalendář zobrazuje správně a bez chyb současné datum včetně vložené akce, události, která na příslušný den připadá.

• Do Kalendáře jdou přidávat Akce a Události správně a bez chyb. Každá událost je v kalendáři vyznačena.

• Struktura webové prezentace je připravena ve dvou jazykových mutacích – v ČJ a AJ. Systém je připraven na rozšíření o další jazykové verze. Čtenář je schopen měnit jazykovou mutaci na veřejném i neveřejném webu v jakékoliv jeho části.

• U neveřejné webové prezentace lze využívat funkci fulltextového vyhledávání.

• U neveřejné webové prezentace lze využívat funkci vyhledávání pomocí klíčových slov.

• Na veřejném webu je možné využít vyhledávání pomocí externího vyhledávače.

• Vyhledané záznamy je možné řadit podle předem stanovených kritérií.

• Každý uživatel přistupující k neveřejné webové prezentaci má předem určeno, ke kterým informacím může přistupovat a také které může vyhledávat. K žádným jiným informacím nemá uživatel přístup, ani nemá možnost tyto informace nějak vyhledat.

• Systém dokáže automaticky vygenerovat přehlednou strukturu webu tzv. sitemap s aktivními odkazy na jednotlivé části webu.

• Stránka FAQ funguje správně a bez chyb, je přehledně rozdělena do jednotlivých

kategorií. Jednotlivé dotazy na stránce jsou odkazem propojeny na příslušné části webu, kterých se obsahově týkají.

• Hromadná e-mailová notifikace funguje správně a bez chyb a podle předem definovaných kritérií informuje jednotlivé uživatele o změnách, novinkách a úpravách pomocí hromadně rozesílaných e-mailových zpráv.

• Pro notifikace lze nastavit následující kritéria:

o Role – jiné notifikace pro čtenáře (příp. skupinu čtenářů), redaktora, šéfredaktora, administrátora.

o Typ – typ změny, například Nový článek, Změna článku, Smazání článku.

o Popis – obsahuje Nadpis článku, kterého se notifikace týká, případně krátký předdefinovaný text.

o Notifikace bude rozdělena na dvě základní. První je notifikace tzv. „urgentní“, která bude určena pro naléhavé případy, kdy je nutné okamžitě informovat

o změnách, hrozbách nebo jiných důležitých informacích.

o Druhá je notifikace „obecná“, kdy budou v předem stanovených časech rozesílány informace o novinkách, hrozbách a dalších důležitých věcech.

Součástí obecné notifikace pak bude také notifikace urgentní, pokud ten den byla odeslána.

o Notifikace si bude každý uživatel moci zapnout a vypnout podle svého uvážení.

o Zadavatel požaduje u notifikací shodného typu, zavést určitý stupeň agregace. Přínos Zadavatel očekává v menším počtu notifikačních emailů k odběratelům notifikací. Agregace je požadována hlavně u druhu notifikace „obecná“

• Systém dokáže generovat kontextový obsah podle obsahu hlavního.

• Systém dokáže tagovat jednotlivé nové články.

• Systém dokáže exportovat vybrané články do souborů: rss, xml, sitemap.

• Struktura a grafické provedení webové prezentace je uživatelsky přívětivé .

• Systém dokáže vytvářet jednotlivé webové prezentace. Pro jejich vytváření nemusí uživatel využívat psaní v jazyce PHP, ale je schopen si webovou prezentaci naklikat.

• Systém poskytuje 100% kontrolu nad customizací webu s možností dalších úprav vlastní silou uživatele.

• Systém je schopen vytvářet a exportovat seznamy článků (včetně článků samotných) k jednotlivým autorům, tématům, sekcím, v kterých jsou seřazeny.

• Systém dokáže vytvářet seznamy článků od jednotlivých uživatelů. Tyto články jsou určené ke schválení hlavním redaktorem. Po schválení jsou tyto články vystaveny podle předem určených parametrů.

• Rozhraní pro správu obsahu dokáže pracovat se všemi dostupnými daty: uživatelé, skupiny, oprávnění, články, aktuality, obrázky, audia, videa.

• Systém umožňuje volně upravovat strukturu obsahu i odpovídající vazby mezi daty.

• Grafická podoba webové prezentace veřejného i neveřejného webu je v souladu s vizuálním stylem, který užívá NBÚ, NCKB, XxxXXXX.XX.

• Správa uživatelů je společná pro celé řešení a všechny projekty, které jsou v rámci CMS realizované.

• Uživatel se může do Systému přihlásit dvěma způsoby:

o Když je pracovník mimo dosah Systému (mimo prostory), připojuje se pouze pomocí VPN s možností dvoufaktorové autentizace (VPN není předmětem plnění této VZ)

o Pokud je pracovník v dosahu Systému užívá přístup přímo z infrastruktury Zadavatele.

• Redaktoři mají možnost vkládat, upravovat a mazat informace, které na web zveřejňují.

• Dodavatel zpracuje školící materiál pro nové uživatele Zadavatele, který zajistí korektní ovládání uživatelem i správcem.

• Systém si pamatuje osobní nastavení konkrétního uživatele.

• Správce Systému má možnost libovolně spravovat všechny uživatele, měnit jim oprávnění, přístupy a řadit je do skupin.

• Systém spolupracuje s RedHat IDM IPA ve verzi RHEL 7.1 s následným updatem na aktuální stabilní verzi.

• Pro jednotlivé uživatele i skupinky uživatelů lze nastavit různá práva pro práci v RS.

• Při zastavení / smazání uživatelského účtu z něj není možné vkládat články, ale již vložené články zůstávají zachovány.

• Každý uživatel je zařazen do určité skupinky:

o X – autoři, redaktoři, šéfredaktor

o A – N – ostatní uživatelé

• Při tvorbě a úpravě článku je možné upravovat parametry článku:

o Redaktor

o Číselné ID článku

o Autor

o Titulek

o Perex

o Perexová fotografie

o Tělo článku

o Datum vydání

o Datum aktualizace

o Datum expirace

o Klíčová slova

o Zařazení do rubriky

o Přiřazení fotografie

o možnost odložené publikace

o vazby článku

o umístění článku v rubrice, umístění na webu

o možnost povolit nebo zakázat diskuzi pod článkem

• Článek je možné vložit ze šablony. Nově vytvořené tělo šablony je možné uložit jako nový vzor pro další ukládané články.

• U článku je možný živý náhled.

• U článku je možné přiřadit přílohu, fotografii, odkaz, zvukový záznam nebo foto či video- galerii.

• U článku je možné nastavit úroveň notifikace – normální nebo urgentní.

• Článek umožňuje dvě jazykové mutace – ČJ, AJ.

• Do článku je možné vložit rámeček s citací nebo výčtem faktů.

• Lze zobrazit článek v článku.

• Systém umožňuje automatické přizpůsobení vkládaného obrázku do Systému. Systém také umožňuje vkládaný obrázek upravit ručně podle parametrů i přetažením myší.

• Systém umožňuje vložit obrázek na šířku textu bez obtékání.

• Článek není možné upravovat dvěma či více uživateli zároveň.

• Článek lze označit tak, aby bylo jasné, že prošel korekturou/editací.

• Systém umožňuje nastavit podmíněný přístup k webu.

• Systém ukládá každou změnu v článku. Tyto změny lze dohledat a zobrazit rozdíly i to kdo tuto změnu provedl. Systém ukládá všechny verze článku samostatně. Při smazání jedné verze se ostatní nemažou, ale zůstávají uloženy a funkční.

• Články lze importovat do Systému pomocí souborů typu: doc, xls, odt, txt, pdf.

• Systém rozlišuje tyto typy článků a dalších objektů:

o Publikovaný objekt

o Rozpracovaný objekt

o Koncept

o Seznam smazaných článků

• Uživatelé si mohou ze Systému stahovat nabízené soubory až do velikosti 1GB.

• Diskuzní fórum funguje správně a bez chyb. Lze v něm vytvářet a provozovat chatovací místnosti. Jedna je společná pro všechny a další jsou určeny podle předem stanovených kritérií pro jednotlivé uživatele a skupinky uživatelů.

• Diskuzní fórum podporuje několik druhů uživatelů, kteří jsou dále v dokumentu popsáni stejně jako uživatelské místnosti a jejich dělení.

• Blog zaměstnanců funguje správně podle dále zmíněných parametrů.

• Výstupy z e-learningu jsou v pořádku a fungují bez problémů pro každého uživatele.

• Integrovaný kontrolní mechanismus CSM funguje podle dále popsaných parametrů v sekci „Vlastní CMS“.

• Zálohování i obnovování souborů je v pořádku a funguje bez problémů pro jednotlivé soubory, RS i CMS.

• Při zveřejnění článku se bude vždy aktualizovat jen ta příslušná část webové prezentace, do které článek patří. Nebude se aktualizovat celá webová prezentace.

• Statická prezentace veřejného webu reflektuje přesně originál.

• CMS podporuje Systémy LDAP a AD včetně Systému identity management.

• CMS pro přihlašování využívá Kerberos a všechna nastavení společnosti RedHat.

• Systém zaznamenává logy k událostem jako je:

o akce uživatelů

o akce administrátorů

o změny konfigurace,

o nestandardní stavy Systému,

o bezpečnostní informace

o auditní log

• Dodaný Systém zasílá logy pomocí syslogu na libovolný server.

• Systém je skenován a kompatibilní s monitorovacím Systémem Nagios, který umožňuje kontrolovat jednotlivé bloky.

• Z návratového stavu v případě chyby nebo varování musí být možné identifikovat závadu bez nutnosti hlubší znalosti dohledového Systému nebo programu.

Například, pokud nastane chyba při ukládání dat do složky, plugin vrátí chybový stav a text "Chyba při ukládání dat do /cesta/ke/složce".

• Automatické kontroly nejsou schopny přístupu k citlivým údajům ani v případě selhání části nebo celého kontrolovaného Systému. Jako výsledek automatické kontroly nesmí být vrácen citlivý údaj.

• Systém dokáže pracovat se všemi dále uvedenými základními typy objektů.

• Administrátor může libovolně měnit název stránky (meta title)

• URL pracuje podle dále uvedených parametrů.

1.4 LICENČNÍ PODMÍNKY

Zadavatel požaduje, aby nabízené řešení bylo licenčně neomezené jak z pohledu počtu uživatelů, instancí RS nainstalovaných v infrastruktuře Zadavatele i mimo ni. Dále Zadavatel požaduje neomezenou licenci na aktualizace nabízeného řešení a na neomezené geografické a časové užití.

Zadavatel požaduje, aby nabízené řešení při případném ukončení podpory bylo bez aktualizací, dále plně funkční bez jakýchkoliv omezení i dílčích funkcionalit. Po dobu smluvního vztahu Dodavatele se Zadavatelem, musí Dodavatel zajišťovat aktualizace nabízeného řešení reagující na bezpečnostní požadavky a hrozby

2. POŽADAVKY

Obr. 1: Schéma celkového CMS, včetně komunikačních rozhraní zadavatele.

• Zadavatel specifikuje základní vlastnosti CMS.

• Všechny informace uvedené ve schématech a obrázcích jsou pro Dodavatele závazné a jsou na stejné úrovni jako informace uvedené v textu této zadávací dokumentace.

CMS musí plnit funkci:

• Redakčního Systému (dále jen „RS“) pro jednotlivé projekty (1,2,….n)

• Celé řešení výstupu CMS bude rozděleno do několika hlavních částí:

o Vlastní CMS pro jednotlivé projekty xxx.xx a xxxxxxx.xx, jejichž statické HTML prezentace budou veřejnou částí webu.

o Jedno CMS pro neveřejný web, jehož jednosměrná samostatně funkční kopie CMS se bude nacházet v DMZ.

API:

• Zadavatel vyžaduje po Dodavateli úplný popis API rozhraní CMS, na základě čehož si bude zadavatel schopen doprogramovat do vlastních programů a aplikací požadované funkcionality, například pro upload či download souborů z externích zdrojů, (100% znalost konfiguračního a programovacího prostředí CMS). Plně popsané rozhraní API bude předáno formou dokumentu přímo zadavateli, včetně doporučených zdrojů, kde zadavatel bude čerpat další znalosti (projektové skupiny, fóra, apod.). Dokument bude obsahovat i popis a základní principy vývoje pro CMS.

• Zadavatel požaduje, aby API měla následující funkce: editovat, mazat a vkládat články a soubory. Další funkcionality API budou upřesněny v rámci fáze analýzy.

• S API souvisí „externí vstupy z aplikací CERT“, které nebudou součástí zakázky. Pro vkládání souborů z těchto aplikací bude využita právě API.

• Provoz CMS bude realizován pouze v prostředí GNU/Linux.

Migrace:

• Zadavatel požaduje po Dodavateli, aby v součinnosti se současným provozovatelem webových prezentací společností ICZ provedl migraci dat do nového CMS.

• Náklady společnosti ICZ na migraci budou hrazeny a koordinovány na základě samostatného smluvního vztahu zadavatele a společnosti ICZ.

• Termín, podoba stránek a jejich obsah a způsob migrace bude upřesněn ve fázi analýzy.

2.1 ZÁKLADNÍ POŽADAVKY NA RS A JEHO FUNKCE

• Redakční Systém bude provozován pouze ve vnitřní části informačního Systému zadavatele (LAN, DMZ), který má konektivitu do internetu.

• Pro potřeby správného fungování je zamýšleno tolik instancí CMS, aby bylo zajištěno dostatečné bezpečné oddělení správy obsahu veřejných webových prezentací od správy neveřejných webových prezentací. Instance CMS pro fungování veřejných webových prezentací xxx.xxx.xx a xxx.xxxxxxx.xx. A instance CMS pro provoz neveřejné webové prezentace, jehož jednosměrná kopie bude provozována v DMZ. Konečný počet instancí bude výsledkem fáze analýzy této VZ.

• Zadavatel požaduje úpravy v redakčním Systému v nativním režimu RS, ale i ve WYSIWYG módu, pokud tento není nativním režimem RS.

• Součástí musí být workflow od vytvoření, přes schválení, až po prezentaci webové úpravy.

• Správa více domén formou projektů (xxx.xx, xxxxxxx.xx, atd.).

• RS musí být schopen vést změny v souborech a textech. Systém musí být schopen zobrazit rozdíly mezi jednotlivými verzemi textových souborů, článků, příspěvků atd.

• V RS musí být možné vyhledávat články podle jejich data publikace, názvu článku, případně dalších parametrů.

• V modulu Aktuality se bude po předem stanovenou dobu zobrazovat nadpis s krátkým úryvkem nově publikovaného článku. Při kliknutí na aktualitu dojde k přesměrování na článek, o kterém pojednává.

• Zavést modul Kalendáře, který bude zobrazovat daný měsíc s rozlišením dnů. V kalendáři budou vyznačeny Akce a Události.

• Zavést modul Akce a Události, který bude provázán s modulem Kalendář. Zadavatel požaduje barevné vyznačení dnů v modulu Kalendář, ve kterých se bude konat akce či událost.

• Jazykové mutace – zadavatel požaduje, aby struktura webové prezentace byla připravena ve dvou jazykových verzích (Čj a Aj). Systém musí být připraven na další případné rozšíření o nové jazyky. Při tvorbě a publikaci nového článku musí být umožněno vytvoření jeho varianty v jiném jazyce (Čj, Aj). Čtenáři webové prezentace (ve veřejné i neveřejné části) musí mít možnost měnit jazykovou verzi (mutaci) zobrazení.

• Zadavatel požaduje pro DMZ zavést funkcionalitu jak fulltextového vyhledávání, tak i vyhledávání pomocí klíčových slov v rámci webové prezentace.

• V případě statické HTML 5 verze stránek je počítáno s dvěma možnostmi vyhledávání. První možností je využití externího vyhledávače (např. Google iFrame), nebo využití indexovacího Systému Xxxxx.

• Zadavatel požaduje, aby bylo možné vyhledané záznamy řadit podle určitých kritérií (čas, téma, autor, atd.).

• Každému uživateli (hlavně v DMZ) bude předem určeno, které informace bude moci vyhledávat a které pro něj nejsou přístupné.

• Zadavatel požaduje automatické generování přehledné struktury webu – tzv. sitemap s aktivními odkazy na jednotlivé části webu.

• Zavést stránku s FAQ, přehledně ji rozdělit dle jednotlivých kategorií (např. XxxXXXX.XX, KII, VIS atd.). U jednotlivých dotazů na stránce FAQ musí být připojen odkaz na část webu, které se dotaz týká.

• Hromadná e-mailová notifikace - zadavatel požaduje zavést funkcionalitu, která bude dle definovatelných kritérií jednotlivé uživatele Systému informovat o změnách a novinkách pomocí hromadného rozesílání e-mailových zpráv. Upozorňovat se bude buď na samostatné články, nebo na balíčky dat, které budou důležité. Pro notifikace budou zavedena tyto kritéria:

o Role – jiné notifikace pro čtenáře (příp. skupinu čtenářů), redaktora, administrátora.

o Typ – typ změny, například Nový článek, Změna článku, Smazání článku.

o Popis – obsahuje Nadpis článku, kterého se notifikace týká, případně krátký předdefinovaný text.

o Notifikace bude rozdělena na dvě základní. První je notifikace tzv. „urgentní“, která bude určena pro naléhavé případy, kdy je nutné okamžitě informovat

o změnách, hrozbách nebo jiných důležitých informacích.

o Druhým druhem notifikace je „obecná“, kdy budou v předem stanovených časech rozesílány informace o novinkách, hrozbách a dalších důležitých věcech.

Součástí obecné notifikace pak bude také notifikace urgentní, pokud ten den byla odeslána.

o Notifikace si bude každý uživatel moci zapnout a vypnout podle svého uvážení.

o Zadavatel požaduje u notifikací shodného typu, zavést určitý stupeň agregace. Přínos Zadavatel očekává v menším počtu notifikačních emailů k odběratelům notifikací. Agregace je požadována hlavně u druhu notifikace „obecná“

• Možnosti navigace - přidání kontextové navigace (automaticky vs. ručně), drobečkové navigace.

• Možnost generování kontextového obsahu dle obsahu hlavního.

• Vytváření štítků obsahu (tagování) - možnost vytvářet nové štítky pro jednotlivé články, ale jejich přednastavené přidávání podle příslušnosti článku k určité sekci či seznamu.

• Možnost exportovat vybrané články. (rss, xml, sitemaps).

Webová prezentace / projekt:

• Zadavatel požaduje, aby struktura a grafické ztvárnění webových prezentací bylo uživatelsky přívětivé.

• Vytváření webových prezentací - určeno pro práci řádově jednotek techniků, kteří velmi dobře znají prostředí Systému - bude realizováno formou webového rozhraní nebo přímé editace souborů na souborovém Systému.

• Redakční Systém musí být schopen spravovat několik webových prezentací současně. Každá webová prezentace bude vedena ve formě projektu, přičemž každý projekt má přiřazenu webovou prezentaci, uživatele včetně vlastního schvalovacího schématu, vlastní workflow a nastavitelný režim exportu úprav webových prezentací na předem definovanou webhostingovou službu.

• Vytváření webových prezentací by mělo být možné jak pomocí webového rozhraní, ve kterém lze weby a jejich sekce relativně jednoduše “naklikat” bez nutnosti psaní PHP skriptů, tak i přímou editací souborů (HTML, CSS, JS) na souborovém Systému včetně zvýraznění syntaxe, která může poskytnout větší komfort při tvorbě a editaci výsledné webové stránky. Systém musí poskytnout stoprocentní kontrolu nad frontendem webu s možností libovolných úprav vlastními silami.

• Tuto činnost bude zajišťovat skupina řádově jednotek techniků dokonale seznámených s redakčním Systémem na této úrovni.

• Systém musí umožnit vytváření seznamů článků od uživatelů, které později schválí hlavní redaktor. Tyto články se po schválení automaticky vystaví podle zvolených parametrů (prezentace, kategorie, atp.).

Obecná správa obsahu

• Webové rozhraní pro správu obsahu musí být stabilní, jednoduché a jednoznačné. Musí umožnit spravovat všechna data, se kterými se v redakčním Systému pracuje. Jde zejména o:

o uživatele, skupiny a oprávnění,

o články, aktuality, obrázky, audia, videa a obecné soubory.

• Je nezbytné, aby Systém umožnil volně definovat jak strukturu obsahu, tak i odpovídající vazby mezi těmito daty.

• S tímto rozhraním bude pracovat největší množství uživatelů – řádově desítky.

Grafická podoba webových prezentací:

• Zadavatel požaduje, aby grafická podoba a design webových projektů odpovídala vizuálnímu stylu organizace zadavatele, včetně log, barev a fontů.

• Očekávaný návrh grafické předlohy, včetně log, barev a fontů dodá zadavatel v předem dohodnutém formátu a termínu (v rámci fáze analýzy).

• Zadavatel požaduje, aby počet diskuzí nad grafickou podobou a následnou iterací nebyl omezen do plné spokojenosti zadavatele.

Obr. 2: Grafický návrh nově zamýšlené webové prezentace xxxxxxx.xx.

• Návrh grafické podoby a struktury webových projektů může být ještě dále upraven podle výsledků analýzy.

• Stejná grafická podoba je zamýšlena také pro potřeby neveřejného webu, kde bude tato struktura rozšířena o položky jako fóra, data ke stažení, blog zaměstnanců a odkazy na e-learning.

• Obr. 3: Předběžný návrh struktury webové prezentace xxxxxxx.xx.

Jádro RS (backend)

• Přímé ovlivňování základních funkcionalit Systému - bude přístupné pouze několika málo určeným vývojářům. Musí poskytovat možnost zásadního rozvoje Systému (v souvislosti s vývojem informačních technologií a tomu odpovídajícímu rozšiřování požadavků zadavatele na nové funkcionality Systému).

• Mělo by být přístupné pouze omezené skupině vývojářů, kteří budou přímo upravovat funkcionality Systému. Redakční Systém, tedy musí poskytovat možnost vývoje backendu programátorům zadavatele.

Správa uživatelů

• Správce Systému – zajišťuje základní správu a konfigurace nabízeného řešení, které nespadají pod žádnou jinou již zmiňovanou roli. Dále vytváří dle požadavků Zadavatele uživatelské role a skupiny v provozovaném IDM Zadavatele, které následně užívá nabízené řešení k autentizaci a následné základní autorizaci uživatelů řešení. Detailní úroveň přístupů a oprávnění se již spravuje v rámci RS. Podrobnější správcovská úroveň bude předmětem fáze analýzy.

• Správa uživatelů bude společná pro celé řešení a všechny projekty v něm realizované.

• Všichni správci RS (redaktoři, šéfredaktor), kteří jsou přiřazeni do rolí v Systému, se připojují k redakčnímu Systému dvěma způsoby. Pokud je pracovník mimo dosah

informačního Systému zadavatele (mimo prostory), připojuje se pouze a jen za užití bezpečného přístupu do IS zadavatele a to v xxxxxxxx xxxx xxxxx xxxx XXX x xxxxxxxx 0 – faktorové autentizace (tuto funkcionalitu zajišťuje Zadavatel a proto není součástí předmětu plnění této VZ). Pokud je pracovník v dosahu informačního Systému zadavatele, přistupuje přímo z infrastruktury Zadavatele.

• Redakční Systém by měl vyhovovat současnému způsobu spravování webových stránek. Je nastaven jeden určený „Šéfredaktor“ (ŠR), u kterého je nastavena možnost zástupu v případě nepřítomnosti. Jemu je následně podřízeno 10 až 15 redaktorů za jednotlivé organizační celky úřadu (např. OTPVV, XxxXXXX.XX, OPL, OIT, OM,…).

• Snahou je, aby měli redaktoři možnost sami vkládat a editovat informace, které na webu zveřejňují. Článek by sami naformátovali a následně odeslali ke zveřejnění. Šéfredaktor by jejich zveřejnění schválil.

• Pro potřeby správného ovládání CMS ze strany redaktora bude požadováno vytvoření materiálů využitelných při školení nových zaměstnanců, kteří budou na stránky vkládat články a provozovat blogy. Další možností je uspořádávání opakovaných a nárazových školení pro zaměstnance ze strany Dodavatele CMS.

• Redakční Systém musí podporovat různé role pro jednotlivé projekty, např.: autor, schvalovatel, redaktor, aj.

• Systém si musí pamatovat osobní nastavení konkrétního uživatele.

• Přístup do redakčního Systému musí být zabezpečený tak, aby se redaktor mohl přihlásit i mimo vnitřní informační Systém zadavatele, ale zároveň byl vyloučen přístup neautorizovaných osob.

• Správce Systému může libovolně spravovat jednotlivé uživatele, třídit je do uživatelských skupin dle definované hierarchie a přidělovat jim oprávnění k editaci / čtení / publikování příspěvků na konkrétních webech nebo rubrikách.

• Zadavatel používá pro autentizaci a autorizaci uživatelů RedHat IDM IPA ve verzi na RHEL

7.1 s následným updatem na aktuální stabilní verze. Jedná se o LDAP a Kerberos

autentifikaci. Více informací je možné nalézt zde:

• xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxxxxxxx/xx- US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_ Policy_Guide/index.html

• DEMO: xxxx://xxx.xxxxxxx.xxx/xxxx/Xxxx

• xxxx://xxx.xxxxxxx.xxx/xxxx/Xxxx_Xxxx

CMS převezme uživatele včetně umístění ve skupinách a dle toho po autentizaci zajistí autorizaci v CMS (přiřazení do role/í dle členství uživatele ve skupině/nách v IDM).

• Konfigurovatelná funkcionalita automatického informování schvalovatelů a vyšších rolí o novém, či upraveném obsahu v RS.

• Uživatelské skupiny mohou mít různá nastavení a také různá práva pro práci v redakčním Systému a následně v celém webovém portálu.

• V případě zastavení uživatelského účtu, kdy není možné vkládat nové články, zůstanou zachovány dosud vložené.

• Každý uživatel je zařazen do určité skupiny. Autoři, Redaktoři, ŠR (obecně zaměstnanci s právem zásahu do CMS) budou ve skupině X. Ostatní uživatelé (Čtenáři) budou rozděleni do skupin A až N. Označení skupin písmeny není závazné, Dodavatel může navrhnout vlastní řešení označení.

Obr. 4: Hierarchie rolí uživatelů pro jednotlivé projekty

Rozlišení vztahu uživatele k článku:

• Redakční Systém musí rozlišovat více identifikátorů autorství. Základní typy jsou:

o Autor – ten, kdo obsah fyzicky vytvořil, může jich být i více, není uživatelem Systému. Zadavatel požaduje, aby v CMS byla zavedena databáze autorů, která se bude plnit postupně při vkládání článků. Pokud bude vkládán článek, jehož autor je již v databázi, bude možnost zvolit jeho jméno z nabídky. Pokud autor dosud v databázi není, jeho jméno se manuálním zadáním do příslušného pole se zároveň s potvrzením akceptace do databáze přidá.

o Redaktor – ten, kdo obsah textově nebo jinak upravil do podoby pro web a vložil autorův příspěvek do RS. Odpovídá za jeho formální podobu a správné vydání. V závislosti na okolnostech může, ale nemusí být totožný s autorem. Autorem i redaktorem mohou být i provozované a vyvíjené aplikace zadavatele.

o Šéfredaktor – ten, kdo schvaluje vložené příspěvky do redakčního Systému a aktivuje jejich publikaci. V závislosti na okolnostech může, ale nemusí být totožný s autorem i redaktorem. V případě nepřítomnosti může stanovit některého z redaktorů svým zástupcem, který dočasně získá práva ŠR. Šéfredaktor může nastavit některým aplikacím případně redaktorům, aby publikovali bez schválení ŠR.

Parametry článku:

• Redaktor/Autor se přihlásí do jednoho místa v rámci CMS, kde bude psát a upravovat své články. Když napíše článek, vybere si, na kterých projektech chce článek zveřejnit

• Rozlišujícím a rozhodným identifikátorem článku je jeho unikátní číselné ID.

Číselné ID se přiřadí automaticky při založení článku, uživatel ani administrátor ho neovlivňuje.

• Autor/Autoři, ten kdo vytvořil obsah.

• Redaktor, který upravuje a vkládá text do RS.

• Titulek, s možností pozdější změny v důsledku vývoje zprávy.

• Xxxxx

• Xxxxxxxx fotografie s možností vybrat zobrazovaný výřez.

• Tělo článku – jednolitý text – WYSIWYG editor umožňující vkládání obrázků a definování jejich pozice v textu, vkládání videozáznamů, map a dalších objektů z katalogu objektů i externích zdrojů.

• Plnohodnotný WYSIWYG editor lze nahradit jednoduchým editorem podporujícím základní HTML (formátování textu, odstavce, tabulky, číslované a odrážkové seznamy). V každém případě je nutné mít možnost přehodit obrázek, zvuk nebo dokument v článku k jinému odstavci prostým přetažením myší.

• Datum vydání

• Datum aktualizace

• Datum expirace – datum a čas, od kterého nebude článek nadále dostupný na webu a bude dohledatelný jen v redakčním Systému.

• Obsah ze šablony – uložení článku jako šablony pro vytváření nových článků (typicky zápisy z jednání, apod).

• Klíčová slova – tagy označující článek, vytvářející příbuznost s dalšími články, přičemž je možné v jednom kroku na základě automatického doplnění potvrdit více klíčových slov.

• Zařazení do rubriky (publikace bude možná jen do rubriky, která odpovídá uživatelským právům).

• Možnost odložené publikace (nastavení konkrétního dne a času, kdy se má článek zpřístupnit veřejně a ve vyhledávání).

• Možnost živého náhledu v aktivní grafice webu, včetně takové formy náhledu, která umožní kontrolu textu i osobám, které nejsou uživateli redakčního Systému (např. formou dočasného odkazu, apod.).

• Možnost příloh v různých formátech (*.doc, *.xls, *.pdf, *.tiff, *.zip a dalších).

• Přiřazení fotogalerie, zvukových záznamů a/nebo videogalerie na konkrétní pozici v textu. Podpora přehrávání zvuků a videozáznamů v HTML5. Zadavatel v současné době nevyužije, ale musí počítat i s touto variantou.

• Nastavení vazeb článku – přiřazení souvisejících článků (automatické nebo ruční), vytváření skupin článků na obdobné téma napříč rubrikami a sekcemi webu.

• Povolení/zakázání diskuse a konkrétních příspěvků, uživatelů a výrazů v diskusi, včetně možnosti schvalování vložených komentářů a zabezpečení proti spamu, a také notifikací nového příspěvku. Zadavatel v současné době diskuzi nevyužije, ale musí počítat i s touto variantou.

• Notifikace – Defaultně „normální“. Možnost nastavit stav na „urgentní“, kdy dojde k okamžitému odeslání hromadné e-mailové notifikace po schválené publikaci článku.

• Jazyková mutace – výchozí je česká, ale článek může mít vícejazyčné varianty.

• Zvláštní typy odstavců – vložení rámečku s citací a rámečku s výčtem faktů.

• Zobrazení „článek v článku“ – vložení jednoho článku do druhého, typicky pro často opakovaný background, který stačí napsat jednou.

• Automatické úpravy obrázků při vkládání do textu (zmenšení velikosti, vytvoření náhledu v galerii).

• Možnost zobrazit obrázek na šířku textu, tedy bez obtékání.

• Blokování souběžné editace dvěma různými uživateli, informace o aktuálním uživateli, převzetí editace uživatelem s vyššími právy.

• Označení, že článek prošel korekturou/editací – volba dostupná jen uživatelům na úrovni korektor.

• Možnost nastavit podmíněný přístup k textu jen pro registrované uživatele webu

• Umístění článku – Autor si při editaci či tvorbě článku zvolí (zaškrtne), kde má být článek vystaven. Na výběr bude mít možnost vybrat všechny nebo jen některé z existujících projektů (nbu, govcert, neveřejný web).

• Nastavení priority (neviditelný parametr, který určí pozici článku na stránce a přebije tak výchozí chronologické řazení – např. „zpráva dne“, která je v průběhu dne aktualizována).

• Každá změna článku se ukládá a je možné dohledat, kdo provedl jakou změnu. Dále je možné porovnávat změny mezi různými verzemi článku. Při smazání článku se staré verze nemažou.

• Článek si nese log s informacemi o tom, kdo z uživatelů redakčního Systému k němu přistupoval, upravoval ho, nebo zrušil jeho vydání.

Import článků

• Podpora importu ze souborů typu: doc, docx, odt, txt a pdf s možností odstranění nadbytečného formátování nebo vykopírování samostatného textu

• Samotný Systém by měl být schopný umístit text do předem připravené šablony bez nutnosti dalšího formátování. Možností by bylo vytvořit šablonu pro vkládání článků do Systému. V této šabloně by byl odlišen název, autor, tělo článku a další již popsaní náležitosti článku, tak aby bylo co nejjednodušší článek na web vložit.

Workflow schvalovacího procesu článků

• Redaktor vloží článek (text, soubor) do CMS, kde vyplní potřebná metada (např. autora).

Pokud je se stavem rozpracovaného článku spokojen, odešle jej ke schválení

šéfredaktorovi. Šéfredaktor článek schválí a publikuje, nebo vrátí zpět redaktorovi k přepracování.

Stavy článků a dalších objektů

• Publikovaný objekt (veřejně přístupný)

• Rozpracovaný (připravený k vydání, ale dosud neschválený, a tedy neveřejný)

• Koncept (objekt vyžadující další editaci, neveřejný)

• Seznam smazaných článků

Správa zdrojů

• Zdroj je původce zveřejněného materiálu. Zdroj je povinná položka.

Objem a charakter dat

• Webová prezentace bude v neveřejné části rozšířena o další funkcionality, jako například diskuzní fóra, aktuality, FAQ, blogy zaměstnanců, připravené balíky dat pro stažení aj. Návštěvníci stránek, si budou moci z veřejných i neveřejných webových stránek stáhnout nabízené soubory, formuláře, ale i velké soubory (xml, csv, zip, json, pdf) o velikosti do cca 1 GB.

• Redakční Systém musí bez problémů zvládat práci s výše uvedeným obsahem dat. Kromě samotné prezentace dat návštěvníkům jde také o rychlou možnost administrace, včetně nejrůznějšího třídění, řazení a filtrování.

• Diskuzní fórum (DF) – moderované fórum v DMZ pouze pro registrované uživatele (čtenáře). Forum bude rozděleno na několik cvhatovacích místností. Jedna místnost je společná pro všechny uživatele. Další místnosti budou mít uživatele podle svého zaměření a určení v rámci Systému (např. energetika, státní správa, atd…). Každý uživatel bude mít přesně specifikováno, do které místnosti může vstoupit. Uživatelé budou v rámci fóra moci přidávat příspěvky a komentáře, ale ne tvořit místnosti. Tvorba místnosti bude plně v moci správce fóra.

o Typy uživatelů:

Čtenáři - účastníci diskuze budou mít možnost číst, editovat a mazat pouze své příspěvky v místnostech, do kterých budou mít přidělený přístup od Moderátora.

Moderátor – uživatel minimálně s rolí Redaktor, který bude mít možnost číst, editovat

a mazat všechny příspěvky, omezovat či povolovat přístup uživatelům do jednotlivých místností. Přístup do diskuzních místností bude odpovídat přístupům skupin v DMZ, proto nebude třeba dalšího přihlašování do diskuzního fóra. Moderátor může nastavit jiného uživatele s rolí Redaktora svým zástupcem v případě své nepřítomnosti.

o Diskusní místnosti – možnost vytvořit Moderátorem místnost pro danou skupinu, či skupiny uživatelů. Jednotlivé diskusní místnosti budou pro 1 až N určených skupin, z nichž jedna bude otevřená všem uživatelům.

o Místnost společná - pro všechny skupiny uživatelů (1 až N)

o Místnost 1 – pouze pro některé skupiny uživatelů (např. 1, 3 a 7)

o Místnost N – pouze pro některé skupiny uživatelů (např. pouze pro skupinu 4)

• Blog zaměstnanců – jednoduchá statická webová stránka, která bude stejná jako ostatní stránky. Blog je zde chápán jako obyčejný textový článek s možnými vloženými obrázky. Články zde budou publikovány se stejným workflow (redaktor – šéfredaktor) jako ostatní články na webu. Řazeny za sebou časově s možností vyhledávání a řazení dle jména autora, názvu článku, data vložení případně jiných metadat článku. Možnost zobrazení profilu zaměstnance (autora).

• E-learning – tvorba e-learningu nebude součástí projektu k řešení, nicméně požaduje návrh možné provázanosti s CMS (formou odkazu, vnořeného okna, pluginu atp..).

V budoucnu plánuje zadavatel využití open source learningového Systému Ilias, který splňuje požadavky na provoz e-learingového portálu a také bezpečnostní požadavky. Tento Systém bude v budoucnu propojen s CMS od Dodavatele. Propojení mezi CMS a e- learningovým Systémem je plánováno na úrovni řízení přístupu a databáze uživatelů,

která by měla být jednotná pro celou DMZ. Také grafická podoba uživatelského rozhraní e-learningového Systému by měla působit jednotně vzhledem ke grafické podobě CMS.

• E-learning – integrace – zadavatel požaduje, aby měl uživatel na svém profilu v DMZ k dispozici informace o postupu (progresu uživatele) v rámci e-learningvého kurzu. Toto je plánováno v rámci zjednodušení uživatelského rozhraní. Uživatel zde bude mít také možnost nastavit si zasílání e-mailu s upozorněním na změny v e-learningu jako jsou nové kurzy, odstávka Systému, atd… Další míra integrace vyjde z uskutečněné analýzy v rámci etapy A v harmonogramu.

• Statistika – pro získávání a vyhodnocování statistických údajů lze využít stávající řešení v podobě Google Analytics nebo AVStac. Přístup k nim budou mít pověřené osoby.

• Úložiště dat – bude sloužit pro ukládání souborů, které si budou moci uživatelé ve vnitřní síti stáhnout v rámci svého přístupu do určitých částí. Toto úložiště bude v prostředí zadavatele a splňuje bezpečnostní náležitosti. Úložiště dat bude stejně jako CMS s neveřejným webem jednosměrně kopírováno do DMZ.

• Vlastní CMS pro projekty (nbu, govcert) a samotný neveřejný web

• Zrcadlová kopie CMS pro neveřejnou část v DMZ

• Statická HTML verze prezentací pro veřejnou část

• Vstupy do RS

• Interní LDAP, AD oba s Identity managementem

• Zálohovací Systém

• Monitorovací Systém Vlastní CMS

• Hlavní úlohou CMS je správa tzv. projektů. Projektem je myšlen souhrn pravidel,

nastavení a správa webové prezentace. Každý webový projekt musí využívat nativní nastavení CMS (zdroje informací, uživatelé, role, schvalovací proces, exportovací režim a napojení na webhostingovou službu).

• Dodavatel se zavazuje dodat plnohodnotný dokument popisující API rozhraní nabízeného CMS, který zadavatel potřebuje při vývoji vlastních aplikací, které budou komunikovat s nabízeným CMS.

• CMS musí mít integrovaný kontrolní mechanismus jednotlivých projektů a to na úrovni webových prezentací. Zadavatel tím požaduje, aby v rámci CMS byly prováděny v nastavitelných intervalech (v rozsahu 1 – 120 minut) kontroly obsahu jednotlivých webových prezentací, a v případě neshody se provede záloha rozdílu, její přepis požadovanou / správnou prezentací a bude emailem vyrozuměn určený redaktor daného webového projektu.

• Zadavatel požaduje zavést funkcionalitu, která provede změnu dílčích webových stránek (veřejných i neveřejného webu) okamžitě po publikaci nového článku v CMS.

• CMS Systém musí podporovat zabezpečenou komunikaci (definovanou dále v tomto dokumentu) mezi částí, která je provozována v interním informačním Systému komunikujícím do internetového prostředí a modulem na straně poskytovatele webhostingu.

• Zadavatel požaduje po Dodavateli kompletní bezpečnostní nastavení CMS a jeho popis.

• Zadavatel provede penetrační testování (aplikace), nezávislou formou na vlastní náklady. Přičemž na základě výsledku testu provede Dodavatel dodatečná nastavení a následně bude opět proveden penetrační test. Proces ověřování / testování se může opakovat.

• Zadavatel požaduje vytvoření zálohování na vlastní síti (v prostředí zadavatele), viz kapitola Zálohování.

• Zadavatel požaduje vytvoření návodu pro správné zálohování a obnovování dat. Zároveň zadavatel požaduje v rámci testovací fáze odzkoušet způsob zálohování a obnovování.

Zrcadlová kopie CMS pro neveřejnou část v DMZ

• Tato část bude řešena jako separátní jednosměrná samostatně funkční kopie vlastního CMS. Veškeré změny v hlavním CMS se budou projevovat v této kopii, ale ne naopak. Jde tedy jen o jednostranné propojení. Samotný export neveřejného webu do DMZ bude probíhat po každé změně v CMS a to pouze u dílčích stránek, které se změna týká. Dále

• Tato část prezentace bude čtenářům přístupná pouze po předchozím přihlášení. Bude mít vlastní DB čtenářů, včetně možnosti jejich kategorizace podle definované hierarchie, možnost ukládání nastavení profilů pro jednotlivé uživatele (customizace individuálního nastavení).

• Zejména zde bude vyžadována pro jednotlivé uživatele a skupiny uživatelů možnost nastavení zasílání informací, sdílení obsahu, včetně dat ke stažení, jak pro jednotlivé kategorie uživatelů, tak pro uživatele jednotlivě.

• V rámci této neveřejné části CMS je kromě zasílání, sdílení a stahování zpráv, plánováno také provozování plně funkčních e-lerningových modulů, kde bude kromě prohlížení obsahu také vyhodnocování úspěšnosti pro jednotlivé uživatele, kteří připravené kurzy absolvují. Databáze těchto uživatelů bude zálohována. Pro správu obsahu e-learningu bude použit open source e-learningový Systém, který splňuje podmínky pro provozování e-learningového portálu.

• Zadavatel požaduje po Dodavateli vytvoření vlastního zálohování pro databázi uživatelů a diskuzního fóra.

• Principiálně uživatelé (redaktoři, šéfredaktor) vytvoří své články ve vlastním CMS, rozhodnou se (nastaví), zda a v kterých projektech (veřejný web, neveřejný web) budou publikovány. Pokud mají být zobrazeny na neveřejném webu v DMZ, projeví se tyto změny po synchronizaci v zrcadlové kopii CMS, ke kterému budou mít teprve přístup čtenáři.

• V případě Správy Uživatelů a správy Diskuzního fóra na neveřejném webu v DMZ, bude administrátor přistupovat k těmto modulům přímo (po přihlášení) v DMZ.

Statická HTML 5 verze prezentací pro veřejnou část

• Webové prezentace (projekty) určené pro veřejnou část na straně webhostingu musí být z CMS exportovány pomocí nástroje či modulu, který umožňuje jejich převedení na čistě statickou HTML stránku. Zadavatel požaduje, aby Dodavatel tento nástroj či modul naprogramoval.

• Zadavatel požaduje, aby se každá změna (např. nový článek, jeho změna apod.) v projektech webových stránek xxx.xx nebo xxxxxxx.xx co nejdříve projevila i ve statické prezentaci. Update statických stránek bude probíhat pouze záměnou té konkrétní vybrané HTML stránky, na které došlo k nějaké změně.

• Zadavatel požaduje, aby nabízené řešení umožňovalo propojení jednotlivých webových projektů formou odkazu. Při editaci projektu musí být tedy přístupné informace

z ostatních webových projektů, pro vlastní vytvoření takového požadovaného webového odkazu, v právě editovaném webovém projektu.

• Zadavatel požaduje, aby tyto statické prezentace co nejpřesněji reflektovali skutečný vzhled originálu. Navrhovaná nová struktura webu xxxxxxx.xx je zobrazena na Obr. 3.

Vstupy do RS

• Vstupem do RS mohou být importované články, vlastní články z PC a mobilních zařízení. Dále mohou být zdrojem informací i aplikace provozované a vyvíjené zadavatelem. Zadavatel považuje za důležité, aby v rámci projektu bylo možné nastavit, zda aplikace, která je zdrojem informací je natolik důvěryhodná, že může prezentovat generované informace ihned bez schvalovacího procesu či nikoliv. Pokud informace není určená ihned k prezentaci, musí se informace ukládat do tzv. pořadníku určeného k postupnému schvalování. Toto platí i pro všechny ostatní zdroje informací.

Interní LDAP + IM

• Nabízený CMS musí podporovat Systémy LDAP a AD včetně Systému identity management. Zadavatel v současné době provozuje IPA server od RedHat, RS tedy musí být plně kompatibilní se stabilní verzí IDP IPA a podporovat zabezpečenou a šifrovanou komunikaci, přičemž RS musí podporovat i jiná řešení. Role, uživatelé a skupiny CMS budou definovány v těchto Systémech. Jejich kategorizace vyžaduje hierarchickou strukturu.

• Nabízený CMS musí při přihlašování využívat Kerberos ve všech podporovaných nastaveních společností RedHat pro RHEL 6 a 7 a IPA server verze 4.0 a vyšší a Microsoft pro WIN7 a vyšší a WIN Servery 2008 a vyšší.

• Zadavatel používá pro autentizaci a autorizaci uživatelů RedHat IDM IPA ve verzi na rhel

7.1 s následným updatem na aktuální stabilní verze. Jedná se o LDAP a Kerberos

autentifikaci. Více informací je možné nalézt zde:

• xxxxx://xxxxxx.xxxxxx.xxx/xxxxxxxxxxxxx/xx- US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authe ntication_and_Policy_Guide/index.html

• DEMO: xxxx://xxx.xxxxxxx.xxx/xxxx/Xxxx

• xxxx://xxx.xxxxxxx.xxx/xxxx/Xxxx_Xxxx

CMS převezme uživatele včetně umístění ve skupinách a dle toho po autentizaci zajistí autorizaci v CMS (přiřazení do role/í dle členství uživatele ve skupině/nách v IDM).

Zálohování

• Zadavatel požaduje, aby bylo umožněno provádět automatické zálohování všech částí Systému na bázi zálohování souborů. V případě databází připravit exportovací skript pro vytvoření zálohy databáze.

• Jednotný zálohovací Systém bude pro JÁDRO CMS i pro kopii CMS v neveřejné části

• Zadavatel využívá pro zálohování řešení EMC Networker. Dodavatel musí zajistit nejméně jednu z následující možností zálohování.

• Zadavatel vyžaduje ukázku zálohování CMS.

o zajištění zálohování pomocí klienta EMC Networkeru tak, že je zajištěno, že veškerá data jsou v kompletní a konzistentním stavu. Bývá řešeno přístupem na API dodaného produktu.

o zajištění zálohovaní pomocí metody implementované v produktu, které vytvoří soubor(y)/adresář s obsahem klíčových dat pro obnovu dat a obnovu plné funkčnosti

o zajištění zálohování pomocí skriptu, které vytvoří soubor(y)/adresář s obsahem klíčových dat pro obnovu dat a obnovu plné funkčnosti

• Záloha musí být provedena tak, aby nedošlo k ovlivnění či výpadku dodaného Systému. Výpadkem se v tomto znění myslí, že na straně uživatele nebude zálohovací proces patrný. Záloha zároveň musí být provedena, i pokud bude k dispozici pouze jeden prvek v zapojení v HA.

Požadavky na logování

• Zadavatel požaduje, aby standartní i nestandartní události byly logovány dle norem řady ISO 27k.

• Systém musí splňovat požadavky na logování dle zákonu č. 181/2014 Sb., o kybernetické bezpečnosti a zároveň následující body.

• Zadavatel požaduje, aby Systém zaznamenával a logoval minimálně události typu:

o akce uživatelů

o akce administrátorů

o změny konfigurace,

o nestandardní stavy Systému,

o bezpečnostní informace

o auditní log

• Dodaný Systém musí umožňovat zasílání logů pomocí syslogu na libovolný server.

• Zasílaný Log musí být v CEF (Common Event Format) formátu, nebo obdobném strukturovaném formátu s dostupnou Dokumentací.

Monitorovací Systém

• Funkčnost dodávaného softwarového celku musí být možné automaticky testovat.

• Pro kontrolu funkčnosti a stavu zadavatel používá software Nagios.

• Zadavatel předpokládá, že softwarový celek je poskládán z jednotlivých bloků, které vykonávají určitou činnost.

• Zadavatel požaduje, aby bylo možné pomocí Systému Nagios kontrolovat jednotlivé bloky.

• Například, pokud softwarový celek využívá služeb webového serveru pro zobrazení dat, musí být Nagios schopen ověřit stav této komponenty a její dostupnost.

• Zadavatel požaduje poskytnutí návodu nebo součinnost při implementaci těchto kontrol do stávajícího Systému Nagios zadavatele.

• Verze Systému Nagios je 3.5.1 na Systému RedHat Enterprise Linux 7.0 a vyšším.

• Zadavatel dále požaduje, aby způsob kontroly nebyl pevně svázán s konkrétní verzí operačního Systému nebo Nagiosu.

• V případě dodání vlastního pluginu tento plugin nesmí používat jiný software, než je obsažen v oficiálních repozitářích RedHat Enterprise Linux 7.0 a vyšším.

• V případě dodání vlastního pluginu je Dodavatel povinen dodat zdrojový kód a kompletní Dokumentaci.

• Dokumentace k pluginu může být provedena i jako komentář v rámci zdrojového kódu.

• Vlastníkem zdrojového kódu pluginu se stává zadavatel.

• Návratové hodnoty při kontrole jednotlivých bloků i softwarového celku musí odpovídat návratovým hodnotám, které jsou uvedeny v Dokumentaci pro tvorbu modulů Nagios.

• Z návratového stavu v případě chyby nebo varování musí být možné identifikovat závadu bez nutnosti hlubší znalosti dohledovaného Systému nebo programu.

• Například, pokud nastane chyba při ukládání dat do složky, plugin vrátí chybový stav a text "Chyba při ukládání dat do /cesta/ke/složce".

• Automatické kontroly nesmí být schopny přístupu k citlivým údajům ani v případě selhání části nebo celého kontrolovaného Systému. Jako výsledek automatické kontroly nesmí být vrácen citlivý údaj (například adresát, odesílatel, text zprávy, heslo, certifikát, příloha a další)

2.2 TECHNICKÁ SPECIFIKACE

• Tato technická specifikace popisuje požadavky, které musí implementovaný Systém splňovat a funkcionality, které musí umožňovat. Zároveň jsou uvedeny základní technické požadavky na strukturu Systému a informace o IT Systémech provozovaných u zadavatele, se kterými bude instalovaný Systém spolupracovat (importovat data).

• Systém musí být schopen provozu na libovolné virtualizované HW infrastruktuře, splňující požadavky pro provoz Systému. (Musí splňovat obecné standardy umožňující provoz na libovolném standardním prostředí).

• Data se na webové servery ukládají pouze zabezpečenou cestou (sFTP, SSH, apod.)

• CMS musí podporovat bezpečné a šifrované napojení na adresářové služby (AD, LDAP, apod.). Zadavatel v současné době provozuje IDM IPA server od RedHatu, CMS musí být s tímto IDM plně propojitelný na úrovni autorizace, autentizace a hledání uživatelů, popřípadě emailových adres. IDM určuje, zda má uživatel právo přístupu a jeho roli (administrator, redaktor, autor). CMS určuje, kam má uživatel přístup.

• Navržené šablony pro webové prezentace musí být validní a kompatibilní se všemi majoritními webovými prohlížeči (Firefox, IE, Google-Chrome a jiné) na platformách, které tyto prohlížeče podporují.

• Navrhované šablony a export musí být validní podle HTML 5 Strict. Tato funkcionalita bude ověřena oproti validátoru na stránkách xxxxxxxxx.x0.xxx.

• Kódování stránky i ukládaná data musí být ve formátu utf-8 a nebo vyšším (utf-16, utf-32, apod.).

• Šablony a export by měly dbát na pravidla web content accessibility guidelines 2.0 od W3C pro podporu slabozrakých.

• Systém a jeho jednotlivé projekty včetně API musí být dostupný přes ipv6, ipv4 a přes protokol http a hlavně jeho šifrovanou variantu https.

• Systém by měl být odolný vůči známým zranitelnostem (SQL injection, XSS, session hijacking, atp…), Dodavatel by měl být schopen v této souvislosti poskytovat případné bezpečnostní aktualizace.

• CMS musí umožňovat automatické přesměrování na https.

Základní typy objektů, se kterými se pracuje:

• články, příspěvky

• fotografie a obrázky (v používaných formátech),

• různé typy rejstříků,

• xml struktury,

• csv struktury,

• videa (v používaných formátech),

• zvukové záznamy,

• fotogalerie,

• videogalerie,

• audiogalerie.

Požadavky na Infrastrukturu, Software a Hardware:

• Popis Hostingové služby Active24

U Active24 provozuje Zadavatel jeden fyzický dedikovaný server, s možností vytvoření několika VPS.

HW konfigurace serveru u Active24:

• DELL PowerEdge R420 TPM

• 1 ks CPU Intel® Xeon® E5-2407 2.20GHz

• 1 ks RAM 4GB

• 2 kusy 250GB, SATA, 2.5-in, 7.2K RPM Hard Drive (Hot Plug)

• Dual Hot Plug Power Supplies 350W Server je rozšiřitelný dle potřeb Zadavatele.

SW konfigurace u Active24:

• Linux Ubuntu

• Apache

• PHP

• MySQL, PostgreSQL

Popis dvou v současné době provozovaných virtuálních dedikovaných serverů VPS:

• Server xxx.xx běží na OS GNU/Linux. Verze PHP: 5.5.28

Nasazení až 100 cron tasků. Zakládání MSSQL i MySQL databází. SFTP a FTP, SSH: ano.

Disková kvóta: 5200MB - nyní obsazeno cca 1500MB.

• Server xxxxxxx.xx běží na GNU/Linux, Verze PHP: 5.5.28

Nasazení až 100 cron tasků. Zakládání MSSQL i MySQL databází. SFTP a FTP, SSH: ano.

Disková kvóta: 1200MB - nyní obsazeno cca 220MB.

• CMS musí reflektovat trend posledních několika let a musí tedy být schopen provozu ve virtualizované infrastruktuře zadavatele. Systém však nesmí být vázán na žádnou

placenou konkrétní virtualizační platformu.

• Neomezený počet virtuálních serverů RedHat Enterprise Linux 7.X (aktuálně 7.1)

• Maximální alokace paměti RAM pro servery CMS je 128GB

• Maximální alokace disku pro servery CMS je 1TB

• Možnost provozovat CMS v geograficky oddělených lokalitách (Praha, Brno), přičemž konektivitu mezi lokalitami zajišťuje Zadavatel, není tedy součástí této VZ.

• Zadavatel v současné době buď provozuje, nebo v době zavádění nového CMS Systému bude provozovat vlastními silami vyvíjené aplikační Systémy, se kterými bude nezbytné nový CMS provázat.

• V rámci technologické strategie NBÚ zůstává jako nosná platforma Linux.

Definice chybových stránek

• Možnost upravovat statické chybové stránky 401, 403, 404, 500 a 503 v CMS. V případě pokusu o využití starého nefunkčního odkazu, zobrazit chybovou hlášku s odkazem na hlavní stránku nebo s možností automatického přesměrování za určitou dobu na hlavní stránku. Toto vše se odvíjí od nastavení.

Meta Title

• Značka meta title musí splňovat následující požadavky:

o Administrátor webu by měl mít možnost značku title libovolně upravovat.

o Pokud není nastaveno jinak, měla by se meta title implicitně generovat podle nadpisu h1 dané stránky. Za oddělující značkou | by měl následovat název webu.

Struktura meta title by měla vypadat následovně Název stránky | Název webu.

Přístupnost pro roboty

• Web (zejména jeho navigace) nesmí být závislý na aktivovaných cookies ani na Javascriptu a Flash. Pokud web tyto technologie využívá, měl by nabízet odpovídající alternativu uživatelům, kteří tyto funkce nemají nainstalované nebo povolené (což platí i pro roboty vyhledávačů, pro které musejí být tyto stránky přístupné).

• Odkazy a navigace indexovatelných stránek by měly být řešeny výhradně HTML značkou

<a>. RS dále musí vytvářet mapu stránek a umisťovat ji do standardního umístění tak, aby byl k nalezení pro majoritní vyhledávače v České republice (Seznam, Google apod.).

• V případě navigace musí být počítáno se všemi důležitými klíčovými slovy. Jejich hustota musí být u každé stránky zohledněna vzhledem k jejímu obsahu.

• Konstantní obsah stránky (navigace, menu, atd…)musí být vzhledem ke konkrétnímu obsahu (text, media, atd..) ve vyváženém poměru.

• Samozřejmostí návrhu je správné využití elementů pro značení obsahu, využití meta tagů title, description a nadpisů H1 a dalších.

Unikátní obsah

• Každá stránka by měla mít metadata unikátní v rámci celého webu (obsah prvku title a meta description). Prvek title je povinný a měl by být tedy na každé stránce (a na každé s jiným obsahem), meta description povinné není, a pokud není možné zajistit, aby bylo na každé stránce jedinečné, může být vhodnější ho zcela vynechat. Metatitle i metadescription musí být ručně editovatelné.

• Aby se snížila pravděpodobnost, že vzniknou duplicity v metadatech, je třeba, aby Systém při snaze o uložení článku (stránky) se stejnými metadaty vygeneroval informaci o faktu, že meta title není unikátní.

• U stránek, jejichž obsah se liší jen uspořádáním (např. různě tříděné či filtrované s eznamy zboží) je vhodnější zvolit jednu variantu k indexaci a ostatní vyloučit z indexování ideálně pomocí robots exclusion protokolu (soubor robots.txt) nebo jinými prostředky (JavaScriptem, formuláři – zde již není zajištěna 100% úspěšnost). Systém musí u filtrovaného obsahu umožnit indexaci pouze jedné formy dané stránky a ostatní vyhledávačům zakázat.

• Na stránkách by se neměly objevovat samotné nadpisy uvozující bloky, ve kterých aktuálně není žádný obsah. Nejčastěji k tomuto problému dochází v navigaci, a také na stránkách se seznamy, které se dynamicky mění. Grafický návrh musí být v tomto směru dostatečně pružný.

Struktura URL

• Z praktických důvodů není vhodné, aby struktura URL odrážela hierarchickou strukturu webu a odkazovala na specifický skript nebo soubor. Při případných změnách na webu (např. změna názvu kategorie, přesun kategorie ve struktuře) pak dochází k nežádoucí změně URL u velkého počtu stránek. URL zachovávající hierarchickou strukturu webu mohou být také zbytečně dlouhá a častěji vedou k duplicitnímu obsahu. U každé stránky musí být zajištěna možnost libovolně modifikovat title, URL, název v navigaci, nadpis stránky (samozřejmě ne pro všechny uživatele CMS).

• V URL se nebudou vyskytovat žádné nadbytečné určující veličiny. Tyto veličiny bude obsahovat pouze stránka, na které bude možné vyhledávat nebo filtrovat její obsah. Identifikátor PHPSESSID se v URL.

Tvary URL by měly vypadat následovně:

• Úvodní stránka webu: xxxx://xxx.xxx.xx/. Úvodní stránka se zobrazuje přímo v rootu domény, není zde žádné přesměrování.

• Jazykové mutace: jsou umístěny v podadresáři nazvaném dle kódu jazyka, např. xxxx://xxx.xxx.xx/xx/.

• URL informačních stránek: obsahují vhodné klíčové slovo a jsou co nejkratší, např. xxxx://xxx.xxx.xx/xxxxxxx.

• URL hlavních sekcí: obsahují upravený název sekce, např. xxxx://xxx.xxx.xx/xxxxx-xxxxx.

• URL podsekcí: tvoří se analogicky jako názvy sekcí, tedy např. xxxx://xxx.xxx.xx/xxxxx- podsekce.

• URL stránek článků: obsahují název článku, např. xxxx://xxx.xxx.xx/xxxxx-xxxxxx-XX.

• URL stránek článků pro publikaci na twitteru vyžaduje co nejkratší délku, např. xxxx://xxx.xxxxxxx.xx/XX. Případně bude třeba vytvořit vlastní zkracované odkazy na principu xxx.xx.

• URL budou fungovat bez koncového lomítka. V případě zadání URL s lomítkem, dojde k automatickému přesměrování na URL bez lomítka.

Změna URL

• Pokud dojde ke změně URL, musí být zajištěno přesměrování staré adresy na novou realizované pomocí HTTPS hlavičky 301. U změn URL u článků musí dojít k přesměrování upravené adresy automaticky.

Jednoznačnost URL

• Je bezpodmínečně nutné, aby jedné URL vždy odpovídala právě jedna obsahová stránka. Problematický je jak stav, kdy na jedné URL je poskytováno více různých typů obsahu (např. různé jazykové verze na jednom URL) podle nastavení prohlížeče nebo obsahu cookies, tak případ opačný, kdy jedna stránka je k dispozici na několika různých URL (tzv. duplicitní obsah).

• Je třeba se vyhnout zvláště těmto případům porušení jednotnosti URL:

o Interní odkazy na úvodní stránku webu nesměřují na kořenový adresář domény (/), nýbrž jmenovitě na výchozí dokument (např. index.html).

o Pro výchozí (implicitní) variantu dynamické stránky se používá jak URL bez parametrů, tak URL s implicitními hodnotami parametrů. Tento problém se často vyskytuje u stránkování, kdy je první stránka často dostupná jak na URL bez údaje o čísle stránky, tak s údajem o čísle stránky 1.

o Stránky jsou paralelně dostupné pod více doménami třetího řádu, nejčastěji ve variantě bez www i s www na začátku.

o V URL je jako parametr zahrnut identifikátor session. Jelikož je pak při každé návštěvě robota vyhledavače URL jiné, k zaindexování webu v některých vyhledávačích vůbec nedojde.

Odstraněné stránky

• Pokud je z webu odstraněna stránka, mohou nastat tři situace:

o Stránka se přesunula na jinou adresu. V tomto případě je třeba nastavit přesměrování pomocí HTTPS kódu 301 z původní adresy na novou, a to automaticky při přesunutí obsahu.

o Existuje adekvátní náhrada/y původní stránky. V tom případě se původní stránka s původním obsahem ponechá na původní adrese. Do její horní části se velmi zřetelně vloží upozornění, že daný obsah již neplatí, a odkazy na stránku/y s adekvátní náhradou.

o Stránka byla zrušena bez náhrady. V tomto případě se vrátí stavový kód 404 a vhodná

404 stránka s upozorněním, že stránka byla zrušena (nebo nikdy neexistovala), a se základní navigací webu.

3. POŽADAVKY NA PODMÍNKY SERVISNÍ PODPORY

• V průběhu procesu migrace zajistit provoz Hotline služby s následujícím minimálním rozsahem: každý pracovní den 8 hodin denně, konkrétně od 9:00 do 17:00 hod.

• Způsob servisního zásahu bude zvolen podle charakteru závady buď telefonicky nebo pomocí vzdáleného přístupu nebo osobním zásahem na místě nebo jejich kombinací tak, aby byla závada odstraněna v definovaných lhůtách.

• Podpora zahrnuje telefonické konzultace tak, aby bylo zajištěno správné užívání software a řešení funkčních problémů, doporučení, kdy je vhodná doba na údržbu hardwaru Systému a asistenci při identifikaci softwarových chyb po jejich výskytu a oznámení, a to v neomezeném rozsahu po dobu trvání podpory, tj. v pracovní dny od 8:00 do 16:30.

• Bližší popis požadovaných minimálních servisních podmínek podle kritičnosti jednotlivých typů závad:

o 1 – kritická chyba

o Kritická závada, Systém zcela nefunkční, žádný z uživatelů nemůže pracovat

o 4 hodiny v pracovních dnech

o 1 pracovní den

o 2 - vážná chyba

o Vážná závada, Systém zčásti použitelný pro většinu uživatelů, Systém umožňuje klíčové funkce (funkční backend), nefunkční je např. možnost vložit nový objekt, vytvořit novou webovou prezentaci atp.

o 8 hodin v pracovních dnech

o 2 pracovní dny

o 3 – chyba neovlivňující klíčové vlastnosti Systému

o Závada umožňující práci Systému pro všechny uživatele s pomocí náhradního pracovního postupu

o 2 pracovních dnů

o 10 pracovních dnů

o 4 – drobná chyba

o Drobná závada neovlivňující činnost Systému

o 5 pracovních dnů

o 30 pracovních dnů

Vysvětlivky k výše uvedeným definicím závad:

o Stupeň priority závady

o Popis závady

o Doba reakce

o Doba odstranění

• Dodavatel se dále zavazuje, že po dobu trvání podpory bude provozovatele neodkladně informovat o vydání nových verzí instalovaného Systému, popřípadě bezpečnostních aktualizací a oprav funkčnosti. Dodavatel se také zavazuje dodat konkrétní opravy a nové verze včetně instrukcí pro jejich aplikaci. Zadavatel se také zavazuje, že v případě, že nebude vydána oprava známé bezpečnostní chyby, předá provozovateli informace, jakým způsobem problém eliminovat, byť s omezením funkčnosti dodávaného Systému.

• Konzultační činnost v rozsahu 10 MD.

• Zadavatel požaduje specifikaci ceny MD pro další konzultace v rozsahu přibližně 25MD/rok.

• Cena za podporu bude rozložena rovnoměrně do jednotlivých let.

4. HARMONOGRAM PLNĚNÍ

Dodavatel začíná plnit Harmonogram plnění Díla následující pracovní den po obdržení podepsané Smlouvy oběma stranami (den D). Hodnota 1 odpovídá pracovnímu dnu.

Aktivity	Ukončení	Základní výstupy	Provádí
Podpis smlouvy	D	Smlouva	Zadavatel, Dodavatel
Inicializační schůzka	D+1	Zápis	Zadavatel, Dodavatel
Etapa A – Analýza a tvorba projektové Dokumentace
Analýza požadavku na řešení (struktura, funkcionality, obsah, design, plán migrace)	D+52	Zápis vyhotovený na základě pravidelných konzultací mezi Zadavatelem a Dodavatelem	Zadavatel, Dodavatel
Představení projektové Dokumentace s možností připomínkování	D+53	Pracovní dokument nabízeného řešení	Zadavatel, Dodavatel
Akceptace navrženého řešení	D+60 (A)	Finální dokument nabízeného řešení/projektová Dokumentace	Dodavatel
Etapa B – Tvorba, implementace a testování CMS s veřejnými projekty (weby) xxx.xx a xxxxxxx.xx
Tvorba podle návrhu řešení	A+38	CMS, webové stránky xxx.xx a xxxxxxx.xx, zabezpečení, vstupy, zálohování	Dodavatel
Nasazení (migrace)	A+40	Spuštění webových stránek xxx.xxx.xx a xxx.xxxxxxx.xx	Zadavatel, Dodavatel
Testování	A+50	Protokol z testování	Zadavatel
Úpravy řešení podle výsledků testování	A+60	Soupis provedených úprav	Dodavatel
Školení uživatelů	1	Příručka (prezentace) základní obsluhypro nové uživatele Systému	Zadavatel, Dodavatel
Předání etapy B1	A+60 (B)	Předávací protokol etapy, API	Zadavatel, Dodavatel
Etapa C – Technická tvorba, implementace a testování kopie CMS 2
Tvorba podle návrhu řešení	B+38	Mirroring CMS 2, zabezpečení, vstupy, zálohování	Dodavatel
Nasazení	B+40	Spuštění kopie CMS	Zadavatel, Dodavatel
Testování	B+50	Protokol z testování	Zadavatel
Úpravy řešení podle výsledků testování	B+60	Soupis provedených úprav	Dodavatel
Školení uživatelů	1	Příručka (prezentace) základní obsluhypro nové uživatele Systému	Zadavatel, Dodavatel
Předání etapy C	B+60 (C)	Předávací protokol etapy, API	Zadavatel, Dodavatel
Etapa D – Obsahová tvorba, implementace a testování Neveřejného webu
Tvorba podle návrhu řešení	C+38	Neveřejný web, moduly Diskusní fórum, Správa uživatelů	Dodavatel
Nasazení	C+40	Vložení obsahové části Neveřejného webu	Zadavatel, Dodavatel
Testování	C+50	Protokol z testování	Zadavatel
Úpravy řešení podle výsledků testování	C+60	Soupis provedených úprav	Dodavatel
Školení uživatelů	1	Příručka (prezentace) základní obsluhypro nové uživatele Systému	Zadavatel, Dodavatel
Předání zakázky	P	Předávací protokol zakázky + dokumentace popisující úplný stav implementovaného řešení	Zadavatel, Dodavatel
Fakturace	P+2	Platba po Akceptaci implementovaného řešení	Zadavatel

5. VÝKLADOVÝ SLOVNÍK ZKRATEK A POJMŮ

• AD – (Lightweight Directory Access Protocol) protokol pro ukládání a přístup k datům na adresářovém serveru.

• API – (Application Programming Interface) rozhraní pro programování aplikací

• A.U.S. – Administrace uživatelů Systému

• CEF – (Common Event Format)

• CMS – (Content Management Systém) Systém pro správu obsahu

• CSS – (Cascading Style Sheets) kaskádové styly pro popis zobrazení elementů

• DMZ – (demilitarized zone) fyzická nebo logická podsíť z bezpečnostních důvodů oddělená od ostatních zařízení

• DNS – (Domain Name Systém) hierarchický Systém doménových jmen realizovaný servery DNS

• EV SSL CERTIFIKÁT – digitální certifikát pro deklaraci internetové bezpečnosti pro webové stránky

• EXTERNÍ VSTUPY Z APLIKACE CERT – soubory z aplikací, které využívá GOVCERT

• FAQ – (Frequently Asked Questions) často kladené dotazy

• GNU/LINUX – počítačový operační Systém Linux

• GOVCERT – vládní Computer Emergency Response Team

• HTML5 – označení verze značkovacího jazyka HTML pro tvorbu webových stránek

• HTTPS – (Hypertext Transfer Protocol Secure)

• HW – hardware

• ICZ – společnost ICZ

• IDM – centrální správa uživatelských účtů

• IS – informační Systém

• ISO27K – normy bezpečnosti informací

• JS - javascript

• KII – kritická informační infrastruktura

• LAN – Local Area Network

• LDAP – Lightweight Directory Access Protocol

• MD – (man day) lidská práce

• NAGIOS – open source Systém pro automatizované sledování stavu počítačových sítí

• NBÚ – Národní bezpečnostní úřad

• NCKB – Národní centrum kybernetické bezpečnosti

• NEVEŘEJNÝ WEB – webové stránky umístěné v DMZ

• PEREX – krátký text k upoutání pozornosti

• RHEL 7.1 – Red Hat Enterprise Linux verze 7.1

• RPM – Red Hat Package Manager

• RS – redakční Systém

• Session hijacking – exploit na data uložená v počítačové session k získání neoprávněného přístupu k informacím nebo službám v počítačovém Systému

• SFTP – bezpečný přenos souborů s pomocí SSH

• SQL injection – technika pro napadení databázové vrstvy

• SSH – (Secure Shell) zabezpečený komunikační protokol

• SW - software

• TAG – slouží k označení článku a jeho přiřazení k určitému tématu

• VEŘEJNÝ WEB – veřejně přístupné webové stránky

• VIS – významné informační Systémy

• VPN – virtuální privátní síť

• VPN TOKENY – mechanismus pro ověření identity uživatele nebo stroje v síti VPN

• VZ – veřejná zakázka

• W3C – World Wide Web Consortium

• WYSIWYG – editor, ve kterém to co upravujete, vidíte přímo na obrazovce

• XSS – metoda k narušení WWW stránek díky bezpečnostní chybě ve skriptech

Smluvní strany se dohodly, že níže uvedená slova nebo slovní spojení označená velkým počátečním písmenem budou mít ve Smlouvě následující význam a to bez ohledu na to, v jaké slovní formě budou použita:

• „Akceptace” – je potvrzení skutečnosti, že Služby, popřípadě jejich část, podléhající samostatné Akceptaci byly podrobeny všem Akceptačním testům a splnily smluvními stranami předem stanovená Akceptační kritéria.

• „Akceptační kriteria” – jsou v této Smlouvě měřitelné technické parametry dostupnosti Systému, které jsou určeny k ověření vlastností poskytnutých Služeb.

• „Akceptační protokol“ – je dokument, kterým Dodavatel a Zadavatel potvrdí, že instalace Systému byla provedena řádně, včas a bez vad a nedodělků, proběhly Akceptační testy a byla splněna sjednaná kritéria.

• „Akceptační test” – je proces, při kterém bude ověřována dostupnost Systému za účelem jejich Akceptace.

• „Dodávka ICT“ – je dodávka jakéhokoliv HW, SW nebo jejich kombinace při plnění závazku Dodavatele včetně instalace, konfigurace a testování tak, aby došlo k naplnění požadavku Zadavatele.

• „Doba reakce” – je maximální doba měřená od Nahlášení Vady/požadavku Zadavatele na řešení do potvrzení o přijetí požadavku.

• „Dokumentace” – jsou manuály, příručky, servisní katalogy jakož i další materiály, které jsou příslušenstvím Systému.

• „Dokumentace k řešení” – je popis řešení, konkrétních konfigurací a funkcionalit použitých pro Systém v prostředí Zadavatele.

• „Nahlášení Vady” – je prokazatelný okamžik nahlášení Xxxx Xxxxxxxxxx, tedy datum a čas odeslání písemného ohlášení Vady (web nebo email) Zadavatelem.

• „Nová verze Software” – vyšší verze Software označená zpravidla vyšším číslem za názvem, která je součástí Systému.

• „Popis služby” – je písemný dokument popisující způsob a podmínky, za jakých jsou poskytovány Služby.

• „Patch” – je změna nebo oprava chybné části kódu Software nebo Softwarové aplikace, jež jsou součástí Systému a předmětem této Smlouvy.

• „Předávací protokol“ – je dokument, ve kterém Dodavatel a oprávněná osoba Zadavatele potvrdí, zda Zařízení dodané Zadavateli odpovídá co do počtu a druhu a zda Zařízení netrpí zjevnými vadami.

• „Service Desk” – je procesní nástroj k oznámení Vad Systému Zadavatele Dodavateli přes příslušné, telefonní číslo a email

• „Servisní protokol“ – je dokument, kterým Zadavatel a Dodavatel potvrdí stav po provedení servisního zásahu, resp. odstranění nahlášené vady.

• „Smlouva” – znamená tuto rámcovou Smlouvu uzavřenou mezi Dodavatelem a Zadavatelem.

• „Software” – znamená počítačový program. Software obsahuje soubor instrukcí tvořících program nebo postup nebo jiné informace včetně databází. Software může být buď v

běžně čitelné formě, nebo ve formě zdrojového kódu, a může být uchováván na různých médiích, včetně magnetické pásky nebo disku, CD ROM.

• „Systém“ – je soustava hardwaru a softwaru u Zadavatele.

• „Studie“ – je dokument obsahující vize a doporučení dalšího rozvoje řešení aplikovaného na Systém.

• „Ukončení servisního zásahu“ – je prokazatelné ukončení servisního zásahu Dodavatelem, a to formou potvrzení Servisního protokolu, ze strany Zadavatele nebo

odhlášením Xxxx a převzetím Systému Zadavatelem a následným potvrzením Servisního protokolu.

• „Update“ – aktualizace Software nebo Softwarové aplikace, jež jsou součástí Systému a předmětem této Smlouvy.

• „Upgrade“ – vylepšení nebo rozšíření funkcí Software nebo Softwarové aplikace, jež jsou součástí Systému a předmětem této Smlouvy.

• „Vada (porucha, havárie)” – je rozpor mezi skutečnými vlastnostmi Systému nebo jeho části a vlastnostmi, které jsou stanoveny v Dokumentaci, funkční specifikaci nebo jiném dokumentu, popřípadě jiná chyba Systému, která je takto označena Zadavatelem.

• „Začátek servisního zásahu“ – je okamžik, kdy Zadavatel nahlásí Vadu prostřednictvím Service Desk.

• „Zařízení” – znamená hardware, příslušenství a další materiály dodané Dodavatelem k příslušnému plnění dle Smlouvy.