PŘÍLOHA Č.1 - TECHNICKÁ SPECIFIKACE ZADÁVACÍ DOKUMENTACE VEŘEJNÉ ZAKÁZKY

PŘÍLOHA Č.1 - TECHNICKÁ SPECIFIKACE ZADÁVACÍ DOKUMENTACE VEŘEJNÉ ZAKÁZKY ve smyslu ustanvení 44 zákna č. 137/2006 Sb., veřejných zakázkách, ve znění pzdějších předpisů (dále jen zákn ) Zadávací řízení: Otevřené řízení Veřejná zakázka: Nadlimitní veřejná zakázka na služby Ddávka a implementace intranetvéh prtálvéh řešení Zadavatel veřejné zakázky: Lesy České republiky, s.p. Hradec Králvé, Přemyslva 1106, PSČ 501 68 IČO: 421 96 451

Obsah 1. Seznam pjmů a zkratek... 7 1.1. Seznam pjmů... 7 1.2. Seznam zkratek... 10 2. Pžadavky na prjektvé řízení ddávky řešení... 11 2.1. Harmngram prjektu... 11 3. Pžadavky na technické řešení... 12 3.1. Obecná charakteristika řešení... 12 3.2. Vstupní technická kritéria řešení... 12 3.3. Mnitrvací sftware... 13 3.4. Vyvažvání farmy a vyská dstupnst... 13 3.4.1. Publikační servery (Frnt End)... 13 3.4.2. Aplikační servery... 13 3.4.3. Vyhledávací servery... 13 3.4.4. Rendervací servery... 13 3.4.5. Databázvé servery... 13 4. Pžadavky na licence... 14 5. Pžadavky na Access Management... 15 5.1. Struktura LDAP databáze zadavatele... 15 5.1.1. Struktura OU... 15 5.1.2. Jmenné knvence LDAP databáze... 15 5.2. Obecná privilegia rlí... 16 5.3. Řízení přístupů... 17 5.4. Integrace s dalšími systémy... 18 6. Pžadavky na prdukční prstředí definice mdulů... 19 6.1. Obecné pžadavky na ddávku řešení... 19 6.1.1. Administrace... 19 6.1.2. Architektura řešení... 19 6.2. Intranetvá část... 26 6.2.1. Náhled přílh v aplikacích... 26 6.2.2. Dmain bject mdel... 26 6.2.3. Ntifikace uživatelů... 26 6.2.4. Naplánvané úlhy... 26 6.2.5. Aplikace... 26 6.3. Definice integrační platfrmy a integrvaných nativních zdrjů bsahu... 27 6.3.1. Zabezpečení kmunikace s integrační platfrmu... 27 2

6.3.2. Vazba na pštvní služby... 28 6.3.3. Vazba na spisvu službu... 28 6.3.4. Vazba na centrální DMS... 28 6.3.5. Vazba na persnální systém TARGET... 28 7. Testvací prstředí zadavatele... 29 7.1. Průběh testvání... 29 8. Pžadavky na grafický design... 30 8.1. Standardy pr grafické prvky... 30 8.2. Definice dynamickéh bsahu webu... 30 8.3. Layut webvých stránek... 30 8.4. Standardy pr frmuláře... 31 9. Číselníky a jejich správa... 31 9.1. Druhy číselníků... 31 9.1.1. Aplikační... 31 9.1.2. Business vrstva... 31 9.1.3. Databázvá... 32 9.1.4. Externí... 32 9.2. Správa paralelně vedených Číselníků mezi aplikacemi a jejich synchrnizace... 32 9.2.1. Jednsměrná vstupní tzv. MASTER... 32 9.2.2. Jednsměrná výstupní SLAVE... 32 9.2.3. Obusměrná... 32 10. SLA... 33 10.1. Specifikace parametrů SLA pr jedntlivá prstředí... 33 10.1.1. Prdukční prstředí... 33 10.1.2. Testvací prstředí... 33 10.1.3. Vývjvé prstředí... 33 11. OLA... 34 11.1. Organizační OLA... 34 11.1.1. Přístup k HW zdrjům... 34 11.1.2. Přístup k SW zdrjům... 34 11.1.3. Vzdálený přístup d pčítačvé sítě... 34 11.1.4. Administrativní zázemí s napájením 220v a připjením k veřejné síti internet... 35 11.2. Technická OLA... 35 11.2.1. Zajištění HW Zdrjů... 35 11.2.2. LDAP... 35 11.2.3. Datvý extrakt TARGET... 36 11.2.4. SMTP Server... 36 3

12. Pžadavky na prvedení testvání a akceptace... 37 13. Pžadavky na šklení... 38 13.1. Uživatelské šklení... 38 13.1.1. Úvd d prblematiky... 38 13.1.2. Vstup d aplikace a věření identity uživatele... 38 13.1.3. Seznámení s navigací aplikace... 38 13.1.4. Seznámení s pdpůrnými číselníky aplikace... 38 13.1.5. Práce s daty a mžnsti jejich pužití v kancelářských aplikacích... 38 13.1.6. Pracvní pstupy... 38 13.2. Šklení pr správce bsahu... 38 13.2.1. Úvd d prblematiky správců bsahu... 38 13.3. Administrátrské šklení správce chdu aplikace... 39 13.3.1. Úvd d prstředí a ppis instalace... 39 13.3.2. Vytvření aplikace pr Intranet... 39 13.3.3. Administrace webů... 39 13.3.4. Knfigurace bsahvéh řízení... 39 13.3.5. Autentifikace... 39 13.3.6. Bezpečnst bsahu... 39 13.3.7. Úpravy prstředí... 39 13.3.8. Ntifikace... 39 13.3.9. Integrace s datvými zdrji... 39 13.3.10. Vyhledávání a správa fulltextvé databáze bsahu... 39 13.3.11. Zálhvací a Obnvvací strategie... 39 13.3.12. Sledvání a ptimalizace výknu... 40 13.3.13. Zajištění prcesů dle ITIL... 40 14. Pžadavky na lgvání... 41 15. Pžadavky na dkumentaci... 43 15.1. Service Desk... 43 15.1.1. Knwledge Base... 43 15.2. Service Supprt... 43 15.2.1. Incident management... 43 15.2.2. Change management... 43 15.2.3. Prblem management... 43 15.2.4. Service asset and cnfiguratin management... 44 15.2.5. Service Catalgue Management... 44 15.2.6. Release and deplyment management... 44 15.2.7. Event management... 44 15.3. Service delivery... 45 15.3.1. Capacity management... 45 15.3.2. Availability management... 45 4

15.3.3. Cntinuity management... 45 15.3.4. Financial management... 45 15.3.5. Service Level Management... 45 15.3.6. Access Management... 45 Přílha č. 1 Detailní technická specifikace Aplikačníh řešení... 46 1. INT 001 Přehled územní evidence... 46 2. INT-002 - Registr nájmů LČR... 49 3. INT-003 - Aplikace Významná místa na území spravvaných LČR... 52 4. INT-004 - Aplikace Pracvní úkly... 55 5. INT-005 - Aplikace Správa publikačních atributů... 58 6. INT-007 - Aplikace Správa pvlenek... 62 7. INT-008 - Aplikace Evidence prstů napadených škůdci... 66 8. INT-009 - Aplikace Inspekce... 69 9. INT-010 - Aplikace Zpětná vazba... 72 10. INT-011 - Aplikace Evidence zalesňvání plch...75 11. INT-012 Pmůcky a předměty... 78 12. INT-013 - Aplikace Vyhledávač typů aktiv splečnsti... 83 13. INT-014 - Aplikace Registr využití techniky... 85 14. INT-015 - Aplikace Nápravná patření... 88 15. INT-016 - Aplikace Registr partnerů... 91 16. INT-017 - Registr smluvních partnerů... 95 17. INT-018 - Nástěnka... 99 18. INT-019 Naše akce... 101 19. INT-020 Krátké zprávy...103 20. INT-021 - Aplikace Důležité dkumenty... 105 21. INT-022 - Aplikace Správa uživatelů intranetu... 107 22. INT-023 - Aplikace Knihvna... 110 5

Přílha č. 2 Technlgické standardy... 113 Přílha č. 3 Integrační standardy... 114 Přílha č. 4 Seznam služeb integrační platfrmy... 122 6

1. Seznam pjmů a zkratek 1.1. Seznam pjmů Pjem Prvzní dba Reakční dba Vyřešení incidentu / zajištění pžadavku na službu (Obnvení služby) Odstávky v režimu prvzu Nedstupnst Výpčet dstupnsti Vysvětlení Prvzní dbu je míněna dba, v průběhu které je Objednatelem pžadvaná a sučasně Pskytvatelem garantván prvzvání systémů. Prvzní dba je měřena/vyhdncvána v jedntkách času (v hdinách) Reakční dbu je míněn maximální časvé bdbí, ve kterém je Pskytvatel pvinen zareagvat na nvý záznam, který byl zalžen v rámci prvzní dby v systému pr HelpDesk. Reakční dba je hdncena puze v rámci prvzní dby každéh jednh systému a je vyhdncvána v hdinách, ppř. minutách. Reakcí na incident se rzumí mment, kdy je incidentu přiřazen řešitel a tét skutečnsti je hlašvateli incidentu pdána zpráva prstřednictví smluvených kmunikačních kanálů. Je maximální dbu dstranění incidentu (ppř. vyřešení statních servisních hlášení), tedy maximální časvé bdbí d reakce na zalžený incident v helpdeskvém systému, který byl zalžen v rámci prvzní dby d značení incidentu jak uzavřený (p dsuhlasení vyřešení incidentu Objednatelem). Dba vyřešení incidentu je stanvena pr incidenty dle jejich kategrií, je hdncena puze v rámci prvzní dby a je vyhdncvána v hdinách, ppř. minutách. Pr kntrlu a přesnu identifikaci časů vzniku a uknčení incidentu může být zdrjem infrmace také mnitrvací nástrj a jím naměřené mnitrvané parametry. Časvé bdbí, ve kterém je mžné prvést výpadek pskytvaných Služeb, který se nekvalifikuje jak incident. Výpadek je v tmt definvaném bdbí mžné prvést vždy puze se suhlasem Objednatele. Situace, kdy z phledu jednh či více uživatelů není daná ICT služba využitelná a t za těcht pdmínek: tat situace byla nahlášena uživatelem/uživateli jak incident neb autmaticky identifikvána mnitrvacím nástrjem a zárveň situace nastala selháním jedné neb více kmpnent dané ICT služby je zahrnuta d servisní pdpry. U takvé situace je v rámci jejíh řešení (incident neb událst) zjištěn čas jejíh vzniku a dba vyřešení. Rzdíl těcht časů pak tvří dbu nedstupnsti dané služby či skupiny služeb pr danu situaci, která bude zapčítávána vůči pžadvanému parametru celkvé dstupnsti v SLA. Dstupnst služby je vypčítávána dle následujícíh vzrce: D = [(P - V) / P] * 100 Dstupnst systému za měsíc (v %): D Režim prvzu systému (v minutách) za měsíc: P Celkvá dba výpadků systému (v minutách) za měsíc: V Dba trvání plánvané dstávky není zapčítávána jak nedstupnst Farmy Webvé aplikace Klekce webu Farmu zadavatel myslí sestavení serverů, které pskytuje zadavateli vysce dstupné a plně škálvatelné a rzšiřitelné prstředí a t jak na úrvni aplikační, databázvé a vyhledávací vrstvy. Webvu aplikací (WA) zadavatel myslí nsiče bsahu na nejvyšší úrvni pr bsah ve farmách, a pskytuje rzhraní mezi uživatelem a webvu aplikací. Klekcí webu (KA) zadavatel myslí ddělenu část webvé aplikace s vlastní definvanu bsahvu databázi, která umžní zabezpečení bsahu a rychlejší vyhledávání v bsahu. 7

Servisní aplikace Spravvaný účet Prvzní účet Organizační jedntka Intranetvá aplikace Extranetvá aplikace Annymní aplikace SQL Injectin Crss Site Scripting CSRF Publikační servery Databázvé servery Vyhledávací servery Rendervací servery pr webvé části Redakční systém Fault Tlerance Vyská dstupnst Servisní aplikací (SA) zadavatel myslí část která pskytuje jedntlivé sučásti, ze kterých jsu klekce webů stavěny a jež jsu reprezentvány jedntlivými aplikačními ply v rámci webvých služeb serveru. Tat servisní aplikace má definvaný vlastní účet pr autrizaci, tak aby ji byl mžn jednznačně identifikvat a zabezpečit v rámci peračníh systému. Spravvaným účtem zadavatel myslí účet umžňující LDAP věřvání vůči centrální databázi LDAP, přičemž hesl tht účtu je autmaticky měněn v rámci času (předem definvanéh) a administrátr ani žádná sba zadavatele tt hesl p jeh změně nezná. Prvzním účtem zadavatel myslí becné uživatelské účty (bjekty v LDAP databázi), které budu využívány pr přístup k celému systému. Organizační jedntku zadavatel myslí slžku, ve které jsu umístěny bjekty typu prvzní účet neb spravvaný účet Intranetvu aplikací zadavatel myslí webvu aplikaci přístupnu puze z interní sítě LAN, kde uživatelé budu věřeni pmcí Single Sign On Extranetvu aplikací zadavatel myslí webvu aplikaci přístupnu z interní sítě LAN a externí sítě internet puze p přihlášení prvzním účtem Annymní aplikací zadavatel myslí webvu aplikaci přístupnu z interní sítě LAN a externí sítě internet bez nutnsti přihlášení prvzním účtem SQL Injectin zadavatel myslí zranitelnst, kdy útčník spustí z webvé aplikace SQL dtaz, který díky nešetřeným vstupům prvede v databázi příkaz, který vypíše d internetvéh kna bsah některé z tabulek databáze Crss Site Scriptingem zadavatel myslí zranitelnst která umžní spustit útčníkvi ve vstupu některý z prgramvacích kódů HTML, PHP, VBS, aj.., tent kód pak vyvlá nějaku akci přím na aplikační vrstvě. Crss-site Request Frgery (CSRF neb také XSRF) je jedna z metd útku d internetvých aplikací (typicky implementvaných skriptvacími jazyky neb CGI) pracující na bázi nezamýšlenéh pžadavku pr vyknání určité akce v tét aplikaci, který všem pchází z nelegitimníh zdrje. Většinu se nejedná útk směřující k získání přístupu d aplikace (i když i pr t může být zneužit); spíše využívá (zneužívá) akce uživatelů, kteří jsu k ní již v kamžiku útku přihlášeni. Publikačním serverem zadavatel myslí servery, které hstují aplikační části a webvé služby pskytvané směrem k uživatelům a zajišťující interpretaci dat ze serverů databázvých. Databázvým serverem zadavatel myslí server, který bude hstvat jedntlivé bsahvé, vyhledávací a knfigurační databáze nutné pr prvz celé webvé aplikace. Vyhledávacím serverem zadavatel myslí server, který se bude sám starat indexvání bsahu na úrvni datvých zdrjů a t nejen databáze ale i lkálních subrvých služeb napříč rganizací zadavatele. Rendervacím serverem pr webvé části zadavatel myslí servery, které se budu starat sestavení datvých náhledů bez nutnsti tevření dkumentů a t zejména kancelářských subrů. Redakčním systémem zadavatel myslí systém s jednduchu správu prstředí bez nutnsti zásahu d vlastníh kódu aplikace. Fault tlerance zadavatel myslí definvaný standard architektury řešení, která je schpna pskytnu bezvýpadkvý stav při výpadku některé z částí infrastruktury a v tmt případě výpadek infrastruktury d úrvně 50% služby na prdukční infrastruktuře. Přesněji řešen výpadek primární neb sekundární lkality. Vysku dstupnstí zadavatel myslí způsb architektury, kdy může djít ke 8

SOAP, SOA, ESB, XML, FTP, JDBC, ODBCAES, TLS, SSL, HTTP, HTTPS, MTOM, atd. Basic neb Client cert Authenticatin Netwrk Lad Balancer LDAP Webvé site Webvé služby Aplikační ply camelcase GUI Datvá vrstva Externí data Frnt-end web Prcesr dtazů Publikvání aplikací Správa Správa připjení databáze Uživatelské rzhraní krátkdbému výpadku na dbu zastavení a spuštění služby aniž by byla vyžadvána sučinnst administrátra neb správce systému. Tt přepnutí musí prbíhat bezbslužně a v případě nahzení selhané části infrastruktury bude prveden přesunutí zpět ručně administrátrem v předem definvaný čas (dstávce služby) Tímt zadavatel myslí standardizvané výrazy pr prtkly, šifrvání, metdiky, standardy, aj. Tímt zadavatel myslí způsby věřvání jména a hesla pr mžnst přihlášení d aplikace. Tímt zadavatel myslí systém pr vyvažvání výknu na úrvni pčtu klientů na jedntlivých serverech. Tímt zadavatel myslí prtkl definvaný pr mdifikaci a přístup k datům na adresářvém serveru. Adresářvý server využívá hierarchické strmvé struktury, která je vhdná zejména pr práci s adresáři, infrmacemi uživatelích neb například může zastupit některé sítvé infrmační služby. Sám neimplementuje slžité transakční mechanismy ani funkce pr kntrlu integrity. Tímt zadavatel myslí standartní slžku subrvéh systému bsahující vlastní data (webvé stránky) Tímt zadavatel myslí služby, které bhspdařují vlastní internetvé stránky Tímt zadavatel myslí aplikační/funkční prvky internetvých služeb Tímt zadavatel myslí způsb psaní víceslvných frází a nadpisů, kdy jedntlivá slva nejsu ddělena mezerami, ale každé z nich začíná velkým písmenem nezávisle na tm, zda by tmu tak pdle pravidel pravpisu měl být. Samtný název camelcase je příkladem tht stylu Tímt zadavatel myslí interaktivní část bez nutnsti zásahu d vlastníh kódu aplikace (typickým příkladem je "Redakční systém") Tímt zadavatel myslí datvu vrstvu aplikace veškerá externí data vstupující d aplikace Tímt zadavatel myslí veškeré frnt-end služby aplikace Tímt zadavatel myslí veškeré prcesr dtazů databázvéh serveru Tímt zadavatel myslí lgvání chyb při nasazení jedntlivých aplikací d aplikačníh prstředí Tímt zadavatel myslí veškeré knfigurace správy v prstředí Tímt zadavatel myslí datvé knektry a jejich funkce Tímt zadavatel myslí veškeré činnsti na úrvni uživatelskéh rzhraní 9

1.2. Seznam zkratek Zkratka Vysvětlení LČR Státní pdnik Lesy České republiky OS Operační systém GŘ Generální ředitelství LČR (také jak GŘ LČR ) OJ Organizační jedntka OHÚL Odbr hspdářské úpravy lesa ÚHÚL Ústav hspdářské úpravy lesa LHC Lesní hspdářský celek IMA Systém evidence majetku ČSÚ Český statistický úřad 10

2. Pžadavky na prjektvé řízení ddávky řešení Ddávka řešení bude řízena pdle standardů metdiky PRINCE2 neb bdbné metdiky pr prjektvé řízení. Zadavatel pžaduje, aby ddavatel p dbu trvání tht prjektu zajistil na vlastní náklady pr členy realizačníh týmu systém pr řízení prjektu, v rámci, kteréh budu všechny zúčastněné sby včas infrmvány svých úklech, jednáních, budu mci čerpat dkumenty, prezentace, videa a prjektvé plány. V rámci ddávky řešení zadavatel předpkládá pr každý z mdulů sestavení tzv. Prject Initiatin Dcumentatin (dále jen PID), který bude detailně ppisvat cílvý kncept řešení. 2.1. Harmngram prjektu Zadavatel pžaduje, aby uchazeč ve své nabídce uvedl prjektvý Gantův diagram s předpkládaným harmngramem v el. Verzi na CD (například ve frmátu aplikace MS Prject neb jiné)termín plnění celéh řešení nesmí překrčit 2 měsíce na analýzu řešení a 6 měsíců na implementaci řešení, za předpkladu pskytnutí plné sučinnsti ze strany zadavatele. 11

3. Pžadavky na technické řešení 3.1. Obecná charakteristika řešení Zadavatel pžaduje ddání mdulů řešení s využitím platfrmy redakčníh systému se snadným způsbem vytváření webvých stránek. Redakční systém musí bsahvat minimálně: knihvnu dkumentů knihvnu wiki stránek diskuze seznam úklů událsti v kalendáři vlastní seznamy rzhraní pr uživatelsku administraci Pkud není specifikván v samstatném dkumentu Aplikací, pak každý záznam v redakčním systému může nabývat minimálně těcht stavů, které se d sebe liší puze významem a služí především k dlišení zbrazvacích filtrů pdle typů uživatelů. Minimální přehled stavů: Nezahájen - záznam byl vytvřen, ale ještě nebyl uživatelem předlžen, ke zveřejnění Prbíhá - zveřejněný záznam Dknčen - uknčený záznam. Již se dále nezveřejnuje Odlžen - záznam, na kterém byla činnst dčasně pzastavena a je/není veřejný Čekání - záznam, který signalizuje, že není ještě v režimu Dknčen, ale že jeh přepnutí d tht stavu je pdmíněn až d uknčení jiné aktivity Pžadavky na migraci histrických dat jsu uvedeny v ppisu dílčích mdulů Pdpra řešení musí být pskytvána v českém jazyce a t minimálně d úrvně vlastních úprav řešení tzv. custmizací. Ddavatel musí p dbu trvání živtníh cyklu řešení zajistit na vyžádání pdpru v rzsahu d 5-ti člvěkdnů/měsíc. Ddaná aplikace musí být schpna během bdbí, kdy bude ddavatel zajišťvat pdpru prvzu, běžet na infrastrukturních kmpnentách ve verzích pdprvaných výrbci všech infrastrukturních kmpnent. Navržené nvé kmpnenty řešení musí být pdprvány výrbcem SW min. d rku 2020 Řešení musí být lkalizván v suladu s českým právem. Sulad s českým právem musí být zajištěn v průběhu celéh živtníh cyklu řešení. Definice pužitých technlgických standardů na úrvni tét zadávací dkumentace je specifikvána v Přílze č. 2 tht dkumentu. 3.2. Vstupní technická kritéria řešení Parametr Hdnta Maximální dezva systému [vteřiny] 2 Velikst databáze [GB] 100 Datvé bjemy ulžených dkumentů [GB] 50 Pčty zpracvávaných pžadavků / den 20000 Pčty ulžených dkumentů 800 Pčet uživatelů 2500 Pčet suběžně pracujících uživatelů 50 Rční přírůstek dat [GB/rk] 30 12

3.3. Mnitrvací sftware Zadavatel pžaduje, aby specifikace mnitrvání celéh řešení vycházel z definvaných prcesů ITIL a dále z mžnstí pr lgvání celéh řešení. Ddavatel ve své nabídce uvede, jak bude mnitrvání prbíhat a jaké atributy je v jeh řešení dpručuje sledvat. Zadavatel má nyní implementván sftware Zabbix, který zajišťuje mnitrvání celé infrastruktury a již implementvaných aplikací. 3.4. Vyvažvání farmy a vyská dstupnst Zadavatel pžaduje, aby celé řešení byl vybudván vysce dstupné s mžnstí umístění serverů d 2 gegraficky ddělených lkalit a s autmatickým přepnutím všech funkcí v případě výpadku jedné z lkality. Zadavatel nevlastní ani nepptává v knceptu řešení žádné hardwarvé Lad Balancery, ale je schpen nabídnut k zajištění vyské dstupnsti systému DNS pr definici jedinečnéh jména v síti pr servery, ppřípadě je mžn instalvat na servery službu Netwrk Lad Balancer, ppřípadě Failver Cluster nicméně ve většině případů je nutné zajistit tzv. bezvýpadkvý prvz, který není službu Failver Cluster mžný, jelikž ta je schpna zajistit puze vysku dstupnst, ale nikliv Fault Tlerance služby. 3.4.1. Publikační servery (Frnt End) Zadavatel pžaduje, aby publikační servery umístěné v primární lkalitě byly vybudvány jak vysce dstupné s Fault tlerance a sekundární lkalita služila pr vysku dstupnst bez mezení funkčnsti neb výknu v případě výpadku primární lkality. Zadavatel pžaduje, aby celý systém publikvaný směrem k uživatelům byl zabezpečen pmcí TLS s využitím certifikátu SSL 3.0, který zadavatel vlastní a systém neumžňval připjení pmcí HTTP a t minimálně v řešení pmcí přesměrvání (redirect) na HTTPS. D tht systému musí být prveden věření na úrvni Basic Authenticatin neb Client Cert Authenticatin. 3.4.2. Aplikační servery Zadavatel pžaduje, aby publikační servery umístěné v primární lkalitě byly vybudvány jak vysce dstupné a sekundární lkalita služila pr Fault Tlerance bez mezení funkčnsti neb výknu v případě výpadku primární lkality. 3.4.3. Vyhledávací servery Zadavatel stanvil, že vyhledávací servery nemusí být budvány jak vysce dstupné v primární ani sekundární lkalitě, pkud nemezí neb nehrzí funkci celéh řešení a v případě výpadku danéh serveru převezme funkcinalitu zálžní server v sekundární lkalitě. 3.4.4. Rendervací servery Zadavatel stanvil, že rendervací servery nemusí být budvány jak vysce dstupné v primární ani sekundární lkalitě, pkud nemezí neb nehrzí funkci celéh řešení a v případě výpadku danéh serveru převezme funkcinalitu zálžní server v sekundární lkalitě. 3.4.5. Databázvé servery Zadavatel pžaduje, aby publikační servery umístěné v primární lkalitě byly vybudvány jak vysce dstupné a sekundární lkalita služila pr Fault Tlerance bez mezení funkčnsti neb výknu v případě výpadku primární lkality. 13

4. Pžadavky na licence Licenční ujednání a autrská práva za vlastní vývj jsu specifikvána ve Smluvě, která je nedílnu sučástí tht dkumentu. 14

5. Pžadavky na Access Management Zadavatel pžaduje, aby právnění byla řízena na úrvni LDAP a t pmcí jedntných věřvacích serverů, které budu pskytvány napříč infrastrukturu zadavatele a t jak pr primární lkality, tak i pr lkality sekundární. Servery pr jedntné věřvání uživatelů pmcí LDAP budu pskytvat přístup d celéh prstředí, přičemž hesla jedntlivých bjektů budu ulžena v šifrvané pdbě a t nejméně se šifrváním AES déle klíče 128bitů. Zadavatel dále pžaduje, aby tyt servery byly prvzvány v režimu vyské dstupnsti bez nutnsti dstávky při rzšíření stávající tplgie věřvacích LDAP serverů. Uchazeč ppíše jakým způsbem je schpen těcht pžadavků dstát a bude vycházet z definvané jmenné knvence pr servisní a prvzní účty. Servisní účet <uživatelské jmén>sa Prvzní účet - <uživatelské jmén> Zadavatel nemá žádný další systém pr řízení identit a jejich správu. Jediným dstupným zdrjem je v tmt případě systém Active Directry, který bude dále ppisván jak LDAP databáze neb věřvací server. 5.1. Struktura LDAP databáze zadavatele Zadavatel nyní má stanvenu níže uvedenu strukturu LDAP databáze, která v rámci implementace nebude předělávána a upravvána, jediné rzšíření, které je mžné je dplnění některých atributů v rámci LDAP databáze, které by byly bezpdmínečně nutné pr vlastní spuštění neb pr pdpru některé funkcinality v rámci Aplikačních částí. 5.1.1. Struktura OU 5.1.2. Jmenné knvence LDAP databáze Zadavatel využívá jmennu knvenci pr stanvení názvů účtů v rámci LDAP databáze a tat knvence je slžena z příjmení a prvníh písmene ze jména (př. Nvakj, nvtnyp, atd.) Zadavatel využívá jmennu knvenci pr stanvení názvů rganizačních jedntek v rámci LDAP databáze a tat knvence je slžena z OJ (rganizační jedntka) a přadvéh čísla v 3 znakvém frmátu (př. OJ010, OJ020, OJ005, atd..) Zadavatel využívá jmennu knvenci pr stanvení názvů skupin v rámci LDAP databáze a tat knvence je slžena z OJ (rganizační jedntka) a přadvéh čísla v 3 znakvém frmátu (př. OJ010, OJ020, OJ005, atd..) dále pak z kategrie a účelu dané skupiny, kdy je plžka kategrie vlitelná a nemusí být v každé situaci využita (př. ###_[kategrie]_ucel, kde ### je číselné značení OJ, plžka kategrie je vlitelná a nepvinná) 15

5.2. Obecná privilegia rlí Zadavatel pžaduje, aby právnění definvané pr prvzní účty byly dděleny d něklika kategrií a t minimálně v tmt rzsahu: FarmAdmin - Interní uživatel aplikace a nejvyšší administrátr s přístupem k aplikační a datvé vrstvě řešení WebAdmin - Interní uživatel aplikace a nejvyšší administrátr s přístupem k aplikační vrstvě DBAdmin - Interní uživatel aplikace a nejvyšší administrátr s přístupem k datvé vrstvě MAAdmin - Interní uživatel aplikace a správce bsahu na úrvni klekce aplikační vrstvy WAAdmin - Interní uživatel aplikace a správce bsahu na úrvni mdulu Uživatel/Návštěvník sba autrizvaná pmcí LDAP databáze (běžný uživatel aplikace) Annymní uživatel (návštěvník) Vlastník, Klíčvý uživatel OJ, Správce bsahu OJ - je sba neb skupina sb, které byly identifikvány vedením, že mají dpvědnst za zachvání důvěrnsti, dstupnst a integritu tht aktiva. Majitel aktiv se může v průběhu živtníh cyklu aktiva změnit. Vlastník je jmenvitý uživatel, který je dpvědný za veškeré změny knfigurace a záznamy v agendách, které má ve Vlastnictví. V každém prcesu změny je nedílnu sučástí schválení změny. Vlastník musí být uveden u všech plžek, které jsu v evidenci knfigurační databáze. Všechna pptávaná řešení musí bsahvat tut entitu a prcesy, které suvisejí s jejich změnami Tit uživatelé budu mít na úrvni LDAP databáze nejnižší mžná právnění bez mžnsti interaktivníh přihlašvání k jedntlivým serverům, přičemž nesmí být jejich právnění na úrvni aplikace mezena (vyjma terminálvých serverů, kam se mhu uživatelé přihlašvat interaktivně). Zadavatel pžaduje, aby z LDAP databáze d interní databáze systému byla data synchrnizvána maximálně každé 3 hdiny a v rámci tét synchrnizace byla dručena d interní databáze systému metadata z systému LDAP, kde budu ulžena a t jak z metadat ulžených v rganizačních jedntkách tak i z bjektů uživatelů. Tat metadata bude mžn plnit z bu míst a t z prstředí intranetvé aplikace tak i z prstředí správy LDAP databáze. Zadavatel pžaduje, aby v intranetvé aplikaci byla minimálně tat metadata, která budu v průběhu živtníh cyklu naplněna, pkud nebudu vyžadvána přím k udržení některé z funkcinalit aplikačních částí: Jmén Příjmení Ppis Kancelář Telefnní čísl Email Měst Okres PSČ Nadřízený Funkce Oddělení Splečnst ZaměstnanckéID Nadřízený 16

5.3. Řízení přístupů Zadavatel pžaduje, aby každý pvlený přístup d intranetu splečnsti byl řízen vlastníkem dané aplikační vrstvy a jím i autrizván, infrmace vlastníkvi/nadřízeném bude dstupná k načtení z atributu bjektu v LDAP databázi. Všechny změny stavů budu ntifikvány el. Zprávu žadateli včetně bsahu ple pznámka. 5.3.1.1. Externí Zadavatel pžaduje, aby v rámci celéh řešení nebyl mžn přistupvat externě ke službám aplikační části intranet standartními uživateli neb annymními uživateli. Externí přístup d intranetvé části bude zajištěn puze z integrační platfrmy, která se stará publikaci dat na extranet, který není sučástí tét zadávací dkumentace a je řešen samstatně. 5.3.1.2. Access management Zadavatel pžaduje, aby veškeré přístupy d systému byly zaznamenávány d lgů, které budu následně vyhdncvány zadavatelem. Pr přístup kncvých uživatelů bude pr intranetvu aplikaci zajištěn přístup pmcí Singl-Sign-On, jelikž jsu veškerá kncvá zařízení umístěna v dméně (LDAP databáze) zadavatele. Zadavatel je schpen prvést některé mžné úpravy prhlížečů pmcí skupinvých plitik, tak aby ddavateli pskytl maximální sučinnst pr mžnst mdifikace nastavení kncvých zařízení bez nutnsti ruční práce s kncvými zařízeními. Zadavatel dále pžaduje, aby uchazeč ve své nabídce uvedl, jaké změny bude nutné na kncvých zařízeních prvést a jakým způsbem je mžn prvést tyt změny centrálně za pužití skupinvých plitik v dméně zadavatele. 5.3.1.3. Prcesy řízení přístupů Zadavatel má implementván prces identity management v rámci, kteréh má definvané vlastníky jedntlivých bjektů, nadřízenst a pdřízenst sb a prt přístup d dané části intranetu neb intranetvé aplikace musí být pdřízen tmut pracvnímu pstupu. Zadavatel pžaduje, aby uchazeč ve své nabídce uvedl, jakým způsbem bude uživatel a vlastník ntifikván v rámci žádsti přístup. Dpručeným a zavedeným pstupem je infrmace prstřednictvím emailu a t s interaktivním dkazem přím d dané intranetvé stránky, kde bude mžn prvést schválení přístupu s následnu autmaticku ntifikací žadatele. 5.3.1.4. Bezpečnstní úrvně Zadavatel pžaduje, aby uchazeč ve své nabídce uvedl, jakým způsbem bude zajišťvat níže uvedené části bezpečnstních úrvní a dále pžaduje, aby hesla pr tyt celky byla vždy v šifrvané pdbě umístěna v LDAP databázi. 5.3.1.4.1. Databázvá Databázvá bezpečnst bude řešena na úrvni předem definvaných účtů z LDAP databáze, přičemž je mžn v tmt případě využít i účty z lkální databáze. Tyt lkální účty však musí být šifrvány a t zejména jejich hesl. Obsah vlastních databází by měl být v tmt případě také šifrván a t jednu z níže uvedených šifer a t buď v symetrickém, neb asymetrickém režimu, ppřípadě jeh kmbinací. DES Triple DES TRIPLE_DES_3KEY RC2 RC4 128-bit RC4 DESX 128-bit AES 192-bit AES 256-bit AES Zadavatel pžaduje, aby úrveň šifrvání byla zajištěna dle nejlepších zkušenstí a t s přihlédnutím k zajištění maximálníh výknu. 17

5.3.1.4.2. Aplikační Aplikační bezpečnst bude řešena na úrvni předem definvaných účtů z LDAP databáze a spuštění celé aplikační části v bezpečném režimu bude pdmíněn plnu funkcí tht účtu, který by měl mít na úrvni LDAP databáze nejnižší mžná právnění, ale na úrvni aplikační by měl mít právnění plnéh řízení danéh aplikačníh celku. 5.3.1.4.2.1. Frmuláře Bezpečnst jedntlivých frmulářů bude zajištěna pmcí účtu, který je aktuálně přihlášen d intranetvé aplikace a dle přidělených právnění bude vždy zbrazen/nezbrazen ppřípadě bude umžněna/neumžněna mdifikace bsahu danéh frmuláře. 5.3.1.4.2.2. Prvky frmuláře Bezpečnst jedntlivých prvků frmuláře bude zajištěna pmcí účtu, který by měl být přiřazen v rámci dané webvé části a tím by měl být i autrizván vždy při přístupu k danému prvku frmuláře a t zejména při zbrazení bsahu danéh frmuláře. Při editaci bude využit právnění prvku frmuláře, které je vázán na aktuálně přihlášenéh uživatele a t tak, aby uživatel A mhl změnit plžku A a C a uživatel B mhl měnit puze plžky B a D. 5.4. Integrace s dalšími systémy Zadavatel pžaduje, aby systém umžnil vazbu na LDAP databázi dle uvedených pžadavků v tmt dkumentu a v jeh přílhách (zejména v částech pr jedntlivé aplikační části) Zadavatel má dále vazbu na integrační platfrmu jejíž způsb je definván v každém ze samstatných mdulů, přičemž integrační platfrma není sučástí tht zadávacíh řízení. Zadavatel v rámci výběrvéh řízení předpkládá vazbu na dkument management systém (dále jen DMS), který zde nemůže být v tut chvíli specifikván, jelikž je sučástí jinéh výběrvéh řízení, ale některé subry (fyzické subry ukládané většinu jak přílhy) budu umísťvány d tht systému DMS. 18

6. Pžadavky na prdukční prstředí definice mdulů 6.1. Obecné pžadavky na ddávku řešení 6.1.1. Administrace Zadavatel pžaduje, aby administrační rzhraní byl ddán v anglickém jazyce, ale veškeré webvé části byly ddané v lkalizaci české. Tt administrační rzhraní by měl umžňvat minimálně tat nastavení: Vytváření nvých webvých aplikací Vytváření nvých bsahvých databází Zapínání a vypínání služeb webvé aplikace Správa bsahvých databází Knfigurace vyhledávacích služeb Knfigurace prezentačních služeb (textvé, prezentační a tabulkvé dkumenty) Knfigurace reprtvacích služeb Knfigurace zálhvání 6.1.2. Architektura řešení Zadavatel pžaduje architekturu řešení, která dpvídá becným standardům minimálně 3 vrstvé úrvně (Obr. 1) ve struktuře uvedené v tmt dstavci. Zadavatel pžaduje, aby uchazeč navrhl plně škálvatelnu strukturu serverů zajišťujících prvz intranetvých služeb a t tak, aby ddělil servery na publikační, databázvé, vyhledávací, rendervací a t primárně z důvdu mžnsti škálvání výknu všech služeb pskytvaných směrem k uživatelům (návštěvníkům). Obr. 1 (becný mdel architektury řešení) Déle je pžadván zajistit vysce dstupné prstředí s umístěním ve 2 gegraficky ddělených lkalitách s Fault Tlerance a t pr služby (přesná specifikace je uvedena v kapitle Chyba! Nenalezen zdrj dkazů.): Publikační servery (WFE neb Frnt-End servery) Databázvé servery (SQL servery) Vyhledávací servery (App neb Appliacatins servery) Rendervací servery pr webvé části (App neb Appliacatins servery) Celá struktura serverů bude umístěna výhradně na serverech virtuálních, u kterých bude výkn dpvídat ptřebám udaným výrbcem, tak aby byl zajištěn dpručený výkn a uživatelé nebyli mezeni při využívání intranetvé aplikace. 19

6.1.2.1. Fyzická/Virtuální infrastruktura Zadavatel pžaduje, aby aplikace a všechny její sučásti byly umístěny na peračním systému, jež bude plně pdprván výrbcem s dstupnu databází znalstí becně značvánu jak FAQ. V níže uvedeném vybrazení je uveden becný mdel pr stavbu webvé aplikace s rzlžením zátěže mezi jedntlivé servervé rle. V tmt scénáři je pžadván, aby farma navržená ddavatelem byla řešena jak 3 vrstvá bez nutnsti využití databáze v režimu Active-Active, ale minimálně s využitím Active-Passive s RTO 1 hdina. Obr. 2 (Obecný mdel farmy primární a sekundární lkality) Frnt-end Web servers jedná se servery pskytující webvé služby, aplikační ply pr jedntlivé webvé site a další pdpůrné služby pr frnt end weby. 20

Applicatin servers jedná se servery hstující rendervací služby, vyhledávací služby a další pdpůrné služby mezi webvými frnt-end servery a databázvými servery SQL Server jedná se servery hstující vlastní databáze, knfigurace vlastní aplikace a další pdpůrné služby pr služby integračních platfrem, aj SQL Server (witness server) jedná se server pr zajištění autmatické chrany prti výpadku jednh z uzlů SQL clusteru (Principal či Mirrr) 6.1.2.2. Prezentační vrstva Prezentační vrstvu představuje libvlný prhlížeč webvéh bsahu s pdpru Skriptvání na straně klienta je v infrmatice značení techniky, ve které je pčítačvý prgram umístěný na webvých stránkách vyknáván na straně klienta, tj. webvým prhlížečem uživatele (ne na straně serveru, jak u skriptvání na straně serveru). Skriptvání na straně klienta je důležitá sučást knceptu DHTML (dynamickéh HTML), jenž umžňuje měnit bsah zbrazené webvé stránky v závislsti na uživatelském vstupu, pdmínkách prstředí (jak například čas a den) neb jiných klnstech. 6.1.2.3. Aplikační vrstva Zde leží jádr aplikace, její lgika a funkce, výpčty a zpracvání dat. Zadavatel pžaduje, aby byla tat vrstva zastupena webvým serverem (dále také publikační vrstva). Aplikační vrstva nesmí bsahvat přímé příkazy pr manipulaci s daty datvé vrstvy. V rámci vývje řešení musí být striktně pužita metda zasílání pžadavků d datvé vrstvy prstřednictvím parametrů bez příméh pužití příkazů pr VYTVOŘENÍ, MAZÁNÍ A ZMĚNU DAT. Zpravidla se jedná příkazy v becném jazyce Transact SQL : INSERT UPDATE DELETE DROP Tyt příkazy nesmí být na úrvni Aplikační vrstvy vůbec pužity, aby se zamezil bezpečnstním rizikům hržujícím Datvu vrstvu Aplikační vrstva musí bsahvat preventivní patření prti útkům: SQL Injectin Crss Site Scripting CSRF Zadavatel pžaduje, aby ddavatel prvedl penetrační testy na danu webvu aplikaci a následně předlžil tyt penetrační testy zadavateli k akceptaci jak sučást ddávky řešení Jedntlivé aplikace pužité v dané webvé části musí být řízeny vlastními aplikačními částmi a jejich spuštění bude autrizván samstatným účtem v LDAP databázi se samstatným heslem, které bude umístěn v aplikační databázi a t jak HASH, tt hesl bude pravidelně měněn bez nutnsti zásahu zadavatele. 21

6.1.2.4. Datvá vrstva Tut vrstvu tvří nejčastěji databáze, která data uchvává, zpřístupňuje a zaručuje jejich knzistenci. Může zde být ale také (síťvý) subrvý systém, webvá služba neb jiná aplikace. Prefervané řešení na úrvni datvé vrstvy je definván jak řešení s nulvu ztrátu dat a rychlstí bnvy v řádu sekund. Zadavatel značil v níže uvedené tabulce pžadavek na řešení vyské dstupnsti celéh řešení, tent pžadavek je nastaven jak minimální pr zvlené řešení. Databázvé řešení vyské dstupnsti Pžadavek na pdpru pr fault tlerance funkcinalitu se synchrnním algritmem Ptenciální datvé ztráty (RPO) Ptencinální čas bnvení (RTO) žádný sekundy ANO Autmatické přepnutí v případě výpadku Pžadavek na pdpru pr fault tlerance funkcinalitu s asynchrnním algritmem v řádu sekund minuty NE Pžadavek na pdpru pr synchrnní kpie databáze v rámci celéh řešení není aplikván minuty ANO Kpie databáze (synchrnní mód + witness server) žádný sekundy ANO Kpie databáze (asynchrnní mód + witness server) v řádu sekund minuty NE Backup, cpy, restre něklik hdin něklik hdin NE Zadavatel pžaduje, aby byly databáze a/neb tabulky dděleny na něklik mžných úrvní (viz nadpisy níže uvedené v tmt dkumentu pd kapitlu 5.1.2.4.1 až 5.1.2.4.4), a dpručuje prvést ddělení minimálně na těcht úrvních. Pkud má ddavatel databáze a/neb tabulky řešeny jinak, je nutné přesně specifikvat jak a jakým způsbem a t zejména z phledu bsahu jedntlivých databází/tabulek. Každá z níže uvedených databází a/neb tabulek má uveden svůj vlastní účel a tent je brán jak minimální. Jména databází/tabulek uvedených níže v tabulce jsu puze infrmativní a jejich název nemusí být ddavatelem ddržen. Z níže uvedených důvdů preferuje Zadavatel rzdělení na úrvni databází: Pžadavek vychází z ptřeby pkrytí vysce dstupnéh řešení, které bude v buducím čase rzšiřván, a některé databáze, v případě nárůstu dat mhu být přesunuty na samstatné servery. Dále pak je ddělení funkcí d jedntlivých databází preferván z důvdu rychlejší bnvy v případě havárie a předpkládá se, že databáze budu bsahvat v tmt scénáři méně dat a zátěž na jedntlivé databáze bude lépe rzdělena zejména při zpracvání dtazů d těcht databází pmcí stre prcedur každé z databází. 22

6.1.2.4.1. Systémvé databáze Knfigurační databáze Pužitý název databáze Účel Pžadavek na pdpru pr synchrnní kpie databáze v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu se synchrnním algritmem Pžadavek na pdpru pr asynchrnní kpie databáze a transakčníh lgu v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu s asynchrnním algritmem LCR_App_System Zadavatel pžaduje, aby tat databáze bsahvala minimálně tyt knfigurační data databází: - Knfigurace z aplikační databáze - Knfigurace z webvých služeb - Knfigurace webvých aplikací - Knfigurace vlastních řešení - Knfigurace webvých částí - Knfigurace předpřipravených template - Infrmace definvaných kvótách ANO ANO NE, může být definván v rámci celéh řešení NE, může být definván v rámci celéh řešení Obsahvá databáze pr administrační web Pužitý název databáze Účel Pžadavek na pdpru pr synchrnní kpie databáze v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu se synchrnním algritmem Pžadavek na pdpru pr asynchrnní kpie databáze a transakčníh lgu v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu s asynchrnním algritmem LCR_Admin_Cntent Zadavatel pžaduje, aby tat databáze bsahvala veškerá knfigurační data z aplikační části administrace. Pkud by byly využity funkce pr pdpru kancelářských aplikací, pak tat bsahvá databáze bude udržvat i infrmace jejich knfiguraci. ANO ANO NE, může být definván v rámci celéh řešení NE, může být definván v rámci celéh řešení 23

Obecné bsahvé databáze Pužitý název databáze Účel Pžadavek na pdpru pr synchrnní kpie databáze v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu se synchrnním algritmem Pžadavek na pdpru pr asynchrnní kpie databáze a transakčníh lgu v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu s asynchrnním algritmem LCR_<název aplikace>_cntent Zadavatel pžaduje, aby tat bsahvá databáze bsahvala veškerá data z dané webvé aplikace neb aplikační části splečně s využitými aplikacemi, jež jsu v dané aplikační části pužity. Tat databáze bude dále bsahvat veškeré subry ulžené d dané aplikační části. Dále bude bsahvat vlastní data z kancelářských aplikací. ANO ANO ANO ANO 6.1.2.4.2. Databáze pr vyhledávání Databáze pr vyhledávání Pužitý název databáze Účel Pžadavek na pdpru pr synchrnní kpie databáze v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu se synchrnním algritmem Pžadavek na pdpru pr asynchrnní kpie databáze a transakčníh lgu v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu s asynchrnním algritmem LCR_Search_App Zadavatel pžaduje, aby: ANO ANO NE NE tat databáze udržvala infrmace prcházení v rámci celéh řešení a dále infrmace SACL tat databáze bsahvala infrmace z analytických reprtů, a bsahuje extrakci všech využitých dkazů v rámci celéh řešení tat databáze bsahvala veškerá data prcházení a jejich histrii tat databáze uchvávala infrmace, které se extrahuje z bsahvých kmpnent (značených vždy jak cntent) 24

6.1.2.4.3. Databáze metadat Databáze metadat Pužitý název databáze Účel Pžadavek na pdpru pr synchrnní kpie databáze v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu se synchrnním algritmem Pžadavek na pdpru pr asynchrnní kpie databáze a transakčníh lgu v rámci celéh řešení Pžadavek na pdpru pr fault tlerance funkcinalitu s asynchrnním algritmem LCR_Metadata_DB Zadavatel pžaduje, aby tat databáze uchvávala infrmace metadatech (pkud existují) pužitých uvnitř veškeréh bsahu ANO ANO ANO ANO 6.1.2.4.4. Databáze reprtvacích služeb Databáze katalgu Pužitý název databáze Účel LCR_Reprting_Catalg Zadavatel pžaduje, aby tat databáze uchvávala infrmace vytvřených reprtech, histrii těcht reprtů, infrmace plánvání a autmatickém genervání reprtů Databáze upzrnění Pužitý název databáze Účel LCR_Reprting_Alert Zadavatel pžaduje, aby tat databáze uchvávala infrmace aktuálních alertech systému 6.1.2.5. Integrační vrstva Ppis integrační vrstvy a jejích standardů je uveden v Přílze č. 3 Integrační standardy a jmenvitý seznam služeb integrační vrstvy je uveden v Přílze č. 4 Seznam služeb integrační platfrmy. 25

6.2. Intranetvá část Zadavatel pžaduje ddat intranetvu aplikační část, která bude pskytvat interním uživatelům zadavatele zdrj infrmací a aplikací pr evidenci různých interních systémů a databází. Zadavatel pžaduje, aby každá z aplikací měla buď vlastní, neb centrální administrativní rzhraní, které umžní zadavateli správu právnění k dané aplikaci a definvat tyt rle dle rganizačních jedntek načtených z LDAP databáze, kde každá bude interpretvána pmcí atributu Ppis a kde bude viditelné a načtené kódvé značení rganizační jedntky v některém z dalších atributu v administračním rzhraní. Zadavatel pžaduje, aby každá z aplikací, pkud není definván přím v aplikaci, měla mžnst nastavit tat právnění: Administrátr plný přístup Editr mžnst přidávání příspěvků (bez mžnsti zbrazit administrativní rzhraní) Návštěvník (čtenář) puze prhlížení bsahu (bez mžnsti zbrazit administrativní rzhraní) Zadavatel pžaduje, aby intranetvá část umžnila změnu statickéh bsahu webu přím v náhledvém kně celé aplikace, tak aby nebyl nutn zasahvat z důvdu úprav d vlastníh kódu aplikace neb statickéh bsahu webvé stránky. Zadavatel pžaduje, aby aplikace intranet jak celek umžňvala přenesení dat d extranetvé části (veřejný web), který není sučástí tht výběrvéh řízení a t skrze integrační platfrmu, které také není sučástí tht výběrvéh řízení a t pmcí definvaných standardů pr přensy (XML, aj ) 6.2.1. Náhled přílh v aplikacích Zadavatel pžaduje, aby přilžená přílha byla indexvána na úrvni bsahu (byl umžněn fulltextvé vyhledávání v bsahu dkumentu) a při najetí/kliknutí myši na danu přílhu zbrazenu u danéh záznamu v aplikaci byla d samstatnéh kna vyrendrvána v náhledu bsahu, a t u všech aplikací, kde existuje mžnst připjení přílh. Tat funkcinalita je pžadvána pr kancelářské dkumenty a PDF. 6.2.2. Dmain bject mdel Zadavatel pžaduje, aby uchazeč přilžil ke své nabídce pr každu aplikaci DOM mdel, který bude definvaný pr každu aplikaci a také na centrální úrvni, tak aby byl zřejmé, jaká ple jsu v aplikacích pužita a jakých mhu nabývat hdnt. Dále pak na centrální úrvni by měl být zřejmé z DOM, jaké jsu glbální číselníky a jejich vazba na jedntlivé aplikace v rámci celéh řešení. Další vazbu, která by měla být na úrvni DOM zřejmá je vazba na jedntné míst pr správu a t pr administrátra a pr správce celéh webu. 6.2.3. Ntifikace uživatelů Zadavatel pžaduje, aby byl ddané řešení ddán s funkcí, která umžní uživatelům prstřednictvím GUI (uživatelskéh rzhraní), knfigurvat svépmcí emailvé ntifikace. Tyt ntifikace musí umžňvat zahájit jejich spuštění na základě událstí pužitých prvků frmuláře neb změnu dat v nich bsažených. 6.2.4. Naplánvané úlhy Zadavatel pžaduje, aby ddané řešení splňval pdmínky pr samstatnu knfiguraci a administraci časvě naplánvaných úlh bez nutnsti pužití prgramvéh kódu. Oprávnění ke knfiguraci bude mít výhradně administrátr mdulu. 6.2.5. Aplikace Tent dkument je nadřazeným dkumentem pr detailní specifikace pptávaných mdulů. Pkud není stanven na detailní úrvni, tak se všechny parametry a vlastnsti řídí tímt dkumentem. Zadavatel pžaduje, aby byla splněna funkcinalita dle přílhy tét technické specifikace a byla ddána dle všech pravidel, přičemž Váhu v případě klize nastavení dané webvé aplikace má vždy větší ta, která je uvedena v samstatném dkumentu a v tmt dkumentu jsu stanveny puze becné funkcinality. 26

6.2.5.1. Jmenvitý seznam pptávaných mdulů Bližší infrmace k jedntlivým mdulům jsu ppsány v Přílze č. 1 tht dkumentu. INT_001 Přehled územní evidence INT_002 Registr nájmů LČR INT_003 Významná místa na území spravvaných LČR INT_004 Pracvní úkly INT_005 Správa publikačních atributů INT_006 Lesní technika INT_007 Správa pvlenek INT_008 Evidence prstů napadených škůdci INT_009 Inspekce INT_010 Zpětná vazba INT_011 Evidence zalesňvání plch INT_012 Pmůcky a předměty INT_013 Vyhledávač typů aktiv splečnsti INT_014 Registr využití techniky INT_015 Nápravná patření INT_016 Registr partnerů INT_017 Registr smluvních partnerů INT_018 Nástěnka INT_019 Naše akce INT_020 Krátké zprávy INT_021 Důležité dkumenty INT_022 Správa uživatelů intranetu INT_023 Knihvna 6.3. Definice integrační platfrmy a integrvaných nativních zdrjů bsahu Zadavatel pžaduje, aby aplikace intranet umžňvala vazbu na tyt systémy jak integrační zdrje, přičemž v rámci tht zadání se nejedná integrační platfrmu, která není sučástí tht zadávacíh řízení Vazba na systémy Obusměrná vazba na LDAP databázi Jednsměrná vazba na systém TARGET (jednsměrný asynchrnní přens dat d intranetvé aplikace) Obusměrná vazba na pštvní služby (systém umžňuje příjem i desílání zpráv) Vazba na spisvu službu (bude řešen integrační platfrmu, která není sučástí tét ddávky) Vazba na centrální DMS (bude řešena integrační platfrmu, která není sučástí tét ddávky) Vazby na integrační platfrmu pdrbný ppis je uveden v Přílze č. 3 a 4 6.3.1. Zabezpečení kmunikace s integrační platfrmu Zadavatel pžaduje, aby systém byl schpný zabezpečit kmunikaci na úrvni TLS s integrací certifikátu pr webvé služby na úrvni SSL 3.0, tent certifikát bude služit pr zabezpečení kmunikace mezi vrstvu aplikační a integrační platfrmu. Zadavatel pžaduje, aby certifikát vydaný veřejnu certifikační autritu byl ddán v rámci řešení a zapčítán d nabídkvé ceny 27

6.3.2. Vazba na pštvní služby Zadavatel pžaduje, aby webvá aplikace umžňvala vazbu na interní pštvní servery a t jak pmcí prtklů MAPI, SMTP, IMAP, POP3 a t tak, aby z webvé aplikace byl mžn emaily nejen desílat, ale i d předem definvaných částí intranetvých stránek i přijímat a t zejména při využití: Ntifikační schránka webvé aplikace Příprava reprtů pravidelně genervaných webvu aplikací Zadavatel dále pžaduje, aby byl mžn v těcht emailech vyhledávat a t na úrvních: Obsah emailvé zprávy Přílha Hlavička Infrmace z emailů budu vyhledávacími servery autmaticky indexvány v pravidelných intervalech a t ve dvu definvaných úrvních: 1x za 2 dny kmpletní reindexace bsahu 4x denně rzdílvá indexace bsahu 6.3.3. Vazba na spisvu službu Zadavatel pžaduje, aby webvá aplikace byla schpna čerpat data ze spisvé služby zadavatele a t na úrvni integrační platfrmy, která není sučástí tht výběrvéh řízení a byla schpna data interpretvat přím d webvé služby a t s c nejnižší míru psaní vlastníh kódu. 6.3.4. Vazba na centrální DMS Zadavatel pžaduje, aby webvá aplikace byla schpna čerpat data z centrálníh DMS zadavatele a t na úrvni integrační platfrmy, která není sučástí tht výběrvéh řízení a byla schpna data interpretvat přím d webvé služby a t s c nejnižší míru psaní vlastníh kódu. 6.3.5. Vazba na persnální systém TARGET Zadavatel v rámci vývje mdulu předpkládá seznámení ddavatele s rzhraním ve splupráci s výrbcem persnálníh systému TARGET. Ze stránek výrbce: Systém Target 2100 je vyvinut v prstředí Brland Delphi 2.0 5.0. Systém je připraven využívat SQL databázvý server MS SQL server 7 2000 neb Oracle 8. Zadavatel pžaduje, aby z tht systému byly načítány infrmace vlitelných parametrech zaměstnanců, které budu v případě ptřeby prezentvány prstřednictvím integrační platfrmy, která není sučástí tét ddávky. Tat vazba musí umžnit přens tak, aby byl mžn vykreslit v části internet (frmu diagramu neb textvéh výpisu jedntlivých pdřízených) infrmace nadřízensti a pdřízensti daných sb a t ve strmvém zbrazení, přičemž vždy bude platit, že bude zbrazen vždy jeden nadřízený a n jeh pdřízených a t vždy d první úrvně pdřízensti. Zadavatel zajistí, aby infrmace byly vždy umístěny v aktuální verzi ve frmátu CSV a t přím v umístění, ze kteréh bude mci aplikace čerpat. Tent prces bude vždy prveden tak, že djde k nahrazení stávajících dat daty nvými, ale nad změnu dané plžky (puze v případě její existence) bude zajištěn verzvání, tak aby byl mžn zkntrlvat, kdy dšl ke změně danéh atributu. 28

7. Testvací prstředí zadavatele Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval, jakým způsbem bude vybudván testvací prstředí. Zadavatel pžaduje mžnst pdpřit svůj prces release management, v rámci kteréh chce každu knfigurační změnu, imprt dat a další činnsti testvat a řídit. Tt testvací prstředí nemusí být řešen jak vysce dstupné a bude umístěn puze v primární lkalitě zadavatele, přičemž by měl být dstatečně výknné, aby byl mžn prvádět samstatné datvé imprty a změny na jedntlivých vrstvách testvacíh aplikačníh řešení. 7.1. Průběh testvání Tt testvací prstředí nesmí mezit ani hrzit prvz prdukčních systémů a musí být zabezpečen a ve stejné knfiguraci jak prstředí prdukční. Zadavatel nepžaduje autmatizaci změn v knfiguraci neb bsahu p prvedení vlastníh testvání změn. Tyt změny bude d prdukce prvádět svépmcí a bez účasti ddavatele. Zadavatel však pžaduje, aby uchazeč ve své nabídce specifikval, jak bude testvání prbíhat, jak bude prveden nasazení p testvání a p dknčení realizační fáze pžaduje d ddavatele ddat dkumentaci a prvzní manuál (testvací scénář) pr zajištění prcesu release management. Zadavatel je beznámen s faktem, že data, jež budu na aplikační úrvni plněna d systému jinými uživateli, nemusí být synchrnní s testvacím prstředím, ale knfigurace se musí shdvat v bu prstředích. 29

8. Pžadavky na grafický design Grafický vzhled výstupních webvých stránek musí být řízen primárně prstřednictvím pužití metdy tzv. kaskádvých stylů CSS dle standardu W3C. Všechny vlastní definvané třídy ddané ddavatelem musí být patřeny kmentářem dle standardu W3C. Příklad: /* Kmentář a ppis třídy */ Výjimky při nepužití CSS stylů musí být zaznamenány d dkumentace, včetně důvdnění. 8.1. Standardy pr grafické prvky Zadavatel má vlastní lgtyp (písm s lgem splečnsti), které je mžn začlenit d grafickéh návrhu intranetvých stránek, které by měly být tvřeny převážně zelenu barvu, která je pr splečnst zadavatele typická. 8.2. Definice dynamickéh bsahu webu Zadavatel pžaduje, aby všechny stránky připravené k webvé prezentaci byly genervány dynamicky a t tak aby umžňvali úpravu a rzlžení stránek při tevření v internetvém prhlížeči v minimalizvaném režimu neb při tevření v mbilním prhlížení na zařízeních smartphne (Windws, Andrid, OSX). Zadavatel by také uvítal, ale není pdmínku, mžnst přípravy vlastníh bsahu pr mbilní zařízení (úprava slupců, úprava filtračních plí, atd..). 8.3. Layut webvých stránek Zadavatel pžaduje, aby uchazeč ve své nabídce navrhl grafický design s přihlédnutím k níže uvedenému rzlžení při tvrbě layutu (wireframe) celé intranetvé kncepce. 30

8.4. Standardy pr frmuláře Zadavatel pžaduje, aby uchazeč ve své nabídce uvedl, jaké druhy plí pr frmuláře umžňuje pužívat. Zadavatel pžaduje, aby v rámci vytváření frmulářů byl mžn využívat minimálně těcht plí: Jednřádkvý text přesně definvaném pčtu pužitelných znaků s maximální hdntu 250 a mžnstí definvání výchzí hdnty pr dané ple Více řádkvý text s mžnstí frmátvání WYSIWYG s mžnstí definice pčtu řádků Výběr z nabídky předvlených hdnt kde bude mžn danu nabídku reprezentvat pmcí výběrvéh menu (list bx), pmcí zaškrtávacích tlačítek (check bx) neb pmcí přepínačů (radi buttn) Číselnu hdntu s mžnstí definice rzsahu hdnt, které je mžn zadat d danéh ple frmuláře a definicí pčtu desetinných míst Mžnst zadání měny ve frmuláři s autmatickým dplňváním zkratky pr danu měnu a mžnstí mezení definváním minimální a maximální hdnty Mžnst zadání hdnty datum a čas, která bude reprezentvána kalendářem Mžnst zadání hdnty pmcí vyhledání v jiném seznamu v rámci danéh aplikačníh celku Mžnst z výběru sby z LDAP databáze, jež je integrvána d dané aplikace Mžnst vlžení hypertextvéh dkazu s mžnstí náhledu při přidání příméh linku na grafický prvek jinéh webu (iframe) Mžnst vlžit pčítaný vzrec pr mžnst kalkulvání cen v některých seznamech Vazba na externí seznamy pmcí předem definvaných vazeb na datvé zdrje (ODBC) Zadavatel pžaduje u všech typů plí ve frmuláři mít mžnst zbrazení/nezbrazení uživatelům a také vynucení zadání dané hdnty s grafickým upzrněním pr kncvéh uživatele (např. hvězdička, křížek, aj ). Zadavatel pžaduje výše uvedená mezení a t z důvdu eliminace mžnsti útků na prvky frmuláře a eliminaci zejména CSFR, XSS, atd.. 9. Číselníky a jejich správa Zadavatel pžaduje, aby jedntlivé číselníky na úrvni aplikačníh prstředí byly prvázány a spravvány samstatně z jedinéh místa (např.: Centrální správa aplikací intranetu ), kde bude mžn definvat jak přístupy a rle pr uživatele (samstatný mdul), tak i číselníky které jsu dstupné puze pr uživatele v rli Administratr. Typickým číselníkem pužitým ve většině mdulů je nyní například: Seznam Organizačních Jedntek, který je načítán z databáze LDAP, ale může být v aplikaci intranet umístěn jak ff-line číselník (s pravidelnu synchrnizací), kdy bude mci bsahvat další metadata, která by v LDAP databázi nebyla bsažena Tt prvázání je na rzhdnutí ddavatele aplikačníh prstředí, přičemž zadavatel pžaduje, aby uchazeč ve své nabídce uvedl relační vazby mezi těmit seznamy. 9.1. Druhy číselníků 9.1.1. Aplikační Zadavatel pd tímt pjmem definuje standard pr vedení číselníku na úrvní prezentační vrstvy, který se bvykle pužívá přím jak datvý typ Ple a/neb ENUMERATOR uvedený a spravvaný přím na úrvni prezentační vrstvy. Zadavatel pžaduje, aby v případě pužití tét metdy byl tent číselník přím uveden v předané dkumentaci řešení v kapitle Service asset and cnfiguratin management 9.1.2. Business vrstva Zadavatel pd tímt pjmem definuje standard pr vedení číselníku na úrvní business vrstvy, který se bvykle pužívá přím jak datvý typ Ple a/neb ENUMERATOR uvedený a spravvaný přím na úrvni business vrstvy. Zadavatel pžaduje, aby v případě pužití tét metdy byl tent číselník přím uveden v předané dkumentaci řešení v kapitle Service asset and cnfiguratin management 31

9.1.3. Databázvá Zadavatel pd tímt pjmem definuje standard pr vedení číselníku na úrvní datvé vrstvy, který se bvykle pužívá jak Tabulka neb Subr a je spravvaný přím na úrvni datvé vrstvy. Zadavatel pžaduje, aby v případě pužití tét metdy byl tent číselník přím uveden v předané dkumentaci řešení v kapitle Service asset and cnfiguratin management 9.1.4. Externí číselníky bez správy s externím vstupním interface XML neb pdbně. Zpravidla se může jednat číselník získaný prstřednictvím veřejné webvé služby 9.2. Správa paralelně vedených Číselníků mezi aplikacemi a jejich synchrnizace Zadavatel tímt definuje standard principu pužívání ttžných číselníků ve dvu a více aplikacích neb integrační vrstvě, kdy je třeba zajistit vzájemnu synchrnizaci číselníků. 9.2.1. Jednsměrná vstupní tzv. MASTER Přidání, změna nvé plžky číselníku prbíhá přím prstřednictvím ddanéh řešení a t výhradně d datvé vrstvy řešení. Další aplikace puze vyzvedávají hdnty pr vlastní zbrazení. Zpravidla jsu tyt číselníky distribuvány prstřednictvím integrační platfrmy výhradně v režimu jen pr čtení. Odstraňvání dat z číselníků NENÍ POVOLENO z důvdu zachvání datvé integrity na úrvni datvé vrstvy. Jedntlivé záznamy musí dispnvat přepínačem aktivní/neaktivní, kdy musí být na úrvni aplikační správy číselníků umžněn zbrazvat plžky s uvedením tht atributu. Neaktivní záznamy nesmí být uživateli řešení zbrazeny v číselníku. 9.2.1.1. S časvým hraničením platnsti V některých případech může být pužit také časvé hraničení platnsti číselníku v režimu OD-DO, kdy je zbrazení řízen prstřednictvím věření prti aktuálnímu datu a času. Tent typ číselníku musí být vybaven také přepínačem aktivní/neaktivní. 9.2.2. Jednsměrná výstupní SLAVE Správa číselníku není na tét úrvni řešení mžná. Obsah číselníku je získáván prstřednictvím integrační platfrmy puze v režimu pr čtení aktivních neb časvě platných údajů. 9.2.3. Obusměrná Tent typ správy hdnt číselníků je vylučen prstřednictvím rganizačních prcesů. Zpravidla je řešen Asynchrnním způsbem. Ddavatel musí mít řešení k tmut způsbu přizpůsben. V případě, kdy bude řešen prstřednictvím časvě naplánvané úlhy musí být tat úlha zavedena d dkumentace sekce Service asset and cnfiguratin management 32

10. SLA 10.1. Specifikace parametrů SLA pr jedntlivá prstředí Zadavatel pžaduje ddání řešení, která budu splňvat pdmínky pr níže uvedená SLA. Samtné SLA však budu v režii zadavatele. 10.1.1. Prdukční prstředí Katalgvý list Služby SS01 Prtály - prdukční Název Služby Dstupnst služby Režim prvzu Reakční dba Režim dstávek Max. dba výpadku Garance dstupnsti funkcinalit, bsahu a pdpra prvzu prtálů LČR (Internet, Extranet, Intranet) 97,77 % v kalendářním měsíci 24x7 30 minut (60 min. v případě pžadavku na službu) Maximální pvlená dba dstávky za měsíc: 4 hdiny 16 hdin/kalendářní měsíc (dle pžadvané dstupnsti služby) 10.1.2. Testvací prstředí Katalgvý list Služby SS01 Prtály - testvací Název Služby Dstupnst služby Režim prvzu Reakční dba Režim dstávek Max. dba výpadku Garance dstupnsti funkcinalit, bsahu a pdpra prvzu prtálů LČR (Internet, Extranet, Intranet) 95 % v kalendářním měsíci 12x5 v pracvní dny d 06-18hd. 30 minut (60 min. v případě pžadavku na službu) Maximální pvlená dba dstávky za měsíc: 4 hdiny 8 hdin/kalendářní měsíc (dle pžadvané dstupnsti služby) 10.1.3. Vývjvé prstředí Katalgvý list Služby SS01 Prtály - vývjvé Název Služby Dstupnst služby Režim prvzu Reakční dba Režim dstávek Max. dba výpadku Garance dstupnsti funkcinalit, bsahu a pdpra prvzu prtálů LČR (Internet, Extranet, Intranet) 95 % v kalendářním měsíci 12x5 v pracvní dny d 06-18hd. 30 minut (60 min. v případě pžadavku na službu) Maximální pvlená dba dstávky za měsíc: 4 hdiny 8 hdin/kalendářní měsíc (dle pžadvané dstupnsti služby) 33

11. OLA Pr zajištění plnění budu zadavatelem p dbu trvání prjektu zajištěny služby tzv. OLA definvané v tmt článku. Pr řízení služeb OLA bude pužit výhradně systém HELD DESKU, kterým dispnuje zadavatel. 11.1. Organizační OLA Zadavatel se zavazuje, že p dbu plnění předmětu tét zadávací dkumentace bude vybranému ddavateli zajišťvat přístup k těmt úrvním OLA. 11.1.1. Přístup k HW zdrjům Zadavatel umžní puze přístup k virtuálnímu serveru a t prstřednictvím jednh z managementvých prtklů a t RDP, SSH, Telnet, http, Https, FTP, TFTP a t na nejvyšší úrvni právnění. Tent přístup k ptřebným zdrjům bude definván pr každý server z nvě budvané farmy. Zadavatel neumžní přístup k serverům stávajícím a t ani k LDAP databázi, změny na tét úrvni budu vždy řešeny prstřednictvím RFC. Katalgvý list Služby OLA001-Přístup k HW zdrjům Název Služby Dstupnst služby Režim prvzu Reakční dba Garance přístupu k HW zdrjům 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) 11.1.2. Přístup k SW zdrjům Zadavatel umžní přístup k instalačním subrům aplikací, které budu vyžadvány neb pžadvány ddavatelem. Zadavatel pžaduje, aby uchazeč v rámci nabídky specifikvat, jaké sftwarvé balíčky pžaduje před zahájením ddávky aplikačníh prstředí. Katalgvý list Služby OLA002-Přístup k SW zdrjům Název Služby Dstupnst služby Režim prvzu Reakční dba Garance přístupu k SW zdrjům 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) 11.1.3. Vzdálený přístup d pčítačvé sítě Zadavatel umžní ddavateli vzdálený přístup na předem připravené servery nainstalvané v režimu Next- Next-Finish, puze s nastavením mžnsti vzdálenéh přístupu. Ddavatel bude mít předem připravený účet v LDAP databáze ze strany zadavatele pr sebe a celý vývjvý tým, který se bude danu aplikaci vyvíjet. Tyt účty budu mít nastavena nejnižší mžná právnění a administrátrský přístup ke všem serverů z farmy intranetvé aplikace. Zadavatel na vyžádání pskytne administrátrský přístup d prstředí ddavateli s právněním administrátr LDAP Databáze a t puze ve chvíli kdy bude nutné knfigurvat knektry d tét databáze. Katalgvý list Služby OLA004-vzdálený přístup Název Služby Kategrie / Kritičnst Dstupnst služby Režim prvzu Reakční dba Garance vzdálenéh přístupu d pčítačvé sítě A 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) 34

11.1.4. Administrativní zázemí s napájením 220v a připjením k veřejné síti internet Katalgvý list Služby OLA006-Administrativní zázemí pr zajištění předmětu plnění Název Služby Kategrie / Kritičnst Dstupnst služby Režim prvzu Reakční dba Administrativní zázemí pr zajištění předmětu plnění s napájením 220V a připjením k veřejné síti internet v rzsahu ptřebném pr zajištění suběžnéh fungvání nejméně 4 pracvišť A 89,50 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) 11.2. Technická OLA 11.2.1. Zajištění HW Zdrjů Katalgvý list Služby OLA008-HW Zdrje Název Služby Kategrie / Kritičnst Dstupnst služby Režim prvzu Reakční dba Pznámka Zajištění HW Zdrjů A 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) Tat OLA bude blíže upřesněna dle pžadavků vítěznéh uchazeče. 11.2.2. LDAP Katalgvý list Služby OLA009-Služba LDAP Název Služby Kategrie / Kritičnst Dstupnst služby Režim prvzu Reakční dba Pznámka Zajištění služeb LDAP prstřednictvím Micrsft Active Directry A 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) Služba je v prvzu v režimu 24x7 avšak bez garance řešení incidentů a pžadavků 35

11.2.3. Datvý extrakt TARGET Katalgvý list Služby OLA010-Datvý extrakt z persnálníh systému TARGET Název Služby Kategrie / Kritičnst Dstupnst služby Režim prvzu Reakční dba Pznámka Zajištění aktuálníh datvéh extraktu z persnálníh systému TARGET A 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) Služba je v prvzu v režimu 24x7 avšak bez garance řešení incidentů a pžadavků 11.2.4. SMTP Server Katalgvý list Služby OLA011-pštvní server Název Služby Kategrie / Kritičnst Dstupnst služby Režim prvzu Reakční dba Pznámka Zajištění služeb pštvníh serveru Micrsft Exchange A 97,77 % v dbě režimu prvzu 8x5 v pracvní dny d 07-15hd. 120 minut (180 min. v případě pžadavku na službu) Služba je v prvzu v režimu 24x7 avšak bez garance řešení incidentů a pžadavků 36

12. Pžadavky na prvedení testvání a akceptace Testvání mdulů bude prbíhat výhradně p schválení testvacíh scénáře zadavatelem. Testvací scénář musí být vždy ddán minimálně 5 pracvních dní před samtným prvedením testvání. Zadavatel pžaduje, aby v rámci ddávky každý z jedntlivých mdulů (aplikací) a zárveň celý systém pršli akceptací ze strany zadavatele. V rámci tét akceptace budu kntrlvány veškeré funkcinality, jež pžaduje zadavatel v rámci technických specifikací jedntlivých mdulů, případně PID a bude kntrlvat zejména plnění bsahu, práci s daty, chybvst a suvisející pžadavky dle tét specifikace. 37

13. Pžadavky na šklení Zadavatel pžaduje v rámci ddávky zajištění fyzickéh šklení. Minimální rzsah šklení je 4 hdiny pr každý mdul a úrveň bsluhy (uživatelské, Klíčvý uživatel OJ, Správce bsahu OJ, Administrátr). Maximální pčet účastníků pr jeden mdul a úrveň je 10. 13.1. Uživatelské šklení Zadavatel pžaduje pr všechny mduly minimálně tut strukturu snvy šklení pr uživatele uživatelské úrvně. 13.1.1. Úvd d prblematiky Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.1.1. Přehled mdulů Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.1.2. Scénáře pužívání Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.2. Vstup d aplikace a věření identity uživatele Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.3. Seznámení s navigací aplikace Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.4. Seznámení s pdpůrnými číselníky aplikace Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.5. Práce s daty a mžnsti jejich pužití v kancelářských aplikacích Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.1.6. Pracvní pstupy Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.2. Šklení pr správce bsahu Pr správce bsahů agend bude uživatelské šklení rzšířen minimálně tyt mduly. 13.2.1. Úvd d prblematiky správců bsahu Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.2.1.1. Správa číselníků Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.2.1.2. Vazby mezi datvými zdrji Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 38

13.2.1.3. Pracvní pstupy Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.2.1.4. Mžnsti využití ntifikací Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.2.1.5. Lgvání dat a jejich využití pr reprting Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3. Administrátrské šklení správce chdu aplikace 13.3.1. Úvd d prstředí a ppis instalace Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.2. Vytvření aplikace pr Intranet Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.3. Administrace webů Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.4. Knfigurace bsahvéh řízení Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.5. Autentifikace Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.6. Bezpečnst bsahu Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.7. Úpravy prstředí Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.8. Ntifikace Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.9. Integrace s datvými zdrji Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.10. Vyhledávání a správa fulltextvé databáze bsahu Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.11. Zálhvací a Obnvvací strategie Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 39

13.3.12. Sledvání a ptimalizace výknu Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 13.3.13. Zajištění prcesů dle ITIL Zadavatel pžaduje, aby uchazeč ve své nabídce specifikval bsah danéh mdulu v rámci tht šklení, jeh časvu nárčnst a úrveň technické dvednsti jedntlivých uživatelů. 40

14. Pžadavky na lgvání Zadavatel pžaduje, aby aplikace umžňvala definvání minimálně následujících úrvní lgvání v interním systému a t v pravidelných intervalech bez zatížení systému max. 20% z celkvéh výknu farmy. Lgvání událstí musí umžnit definvání těcht úrvní lgvání: Žádné Kritické Chyba Varvání Infrmace Diagnstika Dále pak je nutné u trasvacíh lgu umžnit lgvání d těcht úrvní: Žádné Nečekávané Mnitrvané Vyské Střední Diagnstické Lw-Level Diagnstické Lgvání musí být mžn zapnut minimálně na níže uvedených úrvních a ke každé části musí být mžn nastavit úrveň lgvání a trasvání. Lgvání publikační vrstvy Lgvání práce v aplikaci Lgvání práce v administraci Lgvání aplikační vrstvy Lgvání práce v aplikaci Lgvání práce v administraci Lgvání datvé vrstvy Lgvání vyhledávací vrstvy Lgvání rendervací vrstvy Výstupní lgy mhu být ulženy a t na úrvni peračníh systému, aplikace neb v subrech v čitelné pdbě. Zadavatel také pžaduje, aby byl trvale umžněn lgvání na úrvni event lg managementu a t pr níže definvané blasti celéh aplikačníh řešení: Využití analýzy Mnitrvání aplikací Statistiky aplikace Sledvání šířky pásma Využití exprtu bsahu Využití imprtu bsahu Definice využití plí pr vzdělávací telemetrie Definice využití plí pr mikrblgvací telemetrie Definice využití plí pr servisní části Definice využití plí distribuvané cache Definice využití plí pracvních pstupů Pužívání funkcí V/V subrů Žádsti stránky Pužívání akcí rzhraní API klienta a služby REST Využití pžadavků REST a rzhraní API klienta Měření prstředků pžadavků na izlvaný prstr (sandbx) Pžadavky na izlvaný prstr (sandbx) 41

Pužívání výjimek SQL Využití V/V SQL Využití latence SQL Pužívání úklů Prtklvání klienta Úlhy časvače Kntrla času dpvědí/ Prcesní časvé metriky pr přístup ke službám Využití imprtu prfilů uživatelů ze služby LDAP Prfil uživatele pr využití synchrnizace Zadavatel pžaduje, aby byl lgy mžn číst z něklika míst a t: Subrvé umístění Event lg serveru Administrační rzhraní celéh řešení 42

15. Pžadavky na dkumentaci Zadavatel pžaduje jaku sučást řešení ddávku dkumentace v rzsahu minimálně dle tht bdu. Rzsah dílčí dkumentace nemůže být žádným způsbem mezen. V případě, kdy nebude účelné plnit příslušný bd bsahem, tak se míst vyplní bsahem Není aplikván. Pužití tht značení musí být vždy dsuhlasen zadavatelem. V případě pužití základní platfrmy pr vývj řešení zadavatel připuští, že dkumentace může být i ve frmě dkazu na URL adresu výrbce platfrmy. Všechny prvky vývje však musí být zdkumentvány pr pkrytí celéh živtníh cyklu ddanéh řešení. 15.1. Service Desk 15.1.1. Knwledge Base Zadavatel pžaduje, aby uchazeč v rámci ddávky aplikačníh řešení udržval znalstí bázi celéh řešení, ve které bude evidvat veškeré chyby nalezené při implementaci (Incidenty, Prblémy), změny prvedené ve vlastním zadání (RFC), knfigurační změny prti standartním knfiguracím. Tent katalg znalstní báze bude na knci prjektu předán zadavateli ve frmátu XLS, XLSX v čitelné pdbě tak, aby zadavatel v těcht znalstech mhl nadále pkračvat a tut databázi udržvat jak jeden z prvků dkumentace. Zadavatel také pžaduje, aby znalstní báze byla dstupná v intranetvé aplikaci pr uživatele, pkud v rámci implementace budu vznikat pžadavky z jejich strany, tak aby každý z uživatelů mhl v tét databázi vyhledávat a prblémy vzniklé během implementaci řešit svépmcí. 15.1.1.1. Uživatel zadavatel pžaduje jak sučást řešení ddávku scénářů a návdů pr všechny ppsané uživatelské scénáře. Dkumentace bude mít minimálně tut strukturu: Správce Tištěná dkumentace zadavatel pžaduje jak sučást řešení ddávku scénářů a návdů pr všechny administrační scénáře. Dkumentace bude mít minimálně tut strukturu: Ppis pužitých standardů Tištěná dkumentace s ppisem administrace 15.1.1.2. Pdpra pdle úrvně SLA, OLA Zadavatel v rámci ddávky řešení pžaduje ddání dpručených pstupů pr typy incidentů dle nastavených SLA 15.1.1.3. Vývj řešení zadavatel pžaduje jak sučást řešení ddávku zdrjvých kódů s kmentáři pr všechny mduly, funkce a vlastnsti všech prvků a prměnných pužitých při vývji řešení, mim prvků pužitých výrbcem platfrmy, na které bude řešení realizván. Dkumentace bude mít minimálně tut strukturu: Ppis pužitých standardů Tištěná dkumentace s ppisem administrace 15.2. Service Supprt 15.2.1. Incident management Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení. 15.2.2. Change management Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení. 15.2.3. Prblem management 43

Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení. 15.2.4. Service asset and cnfiguratin management Zadavatel v suvislsti s pžadavky na vedení knfigurační databáze pžaduje, aby ddavatel v nabídce navrhl jmenný seznam knfiguračních plžek pr všechny jedntlivé aplikační SLA a v případě ptřeby i OLA. Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení. 15.2.5. Service Catalgue Management Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení. 15.2.6. Release and deplyment management 15.2.6.1. Plán pdpry Zadavatel v suvislsti s pžadavky na pravidelnu údržbu pžaduje, aby Uchazeč uvedl d své nabídky návrh plánu pravidelné údržby, přičemž Zadavatel pžaduje, aby sučástí takvéh plánu i samtné realizace pravidelné údržby byly nejméně níže uvedené blasti: Identifikace Updatů Psuzení dpadů instalace takt identifikvaných Updatů na prvz a úrveň kvality veškerých služeb IT, systémů a aplikací Prvedení zálh veškerých služeb IT, systémů a aplikací a t na úrvni sejmutí snímků aktuálníh stavu serveru před prvedením vlastní instalace Updatu Prvedení instalace updatů Kntrla funkčnsti veškerých služeb IT, systémů a aplikací, zejména pak: Kntrla dstupnsti veškerých serverů Kntrla funkčnsti peračních systémů Kntrla funkčnsti aplikací Kntrla funkčnsti služeb peračníh systému Kntrla přihlášení k serverům pr suběžnu práci více uživatelů Kntrla event lgů Kntrla platnsti certifikátů Kntrla přihlášení d systémů Obnvení zálh u nefunkčních služeb IT, systémů a aplikací Vytvření reprtů nainstalvaných Updatů 15.2.6.2. Dkumentace vývje řešení Zadavatel pžaduje minimálně tut strukturu dkumentace pr každu vrstvu řešení, pkud je na ni aplikván vlastní vývj: Datvý mdel řešení Dplněné kmpnenty třetích stran Přehled pužitých funkcí Přehled vládacích prvků Dkumentace pužitých metd Dkumentace pužitých vlastnstí Dkumentace pužitých funkcí Ppis vlastních knihven a tříd 15.2.7. Event management Zadavatel pžaduje, aby sučástí ddanéh řešení byl návrh prcesů pr bsluhu událstí s využitím atributů definvaných v kapitle 44

Pžadavky na lgvání. Prcesy musí být definvány pdle metdiky ITIL. 45

15.3. Service delivery 15.3.1. Capacity management Zadavatel pžaduje, aby sučástí dkumentace řešení byly ddavatelem ppsány atributy dpručené pr pkrytí uvedenéh prcesu pdle aktuálně platné verze ITIL a t minimálně v tét struktuře: Sledvaný parametr Mezní hdnty minimální a maximální Frekvence sběru dat Vlastník Eskalační schéma a ppis ntifikace 15.3.2. Availability management Zadavatel pžaduje, aby sučástí dkumentace řešení byly ddavatelem ppsány atributy dpručené pr pkrytí uvedenéh prcesu pdle aktuálně platné verze ITIL a t minimálně v tét struktuře: Sledvaný parametr Mezní hdnty minimální a maximální Frekvence sběru dat Vlastník Eskalační schéma a ppis ntifikace Business úrveň mnitrvaný parametr bude ntifikvat přím klíčvéh uživatele systému Technická úrveň mnitrvaný parametr bude ntifikvat administrátra neb help desk pdpry řešení 15.3.3. Cntinuity management Zadavatel pžaduje, aby sučástí dkumentace řešení byly ddavatelem ppsány atributy dpručené pr pkrytí uvedenéh prcesu pdle aktuálně platné verze ITIL Zadavatel připuští přijetí ztráty dat v případě výpadku primární a sekundární lkality maximálně v rzsahu 2 hdin. Zadavatel pžaduje, aby Uchazeč jak sučást své nabídky předlžil Plán zálh a Plán bnv Zadavatel pžaduje, aby prces Cntinuity management zajišťval primárně mžnst pr bnvení dat v případě lidské chyby, kdy může v rámci celéh řešení djít k smazání některých dat, aneb bsahu bsahvých databází, ppřípadě chybě administrátra při knfiguračních změnách prváděných z testvacíh prstředí d vlastníh prdukčníh prstředí. Pkud k tét chybě djde, musí prces Cntinuity management být schpen zajistit bnvení dat a t v rzsahu definvaném v SLA, OLA. Dále je nutné, aby tent prces a systém pr zálhvání a bnvení byl schpen prvést znvu sestavení celéh řešení v případě selhání a v rámci testvání tht prcesu bude prvedena bnva celé farmy d testvacíh prstředí neb d prstředí DMZ v dděleném subnetu, tak aby nedšl k narušení prvzní části celéh řešení. Zadavatel pžaduje, aby uchazeč ve své nabídce uvedl, jakým způsbem bude schpen tent prces zadavatel zajistit svépmcí a t minimálně přípravu dkumentace a prvzníh manuálu na prvedení Disaster recvery planing a tím i stanvení kalendářů plánů bnvy a zálhy celéh řešení. 15.3.4. Financial management Není pžadván 15.3.5. Service Level Management Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení. 15.3.6. Access Management Zadavatel pžaduje, aby sučástí dkumentace byl návrh řešení prcesu dle metdiky ITIL se zhledněním parametrů uvedených v SLA a OLA dle specifikace tht řešení s využitím standardů definvaných v čl. 46

Řízení přístupů 47

Přílha č. 1 Detailní technická specifikace Aplikačníh řešení 1. INT 001 Přehled územní evidence 1.1. Ppis Aplikace umžňuje vyhledávat záznamy v katastru nemvitstí na základě předem definvaných vstupních údajů. Je umžněn vyhledávat dle názvu katastru, 6-ti, neb 9-ti místnéh čísla katastru, názvu OJ, neb čísla OJ. Veškeré tyt parametry se zadávají d frmuláře, který funguje jak bd pr zadávání vstupních vyhledávacích kritérií. Jakmile je prvedené takvé hledání, je autmaticky filtrván list všech záznamů, které zadaným hdntám vyhvují. Pkud je ptřeba, je dále mžné kliknut na jakýkliv z již filtrvaných záznamů v seznamu a následně se zbrazí v další webvé části jedntlivé pdrbnsti detaily k vybrané plžce. Aplikace, která je umístitelná na jakukliv stránku intranetvéh prtálu jakžt samstatná aplikace. Tut aplikaci je mžné prpjit s externími seznamy dat v pdbě datvých připjení. Tyt připjení jsu definvána v rámci nasazení aplikace, nicméně je mžné změnit bez pužití úpravy zdrjvéh kódu aplikace. Je tedy mžné změnit databázi, ze které by byly čerpány data. P změně zdrje dat bude aplikace zbrazvat puze data, která tent zdrj bsahuje. Je důležité zmínit, že tat aplikace služí puze jak zbrazvací prstředek, nikli jak nástrj na editaci evidvaných plžek v databázi, neb na zakládání takvýcht nvých plžek. 1.2. Vlastnsti Aplikace ekatastr je tvřena kmbinací tří prvků v rámci webvé stránky. První prvek tvří frmulář, kde je mžné stanvit uživatelem parametry vyhledávání a na jejich základě vyfiltrvat v druhém prvku knkrétní data z databáze. Tyt vyfiltrvaná data je mžné dále selektvat a zbrazit tak jejich detaily v třetím prvku webvé stránky. Není umžněn data jakýmkliv způsbem mdifikvat, jen je prhlížet. 1.3. Use Cases případy pužití Aplikace služí výhradně k infrmvání uživatelů na základě předem definvaných kritérií pdrbnstech bjektu, který byl vybrán z databáze katastru, případně jinéh předem definvanéh datvéh zdrje. Návštěvník dané aplikace má puze mžnst vyhledávání v tabulce bsahující infrmace katastrálním území, přičemž v základním phledu pr filtrvání bude zbrazena puze skupina záznamů z databáze a t zejména plžky, dle kterých je mžn i filtrvat Jmén katastrálníh celku (značen číslem) Organizační jedntka (vyhledání dle města) Evidenční čísl rganizační jedntky (evidenční čísl města) Evidenční čísl katastru (6 místná hdnta typu integer) Druhé evidenční čísl katastru (9 místná hdnta typu integer) P zbrazení nalezenéh územníh celku je mžn zbrazit celý detail záznamu v tabulce, který bude bsahvat všechny hdnty, které dané katastrální území bsahuje. 1.4. Rle Uživatel čtenář reprezentant kncvéh uživatele, který p zadání pžadvaných vstupních parametrů nahlíží d databáze katastru nemvitstí a v rámci knkrétní selekce i d detailů. Tat rle nemá žádné pžadavky na mezený přístup a je tedy předvlena všem uživatelům prtálvéh řešení. Tent uživatel nemá práva na změnu jakékliv hdnty v plžkách. Katastr nemvitstí je reprezentván databází jedntlivých subjektů, ke kterým má uživatel čtenář přístup v rámci vyhledávání na základě parametrů služících k zúžení vyhledávanéh subjektu. Jedná se externí systém reprezentvaný nastaveným datvým připjením k aplikaci s katastrálními údaji. Správce reprezentant administrativníh pracvníka s mžnstí správy bsahu (glbální nastavení a pvlvání funkcí danéh webu), kdy nemůže upravvat jedntlivé záznamy imprtvané d tabulky katastrálních území. 48

1.5. Číselníky a správa Není aplikván 1.6. OLA Zadavatel zajistí prstřednictvím integrační vrstvy přístup k databázi s tut strukturu zdrjvé tabulky Jmén katastrálníh celku (značen číslem) Organizační jedntka (vyhledání dle města) Evidenční čísl rganizační jedntky (evidenční čísl města) Evidenční čísl katastru (6ti - místná hdnta typu integer) Druhé evidenční čísl katastru (9ti- místná hdnta typu integer) 1.7. SLA Viz. Obecný ppis řešení s upřesněním pr dhadvané mnžství záznamů v rzsahu 1000. Zadavatel pžaduje, aby byla aplikace ptimalizvána na rychlst vyhledávání a zbrazvání výsledků s využitím stránkvání výsledné mnžiny záznamů. Stránkvání musí být řešen na úrvni datvé vrstvy. 1.8. Vstupní interface Vstupní interface je tvřen zadávacím frmulářvým prvkem, který služí pr definvání vyhledávacích parametrů. Datvý můstek pr imprt dat d systému v režimu úplné dstranění a imprtvání nvých dat. 1.9. Migrace dat Není aplikván, ale řešení musí umžňvat napjení na libvlný datvý zdrj prstřednictvím knfigurvatelnéh parametru tzv. CnnectinString v nezávislém subru s využitím frmát XSD a výměny dat prtklem XML. Dalším z mžných zdrjů pr přístup k datům pr migraci je imprt z CSV subru. Zdrjvými databázemi mhu být například: Micrsft SQL Server Oracle MySQL A další becně pužívané 1.10. Wrkflw Není aplikván. Oprávnění k práci se záznamy je řešen prstřednictvím nastavení právnění. 1.11. Lgvání dat Přihlášení uživatele Záznam spuštění úlhy pr vyhledání záznamů se zachycením sekvence vyhledávacíh řetězce a pčtu vrácených výsledků Lgvání dat na úrvni tét aplikace s mžnstí nastavení zbrazení histrických dat za 365 dní s mžnstí exprtu d frmátu tabulky Prvz Pčet zbrazení stránky Jedinečných návštěvníků za den Pčet dkazujících serverů Nejblíbenější stránky Nejčastější návštěvníci Nejčastější dkazující servery Nejblíbenější cíle Nejblíbenější prhlížeče Hledání Pčet dtazů Nejblíbenější dtazy Neúspěšné dtazy Využití nejlepšíh tipu 49

Návrhy nejlepších tipů Histrie akcí návrhů nejlepších tipů Klíčvá slva pr vyhledávání Supis Využití úlžiště Pčet webů 1.12. Časvě plánvané úlhy Zadavatel pžaduje, aby sučástí ddanéh řešení byla Časvě naplánvána úlha pr aktualizaci zdrjvých dat. Termín spuštění bude specifikván v rámci PID dle OS. 1.13. Reprting Není aplikván 50

2. INT-002 - Registr nájmů LČR 2.1. Ppis Aplikace Registr nájmů LČR musí umžnit zadavateli vytvářet, editvat a upravvat plžky registru. Tent registr je statickým bsahem a využívá ke své funkci něklik statických číselníků, ze kterých je nadále sestaven ucelený phled. Aplikace bude využívat statické databázvé tabulky, přičemž nad hlavní tabulku bude mžn filtrvat na těcht úrvních: - Míst nájmu - Stav schválení nájemní smluvy - Velikst prnajímaných prstr - Organizační jedntka - Jmén nájemní smluvy Aplikace musí umžnit přilžení přílhy nájemní smluvy ve frmátu PDF a v rámci interníh vyhledávání umžnit hledat v bsahu dané nájemní smluvy. Infrmace uskutečněných prnájmech bude přenášena skrze integrační platfrmu na extranet zadavatele. 2.2. Vlastnsti Aplikace by měla být tvřena z minimálníh pčtu 5 prvků (číselníků), kdy: - 1. číselník bude služit pr evidenci OJ (načten z číselníku OJ, který je specifikván v dkumentu aplikace Správa uživatelů intranetu ) - 2. číselník bude služit pr evidence stavu schválení nájemní smluvy (Název, Ppis) - 3. číselník bude služit pr evidenci druhu nájmu (Název, Ppis) - 4. číselník bude služit pr evidenci nájemních smluv (Název, Typ, Vlastní bsah) - 5. číselník bude prezenční prvek (webvá stránka) na které budu sestaveny data z statních prvků (číselníků) a budu zde dplněna další metadata a t minimálně: Název OJ (načten z číselníku OJ, který je specifikván v dkumentu aplikace Správa uživatelů intranetu ) Název Čísl Velikst prnajímaných prstr Druh nájmu načten ze samstatnéh číselníku Stav schválení nájemní smluvy načten ze samstatnéh číselníku Míst nájmu Datum uskutečnění nájmu Míst dručení nabídky Datum dručení nabídky Míst knání prhlídky Datum knání prhlídky Čas knání prhlídky Výše zálhy nájmu Prnajímatel Cena nájmu bez DPH Další infrmace Přílhy načten ze samstatnéh číselníku Změnil načten z LDAP databáze Datum změny Zadavatel pžaduje, aby veškeré vlžené přílhy k dané plžce seznamu byl mžn přidat a zbrazit. Nikliv však měnit neb mazat, aby nedšl k narušení datvé integrity. 2.2.1. Vyhledání záznamu Vyhledávání jedntlivých záznamů z databázvé tabulky bude řešen prstřednictvím libvlné kmbinace těcht parametrů: Míst nájmu Stav schválení nájemní smluvy Velikst prnajímaných prstr Organizační jedntka Jmén nájemní smluvy 51

2.3. Use Cases případy pužití Aplikace služí výhradně k vyhledávání záznamů předmětech nájmu, které jsu vyhlašvány zadavatelem. 2.4. Rle Uživatel/Návštěvník sba, která má práva k prhlížení bsahu, vyhledávání dat a náhled dat v intranetvé části. Změnu členství tht seznamu smí prvádět dispnent neb administratr Správce bsahu (Dispnent) sba, která se stará danu OJ v rámci, které je nájem vyhlašván, tat sba má práva přidávat, upravvat a mazat záznamy vytvřené v daném seznamu, přičemž nesmí mít práva na smazání přílhy neb záznamu jak samstatnéh prvku, aby nedšl k prušení integrity dat v daném seznamu Administratr sba, která má nemezená práva k dané aplikaci, může prhlížet, přidávat a mazat záznamy, přičemž tt není hlavní náplní tét funkce. Tat funkce má práva prvádět výpis nastavení, knfigurace bezpečnstních skupin aplikace a dále vystavvání reprtů z lgů aplikace. 2.5. Číselníky a správa Aplikace bsahuje tyt číselníky, které smí upravvat puze rle Správce bsahu a Administratr číselník bude služit pr evidenci OJ (načten z číselníku OJ, který je specifikván v dkumentu aplikace Správa uživatelů intranetu ) číselník bude služit pr evidence stavu schválení nájemní smluvy (Název, Ppis) číselník bude služit pr evidenci druhu nájmu (Název, Ppis) číselník bude služit pr evidenci nájemních smluv (Název, Typ, Vlastní bsah) 2.6. OLA Zadavatel zajistí data ve frmátu CSV s ddělvačem ; neb, ppřípadě přímý přístup d tabulky databáze s tut strukturu zdrjvé tabulky: Název OJ (načten z číselníku OJ, který je specifikván v dkumentu aplikace Správa uživatelů intranetu ) Název (string) Čísl (string) Velikst prnajímaných prstr (integer) Druh nájmu (string) Stav schválení nájemní smluvy (string) Míst nájmu (string) Datum uskutečnění nájmu (datetime) Míst dručení nabídky (string) Datum dručení nabídky (datetime) Míst knání prhlídky (string) Datum knání prhlídky (datetime) Čas knání prhlídky (datetime) Výše zálhy nájmu (decimal) Prnajímatel (string) Cena nájmu bez DPH (integer) Další infrmace (string) Přílhy (-) Změnil (načten z LDAP databáze) Datum změny (datetime) 2.7. SLA Viz. OS s upřesněním pr dhadvané mnžství záznamů v rzsahu 1000. Zadavatel pžaduje, aby byla aplikace ptimalizvána na rychlst vyhledávání a zbrazvání výsledků s využitím stránkvání výsledné mnžiny záznamů. Stránkvání musí být řešen na úrvni datvé, v důvdněných případech i s mžnstí využití aplikační vrstvy, tak aby nebyl mezen výkn aplikace p celu dbu živtníh cyklu. 52

2.8. Vstupní interface Zadavatel pžaduje, aby vstupním prvkem byl frmulář s bsahem všech plí pr všechny definvané rle bez mezení pr jedntlivé rle, frmulář bude puze pr každý číselník a jejich úprava bude mžná i p prvedení implementace a t zejména rzšíření dalšíh ple, aniž by dšl k prušení integrity dat, přičemž data pr nvě definvané ple budu plněna ručně editací každéh samstatnéh záznamu přím z aplikace, nikliv zásahem d databáze. 2.9. Validace dat Validace musí splňvat pdmínky pr věření minimálně na definvané datvé typy. Zadavatel ze svých ptřeb validace dat pr tent mdul plnění nepžaduje. Některé prvky prezentační vrstvy však mhu v průběhu implementace být značeny jak pvinné a pté musí být v rámci plnění frmuláře zajištěna nemžnst ulžení záznamu bez vyplnění tét hdnty. 2.10. Migrace dat Zadavatel ddá tabulku neb přístup d databáze k tabulce bsahující výše uvedené infrmace, které budu d nvé aplikace naplněny, tut tabulku ddá Dispnent neb Administratr zadavatele. 2.11. Wrkflw Není aplikván. Oprávnění k práci se záznamy je řešen prstřednictvím nastavení právnění. 2.12. Lgvání a auditvání Přihlášení uživatele Záznam spuštění úlhy pr vyhledání záznamů se zachycením sekvence vyhledávacíh řetězce a pčtu vrácených výsledků Lgvání dat na úrvni tét aplikace s mžnstí nastavení zbrazení histrických dat za 365 dní s mžnstí exprtu d frmátu tabulky Prvz Pčet zbrazení stránky Jedinečných návštěvníků za den Pčet dkazujících serverů Nejblíbenější stránky Nejčastější návštěvníci Nejčastější dkazující servery Nejblíbenější cíle Nejblíbenější prhlížeče Hledání Pčet dtazů Nejblíbenější dtazy Neúspěšné dtazy Využití nejlepšíh tipu Návrhy nejlepších tipů Histrie akcí návrhů nejlepších tipů Klíčvá slva pr vyhledávání Supis Využití úlžiště Pčet webů 2.13. Časvě plánvané úlhy Zadavatel pžaduje, aby byly d aplikace přenášeny infrmace OJ a uživatelích z LDAP Databáze, které bude mžn následně d nvé aplikace vyplnit a t v časvém intervalu maximálně 15 minut. 2.14. Reprting Zadavatel nepžaduje na tét úrvni aplikace žádný reprting. 53

3. INT-003 - Aplikace Významná místa na území spravvaných LČR 3.1. Ppis Aplikace Významná místa na území spravvaných LČR služí pr evidenci spravvaných lkalit zadavatelem. Tat aplikace pmáhá zadavateli lépe plánvat činnsti údržby, plánvání činnstí a hspdaření s místy spravvanými zadavatelem. Správci jedntlivých OJ prvádí úpravy, vkládání záznamů a tyt změny jsu dále skrze integrační platfrmu prezentvány d extranetu, aby i širká veřejnst měla přehled všech údržbách a činnstech v jedntlivých místech. Tat data jsu pté zbrazena na mapě splečně s ppisem. 3.2. Vlastnsti - Systém musí umžnit vlžní pzice rstliny a t pmcí suřadnic a umžnit přepčty pmcí standardů S- JTSK a WGS-84. Tyt suřadnice musí být dále interpretvány d mapy, která bude tyt rstliny zbrazvat. - Systém musí dále umžnit publikvání d internetvých stránek LCR skrze integrační platfrmu, která není sučástí tét specifikace. - Každý vytvřený záznam bude bsahvat metadata verzi, která bude pvýšena při každé změně záznamu. - Aplikace musí umžnit vlžení ftgrafie, která bude reprezentvána iknu vedle záznamu a bude libvlné její tevření a zbrazení uživatelem 3.2.1. Vyhledání záznamu Vyhledávání jedntlivých záznamů z databázvé tabulky bude řešen prstřednictvím libvlné kmbinace těcht parametrů: Druh rstlin Evidenční čísl katastru Název rstliny Vyhláška PS Kód druhu rstliny Kd zaznamenal druh rstliny Čísl zpracvání Platnst d Platnst d Druh rstliny Výška rstliny Obvd rstliny Stáří rstliny Zdraví rstliny Pznámky Úhyn Míst 3.3. Use Cases případy pužití Aplikace služí výhradně k zajištění centrální evidence rstlin, jejich prhlížení v rámci náhledu a k její plné lkalizaci s grafickým zbrazením na mapě České republiky. Dále pak je aplikace určena jak pr interní uživatele zadavatele, tak i jak zdrj pr integrační platfrmu, která není sučástí tét specifikace ani zadávací dkumentace. 3.4. Rle Uživatel/Návštěvník tat rle zastupuje běžnéh uživatele, který má práva puze k nahlížení d dat a k zbrazení detailu záznamu 54

Klíčvý uživatel OJ tat rle zastupuje uživatele, který může upravvat bsah v záznamech, jež jsu přiřazeny dané OJ Správce bsahu OJ (Dispnent) tat rle zastupuje uživatele, který musí validvat nvě přidaná data k dané OJ Vlastník tat rle zastupuje uživatele, který má práva měnit členství jedntlivých skupin a upravvat veškeré záznamy, ale musí být šetřena integrita dat v případě změny záznamu Administrátr - sba, která má nemezená práva k dané aplikaci, může prhlížet, přidávat a mazat záznamy, přičemž tt není hlavní náplní tét funkce. Tat funkce má práva prvádět výpis nastavení, knfigurace bezpečnstních skupin aplikace a dále vystavvání reprtů z lgů aplikace. 3.5. Číselníky a správa Aplikace by měla bsahvat tyt číselníky, které smí upravvat puze rle Správce bsahu OJ a Administrátr - 1. číselník bude služit pr evidenci OJ (načten z číselníku OJ, který je specifikván v dkumentu aplikace Správa uživatelů intranetu ) - 2. číselník bude služit pr evidenci eknmických celků (ID, Název) - 3. číselník bude služit pr evidenci druhů rstlin (Český název, Odbrný název) - 4. číselník bude služit pr evidenci územních úhrnů (Název, Evidenční čísl území, druhé evidenční čísl území) - 5. číselník bude služit pr zbrazení mapy s plhu - 6. číselník bude služit pr evidenci přílh - 7. číselník bude prezenční prvek (webvá stránka) na které budu sestaveny data z statních prvků (číselníků) a budu zde dplněna další metadata a t minimálně: Druh rstlin (string) Evidenční čísl katastru (string) vazba na číselník z aplikace Přehled územní evidence Název rstliny (string) Vyhláška PS (blean) Kód druhu rstliny (integer) Kd zaznamenal druh rstliny (string) Čísl zpracvání (string) Platnst d (datetime) Platnst d (datetime) Druh rstliny načtení z číselníku Výška rstliny (integer) Obvd rstliny (integer) Stáří rstliny (integer) Zdraví rstliny (string) Pznámky (string) Úhyn (blean) Míst (blean) 3.6. OLA Zadavatel zajistí prstřednictvím integrační vrstvy přístup k databázi s tut strukturu zdrjvé tabulky Druh rstlin (string) Evidenční čísl katastru (string) vazba na číselník z aplikace Přehled územní evidence Název rstliny (string) Vyhláška PS (blean) Kód druhu rstliny (integer) Kd zaznamenal druh rstliny (string) Čísl zpracvání (string) Platnst d (datetime) Platnst d (datetime) Druh rstliny načtení z číselníku Výška rstliny (integer) Obvd rstliny (integer) Stáří rstliny (integer) Zdraví rstliny (string) Pznámky (string) 55

Úhyn (blean) Míst (blean) 3.7. SLA Viz. Obecný ppis řešení s upřesněním pr dhadvané mnžství záznamů v rzsahu minimálně 1000. Zadavatel pžaduje, aby byla aplikace ptimalizvána na rychlst vyhledávání a zbrazvání výsledků s využitím stránkvání výsledné mnžiny záznamů. Stránkvání musí být řešen na úrvni datvé vrstvy. 3.8. Vstupní interface Jedním z klíčvých prvků je vazba na čísl územníh celku, která je načítána z aplikace definvané v dkumentu TECHSPEC_5.4.1_INT-001_Přehled územní evidence.dcx a t z důvdu velkéh mnžství dat v územních celcích a ke zjedndušení správy a validace dat. Oddělení těcht číselníků je důležité zejména z phledu bezpečnsti, kdy v aplikaci Přehled územní evidence může být administrátrem a správcem bsahu jiná sba než v tét aplikaci. Dále pak tyt vstupní interface: - Vstupní interface je tvřen zadávacím frmulářvým prvkem - Datvý můstek pr imprt dat d systému v režimu úplné dstranění a imprtvání nvých dat. 3.9. Validace dat Validace musí splňvat pdmínky pr věření minimálně na definvané datvé typy. Zadavatel ze svých ptřeb validace dat pr tent mdul plnění nepžaduje. Některé prvky prezentační vrstvy však mhu v průběhu implementace být značeny jak pvinné a pté musí být v rámci plnění frmuláře zajištěna nemžnst ulžení záznamu bez vyplnění tét hdnty. Systém musí umžnit validaci dat zadávaných d systému pmcí suřadnic, které budu následně v mapě zbrazvat umístění dané rstliny, tyt suřadnice jsu zadávány přím d vstupníh frmuláře a t přím d číselníku 5, přičemž způsb zadání d tht číselníku je na ddavateli, ale zadavatel preferuje nejjedndušší variantu řešení. 3.10. Migrace dat Zadavatel ddá tabulku neb přístup d databáze k tabulce bsahující výše uvedené infrmace, které budu d nvé aplikace naplněny, tut tabulku ddá Dispnent neb Administratr zadavatele. Uchazeč musí v nabídce pčítat s časem ptřebným k mžnému překladu datvých typů ze zdrjvé d cílvé DB 3.11. Wrkflw V rámci tht řešení je navržen pracvní pstup, při kterém djde ke schválení zadání nvé plžky rlí uživatele Klíčvý uživatel OJ a schválení prběhne uživatelem s rlí Správce bsahu OJ. Správce bsahu OJ musí být vždy při zadání nvé plžky ntifikván emailem a Klíčvý uživatel OJ musí být ntifikván s infrmací schválení Správcem bsahu OJ. 3.12. Lgvání a auditvání Přihlášení uživatele Záznam spuštění úlhy pr vyhledání záznamů se zachycením sekvence vyhledávacíh řetězce a pčtu vrácených výsledků Lgvání dat na úrvni tét aplikace s mžnstí nastavení zbrazení histrických dat za 365 dní s mžnstí exprtu d frmátu tabulky Prvz Pčet zbrazení stránky Jedinečných návštěvníků za den Pčet dkazujících serverů Nejblíbenější stránky Nejčastější návštěvníci Nejčastější dkazující servery Nejblíbenější cíle Nejblíbenější prhlížeče 56

Hledání Pčet dtazů Nejblíbenější dtazy Neúspěšné dtazy Využití nejlepšíh tipu Návrhy nejlepších tipů Histrie akcí návrhů nejlepších tipů Klíčvá slva pr vyhledávání Supis Využití úlžiště Pčet webů 3.13. Časvě plánvané úlhy Zadavatel pžaduje, aby byly d aplikace přenášeny infrmace uživatelích z LDAP Databáze, které bude mžn následně d nvé aplikace vyplnit a t v časvém intervalu maximálně 15 minut. 3.14. Reprting Není aplikván 4. INT-004 - Aplikace Pracvní úkly 4.1. Ppis Aplikace pracvní úkly umžňuje uživatelům zadávat plžky typu kalendářní záznam, který umžní evidenci plánvaných činnstí a akcí knaných v rámci splečnsti zadavatele. Přičemž tat plžka bude mít vždy definvanu platnst, která bude prvádět v hlavním výčtu plžek filtrvání na daný rk a plžky bude mci zbrazit jak nastávající tak i již prběhlé. Tent kalendář prvede zaslání emailu sbě při nastavení jak plánvaná činnst vždy v předem definvaném intervalu. Uživatel p přihlášení musí být schpen vidět na úvdní stránce své plžky a t pr předem definvané termíny předchzí, následující a aktuální den, stantí plžky jsu uživateli skryty. 4.2. Vlastnsti - Umžnit zbrazení určitých záznamů v čase - Umžnit přiřazení záznamů platnsti pr každý rk/kvartál/měsíc/den - Umžnit definici dne spuštění (příklad: 8 den, každé pndělí, první pndělí v měsíci, aj ) - Stanvení způsbu ntifikace Email Telefn Sms - Mžnst zbrazení ve zkrácené frmě tak, aby je byl mžn zbrazit v malém kně intranetvé aplikace - Vazba na LDAP Databázi a t zejména při čerpání infrmace uživateli 4.2.1. Vyhledání záznamu Systém musí umžnit puze filtrvání dat na úrvni glbální tabulky bsahující všechny záznamy a t Správcem (Dispnentem), běžný uživatel tut tabulku neuvidí. Běžný uživatel uvidí puze aktivity své plžky, nikliv statních zaměstnanců zadavatele. 4.3. Use Cases případy pužití Aplikaci budu využívat všichni uživatelé bez výjimky k plánvání svých pravidelných činnstí a dpvědnst za správnst dat a plnění jedntlivých úklů má každá sba, přičemž sba v rli Správce má jediná práv na úpravu záznamů, mazání na úrvni bsahu všech plžek. 4.4. Rle Uživatel/Návštěvník tat rle zastupuje uživatele, který má práva na přidávání záznamů, mazání a úpravu záznamů vlastních Správce bsahu (Dispnent) tat rle zastupuje uživatele, který má práva na přidávání, změnu a mazání všech záznamů na úrvni tét aplikace 57

Administratr - sba, která má nemezená práva k dané aplikaci, může prhlížet, přidávat a mazat záznamy, přičemž tt není hlavní náplní tét funkce. Tat funkce má práva prvádět výpis nastavení, knfigurace bezpečnstních skupin aplikace a dále vystavvání reprtů z lgů aplikace. 4.5. Číselníky a správa Tat aplikace nemá žádné další číselníky. 4.6. OLA Zadavatel zajistí prstřednictvím integrační vrstvy přístup k databázi s tut strukturu zdrjvé tabulky - Obdbí platnsti (string/integer/datetime) - Aktivita (string) - Den aktivity (integer/string/datetime) - Infrmace k aktivitě (string) - Řešitel (string) - Zdpvědná sba (string) - Ntifikace (string) - Kntakt (string) - Pmc (blean) 4.7. SLA Viz. Obecný ppis řešení s upřesněním pr dhadvané mnžství záznamů v rzsahu minimálně 1000. Zadavatel pžaduje, aby byla aplikace ptimalizvána na rychlst vyhledávání a zbrazvání výsledků s využitím stránkvání výsledné mnžiny záznamů. Stránkvání musí být řešen na úrvni datvé vrstvy. 4.8. Vstupní interface Aplikace bsahuje vstupní frmulář, ve kterém bude mžn vyplnit vždy níže uvedená metadata. - Obdbí platnsti (string/integer/datetime) - Aktivita (string) - Den aktivity (integer/string/datetime) - Infrmace k aktivitě (string) - Řešitel vazba na LDAP databázi - Zdpvědná sba vazba na LDAP databázi - Ntifikace (string) - Kntakt vazba na LDAP databázi metadata email z bjektu LDAP vázaný k Zdpvědné sbě - Pmc (blean) 4.9. Validace dat Validace musí splňvat pdmínky pr věření minimálně na definvané datvé typy. Zadavatel ze svých ptřeb validace dat pr tent mdul plnění nepžaduje. Některé prvky prezentační vrstvy však mhu v průběhu implementace být značeny jak pvinné a pté musí být v rámci plnění frmuláře zajištěna nemžnst ulžení záznamu bez vyplnění tét hdnty. 4.10. Migrace dat Zadavatel ddá tabulku neb přístup d databáze k tabulce bsahující výše uvedené infrmace, které budu d nvé aplikace naplněny, tut tabulku ddá Dispnent neb Administratr zadavatele. Uchazeč musí v nabídce pčítat s časem ptřebným k mžnému překladu datvých typů ze zdrjvé d cílvé DB. 4.11. Wrkflw Není aplikván 4.12. Lgvání a auditvání Přihlášení uživatele Záznam spuštění úlhy pr vyhledání záznamů se zachycením sekvence vyhledávacíh řetězce a pčtu vrácených výsledků 58

Lgvání dat na úrvni tét aplikace s mžnstí nastavení zbrazení histrických dat za 365 dní s mžnstí exprtu d frmátu tabulky Prvz Pčet zbrazení stránky Jedinečných návštěvníků za den Pčet dkazujících serverů Nejblíbenější stránky Nejčastější návštěvníci Nejčastější dkazující servery Nejblíbenější cíle Nejblíbenější prhlížeče Hledání Pčet dtazů Nejblíbenější dtazy Neúspěšné dtazy Využití nejlepšíh tipu Návrhy nejlepších tipů Histrie akcí návrhů nejlepších tipů Klíčvá slva pr vyhledávání Supis Využití úlžiště Pčet webů 4.13. Časvě plánvané úlhy Zadavatel pžaduje, aby byly d aplikace přenášeny infrmace uživatelích z LDAP Databáze, které bude mžn následně d nvé aplikace vyplnit a t v časvém intervalu maximálně 15 minut. 4.14. Reprting Není aplikván 59

5. INT-005 - Aplikace Správa publikačních atributů 5.1. Ppis Aplikace Správa publikačních atributů služí výhradně pr infrmvání interních zaměstnanců publikačních atributech zaměstnanců a jejich vzájemných vazbách. Publikvané atributy pdle výběru správce budu služit infrmvání mezi zaměstnanci. Tat aplikace čerpá data z persnálníh systému TARGET a dále je interpretuje zaměstnancům zadavatele v intranetvém prtálu. Tat aplikace také umžňuje nastavení pr přens d zóny extranet skrze integrační platfrmu a t tak, aby byla data na internetu vždy aktuální. Aplikace je z větší části bezbslužná a správce neb interní naplánvané úlhy prvádí aktualizaci dat skrze imprty na s mžnstí jejich dalšíh využití například na extranetu splečnsti. K vzájemné transfrmaci dat bude služit integrační platfrma. V tét aplikaci bude mžné prvádět minimálně fulltextvé vyhledávání záznamů, prhledávání a zbrazení plžek pdle strmvé struktury, zbrazení detailu. 5.2. Vlastnsti Tat aplikace je zalžena na jediném číselníku, d kteréh jsu data čerpána ze systému TARGET, který pskytuje data ve frmátu CSV. V tét aplikaci není mžné prvádět úpravy, jedná se puze interpretaci systému TARGET na jedntné míst. Aplikace rzšiřuje seznam publikačních atributů nvé plžky. Systém TARGET pskytuje zdrjvá data (číselník) s těmit metadaty a minimálně ta musí být bsažena v intranetvé části: Čísl OJ Název OJ Krátký název Pdrbný název Zkratka Textvý ppis Mbilní telefn (kntakt na zdpvědnu sbu) Telefn Pevná linka (kntakt na zdpvědnu sbu) Email (kntakt na zdpvědnu sbu) Nadřazená plžka (rdičvská) Vlastník (sba s přiřazeným publikačním atributem) Dalším kritériem pr danu aplikaci je umžnit uživatelům fulltextvé vyhledávání na úrvni každéh záznamu. Aplikace je sučasně zdrjem infrmací pdrbnstech publikačních dat a pr řízení zbrazení těcht detailů v extranetvé části, pr integrační platfrmu (zárveň tedy prstředníkem mezi systémem TARGET a extranetvým prtálem), která bude prvádět publikvání dat d extranetvé části, přičemž v tmt režimu, musí mít správce mžnst, zamítnut publikvání dané sby d extranetvé části (pmcí výběrvéh ple, radi buttn, check buttn neb jiné) a tat infrmace nesmí být ztracena ve chvíli, kdy dchází k imprtu dat ze systému TARGET skrze integrační platfrmu. Obr. 3 Znázrnění vztahu replikace dat mezi systémy 60