PŘÍLOHA Č.1 - TECHNICKÁ SPECIFIKACE ZADÁVACÍ DOKUMENTACE VEŘEJNÉ ZAKÁZKY ve smyslu ustanovení § 44 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon“)
Zadávací řízení:
Otevřené řízení Veřejná zakázka:
Nadlimitní veřejná zakázka na služby
Dodávka a implementace intranetového portálového řešení Zadavatel veřejné zakázky:
Lesy České republiky, s.p. Hradec Králové, Přemyslova 1106, PSČ 501 68 IČO: 421 96 451
Obsah 1.
2.
Seznam pojmů a zkratek............................................................................. 7 1.1.
Seznam pojmů ......................................................................................................... 7
1.2.
Seznam zkratek ...................................................................................................... 10
Požadavky na projektové řízení dodávky řešení ........................................ 11 2.1.
3.
Harmonogram projektu .......................................................................................... 11
Požadavky na technické řešení .................................................................. 12 3.1.
Obecná charakteristika řešení ................................................................................12
3.2.
Vstupní technická kritéria řešení ............................................................................12
3.3.
Monitorovací software ............................................................................................13
3.4.
Vyvažování farmy a vysoká dostupnost ..................................................................13
3.4.1.
Publikační servery (Front End) ...................................................................................... 13
3.4.2.
Aplikační servery ........................................................................................................... 13
3.4.3.
Vyhledávací servery ...................................................................................................... 13
3.4.4.
Renderovací servery ..................................................................................................... 13
3.4.5.
Databázové servery ....................................................................................................... 13
4.
Požadavky na licence .................................................................................14
5.
Požadavky na Access Management ............................................................ 15 5.1.
6.
Struktura LDAP databáze zadavatele ..................................................................... 15
5.1.1.
Struktura OU .................................................................................................................. 15
5.1.2.
Jmenné konvence LDAP databáze ............................................................................... 15
5.2.
Obecná privilegia rolí ..............................................................................................16
5.3.
Řízení přístupů........................................................................................................ 17
5.4.
Integrace s dalšími systémy ................................................................................... 18
Požadavky na produkční prostředí – definice modulů...............................19 6.1.
Obecné požadavky na dodávku řešení ....................................................................19
6.1.1.
Administrace .................................................................................................................. 19
6.1.2.
Architektura řešení......................................................................................................... 19
6.2.
Intranetová část ..................................................................................................... 26
6.2.1.
Náhled příloh v aplikacích ............................................................................................. 26
6.2.2.
Domain object model ..................................................................................................... 26
6.2.3.
Notifikace uživatelů ........................................................................................................ 26
6.2.4.
Naplánované úlohy ........................................................................................................ 26
6.2.5.
Aplikace ......................................................................................................................... 26
6.3. 6.3.1.
Definice integrační platformy a integrovaných nativních zdrojů obsahu ............. 27 Zabezpečení komunikace s integrační platformou ........................................................ 27 2
7.
6.3.2.
Vazba na poštovní služby .............................................................................................. 28
6.3.3.
Vazba na spisovou službu ............................................................................................. 28
6.3.4.
Vazba na centrální DMS ................................................................................................ 28
6.3.5.
Vazba na personální systém TARGET ......................................................................... 28
Testovací prostředí zadavatele ................................................................. 29 7.1.
8.
9.
Průběh testování .................................................................................................... 29
Požadavky na grafický design ................................................................... 30 8.1.
Standardy pro grafické prvky................................................................................. 30
8.2.
Definice dynamického obsahu webu ..................................................................... 30
8.3.
Layout webových stránek....................................................................................... 30
8.4.
Standardy pro formuláře ........................................................................................31
Čí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ázová.................................................................................................................... 32
9.1.4.
Externí ........................................................................................................................... 32
9.2.
Správa paralelně vedených Číselníků mezi aplikacemi a jejich synchronizace ..... 32
9.2.1.
Jednosměrná vstupní tzv. MASTER.............................................................................. 32
9.2.2.
Jednosměrná výstupní SLAVE ...................................................................................... 32
9.2.3.
Obousměrná .................................................................................................................. 32
10. SLA ........................................................................................................... 33 10.1.
11.
Specifikace parametrů SLA pro jednotlivá prostředí ............................................ 33
10.1.1.
Produkční prostředí ....................................................................................................... 33
10.1.2.
Testovací prostředí ........................................................................................................ 33
10.1.3.
Vývojové prostředí ......................................................................................................... 33
OLA .......................................................................................................... 34 11.1.
Organizační OLA .................................................................................................... 34
11.1.1.
Přístup k HW zdrojům .................................................................................................... 34
11.1.2.
Přístup k SW zdrojům .................................................................................................... 34
11.1.3.
Vzdálený přístup do počítačové sítě ............................................................................. 34
11.1.4.
Administrativní zázemí s napájením 220v a připojením k veřejné síti internet ............. 35
11.2.
Technická OLA ....................................................................................................... 35
11.2.1.
Zajištění HW Zdrojů ....................................................................................................... 35
11.2.2.
LDAP ............................................................................................................................. 35
11.2.3.
Datový extrakt TARGET ................................................................................................ 36
11.2.4.
SMTP Server ................................................................................................................. 36
3
12.
Požadavky na provedení testování a akceptace ......................................... 37
13.
Požadavky na školení ............................................................................... 38 13.1.
Uživatelské školení................................................................................................. 38
13.1.1.
Úvod do problematiky .................................................................................................... 38
13.1.2.
Vstup do aplikace a ověření identity uživatele .............................................................. 38
13.1.3.
Seznámení s navigací aplikace ..................................................................................... 38
13.1.4.
Seznámení s podpůrnými číselníky aplikace ................................................................ 38
13.1.5.
Práce s daty a možnosti jejich použití v kancelářských aplikacích ............................... 38
13.1.6.
Pracovní postupy ........................................................................................................... 38
13.2. Školení pro správce obsahu ................................................................................... 38 Úvod do problematiky správců obsahu ......................................................................... 38
13.2.1.
13.3. Administrátorské školení – správce chodu aplikace ............................................. 39 13.3.1.
Úvod do prostředí a popis instalace .............................................................................. 39
13.3.2.
Vytvoření aplikace pro Intranet ...................................................................................... 39
13.3.3.
Administrace webů ........................................................................................................ 39
13.3.4.
Konfigurace obsahového řízení ..................................................................................... 39
13.3.5.
Autentifikace .................................................................................................................. 39
13.3.6.
Bezpečnost obsahu ....................................................................................................... 39
13.3.7.
Úpravy prostředí ............................................................................................................ 39
13.3.8.
Notifikace ....................................................................................................................... 39
13.3.9.
Integrace s datovými zdroji ............................................................................................ 39
13.3.10.
Vyhledávání a správa fulltextové databáze obsahu ...................................................... 39
13.3.11.
Zálohovací a Obnovovací strategie ............................................................................... 39
13.3.12.
Sledování a optimalizace výkonu .................................................................................. 40
13.3.13.
Zajištění procesů dle ITIL .............................................................................................. 40
14.
Požadavky na logování ..............................................................................41
15.
Požadavky na dokumentaci ...................................................................... 43 15.1. 15.1.1.
15.2.
Service Desk ........................................................................................................... 43 Knowledge Base ............................................................................................................ 43
Service Support ...................................................................................................... 43
15.2.1.
Incident management .................................................................................................... 43
15.2.2.
Change management .................................................................................................... 43
15.2.3.
Problem management ................................................................................................... 43
15.2.4.
Service asset and configuration management .............................................................. 44
15.2.5.
Service Catalogue Management ................................................................................... 44
15.2.6.
Release and deployment 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.
Continuity management ................................................................................................. 45
15.3.4.
Financial management .................................................................................................. 45
15.3.5.
Service Level Management ........................................................................................... 45
15.3.6.
Access Management ..................................................................................................... 45
Příloha č. 1 – Detailní technická specifikace Aplikačního ř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í spravovaných LČR ........... 52
4.
INT-004 - Aplikace Pracovní úkoly ........................................................... 55
5.
INT-005 - Aplikace Správa publikačních atributů ..................................... 58
6.
INT-007 - Aplikace Správa povolenek ....................................................... 62
7.
INT-008 - Aplikace Evidence porostů 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ňování ploch ..........................................75 11.
INT-012 – Pomůcky a předměty ................................................................ 78
12.
INT-013 - Aplikace Vyhledávač typů aktiv společnosti .............................. 83
13.
INT-014 - Aplikace Registr využití techniky .............................................. 85
14.
INT-015 - Aplikace Nápravná opatř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é dokumenty ...................................................105 21.
INT-022 - Aplikace Správa uživatelů intranetu ........................................ 107
22. INT-023 - Aplikace Knihovna................................................................... 110 5
Příloha č. 2 – Technologické standardy ........................................................... 113 Příloha č. 3 – Integrační standardy ................................................................. 114 Příloha č. 4 – Seznam služeb integrační platformy .......................................... 122
6
1.
Seznam pojmů a zkratek
1.1.
Seznam pojmů
Pojem
Vysvětlení
Provozní doba
Provozní dobou je míněna doba, v průběhu které je Objednatelem požadovaná a současně Poskytovatelem garantováno provozování systémů. Provozní doba je měřena/vyhodnocována v jednotkách času (v hodinách)
Reakční doba
Reakční dobou je míněno maximální časové období, ve kterém je Poskytovatel povinen zareagovat na nový záznam, který byl založen v rámci provozní doby v systému pro HelpDesk. Reakční doba je hodnocena pouze v rámci provozní doby každého jednoho systému a je vyhodnocována v hodinách, popř. minutách. Reakcí na incident se rozumí moment, kdy je incidentu přiřazen řešitel a o této skutečnosti je ohlašovateli incidentu podána zpráva prostřednictví smluvených komunikačních kanálů.
Vyřešení incidentu / zajištění požadavku na službu (Obnovení služby)
Je maximální dobou odstranění incidentu (popř. vyřešení ostatních servisních hlášení), tedy maximální časové období od reakce na založený incident v helpdeskovém systému, který byl založen v rámci provozní doby do označení incidentu jako „uzavřený“ (po odsouhlasení vyřešení incidentu Objednatelem). Doba vyřešení incidentu je stanovena pro incidenty dle jejich kategorií, je hodnocena pouze v rámci provozní doby a je vyhodnocována v hodinách, popř. minutách. Pro kontrolu a přesnou identifikaci časů vzniku a ukončení incidentu může být zdrojem informace také monitorovací nástroj a jím naměřené monitorované parametry.
Odstávky v režimu provozu
Časové období, ve kterém je možné provést výpadek poskytovaných Služeb, který se nekvalifikuje jako incident. Výpadek je v tomto definovaném období možné provést vždy pouze se souhlasem Objednatele.
Nedostupnost
Situace, kdy z pohledu jednoho či více uživatelů není daná ICT služba využitelná a to za těchto podmínek: tato situace byla nahlášena uživatelem/uživateli jako incident nebo automaticky identifikována monitorovacím nástrojem a zároveň situace nastala selháním jedné nebo více komponent dané ICT služby je zahrnuta do servisní podpory. U takové situace je v rámci jejího řešení (incident nebo událost) zjištěn čas jejího vzniku a doba vyřešení. Rozdíl těchto časů pak tvoří dobu nedostupnosti dané služby či skupiny služeb pro danou situaci, která bude započítávána vůči požadovanému parametru celkové dostupnosti v SLA.
Výpočet dostupnosti
Dostupnost služby je vypočítávána dle následujícího vzorce: D = [(P - V) / P] * 100 Dostupnost systému za měsíc (v %): „D“ Režim provozu systému (v minutách) za měsíc: „P“ Celková doba výpadků systému (v minutách) za měsíc: „V“ Doba trvání plánované odstávky není započítávána jako nedostupnost
Farmy
Farmou zadavatel myslí sestavení serverů, které poskytuje zadavateli vysoce dostupné a plně škálovatelné a rozšiřitelné prostředí a to jak na úrovni aplikační, databázové a vyhledávací vrstvy.
Webové aplikace
Webovou aplikací (WA) zadavatel myslí nosiče obsahu na nejvyšší úrovni pro obsah ve farmách, a poskytuje rozhraní mezi uživatelem a webovou aplikací.
Kolekce webu
Kolekcí webu (KA) zadavatel myslí oddělenou část webové aplikace s vlastní definovanou obsahovou databázi, která umožní zabezpečení obsahu a rychlejší vyhledávání v obsahu.
7
Servisní aplikace
Servisní aplikací (SA) zadavatel myslí část která poskytuje jednotlivé součásti, ze kterých jsou kolekce webů stavěny a jež jsou reprezentovány jednotlivými aplikačními pooly v rámci webových služeb serveru. Tato servisní aplikace má definovaný vlastní účet pro autorizaci, tak aby ji bylo možno jednoznačně identifikovat a zabezpečit v rámci operačního systému.
Spravovaný účet
Spravovaným účtem zadavatel myslí účet umožňující LDAP ověřování vůči centrální databázi LDAP, přičemž heslo tohoto účtu je automaticky měněno v rámci času (předem definovaného) a administrátor ani žádná osoba zadavatele toto heslo po jeho změně nezná.
Provozní účet
Provozním účtem zadavatel myslí obecné uživatelské účty (objekty v LDAP databázi), které budou využívány pro přístup k celému systému.
Organizační jednotka
Organizační jednotkou zadavatel myslí složku, ve které jsou umístěny objekty typu provozní účet nebo spravovaný účet
Intranetová aplikace
Intranetovou aplikací zadavatel myslí webovou aplikaci přístupnou pouze z interní sítě LAN, kde uživatelé budou ověřeni pomocí Single Sign On
Extranetová aplikace
Extranetovou aplikací zadavatel myslí webovou aplikaci přístupnou z interní sítě LAN a externí sítě internet pouze po přihlášení provozním účtem
Anonymní aplikace
Anonymní aplikací zadavatel myslí webovou aplikaci přístupnou z interní sítě LAN a externí sítě internet bez nutnosti přihlášení provozním účtem
SQL Injection
SQL Injection zadavatel myslí zranitelnost, kdy útočník spustí z webové aplikace SQL dotaz, který díky neošetřeným vstupům provede v databázi příkaz, který vypíše do internetového okna obsah některé z tabulek databáze
Cross Site Scripting
Cross Site Scriptingem zadavatel myslí zranitelnost která umožní spustit útočníkovi ve vstupu některý z programovacích kódů HTML, PHP, VBS, aj.., tento kód pak vyvolá nějakou akci přímo na aplikační vrstvě.
CSRF
Cross-site Request Forgery (CSRF nebo také XSRF) je jedna z metod útoku do internetových aplikací (typicky implementovaných skriptovacími jazyky nebo CGI) pracující na bázi nezamýšleného požadavku pro vykonání určité akce v této aplikaci, který ovšem pochází z nelegitimního zdroje. Většinou se nejedná o útok směřující k získání přístupu do aplikace (i když i pro to může být zneužit); spíše využívá (zneužívá) akce uživatelů, kteří jsou k ní již v okamžiku útoku přihlášeni.
Publikační servery
Publikačním serverem zadavatel myslí servery, které hostují aplikační části a webové služby poskytované směrem k uživatelům a zajišťující interpretaci dat ze serverů databázových.
Databázové servery
Databázovým serverem zadavatel myslí server, který bude hostovat jednotlivé obsahové, vyhledávací a konfigurační databáze nutné pro provoz celé webové aplikace.
Vyhledávací servery
Vyhledávacím serverem zadavatel myslí server, který se bude sám starat o indexování obsahu na úrovni datových zdrojů a to nejen databáze ale i lokálních souborových služeb napříč organizací zadavatele.
Renderovací servery pro webové části
Renderovacím serverem pro webové části zadavatel myslí servery, které se budou starat o sestavení datových náhledů bez nutnosti otevření dokumentů a to zejména kancelářských souborů.
Redakční systém
Redakčním systémem zadavatel myslí systém s jednoduchou správou prostředí bez nutnosti zásahu do vlastního kódu aplikace.
Fault Tolerance
Fault tolerance zadavatel myslí definovaný standard architektury řešení, která je schopna poskytnou bezvýpadkový stav při výpadku některé z částí infrastruktury a v tomto případě výpadek infrastruktury do úrovně 50% služby na produkční infrastruktuře. Přesněji řešeno výpadek primární nebo sekundární lokality.
Vysoká dostupnost
Vysokou dostupností zadavatel myslí způsob architektury, kdy může dojít ke
8
krátkodobému výpadku na dobu zastavení a spuštění služby aniž by byla vyžadována součinnost administrátora nebo správce systému. Toto přepnutí musí probíhat bezobslužně a v případě nahození selhané části infrastruktury bude provedeno přesunutí zpět ručně administrátorem v předem definovaný čas (odstávce služby) SOAP, SOA, ESB, XML, FTP, JDBC, ODBCAES, TLS, SSL, HTTP, HTTPS, MTOM, atd.
Tímto zadavatel myslí standardizované výrazy pro protokoly, šifrování, metodiky, standardy, aj.
Basic nebo Client cert Authentication
Tímto zadavatel myslí způsoby ověřování jména a hesla pro možnost přihlášení do aplikace.
Network Load Balancer
Tímto zadavatel myslí systém pro vyvažování výkonu na úrovni počtu klientů na jednotlivých serverech.
LDAP
Tímto zadavatel myslí protokol definovaný pro modifikaci a přístup k datům na adresářovém serveru. Adresářový server využívá hierarchické stromové struktury, která je vhodná zejména pro práci s adresáři, informacemi o uživatelích nebo například může zastoupit některé sítové informační služby. Sám neimplementuje složité transakční mechanismy ani funkce pro kontrolu integrity.
Webové site
Tímto zadavatel myslí standartní složku souborového systému obsahující vlastní data (webové stránky)
Webové služby
Tímto zadavatel myslí služby, které obhospodařují vlastní internetové stránky
Aplikační pooly
Tímto zadavatel myslí aplikační/funkční prvky internetových služeb
camelCase
Tímto zadavatel myslí způsob psaní víceslovných frází a nadpisů, kdy jednotlivá slova nejsou oddělena mezerami, ale každé z nich začíná velkým písmenem – nezávisle na tom, zda by tomu tak podle pravidel pravopisu mělo být. Samotný název camelCase je příkladem tohoto stylu
GUI
Tímto zadavatel myslí interaktivní část bez nutnosti zásahu do vlastního kódu aplikace (typickým příkladem je "Redakční systém")
Datová vrstva
Tímto zadavatel myslí datovou vrstvu aplikace
Externí data
veškerá externí data vstupující do aplikace
Front-end web
Tímto zadavatel myslí veškeré front-end služby aplikace
Procesor dotazů
Tímto zadavatel myslí veškeré procesor dotazů databázového serveru
Publikování aplikací
Tímto zadavatel myslí logování chyb při nasazení jednotlivých aplikací do aplikačního prostředí
Správa
Tímto zadavatel myslí veškeré konfigurace správy v prostředí
Správa připojení databáze
Tímto zadavatel myslí datové konektory a jejich funkce
Uživatelské rozhraní
Tímto zadavatel myslí veškeré činnosti na úrovni uživatelského rozhraní
9
1.2.
Seznam zkratek
Zkratka
Vysvětlení
LČR
Státní podnik Lesy České republiky
OS
Operační systém
GŘ
Generální ředitelství LČR (také jako „GŘ LČR“)
OJ
Organizační jednotka
OHÚL
Odbor hospodářské úpravy lesa
ÚHÚL
Ústav hospodářské úpravy lesa
LHC
Lesní hospodářský celek
IMA
Systém evidence majetku
ČSÚ
Český statistický úřad
10
2.
Požadavky na projektové řízení dodávky řešení
Dodávka řešení bude řízena podle standardů metodiky PRINCE2 nebo obdobné metodiky pro projektové řízení. Zadavatel požaduje, aby dodavatel po dobu trvání tohoto projektu zajistil na vlastní náklady pro členy realizačního týmu systém pro řízení projektu, v rámci, kterého budou všechny zúčastněné osoby včas informovány o svých úkolech, jednáních, budou moci čerpat dokumenty, prezentace, videa a projektové plány. V rámci dodávky řešení zadavatel předpokládá pro každý z modulů sestavení tzv. Project Initiation Documentation (dále jen PID), který bude detailně popisovat „cílový koncept“ řešení.
2.1.
Harmonogram projektu
Zadavatel požaduje, aby uchazeč ve své nabídce uvedl projektový Gantův diagram s předpokládaným harmonogramem v el. Verzi na CD (například ve formátu aplikace MS Project nebo jiné)termín plnění celého řešení nesmí překročit 2 měsíce na analýzu řešení a 6 měsíců na implementaci řešení, za předpokladu poskytnutí plné součinnosti ze strany zadavatele.
11
3.
Požadavky na technické řešení
3.1.
Obecná charakteristika řešení
Zadavatel požaduje dodání modulů řešení s využitím platformy redakčního systému se snadným způsobem vytváření webových stránek. Redakční systém musí obsahovat minimálně: knihovnu dokumentů knihovnu wiki stránek diskuze seznam úkolů události v kalendáři vlastní seznamy rozhraní pro uživatelskou administraci Pokud není specifikováno v samostatném dokumentu Aplikací, pak každý záznam v redakčním systému může nabývat minimálně těchto stavů, které se od sebe liší pouze významem a slouží především k odlišení zobrazovacích filtrů podle typů uživatelů. Minimální přehled stavů: Nezahájeno - záznam byl vytvořen, ale ještě nebyl uživatelem předložen, ke zveřejnění Probíhá - zveřejněný záznam Dokončeno - ukončený záznam. Již se dále nezveřejnuje Odloženo - záznam, na kterém byla činnost dočasně pozastavena a je/není veřejný Čekání - záznam, který signalizuje, že není ještě v režimu Dokončeno, ale že jeho přepnutí do tohoto stavu je podmíněno až do ukončení jiné aktivity Požadavky na migraci historických dat jsou uvedeny v popisu dílčích modulů Podpora řešení musí být poskytována v českém jazyce a to minimálně od úrovně vlastních úprav řešení tzv. „customizací“. Dodavatel musí po dobu trvání životního cyklu řešení zajistit na vyžádání podporu v rozsahu do 5-ti člověkodnů/měsíc. Dodaná aplikace musí být schopna během období, kdy bude dodavatel zajišťovat podporu provozu, běžet na infrastrukturních komponentách ve verzích podporovaných výrobci všech infrastrukturních komponent. Navržené nové komponenty řešení musí být podporovány výrobcem SW min. do roku 2020 Řešení musí být lokalizováno v souladu s českým právem. Soulad s českým právem musí být zajištěn v průběhu celého životního cyklu řešení. Definice použitých technologických standardů na úrovni této zadávací dokumentace je specifikována v Příloze č. 2 tohoto dokumentu.
3.2.
Vstupní technická kritéria řešení Parametr
Hodnota
Maximální odezva systému [vteřiny]
2
Velikost databáze [GB]
100
Datové objemy uložených dokumentů [GB]
50
Počty zpracovávaných požadavků / den
20000
Počty uložených dokumentů
800
Počet uživatelů
2500
Počet souběžně pracujících uživatelů
50
Roční přírůstek dat [GB/rok]
30
12
3.3.
Monitorovací software
Zadavatel požaduje, aby specifikace monitorování celého řešení vycházelo z definovaných procesů ITIL a dále z možností pro logování celého řešení. Dodavatel ve své nabídce uvede, jak bude monitorování probíhat a jaké atributy je v jeho řešení doporučuje sledovat. Zadavatel má nyní implementován software Zabbix, který zajišťuje monitorování celé infrastruktury a již implementovaných aplikací.
3.4.
Vyvažování farmy a vysoká dostupnost
Zadavatel požaduje, aby celé řešení bylo vybudováno vysoce dostupné s možností umístění serverů do 2 geograficky oddělených lokalit a s automatickým přepnutím všech funkcí v případě výpadku jedné z lokality. Zadavatel nevlastní ani nepoptává v konceptu řešení žádné hardwarové Load Balancery, ale je schopen nabídnout k zajištění vysoké dostupnosti systému DNS pro definici jedinečného jména v síti pro servery, popřípadě je možno instalovat na servery službu Network Load Balancer, popřípadě Failover Cluster – nicméně ve většině případů je nutné zajistit tzv. „bezvýpadkový“ provoz, který není službou Failover Cluster možný, jelikož ta je schopna zajistit pouze vysokou dostupnost, ale nikoliv Fault Tolerance služby.
3.4.1.
Publikační servery (Front End)
Zadavatel požaduje, aby publikační servery umístěné v primární lokalitě byly vybudovány jako vysoce dostupné s Fault tolerance a sekundární lokalita sloužila pro vysokou dostupnost bez omezení funkčnosti nebo výkonu v případě výpadku primární lokality. Zadavatel požaduje, aby celý systém publikovaný směrem k uživatelům byl zabezpečen pomocí TLS s využitím certifikátu SSL 3.0, který zadavatel vlastní a systém neumožňoval připojení pomocí HTTP a to minimálně v řešení pomocí přesměrování (redirect) na HTTPS. Do tohoto systému musí být provedeno ověření na úrovni Basic Authentication nebo Client Cert Authentication.
3.4.2.
Aplikační servery
Zadavatel požaduje, aby publikační servery umístěné v primární lokalitě byly vybudovány jako vysoce dostupné a sekundární lokalita sloužila pro Fault Tolerance bez omezení funkčnosti nebo výkonu v případě výpadku primární lokality.
3.4.3.
Vyhledávací servery
Zadavatel stanovil, že vyhledávací servery nemusí být budovány jako vysoce dostupné v primární ani sekundární lokalitě, pokud neomezí nebo neohrozí funkci celého řešení a v případě výpadku daného serveru převezme funkcionalitu záložní server v sekundární lokalitě.
3.4.4.
Renderovací servery
Zadavatel stanovil, že renderovací servery nemusí být budovány jako vysoce dostupné v primární ani sekundární lokalitě, pokud neomezí nebo neohrozí funkci celého řešení a v případě výpadku daného serveru převezme funkcionalitu záložní server v sekundární lokalitě.
3.4.5.
Databázové servery
Zadavatel požaduje, aby publikační servery umístěné v primární lokalitě byly vybudovány jako vysoce dostupné a sekundární lokalita sloužila pro Fault Tolerance bez omezení funkčnosti nebo výkonu v případě výpadku primární lokality.
13
4.
Požadavky na licence
Licenční ujednání a autorská práva za vlastní vývoj jsou specifikována ve Smlouvě, která je nedílnou součástí tohoto dokumentu.
14
5.
Požadavky na Access Management
Zadavatel požaduje, aby oprávnění byla řízena na úrovni LDAP a to pomocí jednotných ověřovacích serverů, které budou poskytovány napříč infrastrukturou zadavatele a to jak pro primární lokality, tak i pro lokality sekundární. Servery pro jednotné ověřování uživatelů pomocí LDAP budou poskytovat přístup do celého prostředí, přičemž hesla jednotlivých objektů budou uložena v šifrované podobě a to nejméně se šifrováním AES o déle klíče 128bitů. Zadavatel dále požaduje, aby tyto servery byly provozovány v režimu vysoké dostupnosti bez nutnosti odstávky při rozšíření stávající topologie ověřovacích LDAP serverů. Uchazeč popíše jakým způsobem je schopen těchto požadavků dostát a bude vycházet z definované jmenné konvence pro servisní a provozní účty. Servisní účet –
SA Provozní účet - Zadavatel nemá žádný další systém pro řízení identit a jejich správu. Jediným dostupným zdrojem je v tomto případě systém Active Directory, který bude dále popisován jako LDAP databáze nebo ověřovací server.
5.1.
Struktura LDAP databáze zadavatele
Zadavatel nyní má stanovenu níže uvedenou strukturu LDAP databáze, která v rámci implementace nebude předělávána a upravována, jediné rozšíření, které je možné je doplnění některých atributů v rámci LDAP databáze, které by byly bezpodmínečně nutné pro vlastní spuštění nebo pro podporu některé funkcionality v rámci Aplikačních částí.
5.1.1.
Struktura OU
5.1.2.
Jmenné konvence LDAP databáze
Zadavatel využívá jmennou konvenci pro stanovení názvů účtů v rámci LDAP databáze a tato konvence je složena z příjmení a prvního písmene ze jména (př. Novakj, novotnyp, atd.) Zadavatel využívá jmennou konvenci pro stanovení názvů organizačních jednotek v rámci LDAP databáze a tato konvence je složena z „OJ“ (organizační jednotka) a pořadového čísla v 3 znakovém formátu (př. OJ010, OJ020, OJ005, atd..) Zadavatel využívá jmennou konvenci pro stanovení názvů skupin v rámci LDAP databáze a tato konvence je složena z „OJ“ (organizační jednotka) a pořadového čísla v 3 znakovém formátu (př. OJ010, OJ020, OJ005, atd..) dále pak z kategorie a účelu dané skupiny, kdy je položka kategorie volitelná a nemusí být v každé situaci využita (př. ###_[kategorie]_ucel, kde ### je číselné označení OJ, položka „kategorie“ je volitelná a nepovinná)
15
5.2.
Obecná privilegia rolí
Zadavatel požaduje, aby oprávnění definované pro provozní účty byly odděleny do několika kategorií a to minimálně v tomto rozsahu: FarmAdmin - Interní uživatel aplikace a nejvyšší administrátor s přístupem k aplikační a datové vrstvě řešení WebAdmin - Interní uživatel aplikace a nejvyšší administrátor s přístupem k aplikační vrstvě DBAdmin - Interní uživatel aplikace a nejvyšší administrátor s přístupem k datové vrstvě MAAdmin - Interní uživatel aplikace a správce obsahu na úrovni kolekce aplikační vrstvy WAAdmin - Interní uživatel aplikace a správce obsahu na úrovni modulu Uživatel/Návštěvník – osoba autorizovaná pomocí LDAP databáze (běžný uživatel aplikace) Anonymní uživatel (návštěvník) Vlastník, Klíčový uživatel OJ, Správce obsahu OJ - je osoba nebo skupina osob, které byly identifikovány vedením, že mají odpovědnost za zachování důvěrnosti, dostupnost a integritu tohoto aktiva. Majitel aktiv se může v průběhu životního cyklu aktiva změnit. Vlastník je jmenovitý uživatel, který je odpovědný za veškeré změny konfigurace a záznamy v agendách, které má ve „Vlastnictví“. V každém procesu změny je nedílnou součástí schválení změny. Vlastník musí být uveden u všech položek, které jsou v evidenci konfigurační databáze. Všechna poptávaná řešení musí obsahovat tuto entitu a procesy, které souvisejí s jejich změnami Tito uživatelé budou mít na úrovni LDAP databáze nejnižší možná oprávnění bez možnosti interaktivního přihlašování k jednotlivým serverům, přičemž nesmí být jejich oprávnění na úrovni aplikace omezena (vyjma terminálových serverů, kam se mohou uživatelé přihlašovat interaktivně). Zadavatel požaduje, aby z LDAP databáze do interní databáze systému byla data synchronizována maximálně každé 3 hodiny a v rámci této synchronizace byla doručena do interní databáze systému metadata z systému LDAP, kde budou uložena a to jak z metadat uložených v organizačních jednotkách tak i z objektů uživatelů. Tato metadata bude možno plnit z obou míst a to z prostředí intranetové aplikace tak i z prostředí správy LDAP databáze. Zadavatel požaduje, aby v intranetové aplikaci byla minimálně tato metadata, která budou v průběhu životního cyklu naplněna, pokud nebudou vyžadována přímo k udržení některé z funkcionalit aplikačních částí: Jméno Příjmení Popis Kancelář Telefonní číslo Email Město Okres PSČ Nadřízený Funkce Oddělení Společnost ZaměstnanckéID Nadřízený
16
5.3.
Řízení přístupů
Zadavatel požaduje, aby každý povolený přístup do intranetu společnosti byl řízen vlastníkem dané aplikační vrstvy a jím i autorizován, informace o vlastníkovi/nadřízeném bude dostupná k načtení z atributu objektu v LDAP databázi. Všechny změny stavů budou notifikovány el. Zprávou žadateli včetně obsahu pole „poznámka“.
5.3.1.1.
Externí
Zadavatel požaduje, aby v rámci celého řešení nebylo možno přistupovat externě ke službám aplikační části intranet standartními uživateli nebo anonymními uživateli. Externí přístup do intranetové části bude zajištěn pouze z integrační platformy, která se stará o publikaci dat na extranet, který není součástí této zadávací dokumentace a je řešen samostatně.
5.3.1.2.
Access management
Zadavatel požaduje, aby veškeré přístupy do systému byly zaznamenávány do logů, které budou následně vyhodnocovány zadavatelem. Pro přístup koncových uživatelů bude pro intranetovou aplikaci zajištěn přístup pomocí Singl-Sign-On, jelikož jsou veškerá koncová zařízení umístěna v doméně (LDAP databáze) zadavatele. Zadavatel je schopen provést některé možné úpravy prohlížečů pomocí skupinových politik, tak aby dodavateli poskytl maximální součinnost pro možnost modifikace nastavení koncových zařízení bez nutnosti ruční práce s koncovými zařízeními. Zadavatel dále požaduje, aby uchazeč ve své nabídce uvedl, jaké změny bude nutné na koncových zařízeních provést a jakým způsobem je možno provést tyto změny centrálně za použití skupinových politik v doméně zadavatele.
5.3.1.3.
Procesy řízení přístupů
Zadavatel má implementován proces identity management v rámci, kterého má definované vlastníky jednotlivých objektů, nadřízenost a podřízenost osob a proto přístup do dané části intranetu nebo intranetové aplikace musí být podřízen tomuto pracovnímu postupu. Zadavatel požaduje, aby uchazeč ve své nabídce uvedl, jakým způsobem bude uživatel a vlastník notifikován v rámci žádosti o přístup. Doporučeným a zavedeným postupem je informace prostřednictvím emailu a to s interaktivním odkazem přímo do dané intranetové stránky, kde bude možno provést schválení přístupu s následnou automatickou notifikací žadatele.
5.3.1.4.
Bezpečnostní úrovně
Zadavatel požaduje, aby uchazeč ve své nabídce uvedl, jakým způsobem bude zajišťovat níže uvedené části bezpečnostních úrovní a dále požaduje, aby hesla pro tyto celky byla vždy v šifrované podobě umístěna v LDAP databázi. 5.3.1.4.1.
Databázová
Databázová bezpečnost bude řešena na úrovni předem definovaných účtů z LDAP databáze, přičemž je možno v tomto případě využít i účty z lokální databáze. Tyto lokální účty však musí být šifrovány a to zejména jejich heslo. Obsah vlastních databází by měl být v tomto případě také šifrován a to jednou z níže uvedených šifer a to buď v symetrickém, nebo asymetrickém režimu, popřípadě jeho kombinací. DES Triple DES TRIPLE_DES_3KEY RC2 RC4 128-bit RC4 DESX 128-bit AES 192-bit AES 256-bit AES Zadavatel požaduje, aby úroveň šifrování byla zajištěna dle nejlepších zkušeností a to s přihlédnutím k zajištění maximálního výkonu. 17
5.3.1.4.2.
Aplikační
Aplikační bezpečnost bude řešena na úrovni předem definovaných účtů z LDAP databáze a spuštění celé aplikační části v bezpečném režimu bude podmíněno plnou funkcí tohoto účtu, který by měl mít na úrovni LDAP databáze nejnižší možná oprávnění, ale na úrovni aplikační by měl mít oprávnění plného řízení daného aplikačního celku. 5.3.1.4.2.1. Formuláře Bezpečnost jednotlivých formulářů bude zajištěna pomocí účtu, který je aktuálně přihlášen do intranetové aplikace a dle přidělených oprávnění bude vždy zobrazen/nezobrazen popřípadě bude umožněna/neumožněna modifikace obsahu daného formuláře. 5.3.1.4.2.2. Prvky formuláře Bezpečnost jednotlivých prvků formuláře bude zajištěna pomocí účtu, který by měl být přiřazen v rámci dané webové části a tím by měl být i autorizován vždy při přístupu k danému prvku formuláře a to zejména při zobrazení obsahu daného formuláře. Při editaci bude využito oprávnění prvku formuláře, které je vázáno na aktuálně přihlášeného uživatele a to tak, aby uživatel A mohl změnit položku A a C a uživatel B mohl měnit pouze položky B a D.
5.4.
Integrace s dalšími systémy
Zadavatel požaduje, aby systém umožnil vazbu na LDAP databázi dle uvedených požadavků v tomto dokumentu a v jeho přílohách (zejména v částech pro jednotlivé aplikační části) Zadavatel má dále vazbu na integrační platformu jejíž způsob je definován v každém ze samostatných modulů, přičemž integrační platforma není součástí tohoto zadávacího řízení. Zadavatel v rámci výběrového řízení předpokládá vazbu na „dokument management systém“ (dále jen DMS), který zde nemůže být v tuto chvíli specifikován, jelikož je součástí jiného výběrového řízení, ale některé soubory (fyzické soubory ukládané většinou jako přílohy) budou umísťovány do tohoto systému DMS.
18
6.
Požadavky na produkční prostředí – definice modulů
6.1.
Obecné požadavky na dodávku řešení
6.1.1.
Administrace
Zadavatel požaduje, aby administrační rozhraní bylo dodáno v anglickém jazyce, ale veškeré webové části byly dodané v lokalizaci české. Toto administrační rozhraní by mělo umožňovat minimálně tato nastavení: Vytváření nových webových aplikací Vytváření nových obsahových databází Zapínání a vypínání služeb webové aplikace Správa obsahových databází Konfigurace vyhledávacích služeb Konfigurace prezentačních služeb (textové, prezentační a tabulkové dokumenty) Konfigurace reportovacích služeb Konfigurace zálohování
6.1.2.
Architektura řešení
Zadavatel požaduje architekturu řešení, která odpovídá obecným standardům minimálně 3 vrstvé úrovně (Obr. 1) ve struktuře uvedené v tomto odstavci. Zadavatel požaduje, aby uchazeč navrhl plně škálovatelnou strukturu serverů zajišťujících provoz intranetových služeb a to tak, aby oddělil servery na publikační, databázové, vyhledávací, renderovací a to primárně z důvodu možnosti škálování výkonu všech služeb poskytovaných směrem k uživatelům (návštěvníkům).
Obr. 1 (obecný model architektury řešení) Déle je požadováno zajistit vysoce dostupné prostředí s umístěním ve 2 geograficky oddělených lokalitách s Fault Tolerance a to pro služby (přesná specifikace je uvedena v kapitole Chyba! Nenalezen zdroj odkazů.): Publikační servery (WFE nebo Front-End servery) Databázové servery (SQL servery) Vyhledávací servery (App nebo Appliacations servery) Renderovací servery pro webové části (App nebo Appliacations servery) Celá struktura serverů bude umístěna výhradně na serverech virtuálních, u kterých bude výkon odpovídat potřebám udaným výrobcem, tak aby byl zajištěn doporučený výkon a uživatelé nebyli omezeni při využívání intranetové aplikace. 19
6.1.2.1.
Fyzická/Virtuální infrastruktura
Zadavatel požaduje, aby aplikace a všechny její součásti byly umístěny na operačním systému, jež bude plně podporován výrobcem s dostupnou databází znalostí obecně označovánu jako FAQ. V níže uvedeném vyobrazení je uveden obecný model pro stavbu webové aplikace s rozložením zátěže mezi jednotlivé serverové role. V tomto scénáři je požadováno, aby farma navržená dodavatelem byla řešena jako 3 vrstvá bez nutnosti využití databáze v režimu Active-Active, ale minimálně s využitím Active-Passive s RTO 1 hodina.
Obr. 2 (Obecný model farmy primární a sekundární lokality)
Front-end Web servers – jedná se o servery poskytující webové služby, aplikační pooly pro jednotlivé webové site a další podpůrné služby pro front end weby.
20
Application servers – jedná se o servery hostující renderovací služby, vyhledávací služby a další podpůrné služby mezi webovými front-end servery a databázovými servery
SQL Server – jedná se o servery hostující vlastní databáze, konfigurace vlastní aplikace a další podpůrné služby pro služby integračních platforem, aj…
SQL Server (witness server) – jedná se o server pro zajištění automatické ochrany proti výpadku jednoho z uzlů SQL clusteru (Principal či Mirror)
6.1.2.2.
Prezentační vrstva
Prezentační vrstvu představuje libovolný prohlížeč webového obsahu s podporou Skriptování na straně klienta je v informatice označení techniky, ve které je počítačový program umístěný na webových stránkách vykonáván na straně klienta, tj. webovým prohlížečem uživatele (ne na straně serveru, jako u skriptování na straně serveru). Skriptování na straně klienta je důležitá součást konceptu DHTML (dynamického HTML), jenž umožňuje měnit obsah zobrazené webové stránky v závislosti na uživatelském vstupu, podmínkách prostředí (jako například čas a den) nebo jiných okolnostech.
6.1.2.3.
Aplikační vrstva
Zde leží jádro aplikace, její logika a funkce, výpočty a zpracování dat. Zadavatel požaduje, aby byla tato vrstva zastoupena webovým serverem (dále také publikační vrstva). Aplikační vrstva nesmí obsahovat přímé příkazy pro manipulaci s daty datové vrstvy. V rámci vývoje řešení musí být striktně použita metoda zasílání požadavků do datové vrstvy prostřednictvím parametrů bez přímého použití příkazů pro VYTVOŘENÍ, MAZÁNÍ A ZMĚNU DAT. Zpravidla se jedná o příkazy v obecném jazyce Transact SQL : INSERT UPDATE DELETE DROP Tyto příkazy nesmí být na úrovni Aplikační vrstvy vůbec použity, aby se zamezilo bezpečnostním rizikům ohrožujícím „Datovou vrstvu“ Aplikační vrstva musí obsahovat preventivní opatření proti útokům: SQL Injection Cross Site Scripting CSRF Zadavatel požaduje, aby dodavatel provedl penetrační testy na danou webovou aplikaci a následně předložil tyto penetrační testy zadavateli k akceptaci jako součást dodávky řešení Jednotlivé aplikace použité v dané webové části musí být řízeny vlastními aplikačními částmi a jejich spuštění bude autorizováno samostatným účtem v LDAP databázi se samostatným heslem, které bude umístěno v aplikační databázi a to jako HASH, toto heslo bude pravidelně měněno bez nutnosti zásahu zadavatele.
21
6.1.2.4.
Datová vrstva
Tuto vrstvu tvoří nejčastěji databáze, která data uchovává, zpřístupňuje a zaručuje jejich konzistenci. Může zde být ale také (síťový) souborový systém, webová služba nebo jiná aplikace. Preferované řešení na úrovni datové vrstvy je definováno jako řešení s nulovou ztrátou dat a rychlostí obnovy v řádu sekund. Zadavatel označil v níže uvedené tabulce požadavek na řešení vysoké dostupnosti celého řešení, tento požadavek je nastaven jako minimální pro zvolené řešení. Databázové řešení vysoké dostupnosti
Potenciální datové ztráty (RPO)
Potencionální čas obnovení (RTO)
Automatické přepnutí v případě výpadku
Požadavek na podporu pro fault tolerance funkcionalitu se synchronním algoritmem
žádný
sekundy
ANO
Požadavek na podporu pro fault tolerance funkcionalitu s asynchronním algoritmem
v řádu sekund
minuty
NE
Požadavek na podporu pro synchronní kopie databáze v rámci celého řešení
není aplikováno
minuty
ANO
Kopie databáze (synchronní mód + witness server)
žádný
sekundy
ANO
Kopie databáze (asynchronní mód + witness server)
v řádu sekund
minuty
NE
Backup, copy, restore
několik hodin
několik hodin
NE
Zadavatel požaduje, aby byly databáze a/nebo tabulky odděleny na několik možných úrovní (viz nadpisy níže uvedené v tomto dokumentu pod kapitolou 5.1.2.4.1 až 5.1.2.4.4), a doporučuje provést oddělení minimálně na těchto úrovních. Pokud má dodavatel databáze a/nebo tabulky řešeny jinak, je nutné přesně specifikovat jak a jakým způsobem a to zejména z pohledu obsahu jednotlivých databází/tabulek. Každá z níže uvedených databází a/nebo tabulek má uveden svůj vlastní účel a tento je brán jako minimální. Jména databází/tabulek uvedených níže v tabulce jsou pouze informativní a jejich název nemusí být dodavatelem dodržen. Z níže uvedených důvodů preferuje Zadavatel rozdělení na úrovni databází: Požadavek vychází z potřeby pokrytí vysoce dostupného řešení, které bude v budoucím čase rozšiřováno, a některé databáze, v případě nárůstu dat mohou být přesunuty na samostatné servery. Dále pak je oddělení funkcí do jednotlivých databází preferováno z důvodu rychlejší obnovy v případě havárie a předpokládá se, že databáze budou obsahovat v tomto scénáři méně dat a zátěž na jednotlivé databáze bude lépe rozdělena zejména při zpracování dotazů do těchto databází pomocí store procedur každé z databází.
22
6.1.2.4.1.
Systémové databáze
Konfigurační databáze Použitý název databáze
LCR_App_System
Účel
Zadavatel požaduje, aby tato databáze obsahovala minimálně tyto konfigurační data databází: - Konfigurace z aplikační databáze - Konfigurace z webových služeb - Konfigurace webových aplikací - Konfigurace vlastních řešení - Konfigurace webových částí - Konfigurace předpřipravených template - Informace o definovaných kvótách
Požadavek na podporu pro synchronní kopie databáze v rámci celého řešení ANO Požadavek na podporu pro fault tolerance funkcionalitu se synchronním algoritmem
ANO
Požadavek na podporu pro asynchronní kopie databáze a transakčního logu v rámci celého řešení
NE, může být definováno v rámci celého řešení
Požadavek na podporu pro fault tolerance funkcionalitu s asynchronním algoritmem
NE, může být definováno v rámci celého řešení
Obsahová databáze pro administrační web Použitý název databáze
LCR_Admin_Content
Účel
Zadavatel požaduje, aby tato databáze obsahovala veškerá konfigurační data z aplikační části administrace. Pokud by byly využity funkce pro podporu kancelářských aplikací, pak tato obsahová databáze bude udržovat i informace o jejich konfiguraci.
Požadavek na podporu pro synchronní kopie databáze v rámci celého řešení ANO Požadavek na podporu pro fault tolerance funkcionalitu se synchronním algoritmem
ANO
Požadavek na podporu pro asynchronní kopie databáze a transakčního logu v rámci celého řešení
NE, může být definováno v rámci celého řešení
Požadavek na podporu pro fault tolerance funkcionalitu s asynchronním algoritmem
NE, může být definováno v rámci celého řešení
23
Obecné obsahové databáze Použitý název databáze
LCR__Content
Účel
Zadavatel požaduje, aby tato obsahová databáze obsahovala veškerá data z dané webové aplikace nebo aplikační části společně s využitými aplikacemi, jež jsou v dané aplikační části použity. Tato databáze bude dále obsahovat veškeré soubory uložené do dané aplikační části. Dále bude obsahovat vlastní data z kancelářských aplikací.
Požadavek na podporu pro synchronní kopie databáze v rámci celého řešení ANO Požadavek na podporu pro fault tolerance funkcionalitu se synchronním algoritmem
ANO
Požadavek na podporu pro asynchronní kopie databáze a transakčního logu v rámci celého řešení
ANO
Požadavek na podporu pro fault tolerance funkcionalitu s asynchronním algoritmem
ANO
6.1.2.4.2.
Databáze pro vyhledávání
Databáze pro vyhledávání Použitý název databáze
LCR_Search_App
Účel
Zadavatel požaduje, aby: tato databáze udržovala informace o procházení v rámci celého řešení a dále informace o SACL tato databáze obsahovala informace z analytických reportů, a obsahuje extrakci všech využitých odkazů v rámci celého řešení tato databáze obsahovala veškerá data procházení a jejich historii tato databáze uchovávala informace, které se extrahuje z obsahových komponent (označených vždy jako content)
Požadavek na podporu pro synchronní kopie databáze v rámci celého řešení
ANO
Požadavek na podporu pro fault tolerance funkcionalitu se synchronním algoritmem
ANO
Požadavek na podporu pro asynchronní kopie databáze a transakčního logu v rámci celého řešení
NE
Požadavek na podporu pro fault tolerance funkcionalitu s asynchronním algoritmem
NE
24
6.1.2.4.3.
Databáze metadat
Databáze metadat Použitý název databáze
LCR_Metadata_DB
Účel
Zadavatel požaduje, aby tato databáze uchovávala informace o metadatech (pokud existují) použitých uvnitř veškerého obsahu
Požadavek na podporu pro synchronní kopie databáze v rámci celého řešení
ANO
Požadavek na podporu pro fault tolerance funkcionalitu se synchronním algoritmem
ANO
Požadavek na podporu pro asynchronní kopie databáze a transakčního logu v rámci celého řešení
ANO
Požadavek na podporu pro fault tolerance funkcionalitu s asynchronním algoritmem
ANO
6.1.2.4.4.
Databáze reportovacích služeb
Databáze katalogu Použitý název databáze
LCR_Reporting_Catalog
Účel
Zadavatel požaduje, aby tato databáze uchovávala informace o vytvořených reportech, historii těchto reportů, informace o plánování a automatickém generování reportů
Databáze upozornění Použitý název databáze
LCR_Reporting_Alert
Účel
Zadavatel požaduje, aby tato databáze uchovávala informace o aktuálních alertech systému
6.1.2.5.
Integrační vrstva
Popis integrační vrstvy a jejích standardů je uveden v Příloze č. 3 „Integrační standardy“ a jmenovitý seznam služeb integrační vrstvy je uveden v Příloze č. 4 „Seznam služeb integrační platformy“.
25
6.2.
Intranetová část
Zadavatel požaduje dodat intranetovou aplikační část, která bude poskytovat interním uživatelům zadavatele zdroj informací a aplikací pro evidenci různých interních systémů a databází. Zadavatel požaduje, aby každá z aplikací měla buď vlastní, nebo centrální administrativní rozhraní, které umožní zadavateli správu oprávnění k dané aplikaci a definovat tyto role dle organizačních jednotek načtených z LDAP databáze, kde každá bude interpretována pomocí atributu „Popis“ a kde bude viditelné a načtené kódové označení organizační jednotky v některém z dalších atributu v administračním rozhraní. Zadavatel požaduje, aby každá z aplikací, pokud není definováno přímo v aplikaci, měla možnost nastavit tato oprávnění: Administrátor – plný přístup Editor – možnost přidávání příspěvků (bez možnosti zobrazit administrativní rozhraní) Návštěvník (čtenář) – pouze prohlížení obsahu (bez možnosti zobrazit administrativní rozhraní) Zadavatel požaduje, aby intranetová část umožnila změnu statického obsahu webu přímo v náhledovém okně celé aplikace, tak aby nebylo nutno zasahovat z důvodu úprav do vlastního kódu aplikace nebo statického obsahu webové stránky. Zadavatel požaduje, aby aplikace intranet jako celek umožňovala přenesení dat do extranetové části (veřejný web), který není součástí tohoto výběrového řízení a to skrze integrační platformu, které také není součástí tohoto výběrového řízení a to pomocí definovaných standardů pro přenosy (XML, aj…)
6.2.1.
Náhled příloh v aplikacích
Zadavatel požaduje, aby přiložená příloha byla indexována na úrovni obsahu (bylo umožněno fulltextové vyhledávání v obsahu dokumentu) a při najetí/kliknutí myši na danou přílohu zobrazenou u daného záznamu v aplikaci byla do samostatného okna vyrendrována v náhledu obsahu, a to u všech aplikací, kde existuje možnost připojení příloh. Tato funkcionalita je požadována pro kancelářské dokumenty a PDF.
6.2.2.
Domain object model
Zadavatel požaduje, aby uchazeč přiložil ke své nabídce pro každou aplikaci DOM model, který bude definovaný pro každou aplikaci a také na centrální úrovni, tak aby bylo zřejmé, jaká pole jsou v aplikacích použita a jakých mohou nabývat hodnot. Dále pak na centrální úrovni by mělo být zřejmé z DOM, jaké jsou globální číselníky a jejich vazba na jednotlivé aplikace v rámci celého řešení. Další vazbou, která by měla být na úrovni DOM zřejmá je vazba na jednotné místo pro správu a to pro administrátora a pro správce celého webu.
6.2.3.
Notifikace uživatelů
Zadavatel požaduje, aby bylo dodané řešení dodáno s funkcí, která umožní uživatelům prostřednictvím GUI (uživatelského rozhraní), konfigurovat svépomocí emailové notifikace. Tyto notifikace musí umožňovat zahájit jejich spuštění na základě událostí použitých prvků formuláře nebo změnu dat v nich obsažených.
6.2.4.
Naplánované úlohy
Zadavatel požaduje, aby dodané řešení splňovalo podmínky pro samostatnou konfiguraci a administraci časově naplánovaných úloh bez nutnosti použití programového kódu. Oprávnění ke konfiguraci bude mít výhradně administrátor modulu.
6.2.5.
Aplikace
Tento dokument je nadřazeným dokumentem pro detailní specifikace poptávaných modulů. Pokud není stanoveno na detailní úrovni, tak se všechny parametry a vlastnosti řídí tímto dokumentem. Zadavatel požaduje, aby byla splněna funkcionalita dle přílohy této technické specifikace a byla dodána dle všech pravidel, přičemž Váhu v případě kolize nastavení dané webové aplikace má vždy větší ta, která je uvedena v samostatném dokumentu a v tomto dokumentu jsou stanoveny pouze obecné funkcionality.
26
6.2.5.1.
Jmenovitý seznam poptávaných modulů
Bližší informace k jednotlivým modulům jsou popsány v Příloze č. 1 tohoto dokumentu. INT_001 Přehled územní evidence INT_002 Registr nájmů LČR INT_003 Významná místa na území spravovaných LČR INT_004 Pracovní úkoly INT_005 Správa publikačních atributů INT_006 Lesní technika INT_007 Správa povolenek INT_008 Evidence porostů napadených škůdci INT_009 Inspekce INT_010 Zpětná vazba INT_011 Evidence zalesňování ploch INT_012 Pomůcky a předměty INT_013 Vyhledávač typů aktiv společnosti INT_014 Registr využití techniky INT_015 Nápravná opatř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é dokumenty INT_022 Správa uživatelů intranetu INT_023 Knihovna
Definice integrační platformy a integrovaných nativních zdrojů obsahu
6.3.
Zadavatel požaduje, aby aplikace intranet umožňovala vazbu na tyto systémy jako integrační zdroje, přičemž v rámci tohoto zadání se nejedná o integrační platformu, která není součástí tohoto zadávacího řízení Vazba na systémy Obousměrná vazba na LDAP databázi Jednosměrná vazba na systém TARGET (jednosměrný asynchronní– přenos dat do intranetové aplikace) Obousměrná vazba na poštovní služby (systém umožňuje příjem i odesílání zpráv) Vazba na spisovou službu (bude řešeno integrační platformou, která není součástí této dodávky) Vazba na centrální DMS (bude řešena integrační platformou, která není součástí této dodávky) Vazby na integrační platformu – podrobný popis je uveden v Příloze č. 3 a 4
6.3.1.
Zabezpečení komunikace s integrační platformou
Zadavatel požaduje, aby systém byl schopný zabezpečit komunikaci na úrovni TLS s integrací certifikátu pro webové služby na úrovni SSL 3.0, tento certifikát bude sloužit pro zabezpečení komunikace mezi vrstvou aplikační a integrační platformou. Zadavatel požaduje, aby certifikát vydaný veřejnou certifikační autoritou byl dodán v rámci řešení a započítán do nabídkové ceny
27
6.3.2.
Vazba na poštovní služby
Zadavatel požaduje, aby webová aplikace umožňovala vazbu na interní poštovní servery a to jak pomocí protokolů MAPI, SMTP, IMAP, POP3 a to tak, aby z webové aplikace bylo možno emaily nejen odesílat, ale i do předem definovaných částí intranetových stránek i přijímat a to zejména při využití: Notifikační schránka webové aplikace Příprava reportů pravidelně generovaných webovou aplikací Zadavatel dále požaduje, aby bylo možno v těchto emailech vyhledávat a to na úrovních: Obsah emailové zprávy Příloha Hlavička Informace z emailů budou vyhledávacími servery automaticky indexovány v pravidelných intervalech a to ve dvou definovaných úrovních: 1x za 2 dny kompletní reindexace obsahu 4x denně rozdílová indexace obsahu
6.3.3.
Vazba na spisovou službu
Zadavatel požaduje, aby webová aplikace byla schopna čerpat data ze spisové služby zadavatele a to na úrovni integrační platformy, která není součástí tohoto výběrového řízení a byla schopna data interpretovat přímo do webové služby a to s co nejnižší mírou psaní vlastního kódu.
6.3.4.
Vazba na centrální DMS
Zadavatel požaduje, aby webová aplikace byla schopna čerpat data z centrálního DMS zadavatele a to na úrovni integrační platformy, která není součástí tohoto výběrového řízení a byla schopna data interpretovat přímo do webové služby a to s co nejnižší mírou psaní vlastního kódu.
6.3.5.
Vazba na personální systém TARGET
Zadavatel v rámci vývoje modulu předpokládá seznámení dodavatele s rozhraním ve spolupráci s výrobcem personálního systému TARGET. Ze stránek výrobce: „Systém „Target 2100“ je vyvinut v prostředí Borland Delphi 2.0–5.0. Systém je připraven využívat SQL databázový server MS SQL server 7 – 2000 nebo Oracle 8.
„
Zadavatel požaduje, aby z tohoto systému byly načítány informace o volitelných parametrech zaměstnanců, které budou v případě potřeby prezentovány prostřednictvím integrační platformy, která není součástí této dodávky. Tato vazba musí umožnit přenos tak, aby bylo možno vykreslit v části internet (formou diagramu nebo textového výpisu jednotlivých podřízených) informace o nadřízenosti a podřízenosti daných osob a to ve stromovém zobrazení, přičemž vždy bude platit, že bude zobrazen vždy jeden nadřízený a „n“ jeho podřízených a to vždy do první úrovně podřízenosti.
Zadavatel zajistí, aby informace byly vždy umístěny v aktuální verzi ve formátu CSV a to přímo v umístění, ze kterého bude moci aplikace čerpat. Tento proces bude vždy proveden tak, že dojde k nahrazení stávajících dat daty novými, ale nad změnou dané položky (pouze v případě její existence) bude zajištěno verzování, tak aby bylo možno zkontrolovat, kdy došlo ke změně daného atributu.
28
7.
Testovací prostředí zadavatele
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval, jakým způsobem bude vybudováno testovací prostředí. Zadavatel požaduje možnost podpořit svůj proces release management, v rámci kterého chce každou konfigurační změnu, import dat a další činnosti testovat a řídit. Toto testovací prostředí nemusí být řešeno jako vysoce dostupné a bude umístěno pouze v primární lokalitě zadavatele, přičemž by mělo být dostatečně výkonné, aby bylo možno provádět samostatné datové importy a změny na jednotlivých vrstvách testovacího aplikačního řešení.
7.1.
Průběh testování
Toto testovací prostředí nesmí omezit ani ohrozit provoz produkčních systémů a musí být zabezpečeno a ve stejné konfiguraci jako prostředí produkční. Zadavatel nepožaduje automatizaci změn v konfiguraci nebo obsahu po provedení vlastního testování změn. Tyto změny bude do produkce provádět svépomocí a bez účasti dodavatele. Zadavatel však požaduje, aby uchazeč ve své nabídce specifikoval, jak bude testování probíhat, jak bude provedeno nasazení po testování a po dokončení realizační fáze požaduje od dodavatele dodat dokumentaci a provozní manuál (testovací scénář) pro zajištění procesu release management. Zadavatel je obeznámen s faktem, že data, jež budou na aplikační úrovni plněna do systému jinými uživateli, nemusí být synchronní s testovacím prostředím, ale konfigurace se musí shodovat v obou prostředích.
29
8.
Požadavky na grafický design
Grafický vzhled výstupních webových stránek musí být řízen primárně prostřednictvím použití metody tzv. „kaskádových stylů“ CSS dle standardu W3C. Všechny vlastní definované třídy dodané dodavatelem musí být opatřeny komentářem dle standardu W3C. Příklad:
/* Komentář a popis třídy */
Výjimky při nepoužití CSS stylů musí být zaznamenány do dokumentace, včetně odůvodnění.
8.1.
Standardy pro grafické prvky
Zadavatel má vlastní logotyp (písmo s logem společnosti), které je možno začlenit do grafického návrhu intranetových stránek, které by měly být tvořeny převážně zelenou barvou, která je pro společnost zadavatele typická.
8.2.
Definice dynamického obsahu webu
Zadavatel požaduje, aby všechny stránky připravené k webové prezentaci byly generovány dynamicky a to tak aby umožňovali úpravu a rozložení stránek při otevření v internetovém prohlížeči v minimalizovaném režimu nebo při otevření v mobilním prohlížení na zařízeních smartphone (Windows, Android, OSX). Zadavatel by také uvítal, ale není podmínkou, možnost přípravy vlastního obsahu pro mobilní zařízení (úprava sloupců, úprava filtračních polí, atd..).
8.3.
Layout webových stránek
Zadavatel požaduje, aby uchazeč ve své nabídce navrhl grafický design s přihlédnutím k níže uvedenému rozložení při tvorbě layoutu (wireframe) celé intranetové koncepce.
30
8.4.
Standardy pro formuláře
Zadavatel požaduje, aby uchazeč ve své nabídce uvedl, jaké druhy polí pro formuláře umožňuje používat. Zadavatel požaduje, aby v rámci vytváření formulářů bylo možno využívat minimálně těchto polí: Jednořádkový text o přesně definovaném počtu použitelných znaků s maximální hodnotou 250 a možností definování výchozí hodnoty pro dané pole Více řádkový text s možností formátování WYSIWYG s možností definice počtu řádků Výběr z nabídky předvolených hodnot kde bude možno danou nabídku reprezentovat pomocí výběrového menu (list box), pomocí zaškrtávacích tlačítek (check box) nebo pomocí přepínačů (radio button) Číselnou hodnotu s možností definice rozsahu hodnot, které je možno zadat do daného pole formuláře a definicí počtu desetinných míst Možnost zadání měny ve formuláři s automatickým doplňováním zkratky pro danou měnu a možností omezení definováním minimální a maximální hodnoty Možnost zadání hodnoty datum a čas, která bude reprezentována kalendářem Možnost zadání hodnoty pomocí vyhledání v jiném seznamu v rámci daného aplikačního celku Možnost z výběru osoby z LDAP databáze, jež je integrována do dané aplikace Možnost vložení hypertextového odkazu s možností náhledu při přidání přímého linku na grafický prvek jiného webu (iFrame) Možnost vložit počítaný vzorec pro možnost kalkulování cen v některých seznamech Vazba na externí seznamy pomocí předem definovaných vazeb na datové zdroje (ODBC) Zadavatel požaduje u všech typů polí ve formuláři mít možnost zobrazení/nezobrazení uživatelům a také vynucení zadání dané hodnoty s grafickým upozorněním pro koncového uživatele (např. hvězdička, křížek, aj…). Zadavatel požaduje výše uvedená omezení a to z důvodu eliminace možnosti útoků na prvky formuláře a eliminaci zejména CSFR, XSS, atd..
9.
Číselníky a jejich správa
Zadavatel požaduje, aby jednotlivé číselníky na úrovni aplikačního prostředí byly provázány a spravovány samostatně z jediného místa (např.: „Centrální správa aplikací intranetu“), kde bude možno definovat jak přístupy a role pro uživatele (samostatný modul), tak i číselníky které jsou dostupné pouze pro uživatele v roli Administrator. Typickým číselníkem použitým ve většině modulů je nyní například: Seznam Organizačních Jednotek, který je načítán z databáze LDAP, ale může být v aplikaci intranet umístěn jako off-line číselník (s pravidelnou synchronizací), kdy bude moci obsahovat další metadata, která by v LDAP databázi nebyla obsažena Toto provázání je na rozhodnutí dodavatele aplikačního prostředí, přičemž zadavatel požaduje, aby uchazeč ve své nabídce uvedl relační vazby mezi těmito seznamy.
9.1.
Druhy číselníků
9.1.1.
Aplikační
Zadavatel pod tímto pojmem definuje standard pro vedení číselníku na úrovní prezentační vrstvy, který se obvykle používá přímo jako datový typ „Pole“ a/nebo „ENUMERATOR“ uvedený a spravovaný přímo na úrovni prezentační vrstvy. Zadavatel požaduje, aby v případě použití této metody byl tento číselník přímo uveden v předané dokumentaci řešení v kapitole „Service asset and configuration management“
9.1.2.
Business vrstva
Zadavatel pod tímto pojmem definuje standard pro vedení číselníku na úrovní business vrstvy, který se obvykle používá přímo jako datový typ „Pole“ a/nebo „ENUMERATOR“ uvedený a spravovaný přímo na úrovni business vrstvy. Zadavatel požaduje, aby v případě použití této metody byl tento číselník přímo uveden v předané dokumentaci řešení v kapitole „Service asset and configuration management“
31
9.1.3.
Databázová
Zadavatel pod tímto pojmem definuje standard pro vedení číselníku na úrovní datové vrstvy, který se obvykle používá jako „Tabulka“ nebo „Soubor“ a je spravovaný přímo na úrovni datové vrstvy. Zadavatel požaduje, aby v případě použití této metody byl tento číselník přímo uveden v předané dokumentaci řešení v kapitole „Service asset and configuration management“
9.1.4.
Externí
číselníky bez správy s externím vstupním interface XML nebo podobně. Zpravidla se může jednat o číselník získaný prostřednictvím veřejné webové služby
Správa paralelně vedených Číselníků mezi aplikacemi a jejich synchronizace
9.2.
Zadavatel tímto definuje standard principu používání totožných číselníků ve dvou a více aplikacích nebo integrační vrstvě, kdy je třeba zajistit vzájemnou synchronizaci číselníků.
9.2.1.
Jednosměrná vstupní tzv. MASTER
Přidání, změna nové položky číselníku probíhá přímo prostřednictvím dodaného řešení a to výhradně do „datové vrstvy“ řešení. Další aplikace pouze vyzvedávají hodnoty pro vlastní zobrazení. Zpravidla jsou tyto číselníky distribuovány prostřednictvím integrační platformy výhradně v režimu „jen pro čtení“. Odstraňování dat z číselníků NENÍ POVOLENO z důvodu zachování datové integrity na úrovni datové vrstvy. Jednotlivé záznamy musí disponovat přepínačem „aktivní/neaktivní“, kdy musí být na úrovni aplikační správy číselníků umožněno zobrazovat položky s uvedením tohoto atributu. Neaktivní záznamy nesmí být uživateli řešení zobrazeny v číselníku.
9.2.1.1.
S časovým ohraničením platnosti
V některých případech může být použito také časové ohraničení platnosti číselníku v režimu OD-DO, kdy je zobrazení řízeno prostřednictvím ověření proti aktuálnímu datu a času. Tento typ číselníku musí být vybaven také přepínačem „aktivní/neaktivní“.
9.2.2.
Jednosměrná výstupní SLAVE
Správa číselníku není na této úrovni řešení možná. Obsah číselníku je získáván prostřednictvím integrační platformy pouze v režimu „pro čtení“ aktivních nebo časově platných údajů.
9.2.3.
Obousměrná
Tento typ správy hodnot číselníků je vyloučen prostřednictvím organizačních procesů. Zpravidla je řešeno „Asynchronním způsobem“. Dodavatel musí mít řešení k tomuto způsobu přizpůsobeno. V případě, kdy bude řešeno prostřednictvím „časově naplánované úlohy“ musí být tato úloha zavedena do dokumentace sekce „Service asset and configuration management“
32
10.
SLA
10.1. Specifikace parametrů SLA pro jednotlivá prostředí Zadavatel požaduje dodání řešení, která budou splňovat podmínky pro níže uvedená SLA. Samotné SLA však budou v režii zadavatele.
10.1.1.
Produkční prostředí
Katalogový list Služby „SS01 – Portály - produkční“ Název Služby
Garance dostupnosti funkcionalit, obsahu a podpora provozu portálů LČR (Internet, Extranet, Intranet)
Dostupnost služby
97,77 % v kalendářním měsíci
Režim provozu
24x7
Reakční doba
30 minut (60 min. v případě požadavku na službu)
Režim odstávek
Maximální povolená doba odstávky za měsíc: 4 hodiny
Max. doba výpadku
16 hodin/kalendářní měsíc (dle požadované dostupnosti služby)
10.1.2.
Testovací prostředí
Katalogový list Služby „SS01 – Portály - testovací“ Název Služby
Garance dostupnosti funkcionalit, obsahu a podpora provozu portálů LČR (Internet, Extranet, Intranet)
Dostupnost služby
95 % v kalendářním měsíci
Režim provozu
12x5 v pracovní dny od 06-18hod.
Reakční doba
30 minut (60 min. v případě požadavku na službu)
Režim odstávek
Maximální povolená doba odstávky za měsíc: 4 hodiny
Max. doba výpadku
8 hodin/kalendářní měsíc (dle požadované dostupnosti služby)
10.1.3.
Vývojové prostředí
Katalogový list Služby „SS01 – Portály - vývojové“ Název Služby
Garance dostupnosti funkcionalit, obsahu a podpora provozu portálů LČR (Internet, Extranet, Intranet)
Dostupnost služby
95 % v kalendářním měsíci
Režim provozu
12x5 v pracovní dny od 06-18hod.
Reakční doba
30 minut (60 min. v případě požadavku na službu)
Režim odstávek
Maximální povolená doba odstávky za měsíc: 4 hodiny
Max. doba výpadku
8 hodin/kalendářní měsíc (dle požadované dostupnosti služby)
33
11.
OLA
Pro zajištění plnění budou zadavatelem po dobu trvání projektu zajištěny služby tzv. OLA definované v tomto článku. Pro řízení služeb OLA bude použit výhradně systém HELD DESKU, kterým disponuje zadavatel.
11.1. Organizační OLA Zadavatel se zavazuje, že po dobu plnění předmětu této zadávací dokumentace bude vybranému dodavateli zajišťovat přístup k těmto úrovním OLA.
11.1.1.
Přístup k HW zdrojům
Zadavatel umožní pouze přístup k virtuálnímu serveru a to prostřednictvím jednoho z managementových protokolů a to RDP, SSH, Telnet, http, Https, FTP, TFTP a to na nejvyšší úrovni oprávnění. Tento přístup k potřebným zdrojům bude definován pro každý server z nově budované farmy. Zadavatel neumožní přístup k serverům stávajícím a to ani k LDAP databázi, změny na této úrovni budou vždy řešeny prostřednictvím RFC. Katalogový list Služby „OLA001-Přístup k HW zdrojům“ Název Služby
Garance přístupu k HW zdrojům
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
11.1.2.
Přístup k SW zdrojům
Zadavatel umožní přístup k instalačním souborům aplikací, které budou vyžadovány nebo požadovány dodavatelem. Zadavatel požaduje, aby uchazeč v rámci nabídky specifikovat, jaké softwarové balíčky požaduje před zahájením dodávky aplikačního prostředí. Katalogový list Služby „OLA002-Přístup k SW zdrojům“ Název Služby
Garance přístupu k SW zdrojům
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
11.1.3.
Vzdálený přístup do počítačové sítě
Zadavatel umožní dodavateli vzdálený přístup na předem připravené servery nainstalované v režimu „NextNext-Finish“, pouze s nastavením možnosti vzdáleného přístupu. Dodavatel bude mít předem připravený účet v LDAP databáze ze strany zadavatele pro sebe a celý vývojový tým, který se bude danou aplikaci vyvíjet. Tyto účty budou mít nastavena nejnižší možná oprávnění a administrátorský přístup ke všem serverů z farmy intranetové aplikace. Zadavatel na vyžádání poskytne administrátorský přístup do prostředí dodavateli s oprávněním administrátor LDAP Databáze a to pouze ve chvíli kdy bude nutné konfigurovat konektory do této databáze. Katalogový list Služby „OLA004-vzdálený přístup“ Název Služby
Garance vzdáleného přístupu do počítačové sítě
Kategorie / Kritičnost
A
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
34
11.1.4. Administrativní zázemí s napájením 220v a připojením k veřejné síti internet Katalogový list Služby „OLA006-Administrativní zázemí pro zajištění předmětu plnění“ Název Služby
Administrativní zázemí pro zajištění předmětu plnění s napájením 220V a připojením k veřejné síti internet v rozsahu potřebném pro zajištění souběžného fungování nejméně 4 pracovišť
Kategorie / Kritičnost
A
Dostupnost služby
89,50 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
11.2. Technická OLA 11.2.1.
Zajištění HW Zdrojů
Katalogový list Služby „OLA008-HW Zdroje“ Název Služby
Zajištění HW Zdrojů
Kategorie / Kritičnost
A
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
Poznámka
Tato OLA bude blíže upřesněna dle požadavků vítězného uchazeče.
11.2.2.
LDAP
Katalogový list Služby „OLA009-Služba LDAP“ Název Služby
Zajištění služeb LDAP prostřednictvím Microsoft Active Directory
Kategorie / Kritičnost
A
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
Poznámka
Služba je v provozu v režimu 24x7 avšak bez garance řešení incidentů a požadavků
35
11.2.3.
Datový extrakt TARGET
Katalogový list Služby „OLA010-Datový extrakt z personálního systému TARGET“ Název Služby
Zajištění aktuálního datového extraktu z personálního systému TARGET
Kategorie / Kritičnost
A
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
Poznámka
Služba je v provozu v režimu 24x7 avšak bez garance řešení incidentů a požadavků
11.2.4.
SMTP Server
Katalogový list Služby „OLA011-poštovní server“ Název Služby
Zajištění služeb poštovního serveru Microsoft Exchange
Kategorie / Kritičnost
A
Dostupnost služby
97,77 % v době režimu provozu
Režim provozu
8x5 v pracovní dny od 07-15hod.
Reakční doba
120 minut (180 min. v případě požadavku na službu)
Poznámka
Služba je v provozu v režimu 24x7 avšak bez garance řešení incidentů a požadavků
36
12.
Požadavky na provedení testování a akceptace
Testování modulů bude probíhat výhradně po schválení testovacího scénáře zadavatelem. Testovací scénář musí být vždy dodán minimálně 5 pracovních dní před samotným provedením testování. Zadavatel požaduje, aby v rámci dodávky každý z jednotlivých modulů (aplikací) a zároveň celý systém prošli akceptací ze strany zadavatele. V rámci této akceptace budou kontrolovány veškeré funkcionality, jež požaduje zadavatel v rámci technických specifikací jednotlivých modulů, případně PID a bude kontrolovat zejména plnění obsahu, práci s daty, chybovost a související požadavky dle této specifikace.
37
13.
Požadavky na školení
Zadavatel požaduje v rámci dodávky zajištění fyzického školení. Minimální rozsah školení je 4 hodiny pro každý modul a úroveň obsluhy (uživatelské, Klíčový uživatel OJ, Správce obsahu OJ, Administrátor). Maximální počet účastníků pro jeden modul a úroveň je 10.
13.1. Uživatelské školení Zadavatel požaduje pro všechny moduly minimálně tuto strukturu osnovy školení pro uživatele uživatelské úrovně.
13.1.1.
Úvod do problematiky
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.1.1.
Přehled modulů
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.1.2.
Scénáře používání
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.2.
Vstup do aplikace a ověření identity uživatele
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.3.
Seznámení s navigací aplikace
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.4.
Seznámení s podpůrnými číselníky aplikace
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.5.
Práce s daty a možnosti jejich použití v kancelářských aplikacích
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.1.6.
Pracovní postupy
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.2. Školení pro správce obsahu Pro správce obsahů agend bude uživatelské školení rozšířeno minimálně o tyto moduly.
13.2.1.
Úvod do problematiky správců obsahu
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.2.1.1.
Správa číselníků
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.2.1.2.
Vazby mezi datovými zdroji
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
38
13.2.1.3.
Pracovní postupy
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.2.1.4.
Možnosti využití notifikací
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.2.1.5.
Logování dat a jejich využití pro reporting
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3. Administrátorské školení – správce chodu aplikace 13.3.1.
Úvod do prostředí a popis instalace
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.2.
Vytvoření aplikace pro Intranet
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.3.
Administrace webů
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.4.
Konfigurace obsahového řízení
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.5.
Autentifikace
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.6.
Bezpečnost obsahu
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.7.
Úpravy prostředí
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.8.
Notifikace
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.9.
Integrace s datovými zdroji
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.10.
Vyhledávání a správa fulltextové databáze obsahu
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.11.
Zálohovací a Obnovovací strategie
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
39
13.3.12.
Sledování a optimalizace výkonu
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
13.3.13.
Zajištění procesů dle ITIL
Zadavatel požaduje, aby uchazeč ve své nabídce specifikoval obsah daného modulu v rámci tohoto školení, jeho časovou náročnost a úroveň technické dovednosti jednotlivých uživatelů.
40
14.
Požadavky na logování
Zadavatel požaduje, aby aplikace umožňovala definování minimálně následujících úrovní logování v interním systému a to v pravidelných intervalech bez zatížení systému max. 20% z celkového výkonu farmy. Logování událostí musí umožnit definování těchto úrovní logování: Žádné Kritické Chyba Varování Informace Diagnostika Dále pak je nutné u trasovacího logu umožnit logování do těchto úrovní: Žádné Neočekávané Monitorované Vysoké Střední Diagnostické Low-Level Diagnostické Logování musí být možno zapnout minimálně na níže uvedených úrovních a ke každé části musí být možno nastavit úroveň logování a trasování. Logování publikační vrstvy o o
Logování práce v aplikaci Logování práce v administraci
Logování aplikační vrstvy o o
Logování práce v aplikaci Logování práce v administraci
Logování datové vrstvy Logování vyhledávací vrstvy Logování renderovací vrstvy Výstupní logy mohou být uloženy a to na úrovni operačního systému, aplikace nebo v souborech v čitelné podobě. Zadavatel také požaduje, aby bylo trvale umožněno logování na úrovni event log managementu a to pro níže definované oblasti celého aplikačního řešení: Využití analýzy Monitorování aplikací Statistiky aplikace Sledování šířky pásma Využití exportu obsahu Využití importu obsahu Definice využití polí pro vzdělávací telemetrie Definice využití polí pro mikroblogovací telemetrie Definice využití polí pro servisní části Definice využití polí distribuované cache Definice využití polí pracovních postupů Používání funkcí V/V souborů Žádosti o stránky Používání akcí rozhraní API klienta a služby REST Využití požadavků REST a rozhraní API klienta Měření prostředků požadavků na izolovaný prostor (sandbox) Požadavky na izolovaný prostor (sandbox) 41
Používání výjimek SQL Využití V/V SQL Využití latence SQL Používání úkolů Protokolování klienta Úlohy časovače Kontrola času odpovědí/ Procesní časové metriky pro přístup ke službám Využití importu profilů uživatelů ze služby LDAP Profil uživatele pro využití synchronizace Zadavatel požaduje, aby bylo logy možno číst z několika míst a to: Souborové umístění Event log serveru Administrační rozhraní celého řešení
42
15.
Požadavky na dokumentaci
Zadavatel požaduje jakou součást řešení dodávku dokumentace v rozsahu minimálně dle tohoto bodu. Rozsah dílčí dokumentace nemůže být žádným způsobem omezen. V případě, kdy nebude účelné plnit příslušný bod obsahem, tak se místo vyplní obsahem „Není aplikováno“. Použití tohoto označení musí být vždy odsouhlaseno zadavatelem. V případě použití základní platformy pro vývoj řešení zadavatel připouští, že dokumentace může být i ve formě odkazu na URL adresu výrobce platformy. Všechny prvky vývoje však musí být zdokumentovány pro pokrytí celého životního cyklu dodaného řešení.
15.1. Service Desk 15.1.1.
Knowledge Base
Zadavatel požaduje, aby uchazeč v rámci dodávky aplikačního řešení udržoval znalostí bázi celého řešení, ve které bude evidovat veškeré chyby nalezené při implementaci (Incidenty, Problémy), změny provedené ve vlastním zadání (RFC), konfigurační změny oproti standartním konfiguracím. Tento katalog znalostní báze bude na konci projektu předán zadavateli ve formátu XLS, XLSX v čitelné podobě tak, aby zadavatel v těchto znalostech mohl nadále pokračovat a tuto databázi udržovat jako jeden z prvků dokumentace. Zadavatel také požaduje, aby znalostní báze byla dostupná v intranetové aplikaci pro uživatele, pokud v rámci implementace budou vznikat požadavky z jejich strany, tak aby každý z uživatelů mohl v této databázi vyhledávat a problémy vzniklé během implementaci řešit svépomocí.
15.1.1.1.
Uživatel
zadavatel požaduje jako součást řešení dodávku scénářů a návodů pro všechny popsané uživatelské scénáře. Dokumentace bude mít minimálně tuto strukturu: Tištěná dokumentace Správce zadavatel požaduje jako součást řešení dodávku scénářů a návodů pro všechny administrační scénáře. Dokumentace bude mít minimálně tuto strukturu: Popis použitých standardů Tištěná dokumentace s popisem administrace
15.1.1.2.
Podpora podle úrovně SLA, OLA
Zadavatel v rámci dodávky řešení požaduje dodání doporučených postupů pro typy incidentů dle nastavených SLA
15.1.1.3.
Vývoj řešení
zadavatel požaduje jako součást řešení dodávku zdrojových kódů s komentáři pro všechny moduly, funkce a vlastnosti všech prvků a proměnných použitých při vývoji řešení, mimo prvků použitých výrobcem platformy, na které bude řešení realizováno. Dokumentace bude mít minimálně tuto strukturu: Popis použitých standardů Tištěná dokumentace s popisem administrace
15.2. Service Support 15.2.1.
Incident management
Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení.
15.2.2.
Change management
Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení.
15.2.3.
Problem management 43
Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení.
15.2.4.
Service asset and configuration management
Zadavatel v souvislosti s požadavky na vedení konfigurační databáze požaduje, aby dodavatel v nabídce navrhl jmenný seznam konfiguračních položek pro všechny jednotlivé aplikační SLA a v případě potřeby i OLA. Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení.
15.2.5.
Service Catalogue Management
Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení.
15.2.6.
Release and deployment management
15.2.6.1.
Plán podpory
Zadavatel v souvislosti s požadavky na pravidelnou údržbu požaduje, aby Uchazeč uvedl do své nabídky návrh plánu pravidelné údržby, přičemž Zadavatel požaduje, aby součástí takového plánu i samotné realizace pravidelné údržby byly nejméně níže uvedené oblasti: Identifikace Updatů Posouzení dopadů instalace takto identifikovaných Updatů na provoz a úroveň kvality veškerých služeb IT, systémů a aplikací Provedení záloh veškerých služeb IT, systémů a aplikací a to na úrovni sejmutí snímků aktuálního stavu serveru před provedením vlastní instalace Updatu o Provedení instalace updatů o Kontrola funkčnosti veškerých služeb IT, systémů a aplikací, zejména pak: Kontrola dostupnosti veškerých serverů Kontrola funkčnosti operačních systémů Kontrola funkčnosti aplikací Kontrola funkčnosti služeb operačního systému Kontrola přihlášení k serverům pro souběžnou práci více uživatelů Kontrola event logů Kontrola platnosti certifikátů Kontrola přihlášení do systémů o Obnovení záloh u nefunkčních služeb IT, systémů a aplikací o Vytvoření reportů nainstalovaných Updatů
15.2.6.2.
Dokumentace vývoje řešení
Zadavatel požaduje minimálně tuto strukturu dokumentace pro každou vrstvu řešení, pokud je na ni aplikován vlastní vývoj: Datový model řešení Doplněné komponenty třetích stran Přehled použitých funkcí Přehled ovládacích prvků o Dokumentace použitých metod o Dokumentace použitých vlastností o Dokumentace použitých funkcí Popis vlastních knihoven a tříd
15.2.7.
Event management
Zadavatel požaduje, aby součástí dodaného řešení byl návrh procesů pro obsluhu událostí s využitím atributů definovaných v kapitole
44
Požadavky na logování. Procesy musí být definovány podle metodiky ITIL.
45
15.3. Service delivery 15.3.1.
Capacity management
Zadavatel požaduje, aby součástí dokumentace řešení byly dodavatelem popsány atributy doporučené pro pokrytí uvedeného procesu podle aktuálně platné verze ITIL a to minimálně v této struktuře: Sledovaný parametr Mezní hodnoty minimální a maximální Frekvence sběru dat Vlastník Eskalační schéma a popis notifikace
15.3.2.
Availability management
Zadavatel požaduje, aby součástí dokumentace řešení byly dodavatelem popsány atributy doporučené pro pokrytí uvedeného procesu podle aktuálně platné verze ITIL a to minimálně v této struktuře: Sledovaný parametr Mezní hodnoty minimální a maximální Frekvence sběru dat Vlastník Eskalační schéma a popis notifikace o Business úroveň – monitorovaný parametr bude notifikovat přímo klíčového uživatele systému o Technická úroveň – monitorovaný parametr bude notifikovat administrátora nebo help desk podpory řešení
15.3.3.
Continuity management
Zadavatel požaduje, aby součástí dokumentace řešení byly dodavatelem popsány atributy doporučené pro pokrytí uvedeného procesu podle aktuálně platné verze ITIL Zadavatel připouští přijetí ztráty dat v případě výpadku primární a sekundární lokality maximálně v rozsahu 2 hodin. Zadavatel požaduje, aby Uchazeč jako součást své nabídky předložil Plán záloh a Plán obnov Zadavatel požaduje, aby proces Continuity management zajišťoval primárně možnost pro obnovení dat v případě lidské chyby, kdy může v rámci celého řešení dojít k smazání některých dat, anebo obsahu obsahových databází, popřípadě chybě administrátora při konfiguračních změnách prováděných z testovacího prostředí do vlastního produkčního prostředí. Pokud k této chybě dojde, musí proces Continuity management být schopen zajistit obnovení dat a to v rozsahu definovaném v SLA, OLA. Dále je nutné, aby tento proces a systém pro zálohování a obnovení byl schopen provést znovu sestavení celého řešení v případě selhání a v rámci testování tohoto procesu bude provedena obnova celé farmy do testovacího prostředí nebo do prostředí DMZ v odděleném subnetu, tak aby nedošlo k narušení provozní části celého řešení. Zadavatel požaduje, aby uchazeč ve své nabídce uvedl, jakým způsobem bude schopen tento proces zadavatel zajistit svépomocí a to minimálně přípravou dokumentace a provozního manuálu na provedení Disaster recovery planing a tím i stanovení kalendářů plánů obnovy a zálohy celého řešení.
15.3.4.
Financial management
Není požadováno
15.3.5.
Service Level Management
Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení.
15.3.6.
Access Management
Zadavatel požaduje, aby součástí dokumentace byl návrh řešení procesu dle metodiky ITIL se zohledněním parametrů uvedených v SLA a OLA dle specifikace tohoto řešení s využitím standardů definovaných v čl.
46
Řízení přístupů
47
Příloha č. 1 – Detailní technická specifikace Aplikačního řešení 1. INT 001 – Přehled územní evidence 1.1.
Popis
Aplikace umožňuje vyhledávat záznamy v katastru nemovitostí na základě předem definovaných vstupních údajů. Je umožněno vyhledávat dle názvu katastru, 6-ti, nebo 9-ti místného čísla katastru, názvu OJ, nebo čísla OJ. Veškeré tyto parametry se zadávají do formuláře, který funguje jako bod pro zadávání vstupních vyhledávacích kritérií. Jakmile je provedené takové hledání, je automaticky filtrován list všech záznamů, které zadaným hodnotám vyhovují. Pokud je potřeba, je dále možné kliknout na jakýkoliv z již filtrovaných záznamů v seznamu a následně se zobrazí v další webové části jednotlivé podrobnosti – detaily k vybrané položce. Aplikace, která je umístitelná na jakoukoliv stránku intranetového portálu jakožto samostatná aplikace. Tuto aplikaci je možné propojit s externími seznamy dat v podobě datových připojení. Tyto připojení jsou definována v rámci nasazení aplikace, nicméně je možné změnit bez použití úpravy zdrojového kódu aplikace. Je tedy možné změnit databázi, ze které by byly čerpány data. Po změně zdroje dat bude aplikace zobrazovat pouze data, která tento zdroj obsahuje. Je důležité zmínit, že tato aplikace slouží pouze jako zobrazovací prostředek, nikoli jako nástroj na editaci evidovaných položek v databázi, nebo na zakládání takovýchto nových položek.
1.2.
Vlastnosti
Aplikace eKatastr je tvořena kombinací tří prvků v rámci webové stránky. První prvek tvoří formulář, kde je možné stanovit uživatelem parametry vyhledávání a na jejich základě vyfiltrovat v druhém prvku konkrétní data z databáze. Tyto vyfiltrovaná data je možné dále selektovat a zobrazit tak jejich detaily v třetím prvku webové stránky. Není umožněno data jakýmkoliv způsobem modifikovat, jen je prohlížet.
1.3.
Use Cases – případy použití
Aplikace slouží výhradně k informování uživatelů na základě předem definovaných kritérií o podrobnostech objektu, který byl vybrán z databáze katastru, případně jiného předem definovaného datového zdroje. Návštěvník dané aplikace má pouze možnost vyhledávání v tabulce obsahující informace o katastrálním území, přičemž v základním pohledu pro filtrování bude zobrazena pouze skupina záznamů z databáze a to zejména položky, dle kterých je možno i filtrovat Jméno katastrálního celku (označeno číslem) Organizační jednotka (vyhledání dle města) Evidenční číslo organizační jednotky (evidenční číslo města) Evidenční číslo katastru (6 místná hodnota typu integer) Druhé evidenční číslo katastru (9 místná hodnota typu integer) Po zobrazení nalezeného územního celku je možno zobrazit celý detail záznamu v tabulce, který bude obsahovat všechny hodnoty, které dané katastrální území obsahuje.
1.4.
Role
Uživatel čtenář – reprezentant koncového uživatele, který po zadání požadovaných vstupních parametrů nahlíží do databáze katastru nemovitostí a v rámci konkrétní selekce i do detailů. Tato role nemá žádné požadavky na omezený přístup a je tedy předvolena všem uživatelům portálového řešení. Tento uživatel nemá práva na změnu jakékoliv hodnoty v položkách. Katastr nemovitostí – je reprezentován databází jednotlivých subjektů, ke kterým má uživatel čtenář přístup v rámci vyhledávání na základě parametrů sloužících k zúžení vyhledávaného subjektu. Jedná se o externí systém reprezentovaný nastaveným datovým připojením k aplikaci s katastrálními údaji. Správce – reprezentant administrativního pracovníka s možností správy obsahu (globální nastavení a povolování funkcí daného webu), kdy nemůže upravovat jednotlivé záznamy importované do tabulky katastrálních území.
48
1.5.
Číselníky a správa
Není aplikováno
1.6.
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky Jméno katastrálního celku (označeno číslem) Organizační jednotka (vyhledání dle města) Evidenční číslo organizační jednotky (evidenční číslo města) Evidenční číslo katastru (6ti - místná hodnota typu integer) Druhé evidenční číslo katastru (9ti- místná hodnota typu integer)
1.7.
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
1.8.
Vstupní interface Vstupní interface je tvořen zadávacím formulářovým prvkem, který slouží pro definování vyhledávacích parametrů. Datový můstek pro import dat do systému v režimu úplné odstranění a importování nových dat.
1.9.
Migrace dat
Není aplikováno, ale řešení musí umožňovat napojení na libovolný datový zdroj prostřednictvím konfigurovatelného parametru tzv. „ConnectionString“ v nezávislém souboru s využitím formát XSD a výměny dat protokolem XML. Dalším z možných zdrojů pro přístup k datům pro migraci je import z CSV souboru. Zdrojovými databázemi mohou být například: Microsoft SQL Server Oracle MySQL A další obecně používané
1.10. Workflow Není aplikováno. Oprávnění k práci se záznamy je řešeno prostřednictvím nastavení oprávnění.
1.11. Logování dat Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu
49
o
Soupis
Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání Využití úložiště Počet webů
1.12. Časově plánované úlohy Zadavatel požaduje, aby součástí dodaného řešení byla „Časově naplánována úloha“ pro aktualizaci zdrojových dat. Termín spouštění bude specifikován v rámci PID dle OS.
1.13. Reporting Není aplikováno
50
2.
INT-002 - Registr nájmů LČR
2.1.
Popis
Aplikace Registr nájmů LČR musí umožnit zadavateli vytvářet, editovat a upravovat položky registru. Tento registr je statickým obsahem a využívá ke své funkci několik statických číselníků, ze kterých je nadále sestaven ucelený pohled. Aplikace bude využívat statické databázové tabulky, přičemž nad hlavní tabulkou bude možno filtrovat na těchto úrovních: -
Místo nájmu Stav schválení nájemní smlouvy Velikost pronajímaných prostor Organizační jednotka Jméno nájemní smlouvy
Aplikace musí umožnit přiložení přílohy nájemní smlouvy ve formátu PDF a v rámci interního vyhledávání umožnit hledat v obsahu dané nájemní smlouvy. Informace o uskutečněných pronájmech bude přenášena skrze integrační platformu na extranet zadavatele.
2.2.
Vlastnosti
Aplikace by měla být tvořena z minimálního počtu 5 prvků (číselníků), kdy: -
1. číselník bude sloužit pro evidenci OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) 2. číselník bude sloužit pro evidence stavu schválení nájemní smlouvy (Název, Popis) 3. číselník bude sloužit pro evidenci druhu nájmu (Název, Popis) 4. číselník bude sloužit pro evidenci nájemních smluv (Název, Typ, Vlastní obsah) 5. číselník bude prezenční prvek (webová stránka) na které budou sestaveny data z ostatních prvků (číselníků) a budou zde doplněna další metadata a to minimálně: o Název OJ – (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Název o Číslo o Velikost pronajímaných prostor o Druh nájmu – načteno ze samostatného číselníku o Stav schválení nájemní smlouvy – načteno ze samostatného číselníku o Místo nájmu o Datum uskutečnění nájmu o Místo doručení nabídky o Datum doručení nabídky o Místo konání prohlídky o Datum konání prohlídky o Čas konání prohlídky o Výše zálohy nájmu o Pronajímatel o Cena nájmu bez DPH o Další informace o Přílohy – načteno ze samostatného číselníku o Změnil – načteno z LDAP databáze o Datum změny
Zadavatel požaduje, aby veškeré vložené přílohy k dané položce seznamu bylo možno přidat a zobrazit. Nikoliv však měnit nebo mazat, aby nedošlo k narušení datové integrity.
2.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: Místo nájmu Stav schválení nájemní smlouvy Velikost pronajímaných prostor Organizační jednotka Jméno nájemní smlouvy 51
2.3.
Use Cases – případy použití
Aplikace slouží výhradně k vyhledávání záznamů o předmětech nájmu, které jsou vyhlašovány zadavatelem.
2.4.
Role
Uživatel/Návštěvník – osoba, která má práva k prohlížení obsahu, vyhledávání dat a náhled dat v intranetové části. Změnu členství tohoto seznamu smí provádět disponent nebo administrator Správce obsahu (Disponent) – osoba, která se stará o danou OJ v rámci, které je nájem vyhlašován, tato osoba má práva přidávat, upravovat a mazat záznamy vytvořené v daném seznamu, přičemž nesmí mít práva na smazání přílohy nebo záznamu jako samostatného prvku, aby nedošlo k porušení integrity dat v daném seznamu Administrator – osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
2.5.
Číselníky a správa
Aplikace obsahuje tyto číselníky, které smí upravovat pouze role Správce obsahu a Administrator číselník bude sloužit pro evidenci OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) číselník bude sloužit pro evidence stavu schválení nájemní smlouvy (Název, Popis) číselník bude sloužit pro evidenci druhu nájmu (Název, Popis) číselník bude sloužit pro evidenci nájemních smluv (Název, Typ, Vlastní obsah)
2.6.
OLA
Zadavatel zajistí data ve formátu CSV s oddělovačem „;“ nebo „,“ popřípadě přímý přístup do tabulky databáze s touto strukturou zdrojové tabulky: Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) Název (string) Číslo (string) Velikost pronajímaných prostor (integer) Druh nájmu (string) Stav schválení nájemní smlouvy (string) Místo nájmu (string) Datum uskutečnění nájmu (datetime) Místo doručení nabídky (string) Datum doručení nabídky (datetime) Místo konání prohlídky (string) Datum konání prohlídky (datetime) Čas konání prohlídky (datetime) Výše zálohy nájmu (decimal) Pronajímatel (string) Cena nájmu bez DPH (integer) Další informace (string) Přílohy (-) Změnil (načteno z LDAP databáze) Datum změny (datetime)
2.7.
SLA
Viz. OS s upřesněním pro odhadované množství záznamů v rozsahu 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové, v odůvodněných případech i s možností využití aplikační vrstvy, tak aby nebyl omezen výkon aplikace po celou dobu životního cyklu. 52
2.8.
Vstupní interface
Zadavatel požaduje, aby vstupním prvkem byl formulář s obsahem všech polí pro všechny definované role bez omezení pro jednotlivé role, formulář bude pouze pro každý číselník a jejich úprava bude možná i po provedení implementace a to zejména o rozšíření dalšího pole, aniž by došlo k porušení integrity dat, přičemž data pro nově definované pole budou plněna ručně editací každého samostatného záznamu přímo z aplikace, nikoliv zásahem do databáze.
2.9.
Validace dat
Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
2.10. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele.
2.11. Workflow Není aplikováno. Oprávnění k práci se záznamy je řešeno prostřednictvím nastavení oprávnění.
2.12. Logování a auditování Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
2.13. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
2.14. Reporting Zadavatel nepožaduje na této úrovni aplikace žádný reporting.
53
INT-003 - Aplikace spravovaných LČR
3.
3.1.
Významná
místa
na
území
Popis
Aplikace Významná místa na území spravovaných LČR slouží pro evidenci spravovaných lokalit zadavatelem. Tato aplikace pomáhá zadavateli lépe plánovat činnosti údržby, plánování činností a hospodaření s místy spravovanými zadavatelem. Správci jednotlivých OJ provádí úpravy, vkládání záznamů a tyto změny jsou dále skrze integrační platformu prezentovány do extranetu, aby i široká veřejnost měla přehled o všech údržbách a činnostech v jednotlivých místech. Tato data jsou poté zobrazena na mapě společně s popisem.
3.2.
Vlastnosti
-
Systém musí umožnit vložní pozice rostliny a to pomocí souřadnic a umožnit přepočty pomocí standardů SJTSK a WGS-84. Tyto souřadnice musí být dále interpretovány do mapy, která bude tyto rostliny zobrazovat.
-
Systém musí dále umožnit publikování do internetových stránek LCR skrze integrační platformu, která není součástí této specifikace.
-
Každý vytvořený záznam bude obsahovat metadata o verzi, která bude povýšena při každé změně záznamu. Aplikace musí umožnit vložení fotografie, která bude reprezentována ikonou vedle záznamu a bude libovolné její otevření a zobrazení uživatelem
Vyhledání záznamu
3.2.1.
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: Druh rostlin Evidenční číslo katastru Název rostliny Vyhláška PS Kód druhu rostliny Kdo zaznamenal druh rostliny Číslo zpracování Platnost od Platnost do Druh rostliny Výška rostliny Obvod rostliny Stáří rostliny Zdraví rostliny Poznámky Úhyn Místo
3.3.
Use Cases – případy použití
Aplikace slouží výhradně k zajištění centrální evidence rostlin, jejich prohlížení v rámci náhledu a k její plné lokalizaci s grafickým zobrazením na mapě České republiky. Dále pak je aplikace určena jak pro interní uživatele zadavatele, tak i jako zdroj pro integrační platformu, která není součástí této specifikace ani zadávací dokumentace.
3.4.
Role
Uživatel/Návštěvník – tato role zastupuje běžného uživatele, který má práva pouze k nahlížení do dat a k zobrazení detailu záznamu
54
Klíčový uživatel OJ – tato role zastupuje uživatele, který může upravovat obsah v záznamech, jež jsou přiřazeny dané OJ Správce obsahu OJ (Disponent) – tato role zastupuje uživatele, který musí validovat nově přidaná data k dané OJ Vlastník – tato role zastupuje uživatele, který má práva měnit členství jednotlivých skupin a upravovat veškeré záznamy, ale musí být ošetřena integrita dat v případě změny záznamu Administrátor - osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
3.5.
Číselníky a správa
Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu OJ a Administrátor -
3.6.
1. číselník bude sloužit pro evidenci OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) 2. číselník bude sloužit pro evidenci ekonomických celků (ID, Název) 3. číselník bude sloužit pro evidenci druhů rostlin (Český název, Odborný název) 4. číselník bude sloužit pro evidenci územních úhrnů (Název, Evidenční číslo území, druhé evidenční číslo území) 5. číselník bude sloužit pro zobrazení mapy s polohou 6. číselník bude sloužit pro evidenci příloh 7. číselník bude prezenční prvek (webová stránka) na které budou sestaveny data z ostatních prvků (číselníků) a budou zde doplněna další metadata a to minimálně: o Druh rostlin (string) o Evidenční číslo katastru (string) – vazba na číselník z aplikace „Přehled územní evidence“ o Název rostliny (string) o Vyhláška PS (boolean) o Kód druhu rostliny (integer) o Kdo zaznamenal druh rostliny (string) o Číslo zpracování (string) o Platnost od (datetime) o Platnost do (datetime) o Druh rostliny – načtení z číselníku o Výška rostliny (integer) o Obvod rostliny (integer) o Stáří rostliny (integer) o Zdraví rostliny (string) o Poznámky (string) o Úhyn (boolean) o Místo (boolean)
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky Druh rostlin (string) Evidenční číslo katastru (string) – vazba na číselník z aplikace „Přehled územní evidence“ Název rostliny (string) Vyhláška PS (boolean) Kód druhu rostliny (integer) Kdo zaznamenal druh rostliny (string) Číslo zpracování (string) Platnost od (datetime) Platnost do (datetime) Druh rostliny – načtení z číselníku Výška rostliny (integer) Obvod rostliny (integer) Stáří rostliny (integer) Zdraví rostliny (string) Poznámky (string) 55
Úhyn (boolean) Místo (boolean)
3.7.
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
3.8.
Vstupní interface
Jedním z klíčových prvků je vazba na číslo územního celku, která je načítána z aplikace definované v dokumentu „TECHSPEC_5.4.1_INT-001_Přehled územní evidence.docx“ a to z důvodu velkého množství dat v územních celcích a ke zjednodušení správy a validace dat. Oddělení těchto číselníků je důležité zejména z pohledu bezpečnosti, kdy v aplikaci „Přehled územní evidence“ může být administrátorem a správcem obsahu jiná osoba než v této aplikaci. Dále pak tyto vstupní interface: -
3.9.
Vstupní interface je tvořen zadávacím formulářovým prvkem Datový můstek pro import dat do systému v režimu úplné odstranění a importování nových dat.
Validace dat
Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty. Systém musí umožnit validaci dat zadávaných do systému pomocí souřadnic, které budou následně v mapě zobrazovat umístění dané rostliny, tyto souřadnice jsou zadávány přímo do vstupního formuláře a to přímo do číselníku 5, přičemž způsob zadání do tohoto číselníku je na dodavateli, ale zadavatel preferuje nejjednodušší variantu řešení.
3.10. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
3.11. Workflow V rámci tohoto řešení je navržen pracovní postup, při kterém dojde ke schválení zadání nové položky rolí uživatele „Klíčový uživatel OJ“ a schválení proběhne uživatelem s rolí „Správce obsahu OJ“. Správce obsahu OJ musí být vždy při zadání nové položky notifikován emailem a Klíčový uživatel OJ musí být notifikován s informací o schválení Správcem obsahu OJ.
3.12. Logování a auditování Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o
Provoz
Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče
56
o
o
Hledání Soupis
Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání Využití úložiště Počet webů
3.13. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
3.14. Reporting Není aplikováno
4.
INT-004 - Aplikace Pracovní úkoly
4.1.
Popis
Aplikace pracovní úkoly umožňuje uživatelům zadávat položky typu kalendářní záznam, který umožní evidenci plánovaných činností a akcí konaných v rámci společnosti zadavatele. Přičemž tato položka bude mít vždy definovanou platnost, která bude provádět v hlavním výčtu položek filtrování na daný rok a položky bude moci zobrazit jak nastávající tak i již proběhlé. Tento kalendář provede zaslání emailu osobě při nastavení jako plánovaná činnost vždy v předem definovaném intervalu. Uživatel po přihlášení musí být schopen vidět na úvodní stránce své položky a to pro předem definované termíny předchozí, následující a aktuální den, ostantí položky jsou uživateli skryty.
4.2. -
-
Vlastnosti Umožnit zobrazení určitých záznamů v čase Umožnit přiřazení záznamů platnosti pro každý rok/kvartál/měsíc/den Umožnit definici dne spuštění (příklad: 8 den, každé pondělí, první pondělí v měsíci, aj…) Stanovení způsobu notifikace o Email o Telefon o Sms Možnost zobrazení ve zkrácené formě tak, aby je bylo možno zobrazit v malém okně intranetové aplikace Vazba na LDAP Databázi a to zejména při čerpání informace o uživateli
4.2.1.
Vyhledání záznamu
Systém musí umožnit pouze filtrování dat na úrovni globální tabulky obsahující všechny záznamy a to Správcem (Disponentem), běžný uživatel tuto tabulku neuvidí. Běžný uživatel uvidí pouze aktivity své položky, nikoliv ostatních zaměstnanců zadavatele.
4.3.
Use Cases – případy použití
Aplikaci budou využívat všichni uživatelé bez výjimky k plánování svých pravidelných činností a odpovědnost za správnost dat a plnění jednotlivých úkolů má každá osoba, přičemž osoba v roli Správce má jediná právo na úpravu záznamů, mazání na úrovni obsahu všech položek.
4.4.
Role
Uživatel/Návštěvník – tato role zastupuje uživatele, který má práva na přidávání záznamů, mazání a úpravu záznamů vlastních Správce obsahu (Disponent) – tato role zastupuje uživatele, který má práva na přidávání, změnu a mazání všech záznamů na úrovni této aplikace 57
Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
4.5.
Číselníky a správa
Tato aplikace nemá žádné další číselníky.
4.6.
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky -
4.7.
Období platnosti (string/integer/datetime) Aktivita (string) Den aktivity (integer/string/datetime) Informace k aktivitě (string) Řešitel (string) Zodpovědná osoba (string) Notifikace (string) Kontakt (string) Pomoc (boolean)
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
4.8.
Vstupní interface
Aplikace obsahuje vstupní formulář, ve kterém bude možno vyplnit vždy níže uvedená metadata. -
4.9.
Období platnosti (string/integer/datetime) Aktivita (string) Den aktivity (integer/string/datetime) Informace k aktivitě (string) Řešitel – vazba na LDAP databázi Zodpovědná osoba – vazba na LDAP databázi Notifikace (string) Kontakt – vazba na LDAP databázi – metadata email z objektu LDAP vázaný k „Zodpovědné osobě“ Pomoc (boolean)
Validace dat
Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
4.10. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB.
4.11. Workflow Není aplikováno
4.12. Logování a auditování Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků
58
Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o
o
o
Provoz Hledání Soupis
Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání Využití úložiště Počet webů
4.13. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
4.14. Reporting Není aplikováno
59
5.
INT-005 - Aplikace Správa publikačních atributů
5.1.
Popis
Aplikace Správa publikačních atributů slouží výhradně pro informování interních zaměstnanců o publikačních atributech zaměstnanců a jejich vzájemných vazbách. Publikované atributy podle výběru správce budou sloužit informování mezi zaměstnanci. Tato aplikace čerpá data z personálního systému TARGET a dále je interpretuje zaměstnancům zadavatele v intranetovém portálu. Tato aplikace také umožňuje nastavení pro přenos do zóny extranet skrze integrační platformu a to tak, aby byla data na internetu vždy aktuální. Aplikace je z větší části bezobslužná a správce nebo interní naplánované úlohy provádí aktualizaci dat skrze importy na s možností jejich dalšího využití například na extranetu společnosti. K vzájemné transformaci dat bude sloužit integrační platforma. V této aplikaci bude možné provádět minimálně fulltextové vyhledávání záznamů, prohledávání a zobrazení položek podle stromové struktury, zobrazení detailu.
5.2.
Vlastnosti
Tato aplikace je založena na jediném číselníku, do kterého jsou data čerpána ze systému TARGET, který poskytuje data ve formátu CSV. V této aplikaci není možné provádět úpravy, jedná se pouze o interpretaci systému TARGET na jednotné místo. Aplikace rozšiřuje seznam publikačních atributů o nové položky. Systém TARGET poskytuje zdrojová data (číselník) s těmito metadaty a minimálně ta musí být obsažena v intranetové části: Číslo OJ Název OJ Krátký název Podrobný název Zkratka Textový popis Mobilní telefon (kontakt na zodpovědnou osobu) Telefon – Pevná linka (kontakt na zodpovědnou osobu) Email (kontakt na zodpovědnou osobu) Nadřazená položka (rodičovská) Vlastník (osoba s přiřazeným publikačním atributem) Dalším kritériem pro danou aplikaci je umožnit uživatelům fulltextové vyhledávání na úrovni každého záznamu. Aplikace je současně zdrojem informací o podrobnostech publikačních dat a pro řízení zobrazení těchto detailů v extranetové části, pro integrační platformu (zároveň tedy prostředníkem mezi systémem TARGET a extranetovým portálem), která bude provádět publikování dat do extranetové části, přičemž v tomto režimu, musí mít správce možnost, zamítnout publikování dané osoby do extranetové části (pomocí výběrového pole, radio button, check button nebo jiné) a tato informace nesmí být ztracena ve chvíli, kdy dochází k importu dat ze systému TARGET skrze integrační platformu.
Obr. 3 Znázornění vztahu replikace dat mezi systémy 60
Aplikace poskytuje návštěvníkům možnost náhledu vztahu podřazenosti a nadřazenosti publikačních atributů ve vztahu vždy 1:n, kdy u každého nadřazeného atributu bude vidět seznam osob podřazených atributů do 1 úrovně podřazenosti, přičemž u podřazené je zobrazena pouze položka nadřazená. Toto by mělo být znázorněno graficky v této aplikaci tak, aby uživatelé dostali rychlý přehled o daném hierarchickém uspořádání atributů.
Obr. 4 Znázornění zobrazení vztahu nadřízenosti a podřízenosti
5.3.
Rámcový počet záznamů v aplikaci
Zadavatel má nyní celkový počet 2500 interních uživatelů s přiřazenými publikačními atributy což bude odpovídat celkové velikosti tabulky poskytující informace uživatelům.
Vyhledání záznamu
5.3.1.
Vyhledávání jednotlivých záznamů musí být řešeno v režimu fulltextového.
5.4.
Use Cases – případy použití
Aplikace slouží výhradně k rychlému přehledu o publikačních atributech zaměstnanců, hierarchickému uspořádání atributů a společnosti a ke zjištění evidovaných informací k dané osobě. Systém je téměř výhradně bezobslužný, tak aby nezatěžoval správce nastavením replik a jinými režijními požadavky.
5.5.
Role
Uživatel/Návštěvník – tato role zastupuje běžného uživatele, který má práva pouze k nahlížení do dat a k zobrazení detailu záznamu Správce obsahu (Disponent) – tato role zastupuje běžného uživatele, který má práva do aplikace k nahlížení dat a může provádět odepření možnosti replikace do extranetové části webu (respektive odepřít možnost Pull repliky integrační platformy). Správce musí mít možnost výběru a změny atributů k zobrazení. Administrátor – osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
5.6.
Číselníky a správa
Aplikace obsahuje pouze jediný číselník s těmito metadaty pro jednotlivé záznamy, číselník může upravovat pouze integrační platforma v rámci své funkce replikace ze systému TARGET. Číslo OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) Krátký název (string) Podrobný název (string) Zkratka (string) Textový popis (string) 61
Mobilní telefon (integer) Telefon – Pevná linka (integer) Email (string) Nadřazená položka (string) Vlastník (string)
5.7.
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k CSV souboru a to v pravidelném intervalu s touto strukturou zdrojové tabulky Číslo OJ (string) Název OJ (string) Krátký název (string) Podrobný název (string) Zkratka (string) Textový popis (string) Mobilní telefon (integer) Telefon – Pevná linka (integer) Email (string) Nadřazená položka (string) Vlastník (string) K této tabulce bude zajištěn výhradní přístup, tak aby bylo možno čerpat data pro importy integrační platformy.
5.8.
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 2500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
5.9.
Vstupní interface
Vstupním interface je v tomto případě integrační platforma, kterou dodavatel musí navrhnout, aby zajistil automatické nahrávání informací do intranetové aplikace.
5.10. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty. Validace hodnot typu email bude řešena prostřednictvím prezentační vrstvy na přítomnost hodnoty „@“
5.11. Migrace dat Migrace dat v tomto případě nebude prováděna, jelikož data budou importována nově v plném rozsahu.
5.12. Workflow Není aplikováno
5.13. Logování a auditování -
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů
62
o
o
Hledání Soupis
Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání Využití úložiště Počet webů
5.14. Časově plánované úlohy Vše bude řešeno na úrovni integrační platformy pro přenos dat ze systému TARGET asynchronně, a proto zadavatel požaduje, aby interval přenosu nezatěžoval celé řešení, ale doba byla co nejkratší maximálně však 1 hodina.
5.15. Reporting Není aplikováno
63
6.
INT-007 - Aplikace Správa povolenek
6.1.
Popis
Aplikace Správa povolenek poskytuje uživatelům možnosti pro vystavení povolenky k lovu zvěře v rámci jednotlivých OJ. Dále pak tato aplikace slouží k evidenci a zobrazení plánu lovů v rámci jednotlivých OJ a také k informovanosti o provedeném lovu v rámci osoby s vystavenou povolenkou lovu. Aplikace umožňuje evidovat seznamy ulovené zvěře na jednotlivých OJ a lovných místech. Aplikace musí umožnit po vystavení povolenky její následný tisk na tiskárnu uživatele a do formátu PDF.
6.2.
Vlastnosti
Tato aplikace musí umožnit evidenci nejméně na těchto úrovních: -
Evidence povolenek k lovu Evidence lovných míst Evidence osob s povolením k lovu Evidence povolených limitů zvěře
Dále pak tato aplikace musí umožňovat kontroly stavů na úrovni OJ a na úrovni jedinečné osoby s vystavenou povolenkou k lovu, kdy vystavená povolenka nesmí být nikdy smazána ze systému, vždy je pouze skryta a to z důvodu nutnosti udržení historie u každé osoby s povolenkou k lovu. Aplikace musí umožnit hromadný přesun všech povolenek z jednoho roku do roku nového (hromadná změna „Ročník lovu“)
6.2.1.
Vyhledání záznamu
Filtrování jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Na úrovni Evidence povolenek k lovu o Název OJ o Lovné místo o Ročník lovu
Dále již na úrovni aplikace nebude filtrováno, pouze budou sestavována data v rámci reportů (viz popis v Reportech tohoto dokumentu)
6.3.
Use Cases – případy použití
Aplikace slouží výhradně k evidenci vystavených povolenek a také k evidenci stavů zvěře v lovných místech. Měla by umožnit uživatelům tisk povolenek a správcům OJ předat ucelený přehled o stavech jednotlivých míst, lovech, lovcích, atd.
6.4.
Role
Uživatel/Návštěvník - tato role zastupuje běžného uživatele, který má práva pouze k nahlížení do dat a k zobrazení detailu záznamu Klíčový uživatel OJ – tato role zastupuje běžného uživatele, který má práva k nahlížení do záznamů mateřské OJ, dále pak úpravu těchto záznamů v rámci OJ a přidání záznamu o provedeném lovu a počtu zvěře Správce OJ (Disponent) – tato role zastupuje běžného uživatele, který má práva k nahlížení nad všemi záznamy OJ, možnost úpravy všech záznamů v OJ a přidávání záznamů o provedeném lovu do všech OJ, tento uživatel má práva smazat záznam, který nesmí být z databáze smazán, ale všem musí být skryt kromě Administrátora Administrator – osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
64
6.5.
Číselníky a správa
Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu OJ a Administrátor -
-
-
-
-
Evidence povolenek k lovu o ID vystavené povolenky (string) o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) Název (string) Číslo OJ (integer) o Lovné místo (vnořený číselník „Evidence lovných míst“) o Informace k povolence (vnořený číselník „Evidence informací k povolence“) o ID Loveckého lístku (vnořený číselník Evidence osob s povolením k lovu) o Jméno (načteno dle ID Loveckého lístku) o Příjmení (načteno dle ID Loveckého lístku) o Adresa (načteno dle ID Loveckého lístku) o Datum zřízení (datetime) o Datum ukončení (datetime) o Vystavitel (string) Evidence stavu zvěře o Lovné místo (vnořený číselník „Evidence lovných míst“) o Ročník lovu (string) o Datum zjištění (datetime) o Druh (vnořený číselník „Evidence druhů zvěře“) o Pohlaví (vnořený číselník „Evidence pohlaví“) o Počet (integer) 1. číselník - Evidence lovných míst o Název (string) 2. číselník - Evidence osob s povolením k lovu o ID (integer) o Jméno (string) o Příjmení (string) o Adresa (string) o Stav (boolean) 3. číselník - Evidence povolených limitů zvěře o Název (vnořený číselník „Evidence druhů zvěře“) o Povolené minimum (integer) o Povolené maximum (integer) o Velikost – malé/velké (boolean) o Ohroženost (integer) 4. číselník – Evidence informací k povolence o Název (string) 5. číselník – Evidence druhů zvěře o Název (string) 6. číselník – Evidence pohlaví o Název (string)
Pokud bude vyžadován další číselník v návrhu aplikace, jeho správa musí být umožněna pouze Správci OJ nebo Administrátorovi. Z důvodu eliminace chyby Klíčového uživatele OJ při zadání nové položky preferujeme použití více číselníků, pokud bude tato možnost dávat smysl u některé z evidenčních položek nebo sestav reportů.
6.6.
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky -
Evidence povolenek k lovu o ID vystavené povolenky (string) o Název OJ (string) o Lovné místo (string) o Informace k povolence (string) o ID Loveckého lístku (integer) o Jméno (string) 65
-
6.7.
o Příjmení (string) o Adresa (string) o Datum zřízení (datetime) o Datum ukončení (datetime) o Vystavitel (string) Evidence stavu zvěře o Lovné místo (String) o Ročník lovu (string) o Datum zjištění (datetime) o Druh (string) o Pohlaví (string) o Počet (integer)
SLA
Rámcovým počtem vystavených povolenek v rámci roku může být až 5000, ale zde musí být zachována historie záznamů, takže je předpokládaný počet 25 000 za 5 let, přičemž aktuální data, která budou do systému nahrána v rámci migrace, již obsahují cca 5000 záznamů. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
6.8.
Vstupní interface
Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat jednotlivé položky ručně a poté bude provádět tisky povolenek, stavů a dalších informací (viz. část reporting)
6.9.
Validace dat
Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
6.10. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
6.11. Workflow Není aplikováno
6.12. Logování a auditování -
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy
66
o
Soupis
Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání Využití úložiště Počet webů
6.13. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
6.14. Reporting Zadavatel požaduje, aby aplikace umožňovala vytváření sestav dostupných pro všechny definované role bez možnosti úpravy záznamů v těchto sestavách, ale s umožněným tiskem na obrazovku (v rámci aplikace), na tiskárny nebo do formátu PDF. Sestavy musí minimálně umožňovat: -
Tisk sestavy s evidencí součtů míst lovu Tisk sestavy s evidencí osob s povolením k lovu Tisk sestavy s evidencí druhů zvěře Tisk sestavy s evidencí vystavených povolenek k lovu Tisk sestavy ulovené zvěře v určitém období
Sestavy musí obsahovat maximální množství informací, které jsou v jednotlivých evidencích dostupné, přičemž dodavatel navrhne, jak budou tyto sestavy vypadat, jelikož zadavatel nemá přesně stanovené formáty těchto sestav. Zadavatel však požaduje, aby bylo možno při sestavování reportu definovat, jaké položky chce, aby byly v reportu zobrazeny a aby mohl dle všech hodnot v číselníku filtrovat.
67
INT-008 - Aplikace Evidence porostů napadených škůdci
7.
7.1.
Popis
Aplikace evidence porostů napadených škůdci musí umožnit uživatelům evidovat v rámci OJ prostor, který byl zamořen škůdci a to jako odhadovaný dopad a dopad skutečný. Tato aplikace slouží primárně pro uživatele, jež zodpovídají za OJ a musí v rámci aplikace být schopni provést generování reportu do formátu CSV nebo XLSX s definovanými hodnotami, přidat a upravit záznamy.
7.2.
Vlastnosti
Aplikace musí Klíčovému uživateli OJ a Správci obsahu OJ umožnit: -
Zadání záznamu pro danou OJ Editaci záznamu pro danou OJ Prohlížení předchozího stavu záznamu Odhad dopadu nákazy v rámci OJ Skutečné zaznamenání dopadu nákazy v rámci OJ Samostatné přihlášení s ověřením pomocí LDAP databáze bez využití Singl-Sign-On
7.2.1.
Rámcový počet záznamů v aplikaci
Rámcový počet záznamů v aplikaci je odhadován na cca 1000 záznamů.
7.2.2.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
7.3.
Název OJ Verze záznamu
Use Cases – případy použití
Aplikace slouží k evidenci možných dopadů v rámci napadení prostoru škůdci a zanesení skutečné informace o dopadu.
7.4.
Role
Klíčový uživatel OJ - tato role zastupuje běžného uživatele, který má práva do aplikace v režimu založení záznamu, editace záznamu. Tento uživatel je vždy přiřazen k OJ a při vstupu do aplikace musí být požádán o zadání jména a hesla (stejného z LDAP databáze) to znamená, že v této části aplikace nebude zapnuto SinglSign-on a o zadání jména a hesla bude požádán každý uživatel při vstupu do aplikace. V rámci této role musí být možno přiřadit uživatele do více OJ a uživatel tak, musí mít možnost v aplikaci vybrat, pro kterou OJ zadává, upravuje záznamy, a které záznamy v tomto případě může vidět Správce obsahu OJ (Disponent) - tato role zastupuje běžného uživatele, který má práva do aplikace k nahlížení dat, úpravě dat a tyto změny může provádět nad všemi OJ v rámci dané aplikace Administrátor - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
7.5.
68
7.6.
Číselníky a správa
Aplikace by měla být pouze jedinou tabulkou, které nese veškeré informace, ale v rámci daného aplikačního řešení je možné provést rozdělení na více číselníků. -
-
7.7.
Evidence prostorů napadených škůdci o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Zamořený jehličnatý prostor (integer) o Zamořený listnatý prostor (integer) o Celkový napadený prostor (výpočet) o Ošetřeno (integer) o Zlikvidováno (integer) o Informace o prostoru napadeném škůdci (string) o Zapsal (načteno z LDAP databáze) o Datum změny (datetime) Evidence zůstatkových prostor o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Celkový prostor (integer) o Celkový napadený prostor (načteno z Evidence prostorů napadených škůdci)
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k CSV souboru a to v pravidelném intervalu s touto strukturou zdrojové tabulky -
7.8.
Název OJ (string) Zamořený jehličnatý prostor (integer) Zamořený listnatý prostor (integer) Celkový napadený prostor (výpočet) Ošetřeno (integer) Zlikvidováno (integer) Informace o prostoru napadeném škůdci (string) Zapsal (string) Datum změny (datetime) Celkový prostor (integer)
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 2500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
7.9.
Vstupní interface
Vstupním interface bude vždy formulář, který bude vyplňován primárně rolí Klíčový uživatel OJ a Správce obsahu OJ.
7.10. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
7.11. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
7.12. Workflow Není aplikováno 69
7.13. Logování a auditování -
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
7.14. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
7.15. Reporting Není aplikováno
70
8.
INT-009 - Aplikace Inspekce
8.1.
Popis
Aplikace Inspekce slouží primárně k vnitrofiremním inspekcím na úrovni OJ. Tyto inspekce jsou prováděny v pravidelných intervalech a zajišťují podpůrnou část procesu quality management na úrovni LČR. V této aplikace nesmí nikdy dojít ke smazání, ale pouze k označení dané položky jako neviditelné pro Správce obsahu OJ.
8.2.
Vlastnosti
Tato aplikace musí umožnit evidenci nejméně na těchto úrovních: -
Evidence hodnot získaných v rámci inspekce Export dat do formátu PDF (export záznamu o inspekci) Možnost skrýt položky pro Správce obsahu OJ Možnost udržení evidence změn nad jednotlivými záznamy s možností označení verze hlavní
8.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů (popřípadě je možno realizovat filtrováním na těchto úrovních): -
8.3.
Název OJ Kategorie inspekce Název inspekce Rok prováděné inspekce Vyhledávání v příloze na úrovni obsahu Vyhledávání v obsahu záznamu pomocí klíčového slova
Use Cases – případy použití
Aplikace bude sloužit inspektorům (Správcům obsahu OJ), při provádění inspekce, kdy uživatel v roli Správce obsahu OJ (Disponent) provede po provedení inspekce záznam s výsledkem a hodnocením provedené inspekce. Každý provedený záznam musí být vytvořen jako koncept dokud nebude Správcem obsahu OJ označen jako hlavní a poté uzavřen. Pokud dojde k znovu otevření Administrátorem, tak nesmí dojít ke ztrátě předchozích verzí. Záznam bude v tomto případě otevřen ve formátu koncept, který může Správce obsahu OJ nebo administrátor označit jako hlavní a poté jej uzavřít jako dokončený.
8.4.
Role
Správce obsahu OJ (Disponent) – tato role zastupuje uživatele, který má práva k vytváření a modifikaci záznamů vytvořených v tabulce. Tento uživatel může záznamy smazat, ale ty budou pro danou roly pouze skryty, jelikož záznamy v této tabulce nebudou nikdy smazány trvale. Správce OJ je primárně podřízen níže uvedenému workflow. Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace. Tato osoba může také vidět všechny záznamy, jež byly označeny Správcem obsahu OJ za smazané. Dále je zodpovědný za správu obsahu číselníků „Typ inspekce, Druh inspekce, Kategorie inspekce“.
8.5.
Číselníky a správa
Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu OJ (až do označení jako Dokončeno) a Administrátor -
Evidence stavu provedené inspekce o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Název inspekce (automaticky generované dle posledního čísla ve jmenné konvenci XXXYYZZZ, kde XXX slouží pro kód OJ, YY pro poslední 2 čísla roku a ZZZ je automatické číslo generované systémem. (integer) o Kategorie inspekce (string) o Rok provádění inspekce (integer) 71
-
8.6.
o Typ inspekce (string) o Druh inspekce (string) o Disponent (načteno z LDAP databáze) o Vlastník (načteno z LDAP databáze) o Uživatelé (načteno z LDAP databáze) o Začátek inspekce (datetime) o Konec inspekce (string) o Délka trvání (integer) o Datum vytvoření (datetime) o Vytvořil (načteno z LDAP databáze) o Datum změny (datetime) o Změnil (načteno z LDAP databáze) o Datum Dokončení (datetime) o Dokončil (načteno z LDAP databáze) Typ inspekce (enumerator hodnot „interní“, „externí“) Druh inspekce (enumerator hodnot „Ano“, „Ne“) Kategorie inspekce (číselník umožňující zavedení n- záznamů administrátorem)
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky -
8.7.
Evidence stavu provedené inspekce o Název OJ (string) o Název inspekce (integer) o Kategorie inspekce (string) o Rok provádění inspekce (integer) o Typ inspekce (string) o Druh inspekce (string) o Disponent (String) o Vlastník (String) o Uživatelé (String) o Začátek inspekce (datetime) o Konec inspekce (string) o Délka trvání (integer) o Datum vytvoření (datetime) o Vytvořil (String) o Datum změny (datetime) o Změnil (String) o Datum Dokončení (datetime) o Dokončil (String)
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
8.8.
Vstupní interface
Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat jednotlivé položky ručně pomocí předpřipraveného formuláře a poté bude provádět tisky provedených inspekcí, informací o inspekci a dalších informací (viz. část reporting)
8.9.
Validace dat
Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
72
8.10. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
8.11. Workflow Pracovní postup na úrovni aplikace zajistí, že Správce obsahu OJ vytvoří záznam, který může kdykoliv rámci času upravit až do chvíle kdy bude záznam označen jako „Dokončený“, pak mu tento záznam z výčtu Inspekcí zmizí a bude dostupný pouze pro uživatele v roli Administrator, která může zajistit její znovuotevření.
8.12. Logování a auditování -
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
8.13. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
8.14. Reporting Aplikace musí umožnit v rámci připravené sestavy reportu tisk jednotlivých záznamů do formátu PDF ještě před označením Dokončeno, ale až po označení, že se jedná o hlavní verzi na všech definovaných rolích. Zadavatel požaduje, aby před vlastním tiskem byl proveden náhled a to přímo v aplikaci.
73
9.
INT-010 - Aplikace Zpětná vazba
9.1.
Popis
Aplikace Zpětná vazba slouží primárně k evidenci názorů a informací z jednotlivých OJ, tyto informace jsou zadávány interními uživateli a jsou důležitým ukazatelem pro hodnocení poskytované kvality v rámci procesu Quality management.
9.2.
Vlastnosti
Aplikace musí umožnit evidenci minimálně na této úrovni -
Evidence zpětných vazeb Možnost zobrazení seznamu vždy dle aktuálně přihlášeného uživatele a vždy hlavní verzi vytvořeného záznamu Možnost exportu dat do tabulky XLS a XLSX na úrovni OJ Možnost exportu dat do tabulky XLS a XLSX na úrovni organizace Možnost exportu dat do tabulky XLS a XLSX na úrovni Vlastníka záznamu Zákaz změny záznamu po jeho vytvoření a odeslání ke zpracování Udržení předchozích verzí záznamů Evidence příloh Možnost podřízení zpětné vazby již k publikované verzi zpětné vazby
9.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
9.3.
Rok vytvoření Vlastník Klíčové slovo obsažené v daném záznamu Má k danému záznamu uživatel práva
Use Cases – případy použití
Uživatelé tuto aplikaci využívají k evidenci zpětné vazby z jednání, správních činností, činností údržby zeleně a další činnosti, které mohou souviset s činnostmi zadavatele. V rámci této aplikace je nutné zajistit, aby byly podávány Správci obsahu OJ a Klíčovým uživatelům OJ relevantní informace, tak aby na základě zpětné vazby mohla být hodnocena kvalita poskytovaných interních služeb.
9.4.
Role
Uživatel/Návštěvník – tato role reprezentuje uživatele, která má práva ke čtení záznamů spadajících pod OJ, do které spadá přímo on, uživatel nesmí mít právo vidět záznamy jiné OJ, tato role má možnost exportu daného záznamu Klíčový uživatel OJ – tato role reprezentuje uživatele, který má práva ke čtení a modifikaci záznamů spadajících pod OJ jeho vlastní, pokud je členem více OJ, pak může vidět a upravovat záznamy více OJ. Tato role má právo provést export všech viditelných záznamů. Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace. Tato osoba může zobrazovat historii každého záznamu a provádět všechny činnosti rolí nižších.
74
9.5.
Číselníky a správa
Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu OJ (až do označení jako Dokončeno) a Administrátor -
9.6.
Evidence zpětných vazeb OJ o Evidenční číslo (automaticky generované dle posledního čísla ve jmenné konvenci XXXYYZZZ, kde XXX slouží pro kód OJ, YY pro poslední 2 čísla roku a ZZZ je automatické číslo pořadí záznamu) o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Rok vytvoření (integer) o Skartační znak (string) o Datum zjištění (datetime) o Název zpětné vazby (string) o Týká se (string) o Uživatel (string) o Kontakt na uživatele (string) o Zpracovává (načteno z LDAP databáze) o Zpracováno (datetime) o Popis řešení (string) o Datum vytvoření (datetime) o Vytvořil (načteno z LDAP databáze) o Datum změny (datetime) o Změnil (načteno z LDAP databáze) o Příloha
OLA
Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky o o o o o o o o o o o o o o o o
9.7.
Evidenční číslo (string) Název OJ (string) Skartační znak (string) Datum zjištění (datetime) Název zpětné vazby (string) Týká se (string) Uživatel (string) Kontakt na uživatele (string) Zpracovává (string) Zpracováno (datetime) Popis řešení (string) Datum vytvoření (datetime) Vytvořil (string) Datum změny (datetime) Změnil (string) Příloha
SLA
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
9.8.
Vstupní interface
Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat jednotlivé položky ručně pomocí předpřipraveného formuláře a poté bude provádět tisky zaznamenaných zpětných vazeb a dalších informací (viz. část reporting)
75
9.9.
Validace dat
Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
9.10. Migrace dat Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
9.11. Workflow Pracovní postup na úrovni aplikace zajistí, že Správce obsahu OJ vytvoří záznam, který může kdykoliv rámci času upravit až do chvíle kdy bude záznam označen jako „Dokončený“, pak mu tento záznam z výčtu Zpětných vazeb zmizí a bude dostupný pouze pro uživatele v roli Administrator, která může zajistit její znovuotevření.
9.12. Logování a auditování -
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
9.13. Časově plánované úlohy Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
9.14. Reporting Aplikace musí umožnit v rámci připravené sestavy reportu tisk jednotlivých záznamů do formátu PDF ještě před označením Dokončeno, ale až po označení, že se jedná o hlavní verzi na všech definovaných rolích. Zadavatel požaduje, aby před vlastním tiskem byl proveden náhled a to přímo v aplikaci. Dále musí aplikace umožnit exporty do formátu XLS a XLSX ve všech režimech definovaných v kapitole Vlastnosti a s oprávněním definovaným v kapitole Role.
76
10.
INT-011 - Aplikace Evidence zalesňování ploch
10.1. Popis Aplikace evidence zalesňování ploch musí umožnit uživatelům evidovat v rámci OJ prostor, který bude v průběhu času zalesňován a to jako odhadovaný plán zalesnění a skutečné zalesnění. Tato aplikace slouží primárně pro uživatele, jež zodpovídají za OJ a musí v rámci aplikace být schopni provést generování reportu do formátu CSV nebo XLSX s definovanými hodnotami, přidat a upravit záznamy.
10.2. Vlastnosti Aplikace musí Klíčovému uživateli OJ a Správci obsahu OJ umožnit: -
Zadání záznamu pro danou OJ Editaci záznamu pro danou OJ Prohlížení předchozího stavu záznamu Odhad pro zalesnění v rámci OJ Skutečné zaznamenání zalesnění na úrovni OJ a to online při zalesňování
10.2.1.
Rámcový počet záznamů v aplikaci
Rámcový počet záznamů v aplikaci je odhadován na cca 1000 záznamů.
10.2.2.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Název OJ Verze záznamu
10.3. Use Cases – případy použití Aplikace slouží k získání přehledu nad zalesněnými plochami zadavatele a plánu jejich zalesňování. Správce obsahu OJ provádí pravidelné záznamy o plánovaných činnostech a poté provádí úpravu stejného záznamu o skutečné hodnoty. V rámci každé úpravy je provedeno vytvoření nové verze záznamu, tak aby bylo možno dohledat celou historii záznamu.
10.4. Role Klíčový uživatel OJ - tato role zastupuje běžného uživatele, který má práva do aplikace v režimu založení záznamu, editace záznamu. Tento uživatel je vždy přiřazen k předem definované OJ. V rámci této role musí být možno přiřadit uživatele do více OJ a uživatel tak, musí mít možnost v aplikaci vybrat, pro kterou OJ zadává, upravuje záznamy, a které záznamy v tomto případě může vidět Správce obsahu OJ (Disponent) - tato role zastupuje běžného uživatele, který má práva do aplikace k nahlížení dat, úpravě dat a tyto změny může provádět nad všemi OJ v rámci dané aplikace Administrátor - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
77
10.5. Číselníky a správa Aplikace by měla být pouze jedinou tabulkou, které nese veškeré informace, ale v rámci daného aplikačního řešení je možné provést rozdělení na více číselníků. -
Evidence zalesňování ploch o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Místo k zalesnění (string) o Plánováno k zalesnění (integer) o Skutečně zalesněno (integer) o Celkový prostor k zalesnění (integer) o Kontrolu provedl (string) o Datum kontroly (datetime) o Vytvořil (načteno z LDAP databáze) o Datum vytvoření (datetime) o Upravil (načteno z LDAP databáze) o Datum upravení (datetime)
10.6. OLA Zadavatel zajistí prostřednictvím integrační vrstvy přístup k CSV souboru a to v pravidelném intervalu s touto strukturou zdrojové tabulky -
Název OJ (string) Místo k zalesnění (string) Plánováno k zalesnění (integer) Skutečně zalesněno (integer) Celkový prostor k zalesnění (integer) Kontrolu provedl (string) Datum kontroly (datetime) Vytvořil (načteno z LDAP databáze) Datum vytvoření (datetime) Upravil (načteno z LDAP databáze) Datum upravení (datetime)
10.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 2500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
10.8. Vstupní interface Vstupním interface bude vždy formulář, který bude vyplňován primárně rolí Klíčový uživatel OJ a Správce obsahu OJ.
10.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
10.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
10.11.
Workflow
Není aplikováno
78
10.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
10.13.
Časově plánované úlohy
Zadavatel požaduje, aby byly do aplikace přenášeny informace o uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
10.14.
Reporting
Zadavatel požaduje, aby v rámci reportů a sestav bylo možné sledovat, jak probíhá zalesňování na území spravovaném zadavatelem, dále pak kolik bylo zalesněno prostor, jak probíhali kontroly a jestli je plněn plán zalesňování a to vše na úrovni globální (všech OJ zadavatele) tak i na úrovni jednotlivých OJ. Tyto sestavy musí být možno tisknout do formátu PDF a vykreslit přímo v aplikaci.
79
11.
INT-012 – Pomůcky a předměty
11.1. Popis Aplikace Pomůcky a předměty umožňuje evidovat a objednávat z katalogu předmětů, které budou členěné do minimálně padesáti kategorií. Objednávání těchto předmětů bude probíhat organizační jednotkou, přičemž je stanoven předem maximální počet možných objednaných předmětů z každé kategorie pro každou organizační jednotku – jinými slovy každá organizační jednotka má stanoven maximální počet přepočtem ceny předmětů ve formě kreditu a maximálním množstvím přidělených kreditů pro OJ. Maximální počet při objednání schvaluje definovaný klíčový uživatel z OJ. S každým objednáním předmětu se ihned aktualizuje počet zbývajících dostupných předmětů (množství). Kredity jsou přidělovány manuálně Správcem OJ nebo Administrátorem. Předměty jsou zadávány do jednotlivých kategorií na základě následujících atributů: -
Miniatura fotografie Název Popis Množství jednotek na skladě Limit pro uživatele
V rámci této aplikace je dále dostupný reporting: -
Statistika objednávek za jednotlivé zákazníky za určité období, přičemž uživatelem je vedoucí organizační jednotky, nebo zástupce lesní pedagogiky na každé organizační jednotce. Report stavu skladu – tedy množství naskladněných položek, které byly objednány organizačními jednotkami Report zbývajících kreditů organizačních jednotek
11.2. Vlastnosti Aplikace je tvořena seznamem všech předmětů v rámci jednotlivých kategorií, který je možné libovolně procházet a kde jsou zobrazeny základní vlastnosti každého předmětu v kategorii, jako je jeho fotografie, název, popis, množství jednotek na skladě a limit pro uživatele, který je rozpoznán na základě přihlášeného uživatele. Každý předmět je brán a evidován jako jedna položka seznamu, kterou je možné separátně editovat a nastavit jí potřebné vlastnosti, ovšem jen vybranými osobami, které k tomu mají oprávnění. Tento seznam slouží jako skladová evidence jednotlivých marketingových předmětů. Pro objednávání je definován formulářový prvek, který je napojen na tento seznam a je tak možné vybírat jednotlivé položky a přidávat je do finálního seznamu pro objednání s výběrem počtu kusů každého předmětů. Po odeslání objednávky a jejím schválení je aktualizováno množství jednotlivých předmětů, zbývajících na skladě. Povolená množství a nastavení kreditů pro jednotlivé organizační jednotky je prováděno na separátním seznamu, který slouží jako konfigurační místo a je přístupné pouze schvalovatelům a zadavatelům těchto omezení. Na pozadí je využíván pracovní postup, který zajišťuje potřebné odeslání požadavků na schválení nákupu a který zároveň zajišťuje postup procesem objednání objednávky, notifikačních emailů a aktualizaci jednotlivých polí v rámci každého předmětu. Samostatný modul určený pro Správce OJ řeší analytické sestavy s přehledy pohybů předmětů. Sestavy jsou v samostatné sekci přístupné prostřednictvím odkazů v listu nebo seznamu samotném. Aplikace musí umožnit minimálně tyto funkce a vlastnosti: -
Schválení nákupu Klíčovým uživatelem OJ Nastavení kreditního systému s manuálním přičtením kreditů na OJ a uživatele Zamezení nákupu při nedostatečném kreditu Odepření nákupu při nedostatečném množství předmětů skladem Manuální doplnění zásob a kreditů Správcem obsahu OJ Evidence seznamu marketingových položek společně s náhledem Možnost exportu do CSV, XLS nebo XLSX
80
11.3. Vyhledání záznamu Vyhledání předmětů v nabídce bude řešeno fulltextově Vyhledávání záznamů o provedených operacích s předměty z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Název OJ Stav Zadavatel Datum od Datum do
11.4. Use Cases – případy použití Aplikace slouží k objednávání předmětů uživateli. Uživatel po vstupu do aplikace přejde na přehled se seznamem předmětů, variantně může zvolit preferovanou kategorii předmětů, vybere předmět z nabídky, zvolí množství předmětů z různých kategorií a sestaví si tak svůj vlastní objednávkový list. Při odeslání objednávky proběhne kontrola na stav a čerpání kreditů a v případě, že nemá uživatel dostatečný počet disponibilních kreditů, je na to ihned upozorněn a nemůže pokračovat v objednávce. Pokud objednávka splňuje všechny podmínky, tak dojde k odeslání objednávky, nejprve ke schválení a následně do skladu předmětů, kde jsou tyto předměty vybrány. Automaticky se aktualizuje množství objednatelných předmětů z výběrového katalogového listu. Uživatel je upozorněn notifikačním emailem o stavu své objednávky, a pokud je připravena k vyzvednutí, může si ji vyzvednout na odběrovém místě. Správce aplikace může vstoupit do aplikace a modifikovat jednotlivé předměty v rámci katalogu. Je mu umožněno přidávat nové předměty, mazat předměty i editovat vlastnosti jednotlivých, již existujících předmětů. Správce také může zobrazovat jednotlivé reporty, pro zlepšení přehledu stavu celého skladu a objednávek. Správce také může nastavovat limity jednotlivých uživatelů, případně oddělení na konkrétní předměty z konkrétních kategorií. Možnosti správy rolí Administrátor přímo z aplikace musí umožnit nastavení relačních odkazů (díky předem definovaným proměnným v systému) a to tak aby mohl specifikovat obsah zaslaných emailů a definici intervalů pro odbavení objednávek a to dle těchto kritérií nebo funkcí aplikace: -
Vytvoření nového účtu Změna bodů v účtu Zakázání účtu v systému Povolení účtu v systému Vytvoření nové objednávky Přijetí objednávky Zamítnutí objednávky Dokončení zpracování objednávky Odmítnutí objednávky Přidání uživatelského účtu Odebrání uživatelského účtu Objednávka čeká na potvrzení Objednávka čeká na vyřízení Objednávka čeká na převzetí Interval výzvy k objednávce Interval pro zrušení objednávky
11.5. Role Uživatel/Návštěvník – reprezentant koncového uživatele, který po zadání požadovaných vstupních parametrů nahlíží do databáze marketingových předmětů, vybírá z nich a případně je objednává. Tato role nemá žádné požadavky na omezený přístup a je tedy předvolena všem uživatelům portálového řešení. Klíčový uživatel OJ – reprezentant koncového uživatele, který provádí schválení na úrovni OJ, pokud jsou předměty vybrány Uživatelem/Návštěvníkem, popřípadě může za dané OJ předměty objednávat. Tato role je nadřízenou rolí v kolečku schvalování pro uživatele a její zadání již nejsou dále schvalována.
81
Správce obsahu OJ (Disponent) – reprezentant osoby, odpovědné za přidávání, modifikaci, nebo mazání předmětů v katalogu a za aktualizaci listu omezení. Správce obsahu OJ musí být schopen provést výčet všech reportů na úrovni celé aplikace, tak aby mohl dohlížet nad nákupy jednotlivých OJ. Administrator – osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
11.6. Číselníky a správa Kategorie zboží Uživatelé s možností správy přidělených bodů pro nákup. Všechny bodové transakce musí být v systému evidovány včetně přírůstků bodů a jednotlivých nákupů. -
-
-
Katalog marketingových předmětů o Miniatura fotografie (binární soubor obrázkového typu jpg, jpeg, png apod.) o Zadavatel (načteno z LDAP) o Název položky (string) o Popis položky (popis položky) o Množství na skladě (integer) o Limit uživatele (integer) o Skupina produktů (výběrová hodnota z číselníku Skupiny produktů) Objednávka o Evidenční číslo objednávky (integer) automaticky generováno o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Objednatel (načteno z LDAP databáze) o Stav objednávky (boolean) o Datum vytvoření (datetime) o Možnost částečného vyřízení (boolean) bude vybráno za předpokladu, že je možno provést vyskladnění položek, které jsou na skladě a objednávku nechat otevřenu dokud nebudou položky s nedostatečným stavem naskladněny Správcem obsahu OJ o Celková cena (money) Bude vypočítána z ceny jednotlivých položek a násobku počtu položek o Název položky (načteno z Katalogu marketingových předmětů) o Jednotková cena (načteno z Katalogu marketingových předmětů) o Počet (integer) automaticky při schválení kontrolováno zda je dané množství skladem automaticky po schválení se odečte množství z aktuálního stavu o Počet na skladě (načteno z Katalogu marketingových předmětů) o Celková cena položky (integer) Výpočtové pole kdy cena za kus je násobena počtem položek Číselník skupin produktů o Evidenční číslo (integer) o Název skupiny (string) o Popis (string) o Aktivita (boolean)
82
11.7. OLA Zadavatel zajistí prostřednictvím integrační vrstvy přístup k CSV souboru a to v pravidelném intervalu s touto strukturou zdrojové tabulky - Katalog marketingových předmětů: o o o o o
Miniatura fotografie (string) Zadavatel (string) Název položky (string) Popis položky (string) Množství na skladě (string)
Objednávky nebudou přenášeny, pokud budou v počtu méně jak 10požadavků k vyřízení. Pokud bude objednávek více, pak budou předány vstupní data dle specifikovaného číselníku ve formátu CSV.
11.8. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 2500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
11.9. Vstupní interface Vstupním interface bude vždy formulář, který bude vyplňován rolí Uživatel/Návštěvník, Klíčový uživatel OJ nebo Správce obsahu OJ. Specifikace daného formuláře je níže v části číselník pod pojmem „Objednávka“
11.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
11.11.
Workflow
Aplikace musí umožnit pracovní postup v rámci, kterého dojde ke schvalování objednávky a to vždy mezi Uživatelem a Klíčovým uživatelem OJ, popřípadě s možností schválení objednávky Správcem OJ s automatickou notifikací při změně stavu tak jak je definováno níže v části Notifikace.
11.12. -
Logování dat
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
83
11.13.
Časově plánované úlohy
Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
11.14.
Reporting
Zadavatel požaduje, aby byly v rámci aplikace nastaveny minimálně tyto přehledové sestavy, které umožní snadný a rychlí přehled nad celým řešením aplikace. -
Report za uživatele a jeho objednávky vyřízené a nevyřízené Report za OJ a jejich objednávky vyřízené a nevyřízené Aktuální skladové zásoby Přehled objednávky (zobrazení detailu s možností úpravy)
11.14.1.
Notifikace
Notifikace musí probíhat následujícím způsobem 1) Uživatel, který provede odeslání objednávky, bude notifikován potvrzením odeslání objednávky 2) Následně bude notifikován Klíčový uživatel OJ, který může provést schválení objednávky 3) Pokud dojde k zadání objednávky Klíčovým uživatelem, pak bude notifikován Správce obsahu OJ, který provede odbavení objednávky 4) Pokud dojde při vytvoření objednávky k nedostupnosti některého zboží, bude automaticky notifikován Správce obsahu OJ s informací o nedostatečném množství skladových zásob 5) Při vyřízení objednávky (změna stavu objednávky) bude vždy notifikován zadavatel objednávky 6) Uživatelům při události změny kreditu (úbytek/přičtení) 7) Pozitivní vyřízení objednávky „Výzva k vyzvednutí objednávky“ 8) Zamítnutí vyřízení objednávky
84
12.
INT-013 - Aplikace Vyhledávač typů aktiv společnosti
12.1. Popis Aplikace Vyhledávač typů aktiv společnosti slouží pro účely vyhledávání kódů aktiv z číselníku standardů jako například CZ-CC, SKP, ČSN. OKEČ a dalších podle potřeb zadavatele. Zadavatel bude do systému zavádět data prostřednictvím importu dat. Uživatelé mohou v těchto číselnících pouze vyhledávat, nikoliv mazat a upravovat. Aplikace musí umožňovat fulltextové vyhledávání.
12.2. Vlastnosti Aplikace musí Správci obsahu OJ umožnit: - Založení nového záznamu - Editaci záznamu - Smazání záznamu - Fulltextové vyhledávání v záznamech - Přístup všech uživatelů zadavatele - Možnost importu z CSV souboru
12.2.1.
Rámcový počet záznamů v aplikaci
Rámcový počet záznamů v aplikaci je odhadován na cca 500 000 záznamů.
12.2.2.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Vyhledávání dle inventárního čísla Fulltextové vyhledávání
12.3. Use Cases – případy použití Uživatel zadá do vyhledávacího pole libovolnou hodnotu a prostřednictvím tlačítka „najít“ spustí vyhledávání v číselníku. Po vyhledání se uživateli zobrazí seznam nalezených položek a jejich evidenčních kódů. Správce obsahu bude aktualizovat data s režimem „Smazat data zdrojového číselníku“, „import data zdrojového číselníku“
12.4. Role Uživatel/Návštěvník – tuto roli reprezentuje uživatel, který je návštěvníkem intranetového řešení zadavatele, uživatel má práva pouze vyhledávat a číst a nesmí žádné záznamy vytvářet, upravovat ani smazat. Správce obsahu OJ (Disponent) – tato role reprezentuje uživatele, který má práva k vytváření, změnám a mazání záznamů z databáze. Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace. Toto osoba má také práva k importu dat z CSV souboru.
12.5. Číselníky a správa Aplikace by měla být pouze jedinou tabulkou, které nese veškeré informace, ale v rámci daného aplikačního řešení je možné provést rozdělení na více číselníků. -
Evidence aktiv společnosti o Evidenční číslo (integer) o Popis (string) o Zdroj číselníku (string)
12.6. OLA Zadavatel zajistí prostřednictvím integrační vrstvy přístup k CSV souboru a to v pravidelném intervalu s touto strukturou zdrojové tabulky -
Evidenční číslo (integer) Popis (string) 85
-
Zdroj číselníku
12.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 2500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
12.8. Vstupní interface Vstupním interface bude vždy formulář, který bude vyplňován primárně rolí Správce obsahu OJ (disponent) a vyhledávací formulář, který mohou využít všechny dostupné role.
12.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
12.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
12.11.
Workflow
Není aplikováno
12.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky a cíle Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
12.13.
Časově plánované úlohy
Není aplikováno
12.14.
Reporting
Není aplikováno 86
13.
INT-014 - Aplikace Registr využití techniky
13.1. Popis Aplikace Registr využití techniky udržuje informace o motorových prostředcích zadavatele a připravuje data pro plnění povinností vyplývajících z jejich vlastnění. Aplikace bude obsahovat informace převážně o technice, které podléhá zákonu o udržování cestovních příkazů a dále pak o limitech dané techniky, tak aby bylo možno efektivně plánovat její využívání na jednotlivých OJ a při správě OJ.
13.2. Vlastnosti Základní vlastnosti této aplikace jsou: -
-
zajistit ucelený seznam osobní strojní techniky zajistit ucelený seznam nákladní strojní techniky zajistit ucelený seznam manipulační techniky zajištění informace o možnostech přepravy s technikou nákladní příprava podkladů pro plnění daňových povinností pomocí exportů do formátu CSV nebo XLSX v předem definovaném formátu umožňujícím importování do účetního software „Daňová evidence“ společnosti Atlas Consulting ) převod do správného formátu importovatelného do aplikace „Daňová evidence“ bude provádět zadavatel svépomocí vlastní aplikací třetí strany umožnit evidenci počtu dní využití daných zdrojů umožnit sjednocení evidence zdrojů s denní a roční sazbou platby daňových povinností každý záznam musí být převeditelný do jiné OJ každý záznam musí obsahovat informace o kvartální daňové povinnosti každý záznam musí obsahovat informace o roční daňové povinnosti
Aplikace musí být schopna spočítat cenu daňových povinností k definované technice dle vzorce, ve kterém musí být zaznamenány veškeré aspekty a to počet náprav, váha techniky, objem, atd. Tento vzorec musí být schopen vypočítat platbu daňové povinnosti na úrovni dne, měsíce, kvartálu a roku, tyto hodnoty poté sečíst a sestavit do jednotného celku (csv, XLSX), který bude sloužit pro platbu. Vzorec pro tento výpočet musí navrhnout uchazeč a zakomponovat tak, aby byl zřejmý pouze výsledek.
13.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Vlastník Typ prostředku Registrační značka Inventární číslo Váha umožněná k převozu
13.3. Use Cases – případy použití Aplikace bude primárně sloužit vlastníků (správcům) jednotlivých vozů přiřazených k OJ. Tyto vozy s rozdílnou daňovou povinností bude možno evidovat v jediné tabulce, která bude mít společné číselníky. Tyto záznamy pak budou sloužit jako podklad pro platbu daňových povinností a to v ročním zúčtování. Technika zde evidovaná je možno mezi jednotlivými OJ přesouvat a tím přesouvat i daňovou povinnost, kterou má každá OJ samostatně. Uživatelé budou moci zvolit, ve kterých dnech v rámci měsíce využívali tuto techniku.
13.4. Role Klíčový uživatel OJ – tato role reprezentuje uživatele, který má práva k vytváření nových záznamů, změnám svých záznamů a sledování položek na úrovni své spravované OJ Správce obsahu OJ (Disponent) – tato role reprezentuje uživatele, který má práva vytvářet, modifikovat a mazat záznamy v aplikaci na úrovni všech OJ, může vytvářet sestavy a provádět exporty dat Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace
87
13.5. Číselníky a správa Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu OJ a Administrátor -
-
Typ techniky (ENUMERATOR hodnot) Evidence techniky (centrální tabulka se záznamy) o Typ techniky (Vazba na číselník Typ techniky) o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Registrační značka (string) o Inventární číslo (integer) o Vlastník (načteno z LDAP Databáze) o Váha umožněná k převozu (integer) o Váha techniky (integer) o Zdvihový prostor motoru techniky (integer) o Počet využitých dní (integer) o Hodnota aktuálního daňového nákladu (výpočtové pole z hodnot stanovených zákonem o daném výpočtu a stanoveným vzorcem uchazeče) o Informace k dané technice (string) o Datum úpravy záznamu (datetime) o Sleva při využití techniky (integer) Evidence daňové povinnosti (centrální tabulka se záznamy dostupná po zobrazení detailu dané techniky) o Inventární číslo techniky (načteno z číselníku Evidence techniky) o Typ techniky (Vazba na číselník Typ techniky) o Počet využívaných dní (integer) o Denní povinnost platby (integer) o Měsíční povinnost platby (integer) o Kvartální povinnost platby (integer) o Roční povinnost platby (integer)
13.6. OLA Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky -
Evidence techniky o Typ techniky (string) o Název OJ (string) o Registrační značka (string) o Inventární číslo (integer) o Vlastník (string) o Váha umožněná k převozu (integer) o Váha techniky (integer) o Zdvihový prostor motoru techniky (integer) o Počet využitých dní (integer) o Informace k dané technice (string) o Datum úpravy záznamu (datetime) o Sleva při využití techniky (integer)
13.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
13.8. Vstupní interface Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat prostřednictvím formuláře jednotlivé položky ručně a poté bude provádět tisky sestav, stavů a dalších informací (viz. část reporting), pokud to bude funkcionalita vyžadovat.
88
13.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
13.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
13.11.
Workflow
Není aplikováno
13.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
13.13.
Časově plánované úlohy
Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
13.14.
Reporting
Zadavatel požaduje, aby byla aplikace minimálně schopna provádět exporty a tisky sestav, ze kterých bude zřejmé využívání techniky a také je nutné při exportu zajistit, aby data byla ve formátu CSV, díky kterému může poté dojít k převodu dat do účetního software. Dále by aplikace měla umožnit zobrazit sestavu techniky, která není z pohledu evidence efektivní nebo nevyužívána (nízké úrovně zatížení ve dnech a vysoká sazba povinných plateb)
89
14.
INT-015 - Aplikace Nápravná opatření
14.1. Popis Aplikace Nápravná opatření poskytuje uživatelům přehled o provedených kontrolách externích a interních subjektů a to tak, aby bylo možno provést nápravná opatření, která z daných výstupů vznikají. Tato nápravná opatření budou řešena na úrovni organizačních jednotek zadavatele. Systém musí umožnit evidenci provedených kontrol s možností jejich nápravy a poskytovat informace o provedené kontrole a nápravném opatření. Aplikace slouží jako jeden z milníků pro hodnocené kvality v rámci udržitelnosti procesu Quality management.
14.2. Vlastnosti Aplikace musí Klíčovému uživateli OJ a Správci obsahu OJ umožnit: -
Vytvoření, změnu a smazání záznamu Evidenci historie jednotlivých změn v záznamu Přiložení přílohy ve formátu PDF Definovat velikost (počet) stránky se zobrazenými záznamy po vyhledání
14.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Název OJ Rok, ve kterém bylo realizováno Datum počátku řešení Vytvořeno dne Změněno dne Typ provedené kontroly Druh provedené kontroly Možnost definovat počet záznamů na stránku (definice stránkování)
14.3. Use Cases – případy použití Uživatelé na jednotlivých OJ budou provádět na základě provedených kontrol nápravná opatření a jejich průběh a vyjádření bude zaznamenáno ke každému záznamu v dané aplikaci. Provádění nápravných opatření bude umožněno pouze uživatelům Klíčový uživatel OJ (za svou OJ) a Správce obsahu OJ (Disponent) (za všechny OJ)
14.4. Role Klíčový uživatel OJ – tato role reprezentuje uživatele, který má práva v aplikaci záznamy prohlížet pouze na úrovni své vlastní OJ, přidávat, upravovat a mazat na úrovni své vlastní OJ, členství v této skupině může upravovat Administrator a správce obsahu OJ. Tato role může dále zobrazovat historii jednotlivých záznamů na úrovní své vlastní OJ. Správce obsahu OJ (Disponent) – tato role reprezentuje uživatele, který má práva v aplikaci záznamy prohlížet na úrovni všech OJ, přidávat, upravovat a mazat na úrovni všech OJ organizace, členství v této skupině může upravovat pouze Administrator. Tato role může dále zobrazovat historii jednotlivých záznamů na úrovni všech OJ zadavatele Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
14.5. Číselníky a správa Aplikace by měla být pouze jedinou tabulkou, které nese veškeré informace, ale v rámci daného aplikačního řešení je možné provést rozdělení na více číselníků. -
Evidence provedených kontrol o Číslo nápravného opatření (automaticky generované dle posledního čísla ve jmenné konvenci XXXZZZ, kde XXX slouží pro kód OJ a ZZZ je automatické číslo pořadí záznamu) o Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) 90
-
-
o Typ provedené kontroly (načteno z číselníku „Typ provedené kontroly“ ) o Druh provedené kontroly (enum. Interní/Externí) o Disponent řešitele (string) o Vlastník řešitele (string) o Datum počátku řešení (datetime) o Datum ukončení řešení (datetime) o Počet chyb (integer) o Popis/postup řešení (string) o Poznámka (string) o Vytvořil (načteno z LDAP databáze) o Vytvořeno dne (datetime) o Změnil (načteno z LDAP databáze) o Změněno dne (datetime) Typ provedené kontroly o Název (string) o Popis (string) Příloha (binární soubor)
14.6. OLA Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky -
-
Evidence provedených kontrol o Číslo nápravného opatření (string) o Název OJ (string) o Typ provedené kontroly string) o Druh provedené kontroly string) o Disponent řešitele (string) o Vlastník řešitele (string) o Datum počátku řešení (datetime) o Datum ukončení řešení (datetime) o Počet chyb (integer) o Popis/postup řešení (string) o Poznámka (string) o Vytvořil string) o Vytvořeno dne (datetime) o Změnil (string) o Změněno dne (datetime) Typ provedené kontroly o Název (string) o Popis (string)
14.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 1000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
14.8. Vstupní interface Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat jednotlivé položky ručně pomocí předpřipraveného formuláře a poté bude provádět tisky zaznamenaných zpětných vazeb a dalších informací (viz. část reporting)
14.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
91
14.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
14.11.
Workflow
Není aplikováno
14.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
14.13.
Časově plánované úlohy
Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
14.14.
Reporting
Není aplikováno
92
15.
INT-016 - Aplikace Registr partnerů
15.1. Popis Aplikace Registr partnerů je primárně určen Klíčovým uživatelům OJ, kteří se starají o evidenci účetních operací a nákupu položek majetku v rámci procesu Asset management a poskytují tak danou evidenci uživatelům v režimu čtení. Klíčový uživatelé OJ mohou provádět exporty do formátu CSV, XLS a XLSX a to z důvodu lepšího zpracování a datových analýz napříč všemi OJ v organizaci a na úrovni samostatných OJ. V rámci aplikace je nutné analyzovat ceny jednotlivých aktiv společnosti a informovat uživatele proč byla daná cena za pořízení aktiva vybrána.
15.2. Vlastnosti Aplikace musí Klíčovému uživateli OJ a Správci obsahu OJ umožnit: -
Evidenci jednotlivých partnerů Evidenci nabízeného zboží/služby od partnera Evidence ceny jednotek zboží Vyhodnocení ceny zboží od partnera Vyhledávání v partnerech a jejich produktech Vyhledávání na úrovni OJ Export dat do CSV, XLS nebo XLSX
15.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Název OJ Název partnera Datum vytvoření Evidenční číslo aktiva partnera Popis (fulltextové vyhledávání)
15.3. Use Cases – případy použití Uživatelé budou moci nahlížet do položek, které zadavatel zakoupil od svých partnerů a za jaké ceny Klíčový uživatelé OJ budou moci zadávat nové partnery a nabízené položky aktiv, jejich nabízenou cenu za položky aktiv a také budou moci provádět exporty do CSV, XLS nebo XLSX na úrovni svých spravovaných OJ. Správce obsahu OJ bude moci zadávat nové partnery a nabízené položky aktiv, jejich nabízenou cenu za položky aktiv a také bude moci provádět exporty do CSV, XLS nebo XLSX na úrovni všech OJ.
15.4. Role Uživatel/Návštěvník – tato role zastupuje uživatele, který má práva ke čtení na úrovni dané aplikace a to jak položek v seznamech tak i pro zobrazení detailu položky. Klíčový uživatel OJ – tato osoba zastupuje uživatele, který má práva ke čtení, změnám a mazání záznamů na úrovni vlastní OJ. Dále může na této úrovni provádět export záznamů z dané OJ a to do formátu CSV, XLS nebo XLSX. Správce obsahu OJ (Disponent) – tato osoba zastupuje uživatele, který má práva ke čtení, změnám a mazání záznamů na úrovni všech OJ. Dále může na této úrovni provádět export záznamů z dané OJ a to do formátu CSV, XLS nebo XLSX. Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
15.5. Číselníky a správa Aplikace by měla být pouze jedinou tabulkou, které nese veškeré informace, ale v rámci daného aplikačního řešení je možné provést rozdělení na více číselníků. -
Evidence partnerů o Název partnera (string) 93
o o o o o o o o
-
Adresa partnera (string) ICO partnera (integer) Celková cena (integer) Předpokládaný termín dodání (datetime) Termín dodání (datetime) Termín dodání faktury (datetime) Místo doručení (string) Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) o Změnil (načteno z LDAP databáze) o Změněno dne (datetime) o Území (načteno z aplikace „Přehled územní evidence“) Jméno katastrálního celku Evidenční číslo katastru Druhé Evidenční číslo katastru o Evidenční číslo položky aktiva partnera (string) o Typ zakázky (načteno z „Číselník typu zakázky“) Název o Hrazeno (načteno z „Číselník způsobu hrazení“) Název o Datum vytvoření (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Datum podání (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Název aktiva partnera (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Poznámka 1 (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Poznámka 2 (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Poznámka 3 (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Poznámka 4 (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Poznámka 5 (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Datum přijetí (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Počet nabízených položek (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Cena za nabízené položky (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Nejvyšší cena položky (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Průměrná cena položky (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) o Nejnižší cena položky (načteno z číselníku „Evidence aktiv“ na základě zadání hodnoty Evidenční číslo aktiva) Evidence aktiv položek partnerů o Evidenční číslo položky aktiva partnera (string) o Datum vytvoření (datetime) o Datum podání (datetime) o Název položky aktiva partnera (string) o Poznámka 1 (string) o Poznámka 2 (string) o Poznámka 3 (string) o Poznámka 4 (string) o Poznámka 5 (string) o Datum přijetí (datetime) o Počet nabízených položek (integer) o Cena za nabízené položky (integer) o Nejvyšší cena položky (integer) 94
-
-
o Průměrná cena položky (integer) o Nejnižší cena položky (integer) Číselník typu zakázky o Název (string) o Poznámka (string) o Platné (boolean) Číselník způsobu hrazení o Název (string) o Poznámka (string) o Platné (boolean)
15.6. OLA Zadavatel zajistí prostřednictvím integrační vrstvy přístup k databázi s touto strukturou zdrojové tabulky -
-
-
-
Evidence partnerů o Název partnera (string) o Adresa partnera (string) o ICO partnera (integer) o Celková cena (integer) o Předpokládaný termín dodání (datetime) o Termín dodání (datetime) o Termín dodání faktury (datetime) o Místo doručení (string) o Název OJ (string) o Změnil (string) o Změněno dne (string) o Území (string) o Evidenční číslo aktiva položky partnera (string) Evidence aktiv partnerů o Evidenční číslo aktiva položky partnera (string) o Datum vytvoření (datetime) o Datum podání (datetime) o Název aktiva položky partnera (string) o Poznámka 1 (string) o Poznámka 2 (string) o Poznámka 3 (string) o Poznámka 4 (string) o Poznámka 5 (string) o Datum přijetí (datetime) o Počet nabízených položek (integer) o Cena za nabízené položky (integer) o Nejvyšší cena položky (integer) o Průměrná cena položky (integer) o Nejnižší cena položky (integer) Číselník typu zakázky o Název (string) o Poznámka (string) o Platné (string) Číselník způsobu hrazení o Název (string) o Poznámka (string) o Platné (string)
15.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 50000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
95
15.8. Vstupní interface Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat jednotlivé položky ručně pomocí předpřipraveného formuláře a poté bude provádět tisky zaznamenaných zpětných vazeb a dalších informací (viz. část reporting)
15.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
15.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
15.11.
Workflow
Není aplikováno
15.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
15.13.
Časově plánované úlohy
Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut.
15.14.
Reporting
Není aplikováno
96
16.
INT-017 - Registr smluvních partnerů
16.1. Popis Aplikace umožňuje evidenci údajů k externím smluvním partnerům zadavatele a k nim je možné přiřazovat uzavřenou skupinu smluvních typů a to tak, aby k jednomu smluvnímu typu bylo možné přiřadit pouze jeden kontakt. Dříve přiřazený smluvní typ je možné přesouvat mezi kontakty. V aplikaci nemohou být nepřiražené smluvní typy.
16.2. Vlastnosti Aplikace slouží k přehledu uzavřených smluvních typů v daném období s možností fulltextového vyhledání záznamu a zobrazení detailních informací a kontaktů na smluvního partnera. Všichni smluvní partneři musí být přiřazeni k mateřské OJ.
16.2.1.
Vyhledání záznamu
Filtrování jednotlivých záznamů z databázové tabulky bude řešeno fulltextovým vyhledáváním.
16.3. Use Cases – případy použití Uživatelé mohou vyhledávat a zobrazovat detaily o uzavřených smluvních partnerských vztazích. Data musí být možné interpretovat v režimu Správy číselníku typu MASTER dle OS jako zdrojová data pro integrační platformu. Při zobrazení detailu Smluvního partnera musí být v části formuláře zobrazený také přehled všech typů smluvních vztahů partnera (platných i neplatných). Po kliknutí na název smluvního vztahu se uživateli zobrazí náhled detailu smluvního typu. U výběrového menu OJ musí být po zvolení možnosti „zobrazení detailu OJ“ v samostatném formuláři ze specifikace „Správa uživatelů Intranetu“. Při zobrazení detailu smluvního vztahu musí být zobrazen Název smluvního partnera jako hypertextový odkaz na formulář s detailem smluvního partnera. Při editaci detailu smluvního partnera musí být možný tisk smluvního dokumentu dynamicky generovaného ze šablony s použitím dat uvedených v této specifikaci.
16.4. Role Uživatel/Návštěvník - tato role zastupuje běžného uživatele, který má práva pouze k nahlížení do dat a k zobrazení detailu záznamu Správce OJ (Disponent) – tato role zastupuje běžného uživatele, který má práva k nahlížení nad všemi záznamy OJ, možnost úpravy všech záznamů v OJ a přidávání záznamů o smluvním partnerství. Zároveň může tento uživatel přidávat nové typy smluvních vztahů. Tento uživatel má práva ke zneplatnění záznamu, který nesmí být z databáze smazán, ale všem musí být skryt kromě Administrátora. Uživatel může přiřadit záznam i k jiné OJ v organizaci, tím však dojde ke změně oprávnění nad záznamem. Přiřazení smluvního typu nebo partnera k jiné OJ musí být opatřeno notifikací novému Správci OJ. Administrator – osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace. Tato role má zároveň oprávnění konfigurovat parametry naplánovaných úloh.
16.5. Číselníky a správa Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu OJ a Administrátor -
Evidence smluvních partnerů (Číselník typu MASTER dle OS) o Jméno a příjmení (string) povinný atribut o IČO/RČ (string) povinný atribut o Číslo smlouvy (string) o Právnická osoba (boolean)
97
o o o o o o o o o o o o o o o o o o -
-
Ulice (string) Obec (string) PSČ (string) Předčíslí telefon (string) Telefon (string) Předčíslí fax (string) Fax (string) Předčíslí mobil (string) Mobil (string) Email (string) URL (string hypertext) Odpovědná osoba (string) Výpověď ke dni (datetime) Nová smlouva (boolean) Poznámka (string) Editoval (načteno z LDAP databáze) Datum editace (datetime)
Evidence smluvních typů (Číselník typu MASTER dle OS) o Název OJ (dynamicky načteno z číselníku OJ, který je specifikován v modulu „Správa uživatelů intranetu“) – výběr ze seznamu, povinný atribut o Název (string) povinný atribut o Ulice (string) o Obec (string) o PSČ (string) o Předčíslí telefon (string) o Telefon (string) o Předčíslí fax (string) o Fax (string) o Předčíslí mobil (string) o Mobil (string) o Email (string) o Poznámka (string) o Editoval (načteno z LDAP databáze) o Datum editace (datetime) Číselník OJ (dynamicky načteno z číselníku OJ, který je specifikován v modulu „Správa uživatelů intranetu“) – nemusí být replikován do dané aplikace o Název OJ o Číslo OJ
Pokud bude vyžadován další číselník v návrhu aplikace, jeho správa musí být umožněna pouze Správci OJ nebo Administrátorovi.
16.6. OLA Zadavatel předá dodavateli šablonu vytvořenou v aplikaci Microsoft Word se specifikací umístění polí pro načtení informací z této specifikace do výsledného dokumentu.
16.7. SLA Rámcový počet partnerů může dosahovat hodnoty 10000. Počet smluvních typů může dosahovat hodnoty 10000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
16.8. Vstupní interface Vstupním interface je vždy pouze uživatel dle definované role, tento uživatel bude zadávat jednotlivé položky ručně.
98
16.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty. Validace dat pro pole typu telefonní čísla (fax , mobil) musí splňovat konvenci pro mezinárodní předvolby ve formátu „+420“ v poli předčíslí a 9 číselných znaků striktně v poli číslo. Záznam nesmí být možné bez naplnění této validace, možné uložit a uživatel musí být vyzván k zadání správného formátu. Pole s chybou musí být zvýrazněno s textovým popisem chyby. Validace dat musí probíhat na úrovni těchto atributů v definovaných číselnících -
-
Evidence smluvních partnerů o Jméno a příjmení o IČO/RČ Evidence smluvních typů o Název OJ o Název
16.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
16.11.
Workflow
Není aplikováno
16.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů o Organizační Počet přidaných záznamů za období Počet zrušených záznamů za období Naposledy upravené záznamy
99
16.13.
Časově plánované úlohy
Zadavatel požaduje v rámci dodávky sestavení naplánované úlohy, která poskytne data integrační platformě v libovolné a konfigurovatelné časové frekvenci.
16.14.
Reporting
Není aplikováno
100
17.
INT-018 - Nástěnka
17.1. Popis Aplikace Nástěnka poskytuje uživatelům intranetového portálového řešení ucelené informace o významných událostech a dění ve společnosti. Tyto zprávy jsou spravovány jedním, nebo více lidmi, kteří v nich mohou odkazovat na nejrůznější externí i interní informační zdroje.
17.2. Vlastnosti Aplikace Nástěnka má několik základních vlastností, mezi které patří zejména evidence jednotlivých zadaných oznámení, ve které jsou obsažené údaje jako Název, čas události (tedy kdy byla událost vytvořená) a kdo událost vytvořil. Tyto události jsou poskytovány jednotlivým uživatelům prostřednictvím webové části na libovolné stránce intranetu. Je tedy možné nastavit oprávnění pro tuto stránku a řídit ta přístup jednotlivých uživatelů. Tak je možné nastavit, komu všemu budou události přístupné, avšak většinou se zpřístupňují všem uživatelům v rámci domácí stránky. Administrace i modifikace událostí – tedy obsahu této aplikace je prováděna manuálně pověřenými osobami. Tento seznam jednotlivých událostí je doplněn o časovou osu, aby bylo možné podrobněji a přehledněji sledovat jednotlivé firemní události na časové ose. Aplikace umožňuje uživateli prohlížet jednotlivé verze dílčích zadaných položek, umožňuje přepínání mezi jednotlivými druhy pohledů na seznam událostí a vytvářet pohledy nové – uživatelské, tedy unikátní pro každého přihlášeného uživatele. Tyto pohledy je možné koncipovat z pohledu třídění a filtrování a bez nutnosti zásahu do programového kódu aplikace. Řešení musí umožňovat vložení textového obsahu ve formátu HTML, který umožňuje vkládání hypertextového obsahu. Ke každému záznamu je možné přidávat libovolný počet souborových příloh. Jednotlivé záznamy musí být ukládány do databáze a to minimálně s touto strukturou: -
Krátký popis Text Platnost od: Platnost do: Vložil (identifikace uživatele) Vložil dne – časové razítko vložení
Řešení musí obsahovat správu uživatelských přístupů a rolí.
17.3. Use Cases – případy použití Aplikace slouží výhradně k informování uživatelů o událostech ve společnosti. Je možné zobrazit seznam událostí, je možné zobrazit detailní informace jednotlivých událostí, případně je možné správci umožněno spravovat seznam událostí.
17.4. Role Správce – role zodpovědná za přidání, změnu, deaktivaci záznamu Uživatel čtenář – Role s přístupem ke čtení obsahu „bez dalších omezení v přístupu k obsahu“ Administrátor – role zodpovědná za konfiguraci uživatelských rolí prostřednictvím skupin nebo uživatelských jmen z ActiveDirectory.
17.5. Číselníky a správa Není aplikováno
17.6. OLA Zadavatel zajistí data ve formátu CSV, popřípadě přímý přístup do tabulky databáze s touto strukturou zdrojové tabulky: Krátký popis (text) Text (text) Platnost od:(datetime) Platnost do:(datetime) Vložil (text - identifikace uživatele) Vložil dne (datetime – časové razítko vložení)
101
17.7. SLA Viz. Obecné informace o plnění
17.8. Vstupní interface Vstupní interface je tvořen zadávacím formulářem pro každou jednotlivou událost a seznam všech událostí, kde je možné na jakoukoliv událost kliknout, tím ji otevřít a editovat. Následně je nutné každou editovanou událost uložit.
17.9. Validace dat: Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
17.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele.
17.11.
Workflow
Není aplikováno
17.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
17.13.
Časově plánované úlohy
Není aplikováno
17.14.
Reporting
Zadavatel nepožaduje na této úrovni aplikace žádný reporting.
102
18.
INT-019 – Naše akce
18.1. Popis Aplikace Naše akce poskytuje uživatelům na úvodní stránce intranetového portálového řešení ucelené informace o organizačních akcích.
18.2. Vlastnosti Akce musí být zobrazovány jako seznam minimálně o následujících atributech: datum a čas zahájení, název, a to pro účely informování zaměstnanců LČR o plánovaných akcích. Administrace i modifikace akcí – tedy obsahu této aplikace je prováděna manuálně pověřenými osobami s oprávněním typu Správce. Tento seznam jednotlivých událostí je doplněn o časovou osu, aby bylo možné podrobněji a přehledněji sledovat jednotlivé firemní akce na časové ose. Ke každému záznamu je možné přidávat libovolný počet souborových příloh. Jednotlivé záznamy musí být ukládány do databáze a to minimálně s touto strukturou: -
Datum a čas Název Místo Kontaktní osoba Účastníci (výběr ze seznamu zaměstnanců prostřednictvím LDAP) Poznámka (text) Vložil (identifikace uživatele) Vložil dne – časové razítko vložení (datetime) Datum poslední modifikace (datetime) Naposledy modifikoval (identifikace přihlášeného uživatel)
Řešení musí obsahovat správu uživatelských přístupů a rolí.
18.3. Use Cases – případy použití Aplikace slouží výhradně k informování uživatelů o akcích ve společnosti. Je možné zobrazit seznam akcí, je možné zobrazit detailní informace jednotlivých akcí, případně je možné správci umožněno spravovat seznam akcí.
18.4. Role Správce – role zodpovědná za přidání, změnu, deaktivaci záznamu a přiřazení účastníků akce. Uživatel čtenář – Role s přístupem ke čtení obsahu „bez dalších omezení v přístupu k obsahu“ Administrátor – role zodpovědná za konfiguraci uživatelských rolí prostřednictvím skupin nebo uživatelských jmen z ActiveDirectory.
18.5. Číselníky a správa -
Číselník míst pro konání akce Číselník skupin zaměstnanců, pro které je akce určena
18.6. OLA Zadavatel zajistí data ve formátu CSV, popřípadě přímý přístup do tabulky databáze s touto strukturou zdrojové tabulky: -
Datum a čas Název Místo Kontaktní osoba Účastníci (výběr ze seznamu zaměstnanců prostřednictvím LDAP) Poznámka (text) Vložil (identifikace uživatele) Vložil dne – časové razítko vložení (datetime)Krátký popis (text)
103
18.7. SLA dle. OS
18.8. Vstupní interface Vstupní interface je tvořen zadávacím formulářem pro každou jednotlivou akci a seznam všech akcí, kde je možné na jakoukoliv akci kliknout, tím ji otevřít a editovat. Následně je nutné každou editovanou akci uložit dle možnosti oprávnění uživatele.
18.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
18.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele.
18.11.
Workflow
Není aplikováno
18.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
18.13.
Časově plánované úlohy
Není aplikováno
18.14.
Reporting
Zadavatel nepožaduje na této úrovni aplikace žádný reporting.
104
19.
INT-020 – Krátké zprávy
19.1. Popis Aplikace Krátké zprávy poskytuje uživatelům na úvodní stránce intranetového portálového řešení informace o dění ve společnosti ve formě krátkého seznamu zpráv bez možnosti další a podrobnější editace
19.2. Vlastnosti Zprávy musí být zobrazovány jako seznam minimálně o následujících atributech: datum a čas uveřejnění, text zprávy. Administrace i modifikace zpráv – tedy obsahu této aplikace je prováděna manuálně pověřenými osobami s oprávněním typu Správce. Tento seznam jednotlivých zpráv je doplněn o časovou osu, aby bylo možné podrobněji a přehledněji sledovat jednotlivé firemní zprávy na časové ose. Jednotlivé záznamy musí být ukládány do databáze a to minimálně s touto strukturou: -
Datum a čas uveřejnění (datetime) Text zprávy (text 100 znaků) Vložil (identifikace uživatele) Vložil dne – časové razítko vložení (datetime)
Řešení musí obsahovat správu uživatelských přístupů a rolí.
19.3. Use Cases – případy použití Aplikace slouží výhradně k informování uživatelů o zprávách a dění ve společnosti. Je možné zobrazit seznam akcí. Správci je umožněno spravovat seznam akcí.
19.4. Role Správce – role zodpovědná za přidání, změnu, deaktivaci záznamu a přiřazení účastníků akce. Uživatel čtenář – Role s přístupem ke čtení obsahu „bez dalších omezení v přístupu k obsahu“ Administrátor – role zodpovědná za konfiguraci uživatelských rolí prostřednictvím skupin nebo uživatelských jmen z ActiveDirectory.
19.5. Číselníky a správa -
Není aplikováno
19.6. OLA Není aplikováno
19.7. SLA dle. OS
19.8. Vstupní interface Vstupní interface je tvořen zadávacím formulářem pro každou jednotlivou zprávu a seznam všech zpráv, kde je možné na jakoukoliv zprávu kliknout, tím ji otevřít a editovat. Následně je nutné každou editovanou akci uložit dle možnosti oprávnění uživatele.
19.9. Validace dat: Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
19.10.
Migrace dat
Není aplikováno.
105
19.11.
Workflow
Není aplikováno
19.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
19.13.
Časově plánované úlohy
Není aplikováno
19.14.
Reporting
Zadavatel nepožaduje na této úrovni aplikace žádný reporting.
106
20.
INT-021 - Aplikace Důležité dokumenty
20.1. Popis Aplikace Důležité dokumenty slouží všem uživatelům s možností přístupu do intranetu, tato aplikace udržuje informace o důležitých dokumentech zadavatele, které jsou zde uloženy ve formátu PDF a zde jsou k nim doplněna níže uvedená metadata. Aplikace musí umožnit import ze souboru XLS nebo XLSX.
20.2. Vlastnosti Tato aplikace musí umožnit evidenci nejméně na těchto úrovních: -
Umožnění dokumentu formou přílohy Podání informace o vytvořených dokumentech v daném roce Full textové vyhledávání v dokumentech Import ze souboru xls nebo xlsx
20.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Název dokumentu Název OJ Datum vzniku Autor Příloha Data souboru
20.3. Use Cases – případy použití Oprávněný uživatel musí provést v předem definovaném intervalu přípravu dat ve formátu XLS nebo XLSX, která jsou pak nahrána do systému a musí k nim být přiřazen požadovaný rok a Název OJ. Běžný uživatel pak má možnost náhledu na tato data a to dle hodnot definovaných v kapitole Vyhledání záznamu.
20.4. Role Uživatel/Návštěvník – tato role reprezentuje uživatele, který má práva ke čtení jednotlivých dat a příloh záznamů vytvořených v této aplikaci Správce obsahu (Disponent) – tato role reprezentuje uživatele, který má práva k provádění datového importu a ke změně a smazání záznamů z dané aplikace. Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace.
20.5. Číselníky a správa Aplikace by měla obsahovat tyto číselníky, které smí upravovat pouze role Správce obsahu a Administrátor -
Název dokumentu (string) Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“) Datum vzniku (datetime) Autor (načteno z LDAP) Příloha Data souboru (importováno z XLS nebo XLSX)
20.6. OLA Zadavatel zajistí pro prvotní import tabulku se vstupními daty, která budou zaznamenána do databáze aplikace.
20.7. SLA
107
Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
20.8. Vstupní interface Zadavatel požaduje, aby vstupem byl formulář pro úpravy jednotlivých položek a pro primární zadávání musí sloužit možnost importu dat, ke které budou metadata doplněna nebo budou naplněna společně s importem.
20.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty.
20.10.
Migrace dat
Migrace dat nebude probíhat, jelikož data budou nahrána nová.
20.11.
Workflow
Není aplikováno
20.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání o Soupis Využití úložiště Počet webů
20.13.
Časově plánované úlohy
Není aplikováno
20.14.
Reporting
Není aplikováno
108
21.
INT-022 - Aplikace Správa uživatelů intranetu
21.1. Popis Aplikace Správa uživatelů intranetu je primárně určena jako aplikace pro administrátora, tato aplikace poskytuje jednotné místo, ze kterého je možno řídit přístupy do aplikace intranet a do všech podaplikací v ní umístěných a to do úrovně které je specifikována v každé ze samostatných aplikací. V rámci aplikace bude administrátor moci spravovat členství v interních skupinách systému a plnit jejich obsah z LDAP Databáze a to objekty typu uživatel a skupina, měnit metadata uživatelů (synchronní replikace do LDAP Databáze Active Directory) a to zejména metadata specifikovaná v OS. Administrátor v této aplikaci bude dále moci plnit a spravovat veškeré globální číselníky a to zejména číselníky pro OJ, Finanční dle specifikace v OS.
21.2. Vlastnosti Aplikace musí umožnit a poskytnou uživateli v roli administrátor minimálně tyto funkce. -
Přidání uživatele do interní skupiny aplikace (Role) v rámci každé aplikace vytvořené v intranetu Přidání skupiny do interní skupiny aplikace (Role) v rámci každé aplikace vytvořené v intranetu Vytvoření/Změnu/Smazání záznamu z centrálních číselníků, pokud budou aplikovány, minimálně však v registr OJ Při každé konfigurační změně členství nebo změně metadata poslat souhrnný report o provedených změnách administrátorovi nebo osobě nadřízené administrátorovi Maximálně zabezpečený prostor
21.2.1.
Vyhledání záznamu
Na úrovni této aplikace nebude řešeno vyhledávání v záznamech.
21.3. Use Cases – případy použití Aplikace bude sloužit administrátorovi jako centrální místo pro správu celého aplikačního řešení jako celku, bude umožňovat změny v metadatech uživatelů a to se synchronní replikou dat do LDAP databáze a úpravy globálních číselníků, zejména metadat u záznamů v číselníku OJ.
21.4. Role Administrátor - osoba, která má neomezená práva k dané aplikaci, může prohlížet záznamy, upravovat a mazat. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace. Dále pak zajišťuje modifikaci skupin nad všemi aplikacemi, tak, jak je specifikováno v dokumentech aplikací, může měnit vlastnosti daných rolí pro každou z aplikací a definovat rozsah oprávnění přidělený k dané roly.
21.5. Číselníky a správa Zadavatel dodá seznam se jmény uživatelů, kteří budou členy jednotlivých skupin ve formátu -
Aplikace (string)
-
Role (string)
-
Jméno uživatele (načteno z LDAP databáze)
-
Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“)
Pro číselník OJ dodá tento seznam (primárně jsou data načítána z LDAP databáze z objektu Organizační jednotka, ale zde k nim budou doplněna další metadata) -
Název OJ (načteno z LDAP databáze) Číslo OJ (integer) Adresa OJ (integer) Správce OJ (načteno z LDAP databáze) Telefon OJ (integer) Email OJ (string)
109
21.6. OLA Zadavatel dodá seznam se jmény uživatelů, kteří budou členy jednotlivých skupin ve formátu -
Aplikace (string) Role (string) Jméno uživatele (string) Název OJ (načteno z číselníku OJ, který je specifikován v dokumentu aplikace „Správa uživatelů intranetu“)
Pro číselník OJ dodá tento seznam (primárně jsou data načítána z LDAP databáze z objektu Organizační jednotka, ale zde k nim budou doplněna další metadata) -
Název OJ (string) Číslo OJ (integer) Adresa OJ (integer) Správce OJ (string) Telefon OJ (integer) Email OJ (string)
21.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 50 000. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy
21.8. Vstupní interface Vstupním interface bude vždy formulář, který bude vyplňován Administrator. Tento formulář musí být umístěn přímo ve stránce a musí z něho být zřejmé, kdo je a kdo není členem dané skupiny definované aplikace.
21.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty
21.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
21.11.
Workflow
Není aplikováno
21.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče
110
o
o
21.13.
Hledání Soupis
Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání Využití úložiště Počet webů
Časově plánované úlohy
Zadavatel požaduje, aby byly do aplikace přenášeny informace o OJ a uživatelích z LDAP Databáze, které bude možno následně do nové aplikace vyplnit a to v časovém intervalu maximálně 15 minut
21.14.
Reporting
Aplikace musí být schopna sestavit přímo v prohlížeči seznam členů jednotlivých skupin v přehledné podobě, umožnit filtrování na úrovni osoby nebo skupiny, dále pak na úrovni OJ a úrovni aplikace. Dále pak musí být aplikace tuto statistiku posílat emailem administrátorovi a osobě nadřízené. Aplikace musí dále umožňovat zaslání reportu o změnách, přidaných položkách a odstraněných položkách a to minimálně na úrovních: -
Ihned po provedení Jednou denně Jednou týdně
111
22.
INT-023 - Aplikace Knihovna
22.1. Popis Aplikace Knihovna slouží pro všechny zaměstnance jako zdroj informací a jednotné místo pro umístění odkazu na knihy, které zadavatel vlastní ve formátu PDF, ale jsou primárně umístěny v jiné aplikaci. Tato aplikace musí umožnit uživatelům otevření knihy skrze intranetový portál (nemusí být však kniha zobrazena přímo zde) a to bez nutnosti ukládání přímo v této aplikaci (například možno otevřít pomocí hyperlinkování, odkazu, aj… dále jen „prolink“). Aplikace musí umožnit řízení přístupu k různým sekcím v rámci aplikace Knihovna. V aplikaci budou uživatelé vyhledávat a to dle definovaných metadat (klíčových slov), které bude možno u každého záznamu definovat.
22.2. Vlastnosti Tato aplikace musí umožnit evidenci nejméně na těchto úrovních: -
Evidence knihy Řízení oprávnění na úrovni knihy Řízení oprávnění na úrovni sekce knihovny Zaznamenávání klíčových slov Vyhledávání dle klíčových slov Indexování obsahu bez nutnosti uložení v aplikaci
22.2.1.
Vyhledání záznamu
Vyhledávání jednotlivých záznamů z databázové tabulky bude řešeno prostřednictvím libovolné kombinace těchto parametrů: -
Dle klíčového slova Dle názvu knihy Dle data změny
22.3. Use Cases – případy použití Aplikace je určená všem zaměstnancům zadavatele, kteří mohou přijít do dané aplikace vyhledat knihu dle klíčového slova nebo dle názvu a knihu si otevřít a přečíst, tato kniha nebo článek je standardně ve formátu PDF a uživatel může provést i stažení knihy do svého počítače skrze prolink.
22.4. Role Uživatel/Návštěvník – tato role zastupuje uživatele, který má práva ke čtení, nemůže obsah měnit a mazat. Dále pak nemůže provádět úpravu klíčových slov u souborů. Správce obsahu (Disponent) – tato role zastupuje uživatele, který má práva k přidávání dalších knih do databáze knihovny, může provádět modifikace a mazání knih. Administrator - osoba, která má neomezená práva k dané aplikaci, může prohlížet, přidávat a mazat záznamy, přičemž toto není hlavní náplní této funkce. Tato funkce má práva provádět výpis nastavení, konfigurace bezpečnostních skupin aplikace a dále vystavování reportů z logů aplikace. Tato osoba může také vidět všechny záznamy, jež byly označeny Správcem obsahu OJ za smazané. Dále je zodpovědný za správu obsahu číselníků „Typ inspekce, Druh inspekce, Kategorie inspekce“.
22.5. Číselníky a správa Aplikace by měla být pouze jedinou tabulkou, která nese veškeré informace, ale v rámci daného aplikačního řešení je možné provést rozdělení na více číselníků. -
Evidence knih zadavatele o Název knihy (string) o Klíčová slova (string) o Autor (string) o Den vytvoření (datetime)
112
22.6. OLA Zadavatel zpřístupní uchazeči při implementaci systém, ve kterém jsou knihy uloženy ve formě souborů (standartní možností pro načtení obsahu je Průzkumník Windows, SMB Share, aj..) odkud je možno načíst strukturu souborů, názvy souborů a k nim zadavatel dodá tabulku s: -
Název knihy (string) Klíčová slova (string) Autor (string) Den vytvoření (string)
22.7. SLA Viz. Obecný popis řešení s upřesněním pro odhadované množství záznamů v rozsahu minimálně 2500. Zadavatel požaduje, aby byla aplikace optimalizována na rychlost vyhledávání a zobrazování výsledků s využitím „stránkování“ výsledné množiny záznamů. Stránkování musí být řešeno na úrovni datové vrstvy.
22.8. Vstupní interface Vstupním interface bude vždy formulář, který bude vyplňován primárně rolí Správce obsahu (disponent) a vyhledávací formulář, který mohou využít všechny dostupné role.
22.9. Validace dat Validace musí splňovat podmínky pro ověření minimálně na definované datové typy. Zadavatel ze svých potřeb validace dat pro tento modul plnění nepožaduje. Některé prvky prezentační vrstvy však mohou v průběhu implementace být označeny jako povinné a poté musí být v rámci plnění formuláře zajištěna nemožnost uložení záznamu bez vyplnění této hodnoty
22.10.
Migrace dat
Zadavatel dodá tabulku nebo přístup do databáze k tabulce obsahující výše uvedené informace, které budou do nové aplikace naplněny, tuto tabulku dodá Disponent nebo Administrator zadavatele. Uchazeč musí v nabídce počítat s časem potřebným k možnému překladu datových typů ze zdrojové do cílové DB
22.11.
Workflow
Není aplikováno
22.12. -
Logování a auditování
Přihlášení uživatele Záznam o spuštění úlohy pro vyhledání záznamů se zachycením sekvence vyhledávacího řetězce a počtu vrácených výsledků Logování dat na úrovni této aplikace s možností nastavení zobrazení historických dat za 365 dní s možností exportu do formátu tabulky o Provoz Počet zobrazení stránky Jedinečných návštěvníků za den Počet odkazujících serverů Nejoblíbenější stránky Nejčastější návštěvníci Nejčastější odkazující servery Nejoblíbenější cíle Nejoblíbenější prohlížeče o Hledání Počet dotazů Nejoblíbenější dotazy Neúspěšné dotazy Využití nejlepšího tipu Návrhy nejlepších tipů Historie akcí návrhů nejlepších tipů Klíčová slova pro vyhledávání
113
o
22.13.
Soupis Využití úložiště Počet webů
Časově plánované úlohy
Není aplikováno, jedná se o ruční proces evidence knih Správcem obsahu (Disponentem)
22.14.
Reporting
Všichni zaměstnanci zadavatele musí být informováni o umístění nové knihy do knihovny, popřípadě pokud dojde k úpravě některé ze stávajících knih (může se jednat o interní knihu zaměstnanců nebo článek).
114
Příloha č. 2 – Technologické standardy 1. Databáze Microsoft SQL Server 2012 a vyšší, Oracle Database 12c a vyšší
2. Operační systémy Microsoft Windows Server 2012 R2 a vyšší, Red Hat Enterprise Linux 6 a vyšší, Oracle Linux 6 a vyšší
3. Programovací jazyky Microsoft .NET 4.5a vyšší, Oracle APEX 4.2 a vyšší , Java 7 a vyšší / JSP 2.2 a vyšší, PHP 5.4 a vyšší.
115
Příloha č. 3 – Integrační standardy 1. Online integrace Volba integrační platformy v LČR je předmětem výběrového řízení, nicméně obecně tato vrstva zajišťuje orchestraci služeb pro krátkodobě i dlouhodobě běžící procesy. Integrační vrstva umožňuje komunikaci pomocí množství různých protokolů. V rámci LČR budou podporovány následující: Webové služby (SOAP/HTTP), XML/HTTP FTP, E-mail JDBC, ODBC atd.
1.1. Pravidla pro použití integrační vrstvy Propojení aplikací/systémů v rámci prostředí LČR by mělo být prováděno výhradně přes integrační vrstvu tak, aby nevznikaly přímé vazby mezi aplikacemi. o
Pokud aplikace/systém vystavuje svoji logiku přes webové služby, neměly by se ostatní aplikace napojovat na tyto služby „napřímo“, ale tyto služby jsou "vytaženy" na úroveň integrační vrstvy a klienti k nim přistupují přes integrační vrstvu.
Propojení aplikace/systému LČR s aplikací/systémem, který je umístěn mimo prostředí LČR musí být provedeno přes integrační vrstvu. Propojení aplikací mimo integrační vrstvu (např. DB-Link, přímé JDBC, apod.) není žádoucí a může být použito pouze po schválení Integračním architektem LČR. Integrační vrstva nebude používána v případech, kdy aplikace komunikuje pouze proprietárním komunikačním protokolem, pro který neexistuje na integrační vrstvě konektor. Propojení aplikací s integrační vrstvou je implementováno pomocí konektorů (konzumenti služeb) a adaptérů (poskytovatelé služeb).
1.2. Funkce poskytované integrační vrstvou ESB v rámci LČR bude obecně nabízet zejména následující funkce/služby: routing – dynamické směrování (adresace) zpráv podle obsahu zpráv, transformace a zpracování dat, garantované doručení zprávy (v případě asynchronní notifikace), orchestrace služeb, kvalita služeb – transakční zpracování, kvalita komunikace, zaručení dostupnosti, logování a audit služeb, zajištění bezpečnosti (autentizace a autorizace). Kompletní výčet všech funkcí ESB bude znám po ukončení výběrového řízení na integrační platformu. V případě specifických požadavků definují dodavatelé ostatních systémů tyto požadavky v rámci své nabídky.
116
1.3. Integrační návrhové vzory V následujících vzorech jsou používány následující pojmy: Poskytovatel služby – systém, který publikuje službu a implementuje funkcionalitu služby. V případě jednoduché služby, která nevyžaduje orchestraci na ESB je poskytovatelem implementující systém. V případě orchestrované služby je poskytovatelem ESB. Poskytovatel definuje při vytvoření služby návrhový vzor, jakým bude služba použita. Konzument služby – systém, který chce službu využít.
1.3.1.
Asynchronní vzory
Při dlouhodobém zpracování volání webových služeb poskytovatelem budou použity následující návrhové vzory.
Vzor 01: Notifikace Tento vzor spočívá v odeslání zprávy webové služby bez čekání na odpověď. ESB zodpovídá za doručení zprávy a konzument služby (odesilatel) se tak může spolehnout na její doručení. ESB negarantuje čas doručení zprávy, v rámci služby/operace se definuje timeout po jehož uplynutí se ESB přestane pokoušet o doručení zprávy.
Vzor 02: Request – Callback Tento vzor spočívá v zavolání služby, od které je očekávána odpověď. Odpověď nemusí být doručena okamžitě, ale může být doručena později.
1.3.2.
Synchronní vzory
Vzor 03: Request – Response Konzument volá službu poskytovatele a očekává odpověď v definovaném časovém intervalu. Typickým využití tohoto vzoru je nativní volání služby s přístupem do databáze.
1.4. SOA principy SOA principy jsou souborem zásad, kterými se bude řídit návrh webových služeb. Nejedná se o výčet všech principů, ale pouze o nejčastější případy použití.
1.4.1.
Znovupoužitelnost
Znovupoužitelnost služeb je jeden ze základních SOA principů. V praxi by se měl uplatňovat tak, aby nedocházelo k duplikaci služeb s podobným významem nebo podobnou funkcionalitou.
1.4.2.
Bezstavové služby
Bezstavové služby se spouštějí pouze v rámci paměti a neukládají žádné informace o svém stavu, přidávají tak minimální výkonnostní režii a dále je možné využít principu znovupoužitelnosti.
1.4.3.
Standardizovaný kontrakt služeb
Standard pro zprávy mezi jednotlivými službami je rozveden v další kapitole. Jedním z důsledků standardizace je snížení nákladů implementace služeb na všech stranách (poskytovatel/konzument). 117
1.4.4.
Princip abstrakce (granularita služeb)
Při dodržování principu abstrakce se zlepšuje granularita systému (služeb), která má za následek snadnější správu služeb na ESB a jejich další rozvoj. V rámci LČR je preferována tvorba hrubozrnných (coarse grained) služeb. V praxi to znamená např. Namísto služeb ZaložUživatele, ZaložKontakt, ZaložTelefon bude existovat jedna služba ZaložKlienta, která veškeré tyto funkcionality zapouzdří. Finální granularitu jednotlivých služeb bude určovat role Integračního architekta.
1.5. Transakce Pokud je to možné, měla by komunikace využívat transakční schopnosti systémů a platforem (aplikační servery, databáze atd.). Většina komunikace se odehrává přes webové služby, které ale nejsou transakční. Pro minimalizaci rizika, že při zpracování vznikne chyba a data zůstanou v „mezistavu“, se používají dva přístupy: Hrubozrnné služby – na cílových aplikacích existují služby, které vystavují velké bloky funkčnosti (např. ZaložSmlouvu – spolu se smlouvou založí i zákazníka, pokud neexistuje). Tím se odstraňuje nutnost více volání systému a tím i potencionální chyby při druhém volání. Kompenzační služby – používají se při návratu systémů do původního stavu, když se volání operace nepodaří zrealizovat.
1.6. Jmenné konvence Návrh pojmenování služby/operace připravuje budoucí poskytovatel služby. Integrační architekt LČR toto schvaluje, případně upravuje. Dále pak definuje doménu, do které služba spadá a schvaluje finální podobu XSD a WSDL definice. Veškeré názvy služeb, atributů, apod. jsou výhradně v anglickém jazyce.
1.6.1.
Název služby Název služby je unikátní, měl by vzniknout z jejího účelu a musí být nezávislý na poskytovateli a konzumentovi. Začíná velkým písmenem, dále CamelCase notace.
1.6.2.
Název operace Název operace musí být v rámci služby unikátní. Začíná malým písmenem, dále camelCase notace. Nejčastěji se skládá ze slovesa (get, set, modify, list, remove, add, check) a podstatného jména.
1.6.3.
Namespace služby Namespace služby vzniká složením následujících částí (targetNamespace): o o
Prefix „http://lcr.cz“ Doména určující oblast, do které služba patří (PE,Portál,ERP)
o
Jméno služby např.CDrevina
o
Verze služby např.v_1.2.1
118
1.6.4.
Datové elementy Všechny elementy MUSÍ být definovány jako qualified. Všechny komplexní datové typy musí být definovány jako xsd:complexType v root elementu schématu. Všechny simple datové typy s omezením by měly být definovány jako xsd:simpleType v root elementu schématu. Jmenné konvence: a. b.
Elementy (publikované root elementy) – první písmeno velké, dále CamelCase notace (např.: i) Elementy (element uvnitř definice typů) - první písmeno malé, dále camelCase notace
c.
Komplexní typy – první písmeno velké, CamelCase notace, komplexní typy končí slovem „Type“
d.
Request – první písmeno malé, dále camelCase notace, končí sufixem „Request“, např.:
e.
createPersonRequest Response – první písmeno malé, dále camelCase notace, končí sufixem „Response“, např.: createPersonResponse
1.7. Použité standardy WS V rámci integrační vrstvy se používají následující obecné závazné standardy: o XML o
XML Schema 1.1
Pro webové služby jsou navíc závazné následující standardy: o SOAP 1.2 o o
WSDL 1.1 WS-Policy 1.5
o o
WS-Security 1.1 WS-ReliableMessaging 1.2
o
WS-Addressing
1.8. Datový model Datový model interface služby musí vycházet ze jmenných konvencí. Všechny nově vznikající webové služby musí používat společný datový model zpráv – CommonMessage.xsd. Tento model definuje vstupní (request), výstupní (response) a chybové (fault) zprávy webových služeb. Každý request/response/fault obsahuje hlavičku requestHeader/responseHeader a poté komplexní typ requestBody/responseBody, který obsahuje samotný obsah zprávy. Hlavička je obsažena i v chybové fault odpovědi, ta obsahuje faultHeader. Je to z důvodu jednotného logování.
119
Popis komplexního typu Header: Element
Typ
Povin né
Popis
Kdo vyplňuje
Ukázka
messageId
string
Ano
Univerzální identifikátor zprávy. Jedná se o UUID verze 3.
Klient služby
22009893 -774qy48
Klient služby
2011-0101 16:00:00
Klient služby
Portál
physicalSou rce
Portal.lcr. cz
targetSyste m
ERP
http://en.wikipedia.org/wiki/Universally_unique_ identifier Každá zpráva má své unikátní messageId. Request i response mají své různé identifikátory. timestamp
dateTi me
Ano
Časové razítko zprávy, označuje čas odeslání/vytvoření zprávy u klienta. Vyplňuje odesílatel zprávy v době jejího vytvoření. Do response hlavičky se vyplňuje aktuální čas odeslání odpovědi.
sourceSyste m
string
Ano
Při vytváření requestu se vyplňuje jméno volajícího systému (ten který request vytváří). Do response hlavičky se vyplní jméno systému, který zprávu vytváří.
physicalSou rce
string
Ne
Identifikace zdrojového systému – fyzický stroj (member), jméno stroje z DNS, IP adresa. Do response hlavičky se vyplní aktuální jméno stroje, který odpověď vytváří.
targetSyste m
string
Ne
Identifikace cílového volaného systému. Vyplní se jméno systému, ke kterému zpráva putuje. Do response hlavičky se vyplní hodnota sourceSystem z request hlavičky.
1.9. Verzování služeb Z pohledu verzí služeb je ideální, když každá služba běží jen v aktuální verzi. Nicméně pro účely vývoje, testování a oprav chyb je někdy nutné na ESB zajistit souběh dvou rozdílných verzí jedné služby. Proto budeme rozlišovat 3 číselné řady, které dohromady tvoří výslednou verzi služby. o <Major> - změna v čísle znamená změnu rozhraní, která je kompatibilní (přidání operací, o
přidání nového typu atd.) s předchozí verzí služby. <Minor> změna v čísle znamená změnu rozhraní, která není kompatibilní (odebrání operací a atributů, změna business významu – namespace, typy atd.) s předchozí verzí služby.
o
<Micro> změna v čísle neznamená změnu rozhraní, ale jen drobnou implementační změnu v rámci služby (oprava chyb, nastavení security atd.).
Pojmenování výsledných balíčků služeb pro nasazení Soubor jar (ear atd.), který vznikne sestavením služby, musí být pojmenován dle následujících pravidel: <JménoSlužby>_v_<MajorVerze>.<MinorVerze>.<MicroVerze>.jar Například: CDrevina_v_2.0.3.jar První dvě čísla (MajorVerze, MinorVerze) se vkládají do vybraných elementů WSDL – targetNamespace, portType, service name a endpoint.
120
Návaznost na ukládání verzovaných služeb v SVN Pokud se při vytváření nových služeb využívá nástroj SVN, využívá se jeho vlastnost nazývaná branche. Tedy starší verze služeb jsou ukládány v branche a trunk vždy obsahuje poslední/aktuální verzi služby. Například, pokud je aktuální verze služby v02, v branche je uložena verze v01.
1.10. Chybové odpovědi Všechny chybové situace vzniklé při vykonávání služeb mají být prezentovány jako fault. Definovány jsou pod namespacem http://lcr.cz/faultinfo Služby rozlišují 3 typy výjimek: o LCRBusinessLogicFault – je službou vrácena v případě chyb vzniklých uvnitř business logiky integrovaných systémů (např. záznam nenalezen). o
LCRSecurityFault - je službou vrácena v porušení bezpečnosti během autentizace, autorizace nebo souvisejících služeb (změna hesla apod.).
o
LCRSystemFault – je službou vrácena v případě systémové chyby.
Jakékoliv proprietární či custom odpovědi na volání služby jsou nežádoucí. Vrácené výjimky obsahují detailní specifikaci – fault info. Každý typ fault má svou odpovídající fault Info - LCRBusinessLogicFaultInfo, LCRSecurityFaultInfo, LCRServiceFaultInfo. Tvar všech FaultInfo je sjednocený, aby fault Info obsahovalo errorNumber, message a cause: o
errorNumber je hlavní číslo chyby a určuje skupinu souvisejících chyb pro danou službu.
o
Rozsah čísel errorNumber přiděluje v době návrhu služby Integrační architekt. message je zpřesňující textový popis chyby.
o
cause je volitelný odkaz na fault info, který je originálním původcem této výjimky.
1.11. Velikosti zpráv On-line komunikace se používá když: o Je vyžadována okamžitá odpověď od cílového systému a velikost zpráv nepřesahuje 300kB o
Nejsou přenášeny celé struktury s ohledem na velikost (číselník), ale typicky jeden konkrétní záznam.
V případě, že je vyžadován on-line přenos velkých dat – typicky přenos souborů jako příloh zprávy, musí být použít protokol MTOM pro přenos těchto příloh.
1.12. Validace zpráv ESB umožňuje validaci zpráv proti XML Schematu (WSDL a XSD), nastavení validací je následující: o V testovacím prostředí by měla být validace proti XML Schematu prováděna vždy. o
V produkčním prostředí by validace proti XML Schematu měla být prováděna vždy, pokud jde o zprávu ze systému, který není pod kontrolou LČR. V ostatních případech by měla být z výkonnostních důvodů vypnuta.
o
Uživatelské (business) validace by měly být prováděny uvnitř implementace služby.
121
1.13. Bezpečnost 1.13.1. Úvod Základem pro zabezpečení webových služeb v LČR jsou algoritmy na úrovni transportní vrstvy (TLS). Pro autentizaci volání webových služeb se používá SSL certifikát, který podporuje dvě metody one-way nebo twoway. Odlišné přístupy autentizace webových služeb bude individuálně schvalovat Integrační architekt.
1.13.2. Zabezpečení služeb Integrační vrstva bude vystavovat služby vyžadující serverový certifikát (SSL 3.0 a TLS 1.0) integrační platformy. Tento certifikát vydává vždy Integrační architekt pro každou aplikaci. Dále je komunikace zabezpečena buď jako Basic authentication nebo jako Client cert authentication. Při Basic authentication bude systém při komunikaci s Integrační platformou v rámci hlavičky SOAP vždy posílat jméno a heslo. Při Client cert authentication bude systém komunikovat s integrační platformou se systémovým certifikátem (analogie jména a hesla).
122
Příklad SOAP Header s SSL (Basic authentication) <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <soapenv:Username>yourusername <soapenv:Password>yourpassword <soapenv:Body>
1.13.3. Způsoby propagace identit Autentizační, autorizační a auditní moduly systémů LČR jsou založeny na identifikaci uživatele při autentizaci a použití zjištěné identity pro další řízení přístupových práv v systému a pro korektní zápisy do auditních záznamů.
123
Příloha č. 4 – Seznam služeb integrační platformy Název služby
Poskytovatel
Konzument
Popis služby
Synchronní/ asynchronní
/D201Portal/Vytv oreniRezervaceB S
SEM
Web LČR
Provedení rezervace objednávaného množství produktů v aplikaci SEM
Synchronní
/D500Proces/Pra vidloDatacomBS
IP
IP
Přenos datových souborů z OJ v podobě e-mailových příloh na Ředitelství LČ
Synchronní
/D200Portal/Vyk azLes801BS
DS
Intranet
Poskytnutí výkazů LES08-1 Datovým skladem pro zobrazení v rámci Intranetu
Synchronní
/D500Proces/Cirk evniRestituceBS
CIRES
Web LČR
Rozhraní slouží pro přenos dat o církevních restitucích z aplikace CIRES do aplikace Portál
Synchronní
/D201Portal/Znep latneniRezervace BS
SEM
Web LČR
Provedení zrušení rezervace v aplikaci SEM
Synchronní
MailDatacom
Poštovní server
IP
Přenos datových souborů z OJ v podobě e-mailových příloh na Ředitelství LČ
Synchronní
PrenosSouboru
FTP
IP
Přenos souboru z/na InfraFTP
Synchronní
S50013CCSMoni tor_PollAdapter
FTP
IP
Zobrazení informací o firemních vozidlech LČR (SPZ vozidla, Datum, Čas od/do, Trasa, Stav tachometru, Vzdálenost, Řidič, Druh jízdy a GPS souřadnice)
Synchronní
/D200Portal/Geo ObjectBS
GIS
Intranet, Web LČR
Zobrazení mapového podkladu v rámci intranetové aplikace LČR - Významné stromy.
Synchronní
/D200Portal/OrgJ ednotkaBS
TARGET, PE
Intranet, Web LČR
Poskytnutí kontaktních údajů na jednotlivé organizační jednotky LČR, případně na vybrané zaměstnance LČR
Synchronní
/D200Portal/Zam KontaktInfoPLB S
TARGET
Intranet
Poskytnutí kontaktních údajů na zaměstnance LČR
Synchronní
/D100DMS/Evid enceVozidelBS
DMS
Intranet
Zobrazení informací o firemních vozidlech LČR (SPZ vozidla, Datum, Čas od/do, Trasa, Stav tachometru, Vzdálenost, Řidič, Druh jízdy a GPS souřadnice)
Synchronní
/D200Portal/S200 08CUzemniCelek
PE
Intranet
Získání údajů o orgnaizačních jednotkách a jejich příslušnosti k jendotlivým katastrálním územím. Název organizační jednotky, číslo organizační jednotky,
Synchronní
124
katastrální území a další. /D200PortalS200 02Katastr
PE, LHP
Intranet
Získání údajů o orgnaizačních jednotkách a jejich příslušnosti k jendotlivým katastrálním územím. Název organizační jednotky, číslo organizační jednotky, katastrální území a další.
Synchronní
D201Portal/Osiv oBS
SEM
Web LČR
Zjištění aktuálního seznamu produktů v kategoriích "Osivo", "Vlastní zásoby", "Okrasné osivo" z aplikace SEM
Synchronní
DMS/DocInfo,D MS/GetFile
DMS
Intranet
Poskytnutní dokumentů (s příslušným příznakem) k publikaci v rámci intranetu
Synchronní
Publikacni atributy
Intranet
Web LČR
Přenos dat pro část Kontakty, Významné stromy, Honitby a Semenářský závod.
Synchronní
125
