Specifikace předmětu plnění veřejné zakázky

Příloha zadávací dokumentace pro druhou fázi zadávacího řízení č. 5: Specifikace předmětu plnění veřejné zakázky.

Specifikace předmětu plnění veřejné zakázky

1. Obecná specifikace předmětu plnění

   1. Úvod

Předmětem této veřejné zakázky (dále též jen „VZ“ nebo „Veřejná zakázka“) je vytvoření, a poskytování komplexní služby pro pořizování, ukládání, vyhodnocování, správy a zpracování geotagovaných fotografií a správy úkolů včetně vytvoření související mobilní aplikace, jejich provoz, údržba, podpora a další rozvoj a případný exit.

Pod pojmem „služba GT FOTO“ a „GT FOTO“ se rozumí celá služba, která má být vytvořena, implementována, poskytována a rozvíjena v rámci VZ.

Obsahem a náplní služby GT FOTO je:

1. Poskytování služeb cloudové infrastruktury, tj. poskytování výpočetního výkonu, zajištění komunikace, bezpečnosti, ukládání dat, zálohování a potřebného systémového software. Služby cloudové infrastruktury vytváří prostředí pro bezpečný a spolehlivý běh aplikací zajišťujících níže uvedené dílčí služby GT FOTO. Služby infrastruktury musí umožnit zajistit:

   1. Uchování/archivace pořízených fotografií a jejich metadat po dobu 3 let při předpokládaném počtu 1 mil. fotografií pořízených ročně, tj. v úložišti budou na konci 3. roku a dalších let provozu 3 mil. fotografií (1 mil v daném roce pořízený + 2 miliony archivované, v průběhu dalšího roku lze postupně data starší 3 let skartovat).

   2. Zajištění uložených fotografií včetně jejich metadat proti změnám a proti neoprávněnému přístupu.

2. Vytvoření a poskytování služby, která zajišťuje:

   1. Vyhodnocování kvality fotografií dle stanovených parametrů.

   2. Automatické vyhodnocování obsahu fotografií dle stanovených parametrů, tj. rozpoznání toho, co je na fotografii vyfoceno – v rámci této VZ zejména rozpoznání vyfocené plodiny a/nebo prokázání vykonání předepsané aktivity.

   3. Synchronizaci úkolů s IS XXXX Zadavatele, jejich správu a distribuci na jednotlivá mobilní zařízení vybavená aplikací pro pořizování geotagovaných fotografií a správu úkolů.

   4. Komunikační a integrační rozhraní pro komunikaci s dalšími systémy Zadavatele prostřednictvím integrační platformy IS XXXX Zadavatele a integrace s Portálovým systémem SZIF. Cloudové řešení Poskytovatele je s určenými systémy Zadavatele integrováno.

   5. Poskytování webové aplikace a webových služeb umožňujících prohlížení a správu pořízených a uložených fotografií.

   6. Poskytování webové aplikace umožňující správu mobilních zařízení, na kterých je instalována mobilní aplikace pro pořizování fotografií a správu úkolů.

   7. Registraci, identifikaci a správu uživatelů včetně systému řízení jejich přístupu k datům i funkcím poskytovaného řešení na bázi uživatelských rolí, jejich oprávnění a jimi prováděných aktivit.

   8. Poskytování webové aplikace pro správu poskytovaných aplikačních služeb.

   9. Logování komunikace na rozhraních služby GT FOTO s okolními systémy a logování činnosti uživatelů.

3. Vytvoření a poskytování mobilní aplikace pro pořizování fotografií a správu úkolů na platformách iOS, Android.

4. Vytvoření a údržbu dokumentace služby GT FOTO a její aktualizaci. Dodání uživatelské, provozní, bezpečnostní dokumentace a její kontinuální aktualizace.

5. Poskytování Služeb provozu:

   1. Údržba, provoz a servisní, technická, uživatelská a systémová podpora služby GT FOTO.

   2. Poskytování konzultačních služeb a součinnosti.

   3. Provádění školení uživatelů a administrátorů Zadavatele.

   4. Službou provozu se rozumí i poskytování služeb zahrnutých pod body 1 až 4 výše.

6. Poskytování Služeb rozvoje

7. Exit

Služby GT FOTO budou poskytovány formou cloudové služby a zahrnují i použití mobilní aplikace.

K software vyvinutému na základě této služby bude Zadavateli poskytnuto právo tento SW užít v rozsahu uvedeném ve Smlouvě na plnění této VZ – viz Příloha č. 1 „Závazný návrh smlouvy“ této zadávací dokumentace pro druhou fázi zadávacího řízení (dále též jen „ZD“ nebo „Zadávací dokumentace“). Zdrojové texty a analytická a uživatelská dokumentace SW řešení budou předány Zadavateli za podmínek uvedených ve Smlouvě.

Tento dokument stanovuje požadavky na předmět plnění Veřejné zakázky. Detailní požadavky na plnění jsou dále uvedeny též v Příloze č.1 „Závazný návrh smlouvy“ této ZD a jejích přílohách č. 1 „Závazné implementační, funkční a technické požadavky“ a č. 3. „Závazné požadavky na poskytování Služeb“.

V Příloze č. 6 „Technická dokumentace – NDA“ této ZD je detailní specifikace kontextu nezbytného pro zpracování nabídky, kdy informace zde uvedené jsou klasifikovány jako interní, jelikož obsahují informace o interním prostředí a procesech Zadavatele, týkajících se administrace zemědělských dotací. Příloha č. 6 této ZD obsahuje požadavky na celkové řešení systému XXXX, jejichž znalost je třeba pro řádné plnění této VZ.

Zjednodušený pohled na strukturu předpokládaného řešení služby GT FOTO včetně nezbytného kontextu okolních systémů je uveden na následujícím obrázku.

Obrázek 1 Zjednodušený pohled na strukturu předmětu plnění

Plnění jako celek musí splňovat všechny požadavky uvedené v zadávací dokumentaci včetně veškerých jejích příloh.

Nabídka dodavatele a parametry nabízeného řešení služby GT FOTO musí rovněž splňovat Minimální technické požadavky, které jsou součástí Přílohy č. 1 závazného návrhu Xxxxxxx (dále též jen „Smlouva“) jako její kapitola č. 2. V rámci této Přílohy č. 1 Smlouvy dodavatel doplní způsob naplnění uvedeného požadavku odkazem na konkrétní ustanovení nabízeného Technického řešení v rámci Přílohy č. 2 Smlouvy (Technické řešení je součástí nabídky, musí být zpracované dle Přílohy č. 7 ZD a stane se právě Přílohou č. 2 Smlouvy), které bude prokazatelně a bez pochyby dokládat naplnění uvedeného požadavku. V případě, že naplnění požadavku je naplněno samotnými technickými vlastnostmi standardního SW nebo cloudové služby, které jsou předmětem plnění, bude v rámci nabídky uvedeno konkrétní ustanovení technické dokumentace Výrobce software nebo poskytovatele cloudové služby prokazující naplnění požadavku, tato Technická dokumentace bude přílohou nabídky dodavatele. Odkaz bude doplněn ve sloupci s názvem „Splnění požadavku“ ke každému z definovaných požadavků identifikovaných ve sloupci „Reference“ a definovaných sloupci „Znění požadavku“ v celé kapitole č. 2. Přílohy č. 1 Smlouvy.

Věcná specifikace a vlastní vymezení požadavků na předmět této Veřejné zakázky (GT FOTO) v kontextu celého řešení XXXX, tj. v kontextu souvisejících modulů a služeb včetně vazeb na stávající IS Zadavatele, jsou definovány dále v tomto dokumentu. Kontext plnění dle této VZ je popsán také v Příloze č. 6 ZD - „Technická dokumentace - NDA“. Příloha č. 6 ZD obsahuje relevantní požadavky a souvislosti v kontextu celého řešení XXXX, jejichž znalost je třeba pro řádné plnění této VZ.

Způsob realizace předmětu plnění týkající se Vytvoření služby doplní dodavatel do jednotlivých Příloh Smlouvy, a to do příslušných k tomuto vymezených, žlutě podbarvených pasáží, ve kterých je definováno, že tyto pasáže má doplnit Poskytovatel. V rámci žlutě označeného textu v každé z uvedených Příloh jsou rovněž instrukce, které musí dodavatel při doplňování plně respektovat. Konkrétní návrh smluvních ustanovení musí plně odpovídat stanoveným požadavkům a rovněž best practice standardům pro implementační projekty a dodávky informačních systémů nebo služeb obdobně srovnatelného rozsahu! Žlutě označený text, který udává instrukce pro vyplnění, dodavatel plně nahradí vlastním zněním tak, aby doplněním textu vznikla vždy celistvá příloha Smlouvy odpovídající znění ZD včetně veškerých jejích příloh.

2. Milníky harmonogramu předmětu plnění

Detailní způsob a postup poskytování předmětu plnění bude řízen formou projektu. Detailní harmonogram postupného poskytování služeb dle předmětu plnění této VZ bude vytvořen ve spolupráci Poskytovatele a Zadavatele v rámci úvodní fáze projektu Vytvoření služby GT FOTO a v průběhu projektu bude průběžně aktualizován.

Detailní harmonogram plnění musí bezpodmínečně zohledňovat následující nastavené milníky, které jsou dány potřebami Zadavatele pro zajištění výkonu jeho primárních činností (zajištění administrace dotací).

• Dokončení implementace Kritických služeb a jejich podmínečná akceptace umožňující přechod do Pilotního a akceptačního provozu dle návrhu Poskytovatele v nabídce (viz Příloha č. 8 Smlouvy), nejpozději 105 pracovních dnů od účinnosti Smlouvy.

• Zahájení Pilotního a akceptačního provozu – následující den po akceptaci implementace Kritických služeb.

• Ukončení Pilotního a akceptačního provozu včetně zajištění implementace plného rozsahu služeb dle této VZ a plná akceptace plnění dle této VZ do 12 měsíců ode dne přechodu do Pilotního a akceptačního provozu.

• Dokončení implementace kompletní funkčnosti služby GT FOTO včetně plného rozsahu poskytovaných služeb bylo ukončeno nejpozději 3 měsíce před ukončením Pilotního a akceptačního provozu. (Akceptační část Pilotního a akceptačního provozu).

• Zahájení plného Produkčního provozu – následující den po akceptaci celkového plnění (v rozsahu Kritických a Požadovaných služeb) a ukončení Pilotního a akceptačního provozu.

Do Kritických služeb patří:

1. Autentifikace uživatele

2. Pořizování, ukládání, prohlížení a správa fotografií (bez skartační procedury)

3. Evidence a správa mobilních zařízení

4. Registrace mobilních zařízení s anonymním uživatelem a jejich správa

5. Funkce a služby pro kontrolu technické kvality fotografií (ostrost, náklon, azimut ...)

6. Notifikace

7. Správa úkolů a front v mobilní aplikaci v minimálním rozsahu těchto typů úkolů:

   1. Pořízení fota v exteriéru žadatelem na základě zadání Zadavatele

   2. Pořízení fota v exteriéru inspektorem na základě zadání

   3. Pořízení fota v exteriéru žadatelem na základě jeho vlastního rozhodnutí

   4. Pořízení fota v exteriéru inspektorem na základě vlastního rozhodnutí

   5. Otevření dokumentu/formuláře na Portálovém systému SZIF definovaného odkazem uvedeným v úkolu.

8. Správa přístupových práv

9. Delegování úkolů a správa delegovaných úkolů

10. Integrace na Integrační platformu IS XXXX

11. Webové aplikace pro správu fotografií, mobilních zařízení a úkolů a jejich integrace s Portálovými aplikacemi XXXX

Do Požadovaných služeb patří:

1. Skartační procedury na skartaci fotografií a úkolů

2. Typy úkolů a jejich kroků, které nejsou uvedeny v seznamu Kritických služeb.

3. Pořizování fotografií v interiéru

4. Funkce mobilní aplikace pracující s dokumenty s výjimkou otevření dokumentu definovaného odkazem uvedeným v úkolu.

5. Vyhodnocování obsahu fotografií.

6. Funkce a služby pro kontrolu kvality vyhodnocování obsahu fotografií.

Rozsah Kritických služeb a funkcí bude zpřesněn a více detailizován v rámci Analytické a přípravné fáze

Funkčnost uvedená v Kritických službách je také označovaná jako „Kritická“, ostatní funkčnost definovaná zadávací dokumentací této VZ je označována též jako „Požadovaná“. Rozsah obou kategorií může být změněn v rámci jednacího řízení nebo na základě dohody smluvních stran v rámci Analytické a přípravné fáze.

3. Vytvoření služby

   1. Licence SW

Pro vytvoření služby GT FOTO může být nutné nebo výhodné využití knihoven nebo SW produktů třetích stran, případně knihoven a SW modulů vyvinutých dodavatelem nebo jeho poddodavatelem před zahájením plnění této VZ. Ve Smlouvě jsou takové části označeny zkratkou SW produkt.

Výčet SW produktů dodavatel předloží v nabídce. Podrobnosti k předložení tohoto výčtu jsou obsaženy v kapitole č. 3.2 Přílohy č. 1 Smlouvy.

Poskytování Licencí je upraveno v čl. 19 Smlouvy. Společně s Licencemi je třeba poskytnutí kompletních licenčních dokumentů a klíčů, instalačních médií, standardní technické dokumentace výrobce SW. Jako koncový zákazník bude u Licencí uveden Objednatel.

Veškeré SW nástroje a technologie, které budou použity pro Vytvoření služby (případně pro její další rozvoj), musí mít garantovanou dobu udržitelnosti minimálně do roku 2029, aby byla garantována udržitelnost minimálně po celou dobu programového období Společné zemědělské politiky a případného následného přechodného období. Pokud by byla narušena udržitelnost SW nástroje a technologie, bude Poskytovatel povinen navrhnout a provést řešení takové situace (např. nahrazení SW nástroje s ukončenou podporou jiným nástrojem), a to bez nároku na zvýšení ceny plnění. V případě, že byla narušena udržitelnost v důsledku nepředvídatelných okolností a bez zavinění Poskytovatele (např. v době podání nabídky byla u SW nástroje důvodně předpokládána podpora do roku 2029, avšak byla nečekaně výrobcem ukončena dříve), přičemž uplynulo nejméně 5 let od účinnosti Smlouvy, lze případné služby potřebné k obnovení udržitelnosti poskytnout a hradit jako Službu rozvoje.

2. Vytvoření služby GT FOTO a Pilotní a akceptační provoz

Vytvoření služby je pro potřeby této ZD definováno jako proces, kterým je realizováno plnění služby GT FOTO dle požadavků stanovených touto ZD. Jedná se o proces, kterým je na základě popisu požadavků a architektonické, analytické a další dokumentace vytvořeno funkční řešení splňující požadavky, které jsou na službu v této ZD kladené.

Realizace plnění bude řízena formou implementačního projektu (ten ve standardu Zadavatele zahrnuje i přípravné a analytické práce a kontrolu kvality).

Součástí nabídky bude proto detailní návrh řízení implementačního projektu včetně uvedení projektové metodiky, která bude pro realizaci plnění využita.

1. Požadavky na projektovou metodiku

Metodika, která bude pro řízení projektu využita, musí být v souladu s některým z mezinárodně uznávaných standardů projektového řízení. Návrh detailní metodiky a parametry řízení implementačního projektu definuje Poskytovatel v Příloze č. 1 Smlouvy. Součástí metodiky řízení projektu budou minimálně následující oblasti:

• Nastavení projektu, definice projektových struktur, projektových procesů, kompletní výčet projektové dokumentace, v rámci Projektové struktury bude nejvyšším projektovým orgánem Projektový (Řídící) výbor, který bude vrcholným projektovým a eskalačním orgánem. Projektový výbor bude mít lichý počet členů, kdy počet zástupců ze strany Zadavatele bude vyšší než počet zástupců ze strany dodavatele.

• Definice a nastavení projektových rolí – Definice všech projektových rolí na straně dodavatele, stanovení požadovaných projektových rolí na straně Zadavatele, definice odpovědností projektových rolí.

• Řízení harmonogramu projektu, plánování a kontrola plnění harmonogramů a termínů.

• Řízení kapacit projektu.

• Řízení požadavků na součinnost ze strany Zadavatele, kdy součástí bude formalizovaný postup pro zajištění součinnosti nad rámec projektového plánu. Minimální doba na zajištění požadované součinnosti bude 3. pracovní den po vznesení konkrétního požadavku na součinnost ze strany Poskytovatele. Zadavatel výslovně stanovuje, že pro každý vznesený Požadavek na poskytnutí součinnosti musí být jednoznačně identifikován účel požadované součinnosti, způsob poskytnutí součinnosti (např. jednání, dokument, mimořádné testování atd.), odkaz na řešenou oblast/část/systém (v případě požadavku na součinnost u analytických prací bude odkazem konkrétní část/kapitola/odstavec analytického dokumentu), rizika při neposkytnutí součinnosti.

• Řízení projektové a implementační dokumentace, šablony projektových dokumentů, jejich ukládání a řízení – verzování a schvalování projektových dokumentů. Veškeré projektové dokumenty budou řízené takovým způsobem, aby bylo prokazatelně doloženo, kdy jaký dokument vznikl, kdo je jeho autorem, kdy byl dokument upravován, schválen a akceptován.

• Formy a způsob komunikace v rámci projektu – formální komunikace.

• Řízení rizik, projektu, řízení problémů projektu, eskalační mechanismy projektu.

• Detailní popis způsobů akceptace dílčích částí projektu, jednotlivých etap projektu i celku projektu. Zadavatel výslovně uvádí, že v rámci akceptačního řízení je nezbytné definovat procesy pro průběžnou akceptaci, která bude formalizovaná.

• Řízení kvality projektu – součástí projektové metodiky musí být řízení kvality projektu, které umožní přezkoumání způsobu realizace projektu nezávislým auditním subjektem. Zadavatel výslovně uvádí, že řízení projektu a samotná implementace plnění musí být v souladu s požadavky na řízení vývoje a implementace Významného informačního systému – dle klasifikace zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (dále jen „ZoKB“) a navazujících předpisů a v souladu s požadavky na řízení poskytovatelů dle řady norem ISO/IEC 27000.

2. Průběh realizace

Před zahájením Produkčního provozu budou realizována tato plnění:

• Vytvoření služby GT FOTO,

• Zajištění služeb Pilotního a akceptačního provozu.

Vytvoření služby GT FOTO bude realizováno formou implementačního projektu, který bude zahrnovat tyto fáze/bloky:

1. Analytická a přípravná fáze.

2. Implementaci Kritických funkcí a služeb (vlastní Implementace) – fáze 1.

3. Zajištění poskytování Kritických služeb bude realizováno ve fázi vlastní Implementace. Zajištění poskytování plného rozsahu služeb (Požadované služby) dle této VZ bude realizováno v rámci Pilotního a akceptačního provozu – fáze 2.

Fáze Vytvoření služby budou projektově oddělené a jejich výstupy budou podléhat samostatnému akceptačnímu řízení. Před zahájením každé z fází proběhne revize nastavení projektu včetně projektových týmů a bude formálně odsouhlasen způsob realizace dané fáze. Dodavatel ve své nabídce strukturovaně definuje průběh realizace jednotlivých fází, činnosti realizované v uvedených fázích na své straně a obecné požadované činnosti pro realizaci těchto fází na straně Zadavatele (což zahrnuje i součinnost poskytovatelů dalších částí nebo služeb realizovaného celého řešení XXXX). Dodavatel rovněž definuje předpokládaný harmonogram realizace těchto fází. Harmonogram musí respektovat milníky stanovené v příloze č. 8 Smlouvy, která tvoří Přílohu č. 1 této ZD.

1. Analytická a přípravná fáze

V rámci této fáze bude realizováno detailní nastavení vlastního projektu a v rámci této fáze bude realizována i detailní analýza a zpracován detailní návrh řešení služby GT FOTO.

• Přípravná etapa

  • Detailizace projektových struktur a projektových rolí, nastavení projektu, příprava a odsouhlasení základní projektové dokumentace, konkretizace harmonogramu.

  • Bude limitována časem na max. 10 pracovních dní, kdy budou za stranu Zadavatele stanovena maximálně 3 týmová jednání, kdy poslední jednání bude formálním úvodním jednáním projektu – Kick-off, na kterém též dojde k formálním zahájení projektu a odsouhlasení odpovídající projektové dokumentace.

• Předimplementační analýza

  • Bude provedena komplexní analýza prostředí, detailizace požadavků a příprava dokumentů nezbytných pro implementaci.

  • Bude realizována v souladu s principy projektového řízení nastavenými v přípravné fázi a v souladu se schváleným harmonogramem (milníky).

  • Výstupy budou formálně schvalované.

2. Vlastní Implementace - fáze 1

V rámci této fáze bude, v souladu se schválenou implementační dokumentací a stanoveným projektovým harmonogramem, probíhat vlastní Implementace služby GT FOTO v rozsahu poskytování Kritických služeb. Vlastní Implementace začíná schválením výstupů Analytické a přípravné fáze projektu a končí podmínečnou akceptací a předáním plnění do Pilotního a akceptačního provozu.

Součástí vlastní Implementace bude zaškolení spolupracujících poskytovatelů souvisejících plnění vytvářejících řešení XXXX na užití služeb GT FOTO (vystavených webových služeb) prostřednictvím softwarového rozhraní.

Dále bude součástí vlastní Implementace zaškolení zaměstnanců Zadavatele na užití mobilních aplikací a webové aplikace pro prohlížení geotagovaných fotografií. O formě školení bude rozhodnuto s přihlédnutím k aktuální epidemiologické situaci. Poskytovatel poskytne minimálně 4 termíny školení. Dovolí-li to epidemiologická situace, může Poskytovatel požadovat, aby alespoň dvě školení proběhla prezenčně. Ze školení bude pořízen videozáznam, který bude předán Zadavateli.

Pro žadatele bude připravena sada videí demonstrující použití mobilní aplikace a webové aplikace pro prohlížení pořízených geotagovaných fotografií.

Zadavatel zároveň stanovuje, že v rámci této fáze bude provedena podmínečná akceptace plnění, v jejímž průběhu bude ověřen rozsah a kvalita realizovaných funkcí a Kritických služeb. Úspěšná podmínečná akceptace plnění v rozsahu Kritických služeb je podmínkou zahájení Pilotního a akceptačního provozu.

Zadavatel požaduje, aby dodavatel v rámci své nabídky detailně specifikoval způsob implementace plnění dle této VZ včetně harmonogramu uvolňování jednotlivých služeb do provozu, tak aby k předání docházelo v souladu se stanovenými milníky a byla zajištěna realizace služeb Pilotního a akceptačního provozu dle kapitol 3.2.2.3, 3.2.2.4 a následně Navazujících služeb dle požadavků kapitoly 4 této Přílohy č. 5 Zadávací dokumentace a v souladu s ustanoveními Smlouvy, která tvoří Přílohu č. 1 Zadávací dokumentace.

3. Pilotní a akceptační provoz – fáze 2

Pilotní a akceptační provoz bude zahájen na základě splnění dvou podmínek:

1. Podmíněná akceptace služby GT FOTO v rozsahu Kritických služeb a

2. Zahájení Pilotního a akceptačního provozu projektu GT FOTO Zadavatelem.

V rámci Pilotního a akceptačního provozu budou Poskytovatelem zajištěny následující služby, které budou mít charakter kontinuálně poskytovaných služeb v průběhu období Pilotního a akceptačního provozu:

• Provoz Kritických služeb:

  • Zajištění poskytování Kritických služeb v souladu s požadovanými SLA.

  • Dohled a monitoring poskytovaných služeb včetně logování dohodnutého rozsahu transakcí uživatelů.

  • Uživatelská podpora služby GT FOTO.

• Rozvoj Kritických služeb a implementace služeb Požadovaných:

  • Vývoj/customizace dílčích funkčností, jejichž realizace nebyla dokončena/provedena v průběhu fáze vlastní Implementace popsané v kap. 3.2.2.2.

  • Testování dílčích funkčností ve spolupráci s ostatními poskytovateli, kteří se podílejí na vytvoření řešení XXXX.

  • Implementace dalších služeb a funkcí tak, aby bylo realizováno plnění dle této VZ v plném rozsahu, tj. funkčnosti označované jako „Požadovaná“.

  • Testování „Požadovaných“ funkcí a služeb a jejich uvolňování do produkce.

  • Dílčí akceptační testy implementovaných nebo změněných funkčností nebo služeb.

  • Součinnost při funkčním a integračním testování služeb a funkcí dodávaných třetími stranami, které se službami GT FOTO interagují a poskytování další součinnosti Zadavateli v rámci služeb rozvoje v souladu s kap. 4.2.

• Školení

• Školení spolupracujících poskytovatelů na změny a nové funkce sw rozhraní služby GT FOTO.

• Školení zaměstnanců Zadavatele na změny a nové funkce služby GT FOTO ve stejném rozsahu jako v případě vlastní Implementace.

• Update školicích materiálů a videí pro žadatele.

Součástí Pilotního a akceptačního provozu bude rovněž jednorázová služba Finální akceptace služby GT FOTO, která bude zahrnovat akceptační testy kompletního plnění dodávaného v rámci této VZ i součinnost při akceptačních testech celého řešení XXXX a přípravu celého řešení XXXX k uvedení do rutinního provozu a zahájení poskytování Navazujících služeb v souladu s Přílohou č.3 Smlouvy.

Detailní specifikace uvedených služeb Pilotního provozu je definována v Příloze č. 1 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

4. Průběh Pilotního a akceptačního provozu

V průběhu Pilotního a akceptačního provozu bude zajištěn provoz služby GT FOTO s produkčními (ostrými) daty a bude zajištěna podpora procesů administrace žádostí vykonávaných pracovníky Zadavatele i souvisejících procesů na straně Žadatele tak, aby bylo možné ověřit plnohodnotnou funkčnost služby GT FOTO a její integrace s okolními systémy. V období Pilotního a akceptačního provozu dojde k detailnímu ověření požadovaných vlastností služby GT FOTO, definovaných v kompletní analytické a projektové dokumentaci jako nezbytné pro předání do Pilotního a akceptačního provozu („Kritické služby“). V případě zjištění odchylek ve funkčnosti oproti definované dokumentaci a zadání služby GT FOTO bude toto řešeno jako vada plnění postupem dle stanovené klasifikace vady.

Zároveň v průběhu Pilotního a akceptačního provozu bude docházet k postupnému uvolňování funkčností definovaných jako „Požadované“ pro zajištění finální akceptace plného rozsahu služby GT FOTO umožňující přechod do produkce v plném rozsahu služby GT FOTO, tj. všech ostatních funkcí a služeb, které jsou předmětem plnění Poskytovatele a nebyly dodány v rámci vlastní Implementace, a to v souladu se stanoveným projektovým harmonogramem (bude se jednat o veškeré funkce a služby kategorie „Požadovaná“). V případě identifikace potřeby úpravy/změny služby GT FOTO oproti funkčnostem definovaných v rámci předimplementační analýzy (jak funkčnost „Kritická“, tak funkčnost „Požadovaná“) a funkcím definovaným touto ZD, bude toto klasifikováno jako požadavek na dílčí změnu systému, jejíž realizace bude probíhat jako změnové řízení dle kapitoly č. 4.2. této Přílohy Zadávací dokumentace.

5. Doba poskytování služeb

Celková maximální doba poskytování služeb Pilotního a akceptačního provozu je stanovena na dobu určitou – 12 kalendářních měsíců, a to od předání služby GT FOTO do Pilotního a akceptačního provozu. Finální formální akceptace služby GT FOTO proběhne v průběhu posledních tří měsíců Pilotního a akceptačního provozu. Vyhodnocovací období pro průběžně dodávané služby Pilotního a akceptačního provozu je stanoveno na jeden kalendářní měsíc. Vyhodnocování a akceptace průběžně poskytovaných služeb Pilotního a akceptačního provozu bude probíhat v periodě Vyhodnocovacího období a následně pak jejich fakturace a úhrada.

3. Řešení požadavku na změnu ve fázi Pilotního a akceptačního provozu

Jedná se o nástroj, který bude využíván v případě, že bude poptávaná jakákoliv úprava, dílčí změna, rozšíření požadované funkcionality, funkčnosti i aplikace nebo poskytované služby. Požadavek na změnu ve fázi Pilotního a akceptačního provozu zahrnuje veškeré činnosti nezbytné pro úpravy plnění, které nebyly součástí definovaného zadání, a to zejména, nikoliv však výhradně, s ohledem na měnící se legislativu, která bude mít dopad na celkové nastavení cílového řešení služby GT FOTO i její rozvoj. Požadavky na změnu mohou mít vliv na původně definovanou celkovou aplikační, technickou, funkční architekturu plnění. Realizace požadavků na změnu bude považována za rozvoj systému. Schválené požadavky na změnu tedy budou hrazeny stejně jako služby rozvoje dle kapitoly č. 4.2 této Přílohy Zadávací dokumentace.

4. Navazující služby

   1. Služby provozu

V rámci služeb provozu poptává Zadavatel kompletní zajištění poskytování služeb v rozsahu definovaném touto VZ včetně jejich změn provedených v průběhu Vytvoření služby. Služby provozu budou zahrnovat průběžné kontinuální činnosti, které budou realizovány tak, aby byly splněny detailní požadavky na poskytování služeb dle jednotlivých katalogových listů definovaných v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

Doba poskytování služeb je stanovena na dobu neurčitou, kdy prvním dnem poskytování služeb bude den následující po finální akceptaci Vytvoření služby GT FOTO. Vyhodnocovací období pro dodávané služby je stanoveno na jeden kalendářní měsíc. Na základě Vyhodnocovacího období bude probíhat akceptace průběžných služeb Pilotního a akceptačního provozu a jejich fakturace a úhrada.

Předmětem služeb provozu budou zejména následující dílčí služby:

• Poskytování služeb GT FOTO na integračních rozhraních s dalšími komponentami IS Zadavatele (včetně dalších komponent celkového řešení XXXX).

• Poskytování mobilní aplikace vytvořené na základě této VZ.

• Zajištění provozu výše uvedené mobilní aplikace v prostředí všech podporovaných operačních systémů, pro které byla v rámci této VZ vyvinuta.

• Poskytování webových aplikací vytvořených na základě této VZ.

• Údržba a rozvoj výše uvedených aplikací a služeb.

• Dohled a monitoring provozu poskytovaných služeb a aplikací.

• Uživatelská podpora.

• Poskytování konzultačních služeb a součinnosti.

• Provádění školení klíčových uživatelů a administrátorů Zadavatele.

2. Služby rozvoje

V rámci služeb rozvoje Zadavatel poptává realizaci změn, úprav, customizací, vývoj a vytváření nových funkcionalit aplikací plnění dle této VZ. Nejedná se o paušální služby, ale o služby na objednání, které budou zadávány prostřednictvím dvou nástrojů:

• Řešení požadavku na změnu a

• Realizace rozvojového projektu.

1. Řešení požadavku na změnu

Jedná se o zjednodušenou formu realizace projektové změny, kdy není nezbytné zpracovávat kompletní projektovou dokumentaci a realizovat samostatný projekt zahrnující veškeré projektové fáze i projektové nástroje a procesy. Detailní definice služby a procesů řešení požadavku na změnu je předmětem Přílohy č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

Požadavek na změnu je nástroj, který bude využíván v případě, že bude požadována úprava, dílčí změna, rozšíření stávající funkcionality, funkčnosti, aplikace, customizace dodávaného nebo poskytovaného plnění. Požadavek na změnu tedy zahrnuje činnosti úpravy plnění, které nemají vliv na celkovou aplikační, technickou, funkční architekturu dodávaného nebo podporovaného plnění nebo některého z návazných systémů. Prostřednictvím požadavku na změnu dochází primárně ke změně/úpravě, rozšíření stávajících business procesů Zadavatele. Realizace prostřednictvím Požadavku na změnu bude limitována do náročnosti 100 MD/požadavek. V případě, že bude požadována úprava s vyšší kapacitní náročností na straně Poskytovatele, bude změna realizována prostřednictvím rozvojového projektu.

2. Realizace rozvojového projektu

Jedná se o standardizovanou formu realizace nové funkcionality/aplikace, která má vliv na aplikační, nebo technickou, nebo funkční architekturu dodávaného nebo podporovaného plnění nebo některého z návazných systémů. Realizace projektu bude probíhat prostřednictvím standardizované metodologie Zadavatele, která je specifikovaná v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

3. Jednorázové služby

Definované jednorázové služby Zadavatel nebude čerpat automaticky, jedná se o služby, které Zadavatel může v průběhu trvání Smlouvy u Poskytovatele poptávat, a to z jakýchkoliv důvodů na straně Zadavatele. Detailní specifikace jednorázových služeb je specifikovaná v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1

1. Služba JS01 Ukončení poskytování dílčí služby

Řízené ukončení poskytování dílčí služby se stanovuje za účelem zpracování a následného provedení koordinovaného a procesně vymezeného postupu při ukončení poskytování jedné konkrétní služby, skupiny služeb, nebo konkrétní jednoznačně vymezené aplikační části, provedení předání konkrétní služby, skupiny služeb, nebo aplikační části plnění Zadavateli, nebo jím určenému subjektu a ukončení poskytování dílčí služby skupiny služeb, nebo aplikační části Poskytovatelem služeb na základě této Veřejné zakázky.

Požadavky na scénář Ukončení poskytování dílčí služby jsou uvedeny v kapitole 5.3.1 této Přílohy č.5 ZD a požadavky na provedení služby JS01 jsou uvedeny v Příloze č. 3 Smlouvy.

2. Služba JS02 Ukončení poskytování Služeb

Řízené ukončení poskytování všech Služeb se stanovuje za účelem zpracování a následného provedení koordinovaného a procesně vymezeného postupu při ukončení poskytování služeb, provedení předání plnění Zadavateli nebo jím určenému subjektu a ukončení smluvního vztahu s Poskytovatelem služeb.

Požadavky na scénář Ukončení poskytování Služeb jsou uvedeny v kapitole 5.3.2 této Přílohy č. 5 ZD a požadavky na provedení služby JS01 jsou uvedeny v Příloze č. 3 Smlouvy.

5. Požadavky na dokumentaci

   1. Projektová dokumentace

Zadavatel požaduje v rámci nabídky předložení minimálně následujících šablon projektové dokumentace:

• Nastavení projektu, projektová metodika.

• Záznam/zápis z jednání projektových/realizačních týmů.

• Záznam/zápis z jednání eskalační úrovně projektu – Projektový výbor.

• Požadavek na poskytnutí součinnosti.

• Akceptační protokol/dokument.

Tato projektová dokumentace v návrhu dle dodavatele bude využita výhradně pro implementační projekt.

2. Analytická, architektonická, implementační a provozní dokumentace

Zadavatel dále stanovuje následující požadavky na řízení a zpracování implementační, provozní a další dokumentace. Tyto požadavky zahrne dodavatel ve své nabídce a zohlední v definici realizace navazujících služeb.

V případě plnění této VZ budou zdrojové texty poskytovány v rozsahu a za podmínek uvedených ve Smlouvě.

Oblast požadavku	Definice požadavku
Zdrojové kódy	Poskytovatel předá s každou novou verzí softwarového řešení (SW řešení) zdrojové kódy a související konfigurační soubory k veškerému softwarovému vybavení, které vytvořil v rámci plnění této VZ. Pro předání zdrojových kódů bude definován mechanismus, který zabezpečí ochranu proti manipulaci s médii se zdrojovými kódy a přístupu neoprávněných osob k nim.
Vývojové prostředí	Poskytovatel dodá pro každý subsystém image vývojového prostředí, obsahující veškeré nástroje potřebné pro sestavení komponent systému. Poskytovatel dále předá dokumentaci popisující instalaci a konfiguraci prostředí pro vývoj systému tak, aby na jejím základě mohlo být takové prostředí vybudováno a sestaveny komponenty systému z předaných zdrojových kódů.
Provozní dokumentace	Poskytovatel dodá/aktualizuje provozní dokumentaci popisující z pohledu správce (administrátora) činnosti nezbytné pro zajištění chodu dodaného SW řešení. Součástí provozní dokumentace jsou procedury, které zahrnují provozní postupy údržby SW řešení, plány obnovy, zálohovací plány a postupy archivace. Dokumentace popisuje stav systému v jednotlivých prostředích. Provozní dokumentace se skládá z Provozní příručky a Příručky správce aplikace.
Projektová dokumentace	V rámci dodávky plnění dle VZ bude vedena minimálně následující projektová dokumentace: Plány projektu a dokumentace jejich plnění v čase. Organizace projektového týmu a obsazení hlavních rolí jak na straně Zadavatele, tak Poskytovatele. Metodika vedení projektu včetně popisu řízení rizik a eskalačních mechanismů. Zápisy z jednání a projektových schůzek. Plány testů. Testovací případy. Testovací protokoly. Akceptační a předávací protokoly. Metriky a popis způsobu jejich měření. Výstupy měření a sledování metrik.
Uživatelská dokumentace	Poskytovatel dodá uživatelskou dokumentaci minimálně v tomto rozsahu: Uživatelský manuál ve formátu Word a jeho interaktivní verze, která bude zveřejněna na Portálovém systému SZIF. Kontextová nápověda v aplikacích. Videonávod pro uživatele mobilní aplikace a webových aplikací. Často kladené dotazy – zveřejněné na Portálovém systému SZIF.
Modelovací notace	Poskytovatel použije pro popis řešení v dokumentaci pouze standardizované modelovací jazyky (ArchiMate 3, UML 2.5, BPMN 2). Všechny vytvořené modely bude Poskytovatel ukládat do EA repository (Sparx Enterprise Architekt) na straně Zadavatele.
Struktura EA repository	Poskytovatel použije rámci Analytické a přípravné fáze standardizovanou strukturu EA repository a bude i nadále udržovat repository modelů i návazných dokumentů v aktuálním stavu.
Sdílené prvky	Poskytovatel bude při tvorbě modelů využívat v maximální možné míře dostupné sdílené prvky (jsou-li na straně Zadavatele k dispozici) ze sdílené repository Zadavatele. V souladu s modelovacím standardem.
Aktualizace EA modelu	Poskytovatel provede aktualizaci EA modelu ve sdíleném repository Zadavatele před každým plánovaným releasem s dopadem do architektury nebo do v repository uložených modelů.
Zásady	Pro modelování budou v rámci Analytické a přípravné fáze definované zásady a pravidla. Jde zejména o dodržování jmenných konvencí, obecných zásad pro čitelnost a srozumitelnost a také dodržování pravidelného verzování modelů.
Rozsah požadovaných dokumentů	Poskytovatelem bude v rámci plnění dodávána a průběžně aktualizována dokumentace následujících typů:
	- analytická dokumentace,
	- architektonická dokumentace,
	- vývojářská dokumentace,
	- administrátorská dokumentace,
	- provozní dokumentace,
	- bezpečnostní projekt v souladu s požadavky ZoKB a ISO/IEC 27000,
	- testovací dokumentace,
	- uživatelská dokumentace,
	- instalační dokumentace,
	- školící dokumentace.
Analytická dokumentace	Poskytovatel dodá analytickou dokumentaci, která bude rozdělena do několika dokumentů a bude obsahovat:
	- Katalog požadavků (HL (High Level) úroveň popisu v EA/UML, HL i detailní úroveň popisu v separátní příloze návrhu řešení.
	- Trasovací matici (export z EA v XLS s vazbami mezi požadavky, případy užití, realizačními sekvencemi, procesy, rozhodnými skutečnostmi, číselníky, evidovanými případy, datovými toky, testovacími scénáři).
	- Procesní analýzu všech zasažených procesů (každý proces detailně modelovaný v BPMN, HL úroveň s vazbami mezi procesy v byznys vrstvě ArchiMate).
	- Jmenné konvence.
	- Přehled šablon využívaných aplikací (dokumentů, emailů, emailových notifikací atd.) a popis jejich správy.
	- Přehled a popis používaných typů dokumentů.
	- Definici pravidel a omezení pro import a export dat.
	- Přehled Rozhodných skutečností (identifikovaných na základě procesní analýzy).
	- Přehled Evidovaných případů (identifikovaných na základě procesní analýzy).
	- Přehled číselníků (interních a sdílených).
	- Přehled datových toků vyměňovaných s okolními systémy.
	- Popis každého vystaveného rozhraní (WS, DB rozhraní, souborového rozhraní) - popis bude mít charakter zadání pro vývoj (zejména definice povinných/nepovinných polí, datových typů, oborů hodnot / validačních schémat).
	- Use Case modely s vazbou na požadavky (UML).
	- Sekvenční modely (realizační sekvence v UML).
	- Model persistence (datový model v UML).
	- Datová analýza (E2E analýza s popisem vazeb od UI po pole v DB).
	- Model tříd (UML).
	- Model nasazení (UML/součást infrastrukturní dokumentace).
	- Model komponent (UML/ detailní přehled a popis aplikačních komponent systému/ integrační model s přehledem přes všechny zasažené systémy, komponenty a jejich rozhraní).
	- Model rozhraní (UML).
	- Model stavů (UML).
	- Popis autentizace (všech požadovaných metod) a autorizace (matice business rolí, aplikačních rolí a oprávnění).
	Vývojářská dokumentace	Poskytovatel dodá:
- šablony vývojářské dokumentace,
- kompletní výčet a popis knihoven třetích stran plánovaných pro použití v rámci systému,
- definované jmenné konvence pro tvorbu datového modelu (metodika názvosloví datových entit, sloupců, typových označení skupin datových entit - např. číselníků validačních kontrol, indexů, databázových úloh apod.),
- definované jmenné konvence pro tvorbu zdrojových kódů (metodika názvosloví objektů, tříd, funkcí, procedur, proměnných, operací, událostí, ovládacích prvků apod.),
Poskytovatel v rámci implementace dodá:
- Detailní popis datového modelu – zejména popis vlastníků (k jaké části aplikace se vztahuje, co obsahuje, jaký je jeho účel), popis datových entit/tabulek (k jakému účelu je použita), popis číselníků, popis sloupců tabulek, popis logických vazeb mezi tabulkami z business pohledu, popis validačních kontrol, popis indexů, popis databázových úloh majících vazbu na datový model.
- Důsledné využívání komentářů ve zdrojových kódech, tzn. ve všech třídách, funkcích, procedurách apod., popisujících jejich účel, vstupy, výstupy i průběh, včetně komentářů podmínek, cyklů apod.
- Základní README soubor s popisy komponent, vztahů tříd, které systém obsahuje, jejich vlastnosti, význam, obsah nebo propojení s ostatními komponentami.
- Kompletní instrukce ke konfiguraci prostředí pro vývojáře, včetně uvedení všech potřebných nástrojů, jejich verzí a konfiguračních parametrů.
- Kompletní instrukce k vytvoření a úspěšnému buildu systému, včetně příslušných buildovacích skriptů.
- Kompletní výčet a popis knihoven třetích stran, použitých v rámci systému.
- Kompletní vygenerovanou vývojářskou dokumentaci s použitím vhodného nástroje, např. pro vývoj v JAVA Javadoc. - Pokud řešení vystavuje rozhraní pro integraci 3. stran, Poskytovatel poskytuje řádně zdokumentované rozhraní včetně ukázek implementace.
- Kompletní dokumentace uživatelského rozhraní.
- Nastavení používaných pravidel kontroly kvality kódu pro účely provedení nezávislého auditu kvality kódu.
Poskytovatel s každou novou verzí aplikací a jejich zdrojových kódů zajistí aktualizaci vývojářské, architektonické a analytické dokumentace tak, aby odpovídala aktuálnímu stavu vývoje aplikací.
Formáty dokumentace	Dokumentace v podobě dokumentů bude poskytována Poskytovatelem ve formátech DOCX nebo XLSX a v PDF/A ve verzi aktuálně uvolněné ke dni akceptace a v aktualizované verzi po úpravě vad a nedostatků zjištěných v průběhu akceptační procedury.
Enterprise Architect	Architektonické, analytické a vývojářské modely budou modelovány nástrojem Sparx Systems Enterprise Architect. Licenci EA (minimálně corporate edici) si musí zajistit Poskytovatel.
Administrátorská dokumentace	Poskytovatel zpracuje a bude průběžně udržovat Administrátorskou dokumentaci, ve které budou podrobně popsány postupy správy Systému pro administrátora a klíčové uživatele Zadavatele.
Testovací dokumentace	Poskytovatel předá v rámci plnění jednotlivých fází projektu dokumentaci popisující instalaci, konfiguraci, způsob použití prostředí pro testy systému tak, aby na jejím základě mohlo být testovací prostředí vybudováno a provozováno. Součástí dodávky budou také testovací scénáře a skripty pro jednotlivé druhy testů včetně postupu na přípravu nebo vyhledání testovacích dat. Testovací dokumentace bude průběžně aktualizována s ohledem na vývoj systému.
Architektonická dokumentace	Poskytovatel dodá modely s popisem Enterprise a Solution architektury.
Databázové modely	Poskytovatel bude předávat a průběžně aktualizovat modely prostřednictvím repository Enterprise Architect Zadavatele. Veškeré modely budou obsahovat:
	- Model veškerých entit.
	- Vazby jednotlivých entit v rámci architektonické vrstvy.
	- Popis jednotlivých entit formou business popisu významu a využití entity.
	- Popis jednotlivých atributů formou business popisu významu a využití entity.
	- Popis fyzické realizace dané entity.
	- Datové toky a vazby jednotlivých entit mezi vrstvami a systémy.
Popis Entit	Poskytovatel v rámci popisu Entit bude dokumentovat alespoň:
	- Popis entity, její business význam (bude použito jako součást komentáře vytvářené databázové tabulky).
	- Popis jednotlivých atributů včetně jejich datových typů. Pro definici datových typů budou použity datové domény.
	Součástí popisu je:
	- Jméno, doménový typ, povinnost atributu a komentář (business popis) atributu. Integritní omezení na data ukládaná do entity. Integritní omezení na vzájemné vazby jednotlivých entit.
	- Způsob kontroly správnosti dat načítaných do definované entity. Požadovaný termín dodání dat (testovacích, dat pro migraci).
	V případě, že sloupec bude obsahovat budoucí identifikátor entity, bude stanoven způsob generování tohoto identifikátoru, případně jeho validace nebo vazbu na místo vzniku tohoto identifikátoru. Identifikace, které atributy jsou využity a jakým systémem.
Instalační dokumentace	Poskytovatel dodá instalační dokumentaci popisující jednotlivé kroky instalace, konfigurace a zprovoznění systému (pro každé prostředí). Dokumentace bude zahrnovat všechny nezbytné instalační kroky nad rámec instalace operačního systému a instalace DB serveru. Dále bude zahrnovat výčet všech nezbytných komponent včetně verzí, licencí a konfigurací, a to včetně operačního systému, DB a frameworků. Tato dokumentace bude pravidelně udržovaná pro potřeby realizace a testování plánu obnovy.
Bezpečnostní dokumentace	Poskytovatel dodá bezpečnostní dokumentaci prokazující splnění požadavků Zadavatele na bezpečnost v souladu s požadavky ISO 27 000 a ZoKB. Bezpečnostní dokumentace obsahuje metody, postupy a schémata, ze kterých je patrné, jak služby GT FOTO spravovat z hlediska bezpečnosti a které služby a moduly jsou nezbytné pro bezpečný provoz služeb GT FOTO. Součástí dokumentace jsou zejména: Popis hlavních komponent a funkcí, které poskytují zabezpečení včetně vazeb na cloudové služby či jiné aplikační komponenty zajišťující bezpečnost. Popis způsobu zajištění vysoké dostupnosti a zotavení systému po poruše včetně odkazu na dokumentaci k zálohování a jednotlivým plánům. Definici periodických činností jako jsou sledování vydávání bezpečnostních a funkčních updatů a opravných balíčků výrobci použitých technologií a software a implementace upgradů a opravných balíčků, penetrační testy, analýza rizik, sledování a vyhodnocování provozu a procedury reakce na incidenty a nežádoucí stavy. Popis a metody nakládání s bezpečnostními a provozními logy (vyhodnocování, skartační lhůty, způsob uchovávání) a způsob a doba jejich archivace. Popis procesů řešení bezpečnostních incidentů, resp. popis procesu hlášení a obsluhy bezpečnostních incidentů ve vazbě na stávající procesy Zadavatele. Správa certifikátů a nakládání s nimi.
Dokumentace zpracování osobních dat	Poskytovatel dodá dokumentaci popisující rozsah zpracování osobních dat, použité metody a způsoby zajištění jejich důvěrnosti, integrity, aktuálnosti (správnosti) a dostupnosti. Seznam zpracovávaných osobních údajů včetně uvedení právních důvodů a účelů jejich zpracování a jejich skartačních dobách. Diagram datových toků osobních údajů. Seznam přijatých opatření za účelem zajištění důvěrnosti, dostupnosti, integrity a dostupnosti osobních údajů.
Školicí materiály	Poskytovatel dodá podklady použité pro školení uživatelů včetně případných příkladů a jejich dat.
Dokumentace obnovy	Poskytovatel zpracuje komplexní postup obnovy služby GT FOTO s popisem dílčích kroků a využitím jednotlivých modelů a dokumentů. Tento postup bude pravidelně ověřován v rámci auditu realizovaného nezávislým auditorem. Zároveň bude podle Dokumentace obnovy realizován jednou ročně v termínu stanoveném Zadavatelem proveden komplexní test obnovy.
Scénáře ukončení služeb	Poskytovatel zpracuje komplexní scénáře realizace jednorázových služeb (viz Příloha č. 3 Smlouvy): JS01 – Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb (všech cloudových služeb), tj. postup předání řešení tak, aby mohlo být provozováno u jiného provozovatele cloudových infrastrukturních služeb, případně ukončení pouze některé dílčí služby. JS02 – Ukončení poskytování Služeb, tj. postup předání kompletního řešení služby GT FOTO jinému provozovateli včetně aktualizované dokumentace a zpracovávaných dat. Scénáře na ukončení jednotlivých dílčích služeb odlišné od scénářů JS01 a JS02 jsou zpracovávány na výzvu Zadavatele.

Tabulka 1 Požadavky na dokumentaci

Dokumentace bude v průběhu plnění VZ udržována Poskytovatelem aktuální.

Dokumentace s výjimkou architektonické a analytické dokumentace vedené v nástroji Enterprise Architect, zdrojových kódů a dalších souborů ukládaných do repository bude předávána, rozvíjena a udržována v platformě Microsoft Teams (Sharepoint) Zadavatele, kde Zadavatel pro tento projekt založí Team, kanály a projektovou strukturu včetně složek pro ukládání a výměnu dokumentů. Výjimkou jsou zdrojové kódy (viz níže).

Dohodnuté formáty:

1. Textové dokumenty – formáty MS Office, v Zadavatelem editovatelné formě. Důležité dokumenty budou předány jak ve formátu MS OFFICE, tak v .PDF/A, za účelem zachycení předávaného stavu bez možnosti obsah dokumentu změnit.

2. Obrázky – jpg, png, tiff, vsdx.

3. Projektové řízení – mpp, xlsx.

4. Zadavatel používá Sparx Systems Enterprise Architect, proto požaduje vedení architektonické a analytické dokumentace v tomto nástroji.

5. Zdrojové kódy a další soubory vznikající při vývoji software budou udržovány v GIT repository, která bude přístupná Zadavateli. Soubory ze své podstaty nevhodné pro uložení v GIT repository budou ukládány v úložišti Poskytovatele, které bude přístupné Zadavateli.

3. Scénáře ukončení služeb

Poskytovatel rámci Vytvoření služby zpracuje komplexní scénáře realizace jednorázových služeb JS01 a JS02 (viz Příloha č. 3 Smlouvy):

• JS01 – Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb (všech cloudových služeb), tj. ukončení poskytování cloudových infrastrukturních služeb a migraci řešení, aby mohlo být provozováno u jiného provozovatele cloudových infrastrukturních služeb.

• JS02 – Ukončení poskytování Služeb, tj. postup předání kompletního řešení a provozu služby GT FOTO jinému provozovateli včetně aktualizované dokumentace a zpracovávaných dat.

Tyto scénáře mohou být ověřovány na výzvu Zadavatele nebo v rámci auditu informačního systému realizovaného nezávislým auditorem.

1. Scénář služby JS01 Ukončení poskytování dílčí služby

Scénář Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb (všech cloudových služeb) (dále v této kapitole „Scénář“), bude obsahovat postup a harmonogram ukončení poskytování cloudových infrastrukturních služeb a postup a harmonogram migrace služby GT FOTO k jinému poskytovateli cloudových infrastrukturních služeb. Přesné vymezení subjektu, ke kterému bude služba GT FOTO migrována, stanoví Zadavatel před zahájením realizace scénáře dle této služby a v rámci této realizace bude Scénář aktualizován dle konkrétních informací o prostředí a možnostech nového poskytovatele cloudových infrastrukturních služeb.

Scénář musí být navržen a dokumentován tak, aby pokrýval veškeré kroky potřebné pro ukončení provozu služby GT FOTO v prostředí stávajícího poskytovatele cloudových infrastrukturních služeb a migraci a zprovoznění služby GT FOTO do prostředí Zadavatele či nového poskytovatele cloudových infrastrukturních služeb při zachování poskytování služby GT FOTO v souladu s parametry stanovenými Smlouvou.

Scénář bude vytvořen tak, aby veškerá data a informace vzniklé v průběhu poskytování služby GT FOTO dle této Smlouvy,  jejichž předání bude předmětem této jednorázové služby, byla předána, je-li to možné a účelné, v podobě, v jaké byla vytvářena a ukládána při provozu, podpoře a rozvoji služby GT FOTO (jinými slovy: nebudou prováděny žádné exporty, konverze a převody dat a informací, předávají se funkční komponenty s plným datovým obsahem), stejně tak budou předány veškeré nově vyvinuté funkce/komponenty/služby, customizace či úpravy SW nástrojů sloužících pro zajištění provozu, skripty a další programové úpravy vzniklé při poskytování služeb.

Scénář bude zejména obsahovat:

• Seznam služeb, jejichž poskytování bude ukončováno,

• seznam všech komponent/částí IT řešení včetně dat služby GT FOTO, které budou přenášeny do prostředí jiného poskytovatele cloudových služeb,

• seznam všech zdrojových kódů, konfigurací, skriptů a dalších artefaktů dotčených ukončením dílčí služby včetně určení formátu a způsobu předání,

• seznam architektonické, projektové, provozní, bezpečnostní a další dokumentace vztahující se k ukončovaným službám i ukončením těchto služeb dotčeným komponentám/aktivitám/službám provozu služby GT FOTO,

• seznam typů záznamů, které je třeba v rámci Ukončení dílčí služby předat Zadavateli (reporty, provozní deníky, auditní záznamy, znalostní báze, vytvořené v průběhu poskytování služeb) tak, aby po Ukončení poskytování dílčí služby bylo zajištěno, že Zadavatel disponuje kompletními a správnými informacemi a know-how pro zajištění dílčí služby v prostředí jiného poskytovatele cloudových infrastrukturních služeb.

Součástí Scénáře zároveň musí být řešení následujících oblastí:

• Rozsah, forma a obsah součinnosti Poskytovatele při předávání dílčí služby Objednateli/novému poskytovateli a zprovoznění služby GT FOTO ve změněném prostředí.

• Návrh postupu zprovoznění služby GT FOTO v prostředí nového poskytovatele infrastrukturních cloudových služeb.

• Seznam testovacích scénářů a akceptačních protokolů, na jejichž základě bude Zadavatel ověřovat úplnost a správnou funkčnost služby GT FOTO po realizaci ukončení poskytování dílčí služby a její náhrady službou jiného poskytovatele.

• Informace pro nového poskytovatele za účelem detailního seznámení s požadavky na poskytování nové služby nahrazující ukončenou dílčí službu.

• Odhad kapacit a dob potřebných pro provedení jednotlivých aktivit včetně určení profesí, které je budou vykonávat (lze uvádět interval, u aktivit závislých na vlastnostech cílového prostředí se bude jednat o hrubý odhad kapacit a dob trvání aktivit a o zřetelné vyznačení těchto aktivit ve scénáři).

V případě potřeby vytvoření scénáře ukončení jen jedné nebo několika dílčích cloudových nebo jiných služeb, bude scénář vytvořen pro konkrétní zadání Objednatele a na jeho výzvu. Pro jeho vytvoření a/nebo případnou realizaci bude uplatněn postup dle kap. 4.2.2 Realizace rozvojového projektu uvedené v této Příloze č. 5 ZD za uplatnění podmínek definovaných v katalogovém listu služby JS01 uvedeném v Příloze č. 3 Smlouvy.

2. Scénář služby JS02 Ukončení poskytování Služeb

Scénář Ukončení poskytování Služeb (dále v této kapitole „Scénář“), bude obsahovat postup a harmonogram ukončení poskytování služby GT FOTO a jejího předání Zadavateli nebo jím určenému poskytovateli. Přesné vymezení subjektu, ke kterému bude služba GT FOTO předávána, stanoví Zadavatel před zahájením této služby a v rámci jejího provedení bude Scénář aktualizován dle konkrétních informací o cílovém prostředí a možnostech nového poskytovatele.

Scénář musí být navržen a dokumentován tak, aby pokrýval veškeré kroky potřebné pro ukončení provozu služby GT FOTO včetně cloudových infrastrukturních služeb, archivaci a předání veškeré dokumentace, dat a komponent IT řešení tak, aby bylo možné řešení předat novému poskytovateli a ten měl veškeré informace, dokumentaci a data potřebné pro zprovoznění služby GT FOTO v prostředí Zadavatele či nového poskytovatele a při zachování poskytování služby GT FOTO v souladu s parametry stanovenými Smlouvou.

Scénář bude vytvořen tak, aby veškerá data a informace vzniklé v průběhu poskytování Služby GT FOTO dle této Smlouvy  jejichž předání bude předmětem této jednorázové služby, byla předána, je-li to možné a účelné, v podobě, v jaké byla vytvářena a ukládána při provozu, podpoře a rozvoji služby GT FOTO (jinými slovy: nebudou prováděny žádné exporty, konverze a převody dat a informací, předávají se funkční komponenty s plným datovým obsahem), stejně tak budou předány veškeré nově vyvinuté funkce/komponenty/služby, customizace či úpravy SW nástrojů sloužících pro zajištění provozu, skripty a další programové úpravy vzniklé při poskytování služeb.

Celková doba realizace Scénáře: Maximálně 60 kalendářních dní od Xxxxxxxx realizace Scénáře.

Scénář Ukončení poskytování Služeb bude obsahovat zejména:

• Seznam služeb, jejichž poskytování bude ukončováno.

• Seznam všech komponent/částí IT řešení včetně dat služby GT FOTO.

• Seznam všech zdrojových kódů, konfigurací, skriptů a dalších artefaktů služby GT FOTO včetně určení formátu a způsobu předání.

• Seznam architektonické, projektové, provozní, organizační, bezpečnostní a další dokumentace vztahující se ke službě GT FOTO a jejímu poskytování.

• Seznam typů záznamů, které je třeba v rámci Ukončení Služeb předat Zadavateli (reporty, provozní deníky, auditní záznamy, znalostní báze, vytvořené v průběhu poskytování služeb) tak, aby po ukončení poskytování Služeb bylo zajištěno, že Zadavatel/nový poskytovatel disponuje kompletními a správnými informacemi a know-how pro zajištění poskytování služby GT FOTO.

Součástí Scénáře zároveň musí být řešení následujících oblastí:

• Rozsah, forma a obsah součinnosti Poskytovatele při předávání služby GT FOTO novému poskytovateli a zprovoznění služby GT FOTO ve změněném prostředí.

• Návrh postupu zprovoznění služby GT FOTO v prostředí nového poskytovatele infrastrukturních cloudových služeb.

• Seznam testovacích scénářů a akceptačních protokolů, na jejichž základě bude Zadavatel ověřovat úplnost a správnou funkčnost služby GT FOTO po realizaci Ukončení poskytování služby provozu a rozvoje a jejím zajištění jiným provozovatelem.

• Informace pro nového poskytovatele a potřebné zaškolení pracovníků nového poskytovatele za účelem detailního seznámení s provozem služby GT FOTO a její dokumentací.

• Odhad kapacit a dob potřebných pro provedení jednotlivých aktivit Scénáře včetně určení profesí, které je budou vykonávat (lze uvádět interval, u aktivit závislých na vlastnostech cílového prostředí se bude jednat alespoň o hrubý odhady kapacit a dob trvání aktivit a o zřetelné vyznačení těchto aktivit ve scénáři; zprovoznění služby GT FOTO v novém prostředí provádí nový poskytovatel dle předané dokumentace, záloh („obrazů“) IT komponent a dat za součinnosti Poskytovatele).

6. Specifikace plnění

   1. Splnění minimálních požadavků

Poskytovatel je povinen zajistit, aby poskytovaná služba po celou dobu poskytování vždy bezvýhradně splňovala minimální požadavky uvedené ve Smlouvě, která je Přílohou č. 1 této ZD a v její Příloze č. 1 „Závazné implementační, funkční a technické požadavky“.

2. Základní pojmy a kontext požadovaných služeb

   1. Role geotagovaných fotografií v procesu administrace žádosti

Geotagovaná fotografie (fotografie s jednoznačným určením polohy a dalšími požadovanými atributy/metadaty) je v procesu administrace žádosti důkazním prostředkem, který primárně slouží k prokázání plnění/neplnění podmínky pro výplatu na základě daného dotačního programu. Geotagované fotografie pořizují jako důkaz terénní inspektoři Zadavatele i sami žadatelé. Mohou je pořizovat na základě zadaného úkolu nebo z vlastního rozhodnutí.

Fotografie jsou pořizovány mobilním zařízením vybaveným k tomu účelu instalovanou a poskytovanou aplikací vytvořenou jako součást plnění dle této ZD.

Protože je takto pořízená geotagovaná fotografie důkazním prostředkem, nesmí být s ní a s jejími metadaty zaznamenanými při pořízení fotografie nijak manipulováno, nesmí být měněna a musí být zabezpečena tak, aby bylo prokazatelné, že od svého pořízení nebyla fotografie, ani její metadata, změněna.

Fotografie použité pracovníky Zadavatele jako důkaz budou součástí spisu (ve spisové službě Zadavatele), je jim přiřazeno č.j., jsou ukládány do interní databáze Zadavatele a zde archivovány po dobu minimálně 10 let po uzavření daného dotačního případu.

2. Předpokládaná architektura celkového řešení XXXX

Níže uvedený obrázek zachycuje hrubý pohled na to, jak má celkové řešení XXXX pracovat. Část orámovaná červeným rámečkem je předmětem plnění dle této VZ GT FOTO.

Z obrázku je patrné, že všechny procesy sdílejí data uložená v DB XXXX.

Ve fázi kontroly plnění podmínek dotačních programů běží několik cyklických procesů současně a jsou propojeny společnou databází „DB XXXX“, ve které jsou uloženy údaje o jednotlivých podmínkách monitorovaných opatření a jejich vazbách na žádosti a na pozemky, ke kterým se vztahují. Databáze udržuje aktuální stav vyhodnocení plnění těchto podmínek včetně výsledků všech provedených kontrol, které se k parcele nebo podmínce vážou, a drží také historii změn.

Obrázek 2 Základní pohled na celkové řešení XXXX

„Načtení žádostí ke kontrole“- načítá údaje žádostí z IS SAP a LPIS. Do požadovaných stavů budou procesem Načtení a aplikace výjimek promítnuty i žadatelům poskytnuté výjimky.

Kontrolu pomocí satelitního monitoringu zajišťuje externí služba SAMAS. Pro tuto službu IS XXXX poskytuje zadání (co má kontrolovat) a přebírá do dalšího zpracování její výstupy. Toto zajišťuje proces „Komunikace se SAMAS“. Tento proces aktualizuje stav plnění monitorovaných podmínek po každém příjmu nových dat ze satelitu, a také po každé změně sledovaných podmínek v důsledku změny žádosti nebo podání žádosti nové, či jejího zpětvzetí/storna aktualizuje službě SAMAS podmínky, které mají být sledovány.

Blok „Kontrolní aktivity“ v sobě skrývá všechny další kontrolní aktivity, s výjimkou satelitního monitoringu. Ty zahrnují jak zpracování výstupů monitoringu, tak kontroly, které zpřesňují, doplňují nebo kontrolují výstupy satelitního monitoringu a další kontrolní aktivity včetně jejich plánování (kontrolu pomocí ortofota, Follow-up aktivity, kontroly v terénu – PN, KNM, KNP - a kontrolu s použitím geotagovaných fotografií). Část těchto aktivit je sice v IS XXXX naplánována, ale další zpracování se děje v IS SAP (KNM, KNP) nebo také s podporou mobilní aplikace GT FOTO, kterou budou používat inspektoři Zadavatele v terénu.

Služba SAMAS poskytuje i jiné výstupy než stavy monitorovaných podmínek – např. ortofota nebo specializované mapy. Tyto jsou po odeslání službou SAMAS načteny a uloženy do DB XXXX. SAMAS dále poskytuje službu prohlížení mapových podkladů, respektive snímků. Tato služba je integrována do uživatelského rozhraní IS XXXX tvořeného Portálovými aplikacemi XXXX.

Jsou-li v IS XXXX vyhodnoceny všechny podmínky daného opatření vázané na danou AP, kterými je podmíněn nárok na danou dotaci, je jejich zpracování v tomto procesu ukončeno, a proces přechází do zpracování stávajícími procesy – Softwarovou kontrolou II - „SWK II“ a na něj navazujícím procesem „Výplata“, jejichž podpora je realizována stávajícím IS SAP.

V průběhu zpracování je třeba průběžně komunikovat s žadatelem. Tuto funkčnost zajišťuje proces „Komunikace se žadatelem“, který má přístup k aktuálním údajům, které chce Zadavatel se žadatelem sdílet. Tento modul bude integrován s novým Portálovým systémem SZIF, které díky responzivnímu designu umožní přístup i z mobilních zařízení.

Pro splnění požadavku kontinuální komunikace se žadatelem je třeba mít neustále aktuální údaje a umět je žadateli poskytnout, případně jej upozornit, že se mu blíží termín splnění nějakého úkolu, nebo podmínky dotace, a Zadavatel ji splněnou nevidí. Přitom je třeba reagovat na to, jak se žadatel zachová. Jestli doloží plnění geotagovanou fotografií nebo změní žádost, případně neudělá nic.

K tomu, aby se s dostupnými údaji dobře pracovalo, je vhodná vizualizace výsledků nad mapovými podklady.  Pro komunikaci se žadatelem i poskytnutí přehledové informace pracovníkovi Zadavatele je použít tzv. scoreboard, který přehledně informuje o stavu plnění podmínek opatření a úkolů.

Obrázek obsahuje i dva bloky, které zachycují podpůrné procesy. „Načtení a aplikace výjimek“, které zpřístupňují výjimky načtené z registru OOP, který je součástí LPIS, ostatním procesům, a výjimky na základě ohlášení vyšší moci, načítané z registru OVM, který je realizován v IS SAP.

Dále obsahuje externí službu „Správa geotagovaných fotografií“, zajišťující pořizování, ukládání a správu geotagovaných fotografií, které jsou v rámci Kontrolních aktivit pořizovány a používány.

Pro pořizování geotagovaných fotografií a práci s úkoly bude vytvořena specializovaná mobilní aplikace, která bude sloužit k pořizování geotagovaných fotografií i k přenosu informací mezi Zadavatelem a žadatelem nebo komunikaci s terénními inspektory Xxxxxxxxxx.

Vystavené služby pracující s prostorovými daty musí splňovat OGC standardy, aby byla zajištěna bezproblémová výměna informací mezi jednotlivými dílčími systémy celkového řešení XXXX.

Pohled na architekturu informačního systému, do kterého bude řešení dle této VZ integrováno, zachycuje následující obrázek.

Jak je patrné z obrázku níže, projekt IS XXXX dodává integrační platformu a logiku celého systému, zatímco uživatelské rozhraní je tvořeno Portálovými aplikacemi XXXX, webovými aplikacemi služby GT FOTO a také mobilní aplikací poskytovanou službou GT FOTO. Portálové aplikace XXXX budou dodávány v rámci VZ na zajištění služeb Portálového systému SZIF, mobilní aplikace a práce s fotografiemi a mobilními zařízeními bude dodávána v rámci VZ GT FOTO a služby zpracování satelitních snímků bude dodávat projekt SAMAS. Celé řešení je třeba integrovat se stávajícím IS Zadavatele a informačními systémy pracujícími na MZe. V průběhu řešení budou muset všichni poskytovatelé jednotlivých nově vytvářených částí cílového řešení XXXX velice úzce spolupracovat, jejich práce poběží současně.

Obrázek 3 Architektura cílového systému XXXX

3. Uživatelé a jejich role ve vztahu ke službě GT GOTO

Uživatelem služby GT FOTO může být:

1. Zaměstnanec Zadavatele v roli:

   1. Uživatele služby GT FOTO s oprávněními

      1. Správce svého profilu – je oprávněn zaregistrovat svá mobilní zařízení, spravovat své údaje.

      2. Řešitele úkolu – může úkol zobrazit a plnit, odmítnout jej, požádat o změnu termínu, zahájit a ukončit plnění, označit za splněný. Má-li k tomu oprávnění, pak může úkol delegovat na jiného uživatele ve své pravomoci.

      3. Zadavatele úkolu – určuje řešitele úkolu, zadavatel úkolu může sledovat stav plnění zadaného úkolu a schválit/neschválit jeho splnění, může zopakovat zadání úkolu, zpracovává reakce na odmítnutí zadaného úkolu nebo požadavky na jeho změnu. Může úkol zrušit (za splnění definovaných pravidel).

      4. Zadavatele delegovaného úkolu – může sledovat stav plnění delegovaného úkolu, zpracovává reakce na odmítnutí úkolu nebo požadavky na jeho změnu.

      5. Čtenáře fotografií – může fotografie v rozsahu svých práv zobrazovat, ale ne je měnit nebo vymazat. Může k fotografiím přidávat štítky a poznámky.

   2. Správce fotografií – může spustit skartační proceduru

   3. Správce přístupových oprávnění služby GT FOTO – je oprávněn vytvářet role na straně GT FOTO a přiřazovat a měnit jejich oprávnění.

2. Žadatel v roli

   1. Oprávněný uživatel – je uživatel, který je oprávněný jednat za žadatele (JI) s oprávněními:

      1. Správce svého profilu – uživatel má profil na Portálovém systému SZIF, je oprávněn si zaregistrovat svá mobilní zařízení, spravovat své údaje. Každý uživatel registrovaný na Portálovém systému SZIF je správcem svého profilu.

      2. Správce uživatelů patřících ke shodnému JI. Tj. je oprávněn zaregistrovat další uživatele patřící ke stejnému JI a nastavovat jejich oprávnění.

      3. Řešitele úkolu. Může úkol zobrazit a plnit, odmítnout jej, požádat o změnu termínu, zahájit a ukončit plnění, označit úkol za splněný. Má-li k tomu oprávnění, pak může úkol delegovat na jiné uživatele registrované k danému JI a plnění delegovaných úkolů sledovat. Má přístup na Portál pro XXXX a může úkoly spravovat i prostřednictvím Portálových aplikací XXXX.

      4. Zadavatele delegovaného úkolu – určuje řešitele delegovaného úkolu, může sledovat stav plnění delegovaného úkolu a schválit/neschválit jeho splnění, zpracovává reakce na odmítnutí úkolu nebo požadavky na jeho změnu, může delegovaný úkol zrušit.

      5. Čtenáře fotografií – může v rozsahu svých práv zobrazovat fotografie (jak na Portálovém systému SZIF, tak v mobilní aplikaci), ale ne je měnit nebo vymazat.

      6. Správce mobilních zařízení – je oprávněn registrovat anonymní mobilní zařízení, měnit jejich přihlašovací údaje.

   2. Pověřený uživatel – je uživatel zaregistrovaný Oprávněným uživatelem prostřednictvím Portálového systému SZIF s těmito oprávněními:

      1. Správce svého profilu – uživatel má profil na Portálovém systému SZIF, je oprávněn si zaregistrovat svá mobilní zařízení, spravovat své údaje.

      2. Rozsah dalších jeho oprávnění je nastaven Oprávněným uživatelem v rozsahu oprávnění, které sám Oprávněný uživatel má.

   3. Anonymní uživatel, tj. virtuální uživatel pracující se zaregistrovaným mobilním zařízením, které není přiřazeno ke konkrétnímu uživateli registrovanému v systému IS Zadavatele, ale je přiřazeno k JI žadatele. Víme tedy, k jakému žadateli (právnické osobě) dané mobilní zařízení patří, ale není známa fyzická osoba, která s daným zařízením pracuje. Anonymní uživatel může zobrazit úkol, zahájit a ukončit jeho plnění, označit jej za splněný, provádět úkony potřebné k plnění úkolu, tj. pořizovat fotografie, případně vyplnit požadované údaje, úkol odmítnout nebo požádat o změnu termínu. Anonymní uživatel může prohlížet jen úkoly a fotografie uložené na mobilním zařízení, které používá. Nemá přístup do Portálového systému SZIF ani do úložiště služby GT FOTO. Za úkony prováděné anonymním uživatelem plně odpovídá příslušný Oprávněný uživatel, respektive osoba jednající za žadatele jako právnickou osobu (za JI).

Registrace uživatele a nastavení jeho oprávnění se děje na Portálovém systému SZIF. Služba GT FOTO musí umět ověřit uživatele pomocí služby autentizace poskytované IS Zadavatele a převzít z IS Xxxxxxxxxx informaci o jeho příslušnosti k JI nebo k Zadavateli, rolích a oprávněních. Toto se netýká anonymního uživatele mobilního zařízení. Identifikace mobilního zařízení je plně v režii služby GT FOTO. Anonymní uživatel není registrován na Portálovém systému SZIF.

4. Koncept úkolů a front

Ve specifikaci uživatelských požadavků na celkové řešení XXXX se v řadě míst vyskytuje požadavek na zadání úkolu, v některých situacích se úkol nazývá „žádost o spolupráci“. V tomto textu budeme používat pro obě situace termín úkol.

Úkol typicky zadává pracovník Zadavatele žadateli – zasílá žádost o spolupráci (pořízení fotografií, poskytnutí dokumentů, vyžádání jiné součinnosti), nebo je úkol zadáván inspektorovi Xxxxxxxxxx v souvislosti s prováděnou kontrolou. Pokud tento koncept uplatníme důsledně, pak jsou úkolem i požadavky na provedení kontroly (KNM, KNP, PN) nebo provedení Follow-up aktivity. Úkoly mohou být generovány i automaticky IS XXXX nebo některým z modulů informačního systému Zadavatele.

Zadavatelem úkolu může být jak uživatel, ať je to pracovník Zadavatele nebo pracovník žadatele, tak automat nebo můžeme říci algoritmus pracující v rámci IS XXXX případně obecněji kdekoli v systému IS Zadavatele.

Informační systém IS XXXX podporuje plánování a přidělování úkolů pracovníkům, kteří je mají vykonat.

Úkol se po svém vytvoření nalézá v nějaké frontě na zpracování nebo v archivu.

Fronty mohou být různého typu v závislosti na tom, v jaké životní fázi se úkol nalézá a jakého je typu.

Fronta může být:

• Osobní – v ní se nalézají úkoly, které má plnit daný uživatel, jemuž byl úkol zadán.

• Fronta žadatele, ve které se nalézají úkoly, které má plnit daný žadatel (což může být jak právnická, tak fyzická osoba) – fronta příslušná k jeho JI. Oprávněný pracovník žadatele jednající za JI může úkoly plnit sám, nebo delegovat práva na přístup k této frontě na více svých pracovníků. Pracovníka s právem správy fronty úkolů příslušné k JI a s právem spravovat organizační strukturu a uživatele patřící k danému JI nazvěme Zodpovědným pracovníkem. Zodpovědný pracovník žadatele může definovat organizační jednotky a registrované uživatele na tyto organizační jednotky navázat. Pak bude mít možnost delegovat úkoly na organizační jednotky a uživatelé na tyto jednotky navázaní, neuvidí úkoly jiných organizačních jednotek téhož žadatele. Jeden uživatel může být navázán na více organizačních jednotek.

• Fronta vázaná na mobilní zařízení/anonymního uživatele – v této frontě jsou úkoly delegované uživatelem, který má přístup k frontě žadatele a právo úkoly delegovat. Úkoly plní ten, kdo má přístup k danému mobilnímu zařízení, které může být sdíleno více osobami, tj. systém identifikuje jen zařízení a fakt, že se jeho uživatel přihlásil platnými přihlašovacími údaji.

• Týmová – fronta úkolů, které mají plnit pracovníci určitého útvaru, úkoly pro dvojici terénních inspektorů, kteří pracují spolu a vyjíždí na kontroly.

• Fronta na provedení určitých činností/ čekání na událost – naplánování úkolu, čekání na schválení plánu kontrol, schválení splnění úkolu. Činnost může být prováděna manuálně, poloautomaticky nebo automaticky.

Úkol je přidělen řešiteli a je průběžně sledován stav jeho plnění.

O splnění úkolu bude jeho zadavatel informován notifikační zprávou kanály zvolenými v jeho profilu.

Řešitel může být:

• Konkrétní osoba (úkol je zaslán do její osobní fronty).

• Anonymní – držitel daného mobilního zařízení, které si může předávat více osob.

• Tým – úkol je zaslán do týmové fronty, ze které si úkoly ke splnění může vybírat více uživatelů, ale v okamžiku, kdy úkol z této fronty uživatel vybere, stává se jeho osobním úkolem.

Úkoly mohou být různých typů a v závislosti na typu mohou mít i různé atributy. Úkol provést Follow-up aktivitu nese specifikaci této aktivity a žádosti, k jejíž kontrole aktivita náleží, úkol pořízení fotografie pak nese souřadnice bodu, ve kterém má být fotografie pořízena a azimut (bude-li to třeba i náklon) pořízení fota a další parametry.

Úkol může být jednoduchý, nebo se může sestávat z více kroků – k jedné AP může být třeba pořídit více fotografií, v rámci jedné kontroly může být nutné provést více úkonů různých typů – pořídit fotografie + vyplnit formulář.

Podrobnější popis atributů jednotlivých typů úkolů a jejich kroků je uveden v kapitole 4.4 Přílohy č. 6_ Technická dokumentace - NDA ve vnořeném excelovém souboru. Tento popis je základním popisem záměru Zadavatele a bude v rámci realizace projektu průběžně rozšiřován o další potřebné typy úkolů, kroků úkolů a jejich atributy a spolu s tím budou přibývat i business pravidla pro práci s těmito typy úkolů a kroků.

Zadavatel preferuje, aby bylo možno bez programování definovat nové typy úkolů a kroků úkolů včetně pravidel, co je a co není povoleno a za jakých podmínek. Výjimkou je nutnost naprogramování operace, která není dosud v systému k dispozici.

K úkolům i fotografiím je možno přistupovat jak prostřednictvím Portálových aplikací XXXX, tak prostřednictvím mobilní aplikace.

Výše popsanou situaci ilustruje následující obrázek.

Obrázek 4 Uživatelé a jejich přístup k portálu a mobilní aplikaci

3. Správa úkolů

Služby pro práci s úkoly procházejí napříč celkovým řešením XXXX – hlavní logika zpracování úkolů a jejich data leží primárně v IS XXXX, ale lze k nim přistupovat prostřednictvím uživatelského rozhraní tvořeného Portálovými aplikacemi XXXX i prostřednictvím mobilní aplikace.

Úkoly musí být možno spravovat jak prostřednictvím Portálových aplikací XXXX, tak v mobilní aplikaci dodávané v rámci služby GT FOTO. Kromě toho mohou být generovány, plánovány a přidělovány automaticky funkcemi IS XXXX.

Protože může docházet ke změnám úkolů jak v mobilní aplikaci, tak v IS XXXX, musí být zajištěna synchronizace těchto změn (podotkněme, že uživatel pracující na Portálovém systému SZIF pracuje s funkcemi realizovanými v IS XXXX, s daty databáze IS XXXX a také s funkcemi nad frontami a úkoly realizovanými jak v IS XXXX, tak na serveru služby GT FOTO).

Týž úkol může být přidělen více řešitelům, např. na kontrolu jezdí dva inspektoři společně, plní stejný úkol a v případě, že má úkol více kroků, každý z nich může řešit jiné jeho kroky.

IS XXXX zpracovává fronty náležející zaměstnancům Zadavatele, Oprávněným uživatelům (frontu k JI) a Pověřeným uživatelům. Fronty úkolů anonymních uživatelů zpracovává služba GT FOTO. Zaměstnanec Zadavatele zadává úkoly do jedné fronty žadatele (na jeho JI) vedené primárně k Oprávněnému žadateli. Tuto frontu může spravovat i Pověřený uživatel, pokud na něj Oprávněný uživatel toto právo delegoval. V mobilní aplikaci je tedy třeba umožnit výběr fronty úkolů, se kterou uživatel pracuje, aby bylo možno odlišit, jestli pracuje s frontou na JI nebo s frontou svých osobních úkolů. Obdobná situace může nastat i u zaměstnanců Zadavatele. Člen týmu si může z týmové fronty vybrat úkol a stát se jeho řešitelem. Tj. mobilní aplikace musí podporovat práci s více frontami úkolů.

Aktivity nad úkoly mohou vznikat na základě plynutí času a průběhu procesů v celkovém řešení XXXX. Některý úkon může mít za následek zrušení úkolu nebo některého z jeho kroků, splněním všech kroků úkolu se změní stav úkolu na splněno, pokud řešitel úkol nesplní a čas překročí zadaný termín, mění se stav úkolu na nesplněný. V podrobné analýze budou v rámci dodávky Poskytovatele tato pravidla a závislosti popsány do větší podrobnosti.

O přidělení úkolu a o dalších změnách jeho stavu může být, přeje-li si to, uživatel informován notifikací zasílanou do jednoho nebo více notifikačních kanálů nastavených v jeho profilu na Portálovém systému SZIF. Podotkněme, že notifikační služba (notifikátor) je součástí Portálového řešení XXXX, a tedy není předmětem dodávky Poskytovatele této VZ, ale notifikace generované logikou služby GT FOTO nebo mobilní aplikace musí na notifikátor zaslat služba GT FOTO. Notifikátor pak rozhodne na základě nastavených preferencí uživatele, jakými kanály a jestli vůbec pošle notifikaci uživateli. Může vytvářet i souhrnné zprávy za zvolené období.

V tomto textu jsou funkce, až na výjimky, popsány tak, že zpracovávají jeden úkol (základní operace nad úkoly) nebo popisují operaci nad frontou úkolů, v uživatelském rozhraní bude podpora pro hromadné akce – tj. vyzvednutí skupiny úkolů z fronty, přiřazení více úkolů zvolenému řešiteli/řešitelům, nastavení shodných hodnot atributů skupině úkolů nebo vykonání jiné operace nad skupinou úkolů na základě výstupů implementační analýzy. Tyto záležitosti budou řešeny v rámci návrhu uživatelského rozhraní.

Úkoly a jejich podstatné změny budou archivovány po dobu minimálně 3 let a jejich výmaz/skartace podléhá obdobným pravidlům jako výmaz/skartace fotografií, tj. vzhledem k provázanosti úkolů a fotografií je skartace řešena jedním skartačním řízením. V případě, že je v dané věci veden spor, je log úkolů a jejich stavů součástí dokumentace pro právníky.

Výmaz úkolu v mobilní aplikaci je v režii uživatele, ale výmaz v mobilní aplikaci je výmaz pouze lokální, netýká se dat uložených službou GT FOTO, která zajišťuje dlouhodobé uložení fotografií nebo jejich uložení v systému IS XXXX, pro které platí skartační podmínky dle odstavce výše. Tj. jednou odeslanou fotografii již uživatel mobilní aplikace nevymaže.

Práce s úkoly prochází celkovým řešením XXXX napříč. Zasahuje nejen IS XXXX, ale i moduly Portálových aplikací XXXX a službu GT FOTO. Viz obrázek níže.

Obrázek 5 Zpracování úkolů v systému XXXX

Služba GT FOTO, která poskytuje také mobilní aplikaci, musí zajistit, aby v této aplikaci bylo nad úkoly možno provádět:

• úkony zobrazení úkolu a jeho kroků,

• akceptaci/neakceptaci úkolu – žádost o jeho změnu,

• zahájení a ukončení plnění,

• označení úkolu za splněný,

• pořídit k danému úkolu nebo kroku úkolu fotografii v souladu s předepsanými parametry (místo, azimut, sklon + požadované nastavení přístroje, kterým je foto pořizováno),

• otevřít link uvedený v úkolu a umožnit vyplnit formulář na Portálovém systému SZIF nebo zobrazit/stáhnout dokument tam uložený¹,

• delegování úkolu jako celku nebo delegovat splnění jen některých jeho kroků.

Následující obrázek zachycuje návrh stavů úkolů v průběhu jejich životního cyklu.

Obrázek 6 Stavy úkolů v průběhu jejich životního cyklu

1. Další požadavky na funkce a uživatelské rozhraní

   1. Zadání úkolu operátorem Zadavatele

Zadání úkolů/žádostí o spolupráci bude probíhat v prostředí IS XXXX s možností využití mapového okna. Na službu GT FOTO budou odesílána zadání úkolů, případně jejich změny. Služba GT FOTO tyto informace ukládá a propaguje relevantní informace do mobilní aplikace. Informace o změnách úkolů a jejich stavů, které nastaly na její straně zasílá služba GT FOTO do IS XXXX.

Po založení úkolu se úkol odešle z IS XXXX do služby GT FOTO a následně do mobilní aplikace. Úkoly je možno zobrazit i v Portálových aplikacích XXXX na účtu žadatele nebo pracovníka Zadavatele. Podle nastavení v profilu uživatele jsou případně zasílány notifikace.

Úkol bude možné označit jako úkol, u kterého není požadována aktivita daného uživatele (například, pokud se pracovník Zadavatele rozhodne, že foto si pořídí sám, a chce o tom informovat žadatele) a daný uživatel je pouze o existenci úkolu a jeho stavu informován. V takovém případě se uživateli zobrazí informace, že nemá tento úkol plnit, a to jak v mobilní aplikaci, tak na Portálovém systému SZIF.

Úkol bude možné zopakovat v případě, že zadavatel zjistí, že pořízené foto není použitelné pro rozhodnutí, nebo plnění nesplňuje zadání z jiného důvodu. Zadání úkolu lze zopakovat s jiným termínem plnění. Uživateli bude opakovaně zadaný úkol odeslán znovu společně s notifikační zprávou.

Pokud uživatel nesplní úkol v požadovaném termínu, bude úkol označen jako nesplněný. Nedojde tím k jeho smazání, ale vrací se k zadavateli s informací, že jej uživatel do termínu nesplnil. Následně je na zadavateli úkolu, co s ním provede dál. Úkoly, u kterých vypršel čas pro jejich splnění se musí zadavateli úkolu zvýraznit a on se rozhodne, zda úkol nyní přidělí sobě, nebo jinému pracovníkovi či bude postupovat jinak. Může ho opět zadat žadateli se změněným termínem splnění.

2. Správa úkolů na straně uživatele

K úkolům lze přistupovat ze dvou míst. Pro lepší přehled a s bohatší podporou prostřednictvím Portálového systému SZIF a dále prostřednictvím mobilní aplikace. O zadání úkolu bude žadatel informován notifikacemi zasílanými do kanálů, které si pro zasílání notifikací nastaví.

Portálový systém SZIF bude sloužit primárně k přehlednější správě úkolů, budou zde rozlišeny úkoly splněné a nesplněné, k prohlížení mapové aplikace s vyznačením míst, které zadal pracovník regionálního pracoviště Zadavatele (RO), a s dalšími podstatnými informacemi o fotografiích, které mají být nebo byly pořízeny. Úkoly bude možno filtrovat. Mapové pole bude mít kromě informací o úkolech i vhodná podkladová data (ortofoto, ZM 10, LPIS, AP, …). Úkol bude možné rovnou odmítnout, aby pracovník RO věděl, že na fotografie nemusí čekat, nebo požádat o jiný termín plnění.

Uživatel bude moci vkládat k úkolům i pořízeným fotografiím komentáře nebo také přiřadit/delegovat jednotlivé úkoly dalším konkrétním pracovníkům – na konkrétní zaregistrované zařízení, a to jak v mobilní aplikaci, tak prostřednictvím Portálového systému SZIF.

Zadané úkoly a pořízené fotografie budou zobrazovány s využitím mapového okna, které je součástí Portálové aplikace XXXX, tak, aby žadatel nebo pracovník Zadavatele měli přehled, jaké fotografie byly pořízeny a v jakých místech a v jakém stavu jsou zadané úkoly a ke kterým místům se vztahují (pokud jsou na místo vázány). Úkoly, které neobsahují souřadnice místa plnění a jsou vázány na žadatele, se zobrazují v místě sídla žadatele.

3. Funkce: „Vytvoření úkolu“

Funkce vytváří nový úkol zadaného typu, vytváří jeho datovou strukturu a vyplní parametry, které jsou v okamžiku tvorby dostupné. V rámci dalšího zpracování mohou být doplněny, změněny další atributy úkolu.

4. Funkce: „Změna stavu úkolu“

Funkce mění stav úkolu dle zadaného parametru. Kontroluje pravidla určující povolené změny stavu.

5. Funkce: „Změna atributů úkolu“

Funkce mění/doplní zadané atributy úkolu. Kontroluje pravidla určující povolené změny.

6. Funkce: „Delegování úkolu“

Funkce vytváří kopii úkolu a přiřazuje ji novému řešiteli. Kontroluje pravidla určující, kdy je to povoleno. Delegovaný úkol (synovský) je propojen s originálem (otcovský úkol) a změny stavu synovského úkolu jsou následně synchronizovány do otcovského (principiálně takto lze vytvořit řetěz několika úkolů).

Delegovat lze úkol jako celek na jednoho řešitele nebo jej lze rozdělit na několik řešitelů a každý z nich řeší jen některé kroky, pak se jedná o delegování části úkolu. Lze delegovat část úkolu a zbytek může plnit řešitel sám. Zodpovědnost za splnění úkolu zůstává na původním řešiteli, kterému byl úkol přidělen.

7. Funkce: „Odmítnutí úkolu“

Funkce umožňuje řešiteli odmítnout plnění úkolu (s uvedením důvodu) a informuje o tom zadavatele, který úkol zadal. Je povinnost uvést důvod.

8. Funkce: „Žádost o změnu úkolu“

Funkce umožňuje řešiteli požádat zadavatele o změnu úkolu. Odesílá zadavateli úkolu informaci o požadovaných změnách úkolu. Může žádat o změnu libovolných parametrů nebo kroků, nebo požadovat jiné zadání. Je povinnost uvést textový komentář.

9. Funkce: „Žádost o změnu termínu úkolu“

Funkce umožňuje řešiteli požádat zadavatele o změnu termínu úkolu. Odesílá informaci o preferovaném termínu. Tato funkce je podmnožinou předchozí, a je zde proto, že předpokládáme, že požadavek na změnu termínu může být častý a na jeho jednoduché uplatnění by mělo být pamatováno i v uživatelském rozhraní. Je povinnost uvést textový komentář.

10. Funkce: „Změna termínu úkolu“

Funkce provede změnu termínu úkolu dle zadaného parametru. Může proběhnout automaticky, pokud požadovaný termín je v zadaných mezích a zadavatel to povolil. Není-li provedena automaticky, umožní zadavateli změnit termín manuálně, vrátit úkol do plánovacího procesu nebo jej zrušit, případně změnu termínu odmítnout. Textový komentář je volitelný.

11. Funkce: „Změna úkolu na základě žádosti“

Funkce zobrazí požadavky na změnu úkolu a umožní zadavateli provést jeho změny, změny odmítnout, nebo úkol zrušit.

12. Funkce: „Zařazení úkolu do fronty“

Funkce zařadí úkol do zadané fronty. Vyplní příslušné identifikátory řešitele nebo zařízení a v závislosti na konkrétním případu i jiné atributy.

13. Funkce: „Správa fronty“

Funkce umožňuje uživateli oprávněnému frontu spravovat všechny povolené úkony nad úkoly v dané frontě. Pro jednotlivé typy front bude vždy definován sortiment úkonů, které lze nad danou frontou provádět (fronta sloužící k plánování úkolů povoluje jiné úkony než osobní fronta úkolů, které má uživatel plnit).

Řešitel nad svou osobní frontou může úkoly zobrazovat, řadit podle zvolených atributů, může úkol akceptovat nebo odmítnout, požádat o jeho změnu, zahájit jeho plnění nebo plnění ukončit, označit úkol za splněný.

Plánovač provádí nad frontou úkolů k naplánování úkony, které mají za výsledek přiřazení úkolů do osobních nebo týmových front a určení požadovaných termínů splnění.

Vedoucí, který kontroluje plnění úkolů může úkoly přeplánovat, zrušit, ukončit jejich plnění bez ohledu na to, že jsou rozpracované, v rámci kontroly změnit stav splněného úkolu na nesplněný a vrátit jej řešiteli k dopracování. Může své osobní úkoly delegovat buď zcela nebo zčásti.

14. Funkce: „Zrušení úkolu“

Funkce zruší úkol. V rámci detailní analýzy bude stanoveno, které typy úkolů a v jakých stavech lze zrušit a vymazat a které musí zůstat archivovány a v jakých situacích musí být u zrušení uveden povinně důvod.

15. Funkce: „Vytvoření kroku úkolu“

Funkce vytvoří krok úkolu (datovou strukturu + vyplnění známých atributů) a prováže ho se zadaným úkolem.

16. Funkce: „Změna stavu kroku úkolu“

Funkce mění stav kroku úkolu dle zadaného parametru. Kontroluje pravidla určující povolené změny stavu.

17. Funkce: „Změna atributů kroku úkolu“

Funkce mění/doplní zadané atributy kroku úkolu. Kontroluje pravidla určující povolené změny.

18. Funkce: „Zrušení kroku úkolu“

Funkce zruší krok úkolu. V rámci detailní analýzy bude stanoveno, které typy kroků úkolů a v jakých stavech lze vymazat/zrušit a které musí zůstat archivovány, případně jejich změny logovány a dlouhodobě uchovány.

19. Funkce: „Zahájení plnění úkolu“

Funkce aktivovaná stisknutím tlačítka na mobilní aplikaci nebo kliknutím na tlačítko v uživatelském rozhraní Portálových aplikací XXXX odešle do IS XXXX kód zahájení úkolu, jeho identifikátor + datum a čas tohoto úkonu.

20. Funkce: „Ukončení plnění úkolu“

Funkce aktivovaná stisknutím tlačítka na mobilní aplikaci nebo kliknutím na tlačítko v uživatelském rozhraní Portálových aplikací XXXX odešle do IS XXXX kód ukončení/splnění úkolu řešitelem, identifikátor úkolu + datum a čas tohoto úkonu.

Plnění úkolu může být ukončeno z různých důvodů. Ukončením plnění úkolu řešitelem (viz odstavec výše), zásahem třetí osoby (zadavatel úkol zruší), akcí automatu (algoritmus na základě jiných událostí vyhodnotí úkol jako již nepotřebný – žadatel sám ze svého rozhodnutí pořídil fotografii k Follow-up aktivitě a inspektor ji nemusí pořizovat) nebo uplynutím limitního času (plnění úkolu ztratilo smysl). V okamžiku ukončení plnění úkolu mohou být splněny žádné nebo jen některé kroky úkolu.

21. Funkce: „Kontrola splnění úkolu“

V závislosti na typu úkolu a jeho kroků je automaticky nebo manuálně zkontrolováno, zda byl úkol splněn. Výstupem je informace Splněn/Splněn v termínu/Nesplněn. V případě nesplnění je možno úkol vrátit s vysvětlujícím textem řešiteli.

22. Funkce výmaz úkolu

Rozlišujeme dva režimy výmazu úkolu.

1. Výmaz úkolu z evidence v IS XXXX. Tento výmaz se provádí na základě skartační procedury, která slouží k výmazu dat po uplynutí skartační doby. Skartační procedura na výmaz úkolů probíhá ve spojitosti se skartační procedurou na geotagované fotografie (fotografie je uchována včetně úkolu, kterým byla zadána).

2. Výmaz úkolu z individuální fronty uživatele. Z individuální fronty může uživatel úkol vymazat kdykoli (v rámci detailní analýzy mohou vzniknou případná omezení, třeba že nelze vymazat zadaný úkol před termínem jeho splnění). V profilu uživatele je možno nastavit automatický výmaz splněných nebo ukončených úkolů po určité době po jejich splnění nebo ukončení. Totéž lze nastavit i pro fronty úkolů zadaných anonymnímu uživateli. Nastavit tento parametr pro anonymního uživatele (dané mobilní zařízení) může uživatel s oprávněním takového uživatele registrovat.

4. Geotagované fotografie

Jak již bylo výše uvedeno, geotagované fotografie jsou v celkovém řešení XXXX důkazními prostředky a je třeba, aby byly zabezpečeny proti změně, a to tak, že musí být možno prokázat i s odstupem času, že fotografie ani níže uvedená metadata této fotografie změněny nebyly. Způsob zabezpečení fotografií a jejich metadat proti změně a bezpečného dlouhodobého uložení navrhne ve své nabídce dodavatel.

1. Pořizování fotografií

Pořízení geotagované fotografie probíhá prostřednictvím mobilní aplikace dodávané na základě této VZ.

Jak žadatel, tak terénní inspektor Xxxxxxxxxx mohou pořizovat geotagované fotografie na základě zadaného úkolu, nebo z vlastního rozhodnutí.

Úkoly zadávané terénním inspektorům Zadavatele a žádosti o spolupráci zasílané žadatelům jsou vytvářeny prostředky IS XXXX a předávány službě GT FOTO (dodávané na základě této VZ) prostřednictvím rozhraní.

Geotagované fotografie jsou evidovány minimálně s vazbou na uživatele a AP. Jsou-li pořizovány ke splnění úkolu, pak s vazbou na tento úkol.

Pořízená fotografie musí obsahovat veškeré nezbytné náležitosti, aby ji bylo možné prostorově přiřazovat k AP v rámci IACS nebo k projektu/žádosti/katastrální parcele. Metadata ukládaná s fotografií jsou uvedena dále.

V případě pořízení fota žadatelem z jeho rozhodnutí bude na straně IS XXXX foto standardně přiřazeno ke konkrétnímu dostupnému obsahu (AP, projekt, žádost) odpovídajícímu geoprostorovému umístění místa pořízení fotografie.

V režimu, kdy bude přihlášen zaměstnanec Zadavatele, bude přiřazení volitelné s uvedením dostupných možností hodnot jednotlivých parametrů (výběry ze seznamů v rámci aplikace) včetně možnosti nezvolení hodnoty žádného prvku.

Aplikace musí zabezpečit pořízení fotografií v požadované kvalitě, v případě zadaného úkolu, pak musí být fotografie pořízena v místě zadaném v úkolu (jeho definovaném okolí) a pod zadaným azimutem (v rámci dané tolerance) a náklonem zařízení použitého k pořízení fotografie.

Plnění musí být navrženo tak, aby bylo možno aplikaci v rámci dalšího rozvoje rozšířit o tuto funkčnost:

Rozvojový požadavek: Při focení bude obrazovka obsahovat rozšířenou realitu, která bude zobrazovat hranice LPIS, AP či další vhodné vrstvy. Bude zde možné navigovat i na směr, kterým má žadatel fotit tak, aby se jej podařilo co nejlépe navést do správné pozice a na správný směr focení.

2. Ukládání vyhodnocování a správa fotografií

Služba GT FOTO poskytuje úložiště fotografií, které musí zabezpečit, že fotografie nemůže být po dobu uložení změněna a smazána může být až po uplynutí skartační doby, a to pouze skartační procedurou prováděnou uživatelem s patřičným oprávněním.

Služba GT FOTO musí disponovat prostředky, které umožní prokázat, že fotografie ani její metadata připojená k ní v okamžiku vytvoření fotografie nebyly změněny.

Je nutné dodržovat předpisy týkající se archivu kontrolních zjištění, se kterými bude Poskytovatel seznámen.

Před odesláním fotografie z mobilní aplikace do úložiště služby GT FOTO se kontroluje, zda byly splněny všechny podmínky, kterým má daná fotografie vyhovovat. Další kontrola proběhne na straně služby GT FOTO. Rozsah těchto podmínek je definován atributy úkolu, ke kterému fotografie náleží.

Fotografie se považuje za uloženou v okamžiku, kdy služba GT FOTO uložení fotografie v úložišti potvrdí.

O úspěšném/neúspěšném přenosu fotografie a jejím uložení bude uživatel informován na obrazovce svého zařízení. O přenosech bude veden záznam. Jak z mobilní aplikace, tak na serveru bude možno protokol o přenosech prohlížet.

Poskytovatel je povinen provádět statistickou analýzu protokolů o přenosech a sledovat počet neúspěšných a úspěšných přenosů a četnost výskytu jednotlivých chyb. Tyto statistiky sdílí se Zadavatelem.

Uživatel má možnost si data, ke kterým má přístupová oprávnění, ze služby GT FOTO stáhnout a uložit na své lokální zařízení (v tomto případě i PC, ze kterého může přistupovat ke službě GT FOTO prostřednictvím Portálového systému SZIF).

Uživatel může fotografie i úkoly prohlížet jak v mobilní aplikaci, tak prostřednictvím Portálového systému SZIF. Má přístup jen k fotografiím, ke kterým má přístupová oprávnění. Může je označovat, provádět výběry a povolené operace provádět se skupinou fotografií. V zobrazení je může filtrovat podle hodnot zvoleného seznamu atributů. Může volit zobrazení tabulkové nebo zobrazení nad mapovými podklady. Pokud volí zobrazení nad mapovými podklady, může dělat výběry prostřednictvím výběru oblasti myší, a to jak výběrem pomocí polygonu, tak třeba výběrem klikáním na jednotlivé parcely, úkoly nebo fotografie. Oba způsoby výběru bude možno kombinovat. Pořízené fotografie a úkoly jsou na mapě vyznačeny ikonami. Lze volit i zobrazení, které ukazuje miniatury fotografií. Miniatura včetně zvolené sady atributů se ukazuje i při najetí myší na ikonu pořízené fotografie/fotografií (na jednom místě může být pořízeno fotografií více).

Dvojklikem na ikonu úkolu se zobrazí detaily úkolu, dvojklikem na ikonu/miniaturu fotografie se zobrazí všechny fotografie pořízené v daném místě a to tak, že každá z nich se zobrazí v samostatném okně.

K úkolům i fotografiím může uživatel přidávat tagy. Tagy jsou primárně viditelné jen pro toho uživatele, který je vytvořil, ale může nastavit viditelnost i pro další uživatele, kteří je mohou sdílet. Pomocí tagů lze fotografie filtrovat. (Lze takto třeba označit fotografie pro kontrolu kvality, nebo fotografie použité pro kontrolu v daném případě.)

Přístup k fotografiím i úkolům bude řízen dle oprávnění jednotlivých rolí a uživatelů.

3. Prohlížení fotografií

Služba GT FOTO poskytuje webovou aplikaci pro prohlížení fotografií.

Do webové aplikace mají uživatelé standardně přístup po autentizaci uživatele Portálem pro XXXX – uživatel je přihlášen do Portálového systému SZIF a přechází do aplikace pro prohlížení fotografií, která se mu otevírá v okně jeho uživatelského rozhraní. Informace i jeho identitě je předávána Portálovým systémem SZIF. Druhou možností je, že se uživatel přihlásí přímo do samostatné webové aplikace služby GT FOTO a je ověřen prostředky, které poskytuje IS Zadavatele (resp. IDM Zadavatele).

Fotografie lze zobrazovat jako seznamy řazené dle hodnot vybraných atributů (včetně zobrazení těchto hodnot) nebo je zobrazovat jako miniatury doplněné hodnotami vybraných atributů (opět s volitelným řazením).

Rozsah fotografií, které uživatel vidí je omezen jeho oprávněními.

Uživatel může také volit zobrazení fotografií na mapě. Fotografie se pak zobrazují v závislosti na volbě měřítka mapy jako šipky ukazující, v jakém místě a jakým směrem byla fotografie pořízena. Při zmenšení zobrazovaného prostoru změnou měřítka se u šipek objeví miniatury fotografií. Kliknutím na miniaturu nebo na šipku, se zobrazí příslušná fotografie v samostatném okně.

Zastavení myši na miniatuře fotografie vyvolá zobrazení jejích metadat. K identifikátorům budou dotaženy hodnoty potřebné pro uživatele (např. k JI název uživatele).

4. Vyhodnocení geotagovaných fotografií

Vyhodnocení geotagovaných fotografií může být, vzhledem k množství zasílaných fotografií, velmi časově náročná operace. Proto je vhodné v první fázi přenechat co největší díl práce na automatické vyhodnocení a následně provádět kontrolu tohoto automatického mechanismu. V druhé fázi pak provádět manuální vyhodnocení zbývajících fotografií, které systém nedokázal automaticky vyhodnotit.

Ukládání dat bude probíhat taktéž dvoustupňově. V první fázi (na straně datového úložiště služby GT FOTO) se budou ukládat všechna přijatá data. Do informačního systému Zadavatele budou přenesena data, která byla využita v rozhodovacím procesu a jsou nutná pro další aktivity procesu kontroly.

Při zobrazení náhledu fotografie bude vyznačeno, zda byl, nebo nebyl rozpoznán její obsah. Bude možno volit režim, kdy bude spolu s miniaturou zobrazována plodina rozpoznaná na fotografii (ať již automaticky, nebo lidskou obsluhou). Po kliknutí bude vyvoláno zobrazení fotografie v plné kvalitě včetně veškerých dostupných metadat (JI, žadatel, kontaktní osoba, číslo žádosti, projektu, úkol a další atributy specifikované v této zadávací dokumentaci). K identifikátorům budou dotaženy hodnoty potřebné pro uživatele (např. k JI název uživatele). Uložení foto včetně metadat musí být realizováno ve všech okamžicích zpracování v nezměněné podobě, tedy jak obrazová část, tak metadata musí být u fotografie po jejím odeslání z mobilní aplikace stále stejná.

5. Požadované funkce

   1. Automatické vyhodnocení kvality geotagovaných fotografií

Fotografie se musí posoudit z technického i kvalitativního hlediska.

Vyhodnocení dle technického hlediska zahrnuje kontrolu technických parametrů přístroje při pořizování fotografie. Hodnoty těchto parametrů jsou uvedeny v tabulce níže.

Automatické vyhodnocení kvality fotografie proběhne v omezené míře hned po jejím pořízení na úrovni mobilní aplikace, aby uživatel dostal rychlou zpětnou vazbu a nevyhovující (neostrou, příliš tmavou nebo světlou) fotografii mohl obratem nahradit fotografií lepší. Mobilní aplikace nevyhovující fotografii ohlásí a neuloží ji do úložiště služby GT FOTO.

Druhá úroveň kontroly proběhne na úložišti služby GT FOTO. Tento krok musí probíhat v co nejkratším čase po obdržení fotografie, aby uživatel mohl včas reagovat na požadavek vytvoření nové fotografie. V případě, že fotografie bude označena jako nevyhovující, bude odeslána žadateli informace, že je třeba tuto fotografii pořídit znovu spolu s informací o důvodech, proč fotografie nevyhověla. Mobilní aplikace musí na tuto skutečnost reagovat a znovu otevřít daný úkol a zároveň žadatele vhodně informovat, že úkol nebo jeho krok nejsou splněny. Hodnotit se budou především parametry jako jas, zrnitost, rozložení histogramu a další, které mohou zabránit analyzování obsahu nekvalitní fotografie. Zároveň bude kontrolováno, jestli od pořízení fotografie nedošlo k manipulací s fotografií a zdali je shodná s původně pořízenou.

Vstup: Geotagované fotografie v paměti mobilní aplikace nebo v úložišti služby GT FOTO.

Výstup: Informace žadateli o nutnosti pořídit nové foto. Chybová hlášení. Potvrzení uložení správné fotografie.

2. Automatické vyhodnocení obsahu fotografie na straně úložiště služby GT FOTO

Po kontrole kvality následuje vyhodnocení obsahu fotografie.

Služba GT FOTO bude provádět automatické vyhodnocení obsahu fotografie.

Automat bude stanovovat, zdali se na snímku nachází konkrétní plodiny, nebo zda lze na něm rozpoznat provedenou zemědělskou operaci vyznačenou v úkole. Pokud bude algoritmus úspěšný, nebude tedy nutné fotografii manuálně prohlížet. Výsledek automatického vyhodnocení obsahu bude připojen k dané fotografii, bude uložen a bude poskytován prostřednictvím rozhraní služby GT FOTO systému IS XXXX. V atributech fotografie bude označeno, že prošla automatickým vyhodnocením a výsledek tohoto vyhodnocení.

V rámci IS XXXX dojde na základě geotagovaných fotografií k ověření, zda byla splněná požadovaná a vyhodnocovaná podmínka na AP.

Následně bude u této podmínky automaticky systémem IS XXXX zapsán její výsledek do DB XXXX (následně dojde k vyhodnocení definovaném odpovídajícím monitorovacím scénářem).

Algoritmus zapíše do atributů fotografie i skutečnost, že obsah fotografie nerozpoznal a kód důvodu nerozpoznání.

Vstup: Dostatečně kvalitní geotagované fotografie.

Výstup: Fotografie včetně informace o výsledku automatického vyhodnocení.

3. Manuální vyhodnocení obsahu fotografií

Manuální vyhodnocení geotagovaných fotografií bude probíhat v IS XXXX pracovníkem Zadavatele. Ten bude mít k dispozici všechny fotografie, včetně těch, které již předtím prošly automatickým vyhodnocením kvality i obsahu. Je jedno, jestli byly fotografie zaslány předem, nebo byly pořízeny na vyžádání pracovníka RO. V IS XXXX bude mít pracovník k dispozici fotografie i z jiných let, pokud mají k dané AP vztah. Výsledek posouzení pracovník zaznamená do atributu fotografie.

Pracovník na základě fotografií může změnit semafor pro danou AP, a to v případě, že byly všechny dostupné důkazy průkazné.

Fotografie budou zobrazovány v mapovém okně tak, aby bylo jasné odkud byl snímek pořízen, jakým směrem a pod jakým náklonem, bude možné si ho prohlížet, zvětšovat a bude možno zobrazit všechny dostupné atributy snímku.

Pracovník Zadavatele označí fotografie použité jako důkaz (toto označení se uloží do atributů fotografie a bude možno podle něj filtrovat při prohlížení nebo výběrech). Takto označené kopie fotografií budou ze serveru služby GT FOTO staženy, bude jim přiřazeno č.j. a budou uloženy v IS XXXX. Přidělení č.j. provede IS XXXX.

Pokud důkazy nebudou stačit na rozhodnutí o splnění kontrolované podmínky nebo budou neprůkazné, parcela zůstává dále žlutá a pracovník Zadavatele musí obstarat další důkazy k potvrzení jednoho ze stavů (červená nebo zelená). Pravděpodobně pojede do terénu a pořídí další fotografie. Další možností je požádat žadatele o doplnění fotografií (např. založením nového úkolu). Při dalším hodnocení budou k dispozici opět všechny dostupné fotografie, tedy i ty, které byly nově pořízeny bez ohledu na to, zda je pořídil žadatel nebo pracovník Zadavatele v terénu.

Vstup: Dostatečně kvalitní geotagované fotografie, vztažené k AP, tedy i ty, které automat označil jako vyhodnocené.

Výstup: Doplnění údaje o obsahu fotografie, manuální přenastavení semaforu na kontrolovaném AP nebo zadání dalšího úkolu pro žadatele či pracovníka RO. Označení fotografií použitých jako důkaz.

5. Evidence a správa mobilních zařízení

Uživatel, který má profil v Portálovém systému SZIF, je oprávněn se svým profilem propojit více mobilních zařízení, na kterých má instalovanou mobilní aplikaci poskytovanou na základě této VZ.

Uživatel s oprávněním správce mobilních zařízení je oprávněn zaregistrovat mobilní zařízení na anonymního uživatele. Zařízení je přiřazeno jméno, aby na něj bylo možno delegovat úkoly. Ke každému takovému zařízení bude vytvořena fronta, do které bude možno zasílat úkoly, které mají být plněny držitelem tohoto mobilního zařízení. Správa této fronty je plně v režii služby GT FOTO.

Při inicializaci mobilní aplikace na mobilním zařízení bude provedena kontrola minimálních technických parametrů zařízení, a v případě, že zařízení tyto parametry nesplňuje, nebude na něm aplikace funkční a zařízení nebude zaregistrováno.

Uživatel má na všech svých mobilních zařízeních přístup ke své frontě úkolů.

Pro každé registrované mobilní zařízení je ukládán profil, jehož minimální rozsah je uveden v následující tabulce.

Je vedena evidence o tom, kdy bylo zařízení kalibrováno a výsledek kalibrace (kalibrace může odhalit vadu zařízení nebo změnu jeho nastavení). Evidence se vede i o neúspěšných pokusech o kalibraci, je dobré vědět jaká zařízení chtějí uživatelé užívat, abychom na to mohli reagovat.

Minimální požadované parametry mobilního zařízení jsou:

• Schopnost pořizovat fotografie s rozlišením 5M pixelů nebo více,

• zařízení musí podporovat lokalizační služby,

• musí být vybaveno digitálním kompasem, aby bylo možno určit azimut pořízení fotografie.

Podrobnější informace je uvedena v následující tabulce.

Vysvětlivky:

Název sloupce	Popis parametru
Název	Název parametru
Datový typ	Preferovaný datový typ údaje, pokud je znám
Povinný	Hodnota P - parametr je povinný Hodnota V - parametr je volitelný
Popis	Slovní popis atributu
Rozsah	Povolený rozsah hodnoty atributu
Kontroly	Požadovaná kontrola hodnoty parametru; splnění předepsané podmínky je podmínkou registrace zařízení pro práci s mobilní aplikací
Účel	Informace o tom, k čemu daný atribut slouží

Zkratky:

BSP – Bude stanoveno Poskytovatelem

Název:	Datový typ	Povinný	Popis	Rozsah	Kontroly	Účel
ID zařízení	BSP	P	Jednoznačný identifikátor zařízení.		Zařízení musí být registrováno.	Identifikace zařízení uživatele.
ID uživatele	BSP	P	JI žadatele nebo ID uživatele, ke kterému je zařízení zaregistrováno, ID je přiřazeno i anonymnímu uživateli.		Žadatel nebo inspektor musí být evidován.	Identifikace uživatele.
Organizační jednotka	BSP	N	Útvar Zadavatele, kterému zařízení patří, nebo organizační jednotka žadatele.			Evidence.
Anonymní zařízení	ANO/NE	N	Určuje, zda je zařízení propojeno s nějakým na Portálu nebo v IDM Zadavatele registrovaným uživatelem.	ANO/NE		Na anonymní zařízení Zadavatel nezasílá úkoly, ale uživatel registrovaný pod JI na ně může úkoly delegovat nebo zasílat.
Datum provedení poslední kalibrace	Datum	P	Datum, kdy dle aplikace byla provedena poslední kalibrace (úspěšně).	Dle ISO 8601 nebo prázdné	Jestliže od posledního data kalibrace uplynulo více dnů, než je nastavený parametr, pak je uživatel vyzván k provedení kalibrace.	Je-li prázdné, kalibrace dosud neproběhla.
Maximální rozlišení	Desetinné číslo	P	Maximální rozlišení fotografie pořízené daným mobilním zařízením.	XX.XX Mpx	Min. 5 Mpx	Pro kontrolu zařízení a pro kontrolu, zda uživatel nesnížil rozlišení, a tedy nezhoršil záměrně použitelnost fotografie.
Je zařízení vybaveno GPS?	ANO/NE	P	Musí být vybaveno možností měřit polohu.	ANO/NE	Pokud NE, nevyhoví požadavkům na registraci.
Je zařízení vybaveno kompasem?	ANO/NE	P	Musí být možno určit azimut.	ANO/NE	Pokud NE, nevyhoví požadavkům na registraci.
Umí zařízení měřit nadmořskou výšku?	ANO/NE	P	Musí být vybaveno možností měřit nadmořskou výšku.	ANO/NE	Pokud NE, nevyhoví požadavkům na registraci.
Typ operačního systému telefonu	Text	P	Typ/Verze OS.		Může existovat black list verzí, na kterých aplikace nepracuje správně.

Tabulka 2 Parametry mobilních zařízení

6. Mobilní aplikace pro pořizování fotografií a správu úkolů

Mobilní aplikace slouží jak uživatelům, ta zaměstnancům Zadavatele a umožňuje správu úkolů a úkony potřebné k jejich plnění včetně pořizování geotagovaných fotografií. Rozsah funkcí, které může uživatel vykonávat, je řízen jeho oprávněními.

Při prvním spuštění mobilní aplikace na daném mobilním zařízení je vynuceno vytvoření přihlašovacích údajů nebo volba PIN (bude upřesněno po dohodě s Poskytovatelem). Těmito údaji se bude uživatel nadále přihlašovat při spuštění aplikace.

Uživatelé mobilní aplikace se přihlašují jménem a heslem nebo PINem. Pokud to zařízení podporuje, bude možno se přihlásit i otiskem prstu nebo rozpoznáním uživatele dle tváře.

Uživatel si může své heslo nebo PIN měnit. Je k dispozici funkce „Zapomenuté heslo/PIN“.

Jediné povolené operace s fotografií v mobilní aplikaci jsou prohlížení, smazání a odeslání fotografie. Smazání fotografie již odeslané na úložiště služby GT FOTO, nemá na fotografii uloženou v úložišti GT FOTO vliv, smaže se pouze lokální kopie v mobilním zařízení. Smazání fotografie před odesláním znamená, že úkol nebo krok úkolu nebyl splněn. Úkolu nebo krok úkolu může být převeden do stavu „Splněno“ až poté, co je službou GT FOTO potvrzeno uložení fotografie, tj. fotografie prošla kontrolou na straně úložiště služby GT FOTO a byla řádně včetně svých metadat uložena.

K jednomu JI lze registrovat více uživatelů – ať již zaměstnanců žadatele nebo jeho smluvních partnerů. Pod jedním JI bude možno registrovat více mobilních zařízení.

Registraci zařízení, ze kterého je možné pořizovat geotagované fotografie, bude vždy provádět uživatel, který má účet na Portálovém systému SZIF pod svým konkrétním uživatelským účtem. Platí tato pravidla:

• Jedno JI (žadatel) může mít více podniků (provozoven).

• Ke každému JI nebo provozovně může být registrováno více Pověřených uživatelů, kteří budou moci pracovat s mobilní aplikací.

• Uživatel může mít více mobilních zařízení.

• Uživatel mobilní aplikace se přihlašuje svými přihlašovacími údaji.

• Anonymní uživatel mobilní aplikace pracuje s mobilní aplikací na zařízení registrovaném k danému JI a jeho přihlašovací údaje nemusí být vázány na fyzickou osobu (více osob může pořizovat fotografie jedním mobilním zařízením).

• Do metadat se bude k jednotlivým fotkám ukládat, ID zařízení, kterým byla fotografie pořízena. Musí být zajištěna jednoznačná identifikace zařízení jeho přiřazení k žadateli (JI) k němuž pořízené foto patří. Poskytovatel v rámci své nabídky navrhne způsob jednoznačné identifikace mobilních zařízení.

1. Pořízení fotografie

Pořízení fotografie se děje mobilní aplikací dodanou Poskytovatelem instalovanou na mobilním zařízení registrovaném službou GT FOTO.

Při plnění úkolů musí být při pořizování fotografie splněna všechna pravidla nastavená zadavatelem úkolu.

Mobilní aplikace neumožní odeslat jiné fotografie než ty, které byly pořízeny touto aplikací. Nebude tedy možné do ní nahrát foto z jiného zdroje.

1. Seznam atributů ukládaných do metadat geotagované fotografie při pořízení

Veškeré parametry fotografie uvedené v tabulce níže budou zaznamenány ve formě metadat fotografie v rozšířeném EXIF souboru. Po pořízení fotografie již nebude možné žádný z níže uvedených parametrů fotografie změnit nebo doplnit, fotka bude uzamčená. Další atributy fotografie, které budou spolu s fotkou ukládány (např. komentář fotografa, ID úkolu atd.) nejsou předmětem této tabulky. 

Vysvětlivky:

Název sloupce	Popis parametru
Parametr	Název parametru
Povinný	Hodnota P (parametr je povinný, pokud není zaznamenán, fotografie se neuloží a neodešle do centrálního úložiště GTF); Hodnota V (parametr je volitelný).
Veličina	Slovní popis, jaká veličina je požadována (např. číslo, datum, text…) a formát záznamu veličiny (např. MM/DD/YYYY).
Popis veličiny	Slovní popis veličiny (např. u parametru Identifikace zařízení – IMEI: International Mobile Equipment Identity. Jde o unikátní číslo přidělené výrobcem mobilnímu telefonu.)
Hodnota	Jakých hodnot může veličina nabývat, má-li být relevantní (např. IMEI – 15místné číslo).
Kvalita GTF	hodnota A (parametr musí být kontrolován při vyhodnocení kvality geotagované fotografie, bez splnění této podmínky kvality se fotografie neuloží a neodešle do centrálního úložiště GT FOTO); hodnota N (parametr není kontrolován)
Hodnota kvality	Hodnota Veličiny, která musí být u daného parametru splněna (např. pro parametr Počet satelitů se se jedná o hodnotu „3“)

Tabulka 3 Vysvětlení významu sloupců v následující tabulce

Použité zkratky:

BSP – Bude stanoveno Poskytovatelem

Parametr	Povinný	Veličina	Popis veličiny	Hodnota	Kvalita GTF	Hodnota kvality
Identifikace zařízení.	P	BSP	Jednoznačný identifikátor zařízení.	Bude stanoveno Poskytovatelem .	N	N/A
Identifikace uživatele, na kterého je zařízení registrováno.	P	BSP	Identifikátor uživatele.		N	N/A
Datum a čas pořízení s přesností na vteřinu – zdroj GNSS anténa.	P	Timestamp	Datum a čas dle údajů z GNSS antény.	Dle ISO 8601	N	Primárně nebude omezeno, může však být omezeno datum, do kdy lze fotky pořizovat. Toto bude nastaveno úkolem.
Souřadnice místa, kde byla fotografie pořízena.	P	GPS souřadnice	Souřadnice dle údajů z GNSS antény v souřadnicovém systému WGS84.	V rozsahu běžném pro tento typ souřadnic 0-90°resp 0-180°.	N	Primárně nebude omezeno, může však být definováno typem úkolu, kde souřadnice budou muset odpovídat nějakému okolí kolem zadaného bodu, linie či polygonu.
Azimut pořízení fotografie.	P	Úhlové stupně	Směr pořízení fotky dle kompasu v přístroji. Pokud přístroj kompas nemá funkční nebo z nějakých důvodů nelze určit, ať je dosazena hodnota N/A.	0° - 360°	N	Primárně nebude omezeno, může však být definováno typem úkolu, kde bude požadován nějaký konkrétní azimut +- okolí.
Nadmořská výška.	V	Metry/ celé číslo	Nadmořská výška v metrech.	Celé číslo	N	N/A
Náklon pořízení fotografie – vertikální a horizontální úhel.	V	Úhlové stupně	Náklon pořízení fotky dle gyroskopu v přístroji. Pokud přístroj gyroskop nemá, ať je dosazena hodnota N/A.	-90° - 90°	N	N/A
Datum provedení poslední kalibrace.	P	Datum	Datum, kdy byla naposledy úspěšně provedena kalibrace.	Dle ISO 8601	N	N/A
Počet satelitů.	P	Celé  číslo	Počet viditelných satelitů.	0-N	A	Min 3 v případě fota pořizovaného v exteriéru.
Počet satelitů GNSS využitých pro výpočet.	P	Celé  číslo	Počet satelitů, které byly použity pro výpočet polohy.	0-N	A	Min 3 v případě fota pořizovaného v exteriéru.
Zda byla poloha získána z externí nebo interní antény.	P	Boolean	Informace o tom, zda výpočet polohy byl proveden na základě dat z interního nebo externího chipsetu.	A = interní/ N= externí anténa	N	N/A
Rozlišení fotografie.	P	Desetinné číslo	Použité rozlišení fotoaparátu při pořízení fotografie.	≥ 5	A	Min 5 Mpx, přesnost na jedno desetinné místo.
DOP	P	Desetinné číslo	Hodnota (PDOP- parametr přesnosti polohy - position (3D) dilution of precision.		N	N/A
RMS chyba	P	Desetinné číslo	Hodnota RMS chyby (RMSE- root mean square error).		N	N/A
Byl v době focení využit EGNOS.	P	Boolean	Ano / ne dle údajů z GNSS antény.	A/N	N	N/A
Byly v době focení využity online korekce.	P	Boolean	Ano / ne dle údajů z GNSS antény	A/N	N	Tento atribut je rezervní, zatím nebude použit
Zda bylo využito fázového měření.	P	Boolean	Ano / ne dle údajů z GNSS antény.	A/N	N	N/A

Tabulka 4 Seznam atributů ukládaných do metadat při pořízení fotografie

2. Uložení fotografie v mobilním zařízení

Fotografie bude ukládána tak, aby k ní nebyl jiný přístup než z mobilní aplikace. Nebude tedy viditelná v paměti mobilního telefonu, ani ostatními aplikacemi. Nebude možné foto editovat či zaměnit, a to ani jeho metadata s výjimkou komentáře nebo povolených hodnot atributů.

Bude zajištěno, že pořízená fotografie je shodná s tou, která byla uložena v úložišti služby GT FOTO, tj. musí být prokazatelné, že nebyla mezi pořízením a uložením změněna.

Geotagované fotografie budou ukládány včetně všech metadat – viz výše. Fotografie nepůjde ze zařízení exportovat, jediný přístup k ní bude mít mobilní aplikace a její zobrazovací a synchronizační služba, která fotografii bude odesílat na uložiště služby GT FOTO.

V rámci správy úložiště služby GT FOTO bude garantována a prokazatelná neměnnost fotografie i jejích metadat.

3. Požadavky na mobilní aplikaci pro správu úkolů a pořízení geotagovaných fotografií

• Mobilní aplikace bude pracovat minimálně pod operačními systémy iOS a Android.

• Při instalaci aplikace bude provedena kontrola parametrů mobilního přístroje.

• Aplikace bude dodávána s uživatelským rozhraním v českém a anglickém jazyce, ale musí umožnit snadné vytvoření dalších jazykových mutací. To znamená, že všechny texty musí být odděleny od vlastního kódu programu, a to včetně chybových hlášení, být uloženy jako data a aplikace musí mít možnost přepnutí z jednoho jazyka na druhý.

• Evidence zadaných úkolů a jejich správa. Budou zde rozlišeny splněné a nesplněné úkoly, možnost prohlížet si fotografie ve vazbě na úkoly a jejich kroky.

• Úkoly, které obsahují v zadání souřadnice plnění bude možno zobrazit na mapě.

• Uživatel bude moci jednoduchým úkonem informovat o „zahájení plnění“ úkolu a o „ukončení plnění“ úkolu. U úkolů, jejichž náplní je pořízení fotografií, lze nastavit, že splnění úkolu nastane automaticky xx (xx = Zadavatelem nastavitelný parametr) minut po uložení poslední požadované fotografie v úložišti služby GT FOTO.

• Bude možno zobrazit přehled úkolů s vazbou na již pořízené fotografie – u úkolů, ke kterým byla pořízena fotografie bude vidět miniatura nebo ikona fotografie v závislosti na zvoleném zobrazení.

• Úkoly přiřazené konkrétnímu uživateli nebo zařízení se budou synchronizovat tak, aby informace o nich byly dostupné i v off-line režimu.

• V rámci úkolu bude aplikace kontrolovat dodržení parametrů úkolu (počtu fotografií, typ fotografií, ...) a upozorní žadatele, co ještě musí pořídit.

• Mobilní aplikace bude uživatele informovat o notifikacích, pokud si ji uživatel ve svém profilu vybere jako notifikační kanál. Na ikoně aplikace v uživatelském rozhraní mobilního zařízení bude informace o počtu nepřečtených notifikací a nových úkolů (stačí hodnota součtu).

• Mapová prohlížečka zobrazující podkladová data k DPB/AP s vyobrazením jednotlivých úkolů. Prohlížečka bude mít k dispozici základní podkladovou mapu i pro použití v off-line režimu, tak aby bylo možné nalézt požadované místo pro pořízení fotografie i v situacích, kdy je slabý nebo žádný GSM signál.

• Pro navigaci na pozemek bude možné využít externí aplikaci navigace. V ideálním případě předáním souřadnic do externí mapové aplikace či navigace, případně možností zkopírovat souřadnice požadovaného místa focení, které pak v externí aplikaci půjdou vložit do pole vyhledávání.

• Navigace na bod (požadované místo focení) na AP na displeji zařízení. Navigace bude sloužit k donavigování na správné místo, odkud má fotka vzniknout. Bude ukazovat směr k požadovanému bodu a vzdálenost od něj.

• Kolem každého bodu bude zvoleno vhodné okolí (jeho velikost nastaví buď Zadavatel v úkolu, nebo bude použito defaultní nastavení), do kterého se musí uživatel dostat, jinak nepůjde pořídit foto ke splnění konkrétního úkolu nebo jeho kroku.

• Obdobně bude kontrolován předepsaný azimut a náklon zařízení. Uživatel bude na displeji vidět odchylku od správného směru. Aplikace může poskytovat i hlasové povely umožňující uvedení zařízení do správné polohy při focení.

• Uživatel může volit zobrazení souřadnic dle svých preferencí (S 50° 13” 1’ V 15° 50” 23’ nebo 50,21521215 015,1212151)

• Mobilní aplikace reportuje do služby GT FOTO aktivity prováděné při správě úkolů nebo k jejich splnění. Delegování úkolu, změnu termínu, odmítnutí úkolu, přijetí úkolu, pořízení fotografie, odeslání fotografie. Mobilní aplikace vede o těchto událostech záznam, který si může uživatel zobrazit, ale nelze jej měnit. Záznamy jsou po lhůtě nastavené parametrem v mobilním zařízení vymazány (v úložišti služby GT FOTO NE).

• Mobilní aplikace bude vyžadovat ve vhodných intervalech a vždy po nečinnosti jejíž délka je určována parametrem nastavovaným administrátorem služby GT FOTO, kalibraci kompasu/gyroskopu. Uživatel bude po instalaci a spuštění aplikace nebo po vypršení nastaveného intervalu kalibrace vyzván k provedení kalibrační procedury. Zařízením s prošlou kalibrací nebo zařízením, u kterého ještě kalibrace neproběhla, nebude možné pořídit foto.

• Bude možné nastavit, zda aplikace má odesílat fotografie přes mobilní data, nebo jen prostřednictvím Wi-Fi.

• Mobilní aplikace bude během svého provozu poskytovat uživateli informace o zařízení a jeho stavu:

  • stav lokalizačních služeb – zapnuto/vypnuto;

    • počet satelitů,

    • zda je dostupná lokalizaci pomocí duální frekvence,

    • zda je v době měření dostupný EGNOS,

    • zda je využívána navigační zpráva Xxxxxxx,

  • stav kompasu, pro určení azimutu,

  • stav gyroskopu pro určení náklonu.

Žádný z výše uvedených atributů nelze vkládat ručně, všechny musí být sejmuty ze zařízení aplikací.

• Pořízení geotagovaných fotografií:

  • Mobilní aplikace bude vytvářet pouze geotagované fotografie.

  • Po instalaci mobilní aplikace ověří, zda zařízení, na kterém je instalována, splňuje minimální parametry, které budou stanoveny Zadavatelem po dohodě s Poskytovatelem. Pokud zařízení nebude v souladu s předepsaným standardem, objeví se při spuštění aplikace informace, že zařízení nesplňuje technické požadavky a nelze na něm aplikaci pro tvorbu geotagovaných fotografií používat.

  • Možnost pořízení fotografie i mimo „režim plnění úkolu“, z rozhodnutí uživatele. V tomto případě, pak aplikace musí vygenerovat potřebné datové struktury nutné pro jednotnou evidenci fotografií – speciální typ úkolu, jehož zadavatelem i řešitelem je uživatel.

  • Pořízení fotografie v režimu plnění úkolů bude sledovat, zda foto splňuje zadané parametry. Nedovolí například pořídit fotografii na špatném místě, pod špatným úhlem a náklonem.

  • Mobilní aplikace bude kontrolovat nastavení fotoaparátu (ISO, clona, jas, rozlišení fotografie) dle v parametrech předepsaného standardu.

  • Mobilní aplikace bude kontrolovat polohu při focení včetně odhadované přesnosti GNSS signálu (DOP, RMSE, …), zabrání focení při nevyhovujících parametrech.

  • Obrazová informace musí být odeslána a uložena v originálním formátu, v jakém byla pořízena. To znamená, že nesmí být použita žádná dodatečná komprese odlišná od té, která je nativně použita při pořízení fotografie.

  • V případě focení do JPG aplikace nastaví režim „low compression“ nebo „fine“.

  • Povolené formáty fotografií jsou: RAW, JPEG, JPG, HEIC (HEIF), TIFF. Přesná pravidla použití formátů budou stanovena v rámci detailní analýzy.

  • Při výběru úkolu k pořízení fotografie bude možno filtrovat splněné/ nesplněné úkoly, filtrovat dle textového řetězce obsaženého v názvu úkolu či dle jiného atributu úkolu a jeho hodnoty, dále možnost řazení dle hodnoty zvolených atributů, zobrazení úkolů dle vzdálenosti od zvoleného bodu k jednotlivým úkolům (vyhledání úkolů, k jejichž splnění je třeba udělat fotografie v okolí zvoleného bodu) + zobrazení hodnoty této vzdálenosti.

  • K fotografii budou ukládány veškeré informace o senzorech a dalších atributech výše uvedených metadatech.

  • Bude hlídáno, že při provozu aplikace nedochází k podvržení GNSS signálu. Rozsah a způsob kontrol bude dohodnut s Poskytovatelem. Poskytovatel ve své nabídce rozsah a způsob případně možnosti kontrol navrhne.

  • Možnost vložit komentář k fotografii nebo vyplnit či zvolit další parametry, jejichž zadání je povoleno uživateli (rozsah těchto parametrů je definován pravidly, která se vážou k danému typu úkolu, a šablonou tohoto typu úkolu.

• Správa fotografií.

  • Fotografie lze prohlížet, mazat nebo odeslat. Při prohlížení lze uplatnit filtry na bázi metadat fotografií a filtry využívající vazeb na uživatele nebo na zadané úkoly a jejich atributy.

  • Fotografie včetně metadat musí být aplikací zabezpečena proti změně (integrity check).

  • Aplikace umožní pořizovat fotografie v on-line i off-line režimu.

• Uživatelské nastavení bude obsahovat volbu:

  • Zda má aplikace pro přenos dat využívat mobilní data, wifi či kombinaci.

1. Ověření a kalibrace mobilního zařízení

Je požadováno, aby v rámci registrace mobilní aplikace na mobilním zařízení proběhlo ověření, zda je dané mobilní zařízení vybaveno tak, aby na něm mohla aplikace bezproblémově pracovat. Pokud tomu tak není, uživateli jsou oznámeny důvody, proč dané mobilní zařízení není pro použití s touto mobilní aplikací vhodné. V průběhu ověření jsou do profilu mobilního zařízení na úložišti služby GT FOTO zapsány kontrolou zjištěné technické údaje, které jsou v profilu mobilního zařízení sledovány.

Je-li zařízení pro mobilní aplikaci vhodné, proběhne kalibrace zařízení, o jejímž výsledku je uživatel informován a tento výsledek je taktéž zapsán do profilu mobilního zařízení na úložišti služby GT FOTO. Způsob a rozsah kalibrace bude navržen Poskytovatelem. Účelem je zajistit, aby údaje uváděné v metadatech pořízených fotografií byly validní. Kalibrace musí proběhnout před prvním pořízením geotagované fotografie.

Kalibrace bude po uplynutí zadaného časového intervalu opakována. Záznamy o výsledku kalibrací budou evidovány v profilu zařízení. Skartační doba záznamů bude po dohodě se Zadavatelem určena v průběhu analytických prací na projektu.

7. Zajištění bezpečnosti a dostupnosti služeb

Služba GT FOTO je součástí informačního systému Zadavatele, který je klasifikován jako významný informační systém (VIS) dle prováděcí vyhlášky k ZoKB, tj. vyhlášky č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů. Služba je přístupná z internetu běžným uživatelům a je integrována s moduly IS Zadavatele provozovanými na jeho vlastní infrastruktuře, proto musí být služba GT FOTO řádně zabezpečena jak proti útokům z prostředí internetu, tak proti neoprávněným operacím uživatelů.

Součástí předmětu Xxxxxxx zakázky je zajištění bezpečnosti a dostupnosti všech dílčích služeb poskytovaných Poskytovatelem služby GT FOTO v souladu s předmětem plnění popsaným výše. Požadované provozní parametry těchto služeb jsou spolu s metrikami měření jejich kvality uvedeny v přílohách Smlouvy, která je Přílohou č. 1 této zadávací dokumentace.

Součástí zajištění bezpečnosti je i zajištění důvěrnosti dat. Služba GT FOTO zpracovává osobní data a data obsahující neveřejné údaje vztahující se k dotacím a jejich kontrole.

Součástí plnění je i součinnost při provádění penetračních testů, jejichž poskytovatele zajistí Zadavatel.

1. Zajištění kontinuity provozu

Součástí předmětu Xxxxxxx zakázky je zajištění kontinuity poskytování služby GT FOTO v souladu s SLA parametry definovanými ve Smlouvě.

Dodavatel v rámci dodávky provede:

• návrh plánů řízení kontinuity,

• přehled všech klíčových komponent služby GT FOTO a dat vyžadujících zálohování či jiné zabezpečení,

• návrh metod zabezpečení kontinuity služeb identifikovaných komponent,

• návrh řešení a plán zálohování identifikovaných klíčových komponent,

• návrh plánů a postupů pro obnovu služby GT FOTO v případě havárie,

• vývoj funkcionalit/rutin nebo nastavení služby GT FOTO pro vykonávání zálohovacích úloh a obnovy dle navrženého plánu řízní kontinuity,

• návrh postupů a pravidel pro testování záloh a využitelnosti záloh,

• zajištění monitoringu klíčových komponent a úloh systému zálohování.

Návrh zajištění kontinuity provozu a vysoké dostupnosti řešení musí umožňovat:

• bezvýpadkové nasazování nových verzí služeb,

• bezvýpadkovou postupnou aktualizaci jednotlivých komponent a služeb tvořících službu GT FOTO,

• zálohování dat bez potřeby zastavit službu GT FOTO nebo její dílčí služby,

• ošetřit situace výpadku služeb poskytovaných Objednatelem on-premis (z datového centra),

• obsluhovat údržbu uživatelských session a replikace session mezi jednotlivé instance služeb, tvořících službu GT FOTO, pokud je funkcionalita uživatelských session v řešení využita.

2. Analýza rizik a jejich omezení

Součástí předmětu Xxxxxxx xxxxxxx je:

• analýza všech potenciálních rizik a zranitelností služby GT FOTO, klasifikace dle úrovně rizika a potenciálních dopadů,

• určení všech komponent řešení či dat (obecně aktiv), které jsou vystaveny uvedeným rizikům a stanovení míry ohrožení aktiv identifikovanými riziky,

• návrh zabezpečení komponent či dat (aktiv) nebo služby GT FOTO jako celku tak, by byla identifikovaná rizika minimalizována,

• dodávka, nasazení a konfigurace služeb využitých pro zabezpečení řešení dle výše uvedeného návrhu,

• centrální monitoring provozu, sběr, reporting a notifikace bezpečnostních událostí.

3. Logování a auditování

Pro logování a auditování je z bezpečnostního ohledu požadováno anebo platí:

• Funkcionalita auditování a logování bude zaznamenávat informace o bezpečnostních a provozních událostech zahrnující:

  • datum a čas včetně specifikace časového pásma,

  • typ činnosti,

  • identifikaci technického aktiva, které činnost zaznamenalo,

  • jednoznačnou identifikaci účtu, pod kterým byla činnost provedena,

  • jednoznačnou síťovou identifikaci zařízení původce, 

  • úspěšnost nebo neúspěšnost činnosti.

• Logováno musí být:

  • přihlašování a odhlašování ke všem účtům (i neexistujících účtů), a to včetně neúspěšných pokusů,

  • činnosti provedené administrátory,

  • úspěšné i neúspěšné manipulace s účty, oprávněními a právy,

  • neprovedení činností v důsledku nedostatku přístupových práv a oprávnění,

  • činnosti uživatelů, které mohou mít vliv na bezpečnost služby GT FOTO,

  • zahájení a ukončení činností technických aktiv,

  • kritická i chybová hlášení technických aktiv,

  • přístupy k záznamům o událostech, pokusy o manipulaci se záznamy o událostech a změny nastavení nástrojů pro zaznamenávání událostí.

• Funkcionalita musí volitelně umožňovat odesílat vybrané bezpečnostní události do služby SIEM nebo případně do dalších dohledových systémů Objednatele využitím jedné z metod:

  • Syslog zabezpečený TLS/SSL,

  • SNMP TRAP v3,

  • Textový soubor,

  • JDBC,

  • Systémový log (žurnál operačního systému).

4. Ochrana proti běžným zranitelnostem webových aplikací

Mimo zranitelností identifikovaných Dodavatelem jako součást Veřejné zakázky požaduje Objednatel ošetření zejména následujících zranitelností:

• Injekce – Zranitelnosti vsunutím škodlivého kódu jako např. SQL Injection nastává, pokud jsou použita neověřená data v dotazu nebo příkazu a interpretována. Může vést k úniku a ztrátě dat nebo spuštění nežádoucího kódu.

  • Budou využity nástroje pro kontrolu kódu a provedeno bezpečnostní testování.

• Denial of service (DoS, DDoS) útok, zahlcení požadavky, na služby portálu, jehož cílem je cílovou službu znefunkčnit a znepřístupnit ostatním uživatelům.

  • Pro minimalizaci rizika zahlcení služby GT FOTO požadavky bude využit IPS/IDS systém a WAF (Web application firewall). Uvedené bezpečnostní nástroje budou dostupné jako vysoce kvalitní služba v prostředí cloudu.

• Nefunkční autentizace – Autentizace je často implementována chybně nebo nedostatečně. Může vést k převzetí uživatelských účtů nebo celé webové aplikace či celé serverové části řešení nebo mobilní aplikace útočníkem.

  • Autentizace a autorizaci uživatelů bude v cílovém stavu realizována využitím služeb centrálního autentizačního a autorizačního systému Objednatele. Toto řešení bude na problematiku autentizace a autorizace specializováno a bude tak naplňovat vysoké bezpečnostní požadavky a standardy. Řešení bude mimo jiné využívat služeb NIA a jednotného přihlášení MZe.

  • Nezabezpečení citlivých dat – Nezabezpečený přenos a uchovávání citlivých dat. Útočník může tato data změnit nebo zneužít k dalším útokům.

    • Komunikace klienta se službou GT FOTO bude šifrována využitím aktuálních protokolů TLS. Nezabezpečený přístup nebude umožněn. Pracovní a konfigurační data budou uložena v zabezpečených databázích poskytovaných jako cloud služba.

• Chybná konfigurace – Použití výchozí konfigurace, nekompletní konfigurace, detailní výpis chyb na klientovi, špatné HTTP hlavičky a další.

  • Uvedené chyby budou detekovány v průběhu funkčních a bezpečnostních testů.

• Cross-Site Scripting (XSS) - Pokud není sanitizován vstup od uživatele, může útočník spustit škodlivý javascriptový kód v prohlížeči oběti.

  • Součástí řešení budou funkcionality a opatření eliminující uvedené riziko. Skutečné ošetření zranitelností pak bude ověřeno prostřednictvím bezpečnostních testů, které jsou součástí předmětu překládaného projektu.

• Cross-site request forgery (CSRF) - Podvržení požadavku mezi různými stránkami. Součástí zadání portálu bude sada bezpečnostních požadavků zahrnujících mimo jiné povinné ošetření základních zranitelností webových aplikací.

  • Součástí řešení budou funkcionality a opatření eliminující uvedené riziko. Skutečné ošetření zranitelností pak bude ověřeno prostřednictvím bezpečnostních testů, které jsou součástí předmětu překládaného projektu.

• Použití komponent se známými zranitelnostmi – Útočník může využít zranitelnosti v komponentách a frameworcích třetích stran, zvláště pokud jsou použity neaktualizované verze se známými zranitelnostmi.

  • Řešení bude v maximální míře postaveno na standardních a průběžně aktualizovaných cloudových službách.

  • Pro další využité software komponenty bude Dodavatel vyhledávat a identifkovat rizika a provádět aktualizace v souladu s Katalogovými listy služby.

• Nedostatečné logování a monitorování – Nedostatečné logování a monitorování včetně chybějící automatické notifikace znemožňuje včasnou reakci na útoky a umožňuje útočníkům nerušeně hledat zranitelnosti v aplikaci.

• Zneužití API a mobilních aplikací.

• Zdrojové kódy budou kontrolovány nástrojem pro automatizovanou kontrolu zdrojových kódů a odhalování zranitelností a vad.

5. Požadavky na kryptografické operace a šifrování

Pro zabezpečení komunikace a kryptografické operace v řešení XXXX je požadováno:

• Komunikace s klientem je realizována výhradně kanálem zabezpečeným TLS v poslední známé verzi anebo verzi podporované klientem, minimálně však verzí TLS 1.2 nebo TLS 1.3.

• Zabezpečená TLS komunikace pro přístup ke všem dalším zdrojům načítaným do portálových stránek (není kombinován zabezpečený a nezabezpečený obsah).

• Využití cipher suites s minimálně 128-bitovým šifrováním anebo silnějším, využití AES cipher.

• Podpora perfect forward secrecy (PFS) ve formě Elliptic Curve Diffie-Hellman (EDCHE) nebo Ephemeral Diffie-Hellman protokolů pro výměnu klíčů.

• Podpora obnovení relace TLS - TLS Session Resumption, minimalizace potřeb opakovaného sestavování zabezpečené relace a vyjednávání o využitých klíčích.

• Volitelná podpora poskytování informací o revokovaných certifikátech přímo klientovi (OCSP stapling), minimalizace komunikace klienta s OCSP serverem.

• V případě využití cookies využití secure cookies s nastaveným secure příznakem (secure flag), zároveň bude zohledněna možnost přistupovat ke cookies pouze HTTPS (flag HttpOnly) a možnost zamezení cross-site využití cookies nastavením příznaku (SameSite).

• Podpora využití serverového TLS certifikátu vydaného komerční certifikační autoritou využívanou Zadavatelem.

• Uložení certifikátů (zejména privátních klíčů) v zabezpečeném úložišti.

• Pro autentizaci a zajištění systému jednotného přihlašování SSO musí systém podporovat jeden z protokolů: SAML2, OAuth, OpenID Connect. Preferovaným protokolem je SAML2.

• Uložení fotografií na mobilním zařízení v šifrovaném úložišti.

8. Osobní data

Implementace služby GT FOTO a celého řešení XXXX musí splňovat požadavky GDPR a zákona č. 110/2019 Sb., o zpracování osobních údajů. To v tomto případě znamená zejména:

1. Dodržení principů Minimalizace a Privacy by Design. To znamená zejména:

   1. V databázích se, pokud je to možné, neukládají detailní osobní data, pracuje se pseudonymizací – s ID žadatele (právnické osoby), ID uživatele (fyzické osoby), ID zařízení nebo ID žádosti, v nezbytné míře dalšími údaji spojenými s fyzickou osobou (např. login).

   2. Údaje, jejichž únik by mohl způsobit významnou újmu subjektu údajů např. login), musí být chráněny šifrováním.

   3. Přihlašovací údaje pracovníků Zadavatele a Oprávněných uživatelů, tj. uživatelů registrovaných v IDM Zadavatele s mandátem jednat za žadatele, služba do webové aplikace, poskytované službou, neukládá. Přihlašování do webové aplikace se děje prostřednictvím Portálového systému SZIF.

   4. Proces registrace a autentizace uživatelů mobilní aplikace navrhne ve své nabídce dodavatel. Jestliže mobilní zařízení poskytuje možnost autentizace prostřednictvím biometrických prvků (otisk prstu, rozpoznání tváře), pak aplikace musí umožnit využití tohoto způsobu autentizace.

   5. Služba GT FOTO zpracovává jen osobní údaje schválené Zadavatelem.

2. V testovacím nebo vývojovém prostředí jsou pseudonymizovaná data. Použití vzorků ostrých dat musí být schváleno Zadavatelem.

3. Služba GT FOTO poskytuje report o tom, jaká data o daném subjektu údajů eviduje. Report je určen subjektu údajů, pokud si takovou informaci vyžádá.

4. Služba GT FOTO poskytuje report o tom, kdo k osobním údajům přistupoval.

5. Musí být zajištěno, že služba GT FOTO pracuje s aktuálními osobními údaji. Zdrojem aktualizací mohou být okolní systémy.

6. Služba GT FOTO musí mít realizovány mechanismy pro sledování skartačních lhůt a upozorňovat na jejich vypršení. Musí podporovat proces skartace vybraných dat.

7. Tam, kde je to relevantní, musí být zajištěna realizace práva na výmaz.

8. Poskytovatel povede přehledné záznamy o právních důvodech a účelech zpracování osobních údajů, o jejich skartačních dobách.

9. Tam, kde je to relevantní, musí být podporováno právo na omezení zpracování osobních údajů.

10. Osobní data budou uložena na území EU/EHP.

9. Požadavky na uživatelské rozhraní

Zadavatel požaduje tyto vlastnosti uživatelského rozhraní – UI:

1. Standardní jazyk uživatelského rozhraní je čeština.

2. Lokalizaci do dalších jazyků lze provést bez zásahu do zdrojového kódu programu, jeho překladu a sestavení “ a je proveditelná Zadavatelem. Je-li pro účel lokalizace použit nějaký nástroj, je v rámci plnění spolu s potřebnou dokumentací poskytnut Zadavateli.

3. Uživatelské rozhraní musí vyhovovat standardu podpory pro handicapované.

4. Aplikace používají kontextová menu, která neukazují funkce, ke kterým nemá uživatel oprávnění. Funkce, které nejsou v dané situaci použitelné jsou v menu barevně odlišeny/skryty.

5. Součástí rozhraní je interaktivní nápověda.

6. Aplikace bude poskytovat tzv. in app guidance and tips, které uživatele provedou danou aplikací nebo procesem, pomohou s jejím seznámením a s vytvořením co nejpříjemnější uživatelské zkušenosti (user experience).

7. Vzhled webové aplikace dodrží standardy definované Zadavatelem.

8. Design UI musí být responzivní. Musí umožnit přístup jak z počítačů, tak z mobilních zařízení s obrazovkami různých parametrů.

9. Je vyžadována bezproblémová funkčnost webových aplikací na platformách a v internetových prohlížečích uvedených v tabulce níže. Všechny níže uvedené prohlížeče budou podporovány v aktuální verzi a prohlížeče pro počítače s Windows a Linux zároveň minimálně v jedné předchozí hlavní verzi.

	Počítače			Mobilní zařízení
Prohlížeč	Windows	Mac OS X	Linux	IOS	Android
Microsoft Edge	X	X		X	X
Google Chrome	X	X	X	X	X
Mozilla Firefox	X	X	X	X	X
Safari		X		X
Opera	X	X	X	X	X
Samsung Internet					X

Tabulka 5 Podporované prohlížeče a platformy

10. Správa číselníků a pravidel

Některé číselníky a pravidla nebo scénáře řídící algoritmy vyhodnocování budou sdílené v rámci celkového řešení XXXX, proto Zadavatel poskytuje informaci o požadavcích na práci s číselníky a pravidly.

Od Poskytovatele je požadována realizace relevantních požadavků, tak aby mohl potřebné číselníky a jejich aktualizace sdílet.

Požadavky na správu číselníků jsou následující:

Ref.	Text
	Modul správy číselníků a pravidel podporuje, jak definici nových číselníků nebo sad pravidel, tak jejich změny.
	Drží historii změn.
	Umožňuje definovat jak jednoduché číselníky, tak hierarchické.
	Poskytuje podporu metodikům pro vytváření číselníků a řídících tabulek. Umožňuje vytvářet jejich klony pro nové období.
	Některé číselníky jsou primárně spravovány v SAP nebo LPIS. U těchto číselníků zajišťuje jejich aktualizaci IS XXXX.
	Umožňuje vytvářet scénáře pro monitoring a jeho vyhodnocování včetně pravidel pro určení, kdy je scénář splněn a kdy ne.
	Definuje pravidla nastavování semaforů.
	Definuje optimální termíny pro provádění kontrol a Follow-up aktivit.
	Obsahuje číselník opatření a návazně na něj i ceníky, doby, po které jsou jednotlivé podmínky opatření monitorovány.
	Umožňuje vytváření a správu pravidel pro provádění kontrol a Follow-up aktivit.
	Vytváření a správa pravidel pro generaci alertů.
	Vzory a pravidla pro generaci reportů – např. předběžných výsledků, výstupů kontrol.

Tabulka 6 Požadavky na správu číselníků

11. Cloudová infrastruktura a služby

Zadavatel požaduje návrh, výstavbu a provoz služby GT FOTO v cloudové infrastruktuře s využitím cloudových služeb. Zadavatel připouští využití vlastních cloudových služeb Poskytovatele anebo třetí strany (i v podobě privátního cloudu) typů IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) či FaaS (Function as a Service).

Využité cloudové služby musí naplňovat následující požadavky:

1. Cloudové služby mají certifikaci systému managementu bezpečnosti informací ISO 27001 (s uplatněním norem ISO 27017 pro bezpečnostní opatření u cloudových služeb a ISO 27018 o ochraně osobních údajů v cloudu).

2. Poskytovatel cloudových služeb musí být pravidelně (min. 1x ročně) auditován v oblasti bezpečnosti informací, kontrolní protokoly a auditní zprávy musí být dostupné SZIF na vyžádání.

3. Poskytovatel cloudových služeb musí splňovat pravidla GDPR pro zpracování osobních dat.

4. Data musí být uložena ve dvou geograficky oddělených lokalitách umístěných v zemích EU/EHP; archivace dat musí být též prováděna ve dvou geograficky oddělených lokalitách umístěných v zemích EU/EHP; nebude docházet k předávání osobních údajů mimo EU/EHP.

Pro využití cloudových služeb dále platí:

• Využití cloudových služeb musí být navrženo tak, aby byla zachována možnost migrace služby GT FOTO k jinému poskytovateli cloudových služeb.

• Komponenty vyvíjené na míru pro Zadavatele anebo využité komerční komponenty tvořící řešení musí být kontejnerizovány a orchestrovány využitím technologií kontejnerizace a microservices do podoby celkového řešení služby GT FOTO tak, aby je bylo možné v případě potřeby přenést k jinému poskytovateli cloudových služeb či do on-premise infrastruktury Zadavatele.

• V případě využití IaaS a dalších PaaS služeb, musí být využity pouze takové služby, které lze čerpat i v případě hostování aplikace v prostředí jiných poskytovatelů cloudových služeb, nebo lze čerpat služby obdobné, které umožní migraci řešení k jinému poskytovateli cloudu.

• Serverless funkcionality, resp. služby FaaS, mohou z důvodů zajištění maximální přenositelnosti mezi poskytovateli cloudových služeb využívat některý z programovacích jazyků:

• Java,

• .NET,

• Node.js (JavaScript nebo TypeScript kompilovaný do JavaScript),

• Python.

• Síťové propojení infrastruktury Poskytovatele a on-premise prostředí Objednatele (datových center), pokud se bude jednat o dvě vzdálené lokality, bude realizováno dedikovanou, dostatečně výkonnou a maximálně zabezpečenou komunikační linkou, která bude zakončena v CMS druhé generace, do které jsou připojena datová centra Objednatele a další lokality Objednatele prostřednictvím KIVS (komunikační infrastruktury veřejné správy). Síťové propojení musí umožňovat zajistit dostatečnou kapacitu a rychlost linky odpovídající vysokému objemu datových přenosů mezi prostředím cloudu a infrastrukturou Objednatele.

• Pro zajištění bezpečnosti služby GT FOTO a jí poskytovaných služeb je možné využít IaaS cloudové služby.

• Všechny využité cloudové služby budou na straně poskytovatele cloudu pravidelně aktualizovány tak, aby byl minimalizován výskyt chyb a bezpečnostních rizik souvisejících s případnými zranitelnostmi cloudových služeb.

• Konfigurace cloudové infrastruktury a služeb musí být exportovatelné v podobě konfiguračních souborů (IaaC – Infrastructure as a Code) či obdobné tak, aby je bylo možné v případě exitu cloudových služeb předat jinému provozovateli, který je následně může využít jako zdroj informací pro přípravu nového nasazení. Konfigurace musí být předána v podobě IaaC zdrojů a formátů běžně podporovaných hlavními provozovateli veřejných a privátních cloudových služeb.

• Součástí cloudových služeb mohou být i nástroje pro řízení projektu s využitím agilního přístupu – DEV-OPS, pokrývající celý životní cyklus návrhu, nasazení a rozvoje služby. Jedná se zejména o nástroje pro:

  • Repositář pro správu zdrojových kódů, jiných artefaktů a jejich verzování s využitím technologií GIT.

  • Správu požadavků.

  • Projektové řízení.

  • Automatizované sestavování programů (Continuous Integration).

  • Testování.

  • Release management – řízené nasazování nových verzí.

12. Testování

Součástí předmětu Xxxxxxx zakázky je návrh a realizace minimálně všech níže uvedených druhů testů. Vzhledem ke skutečnosti, že služba GT FOTO představuje i elektronické rozhraní pro komunikaci s klienty veřejné správy, musí být publikován do internetu, a proto musí být maximálně zabezpečen tak, aby byla minimalizována hrozba zneužití případných zranitelností. Zároveň je požadována maximální dostupnost a odolnost oproti výpadkům. Z těchto důvodu musí být služba GT FOTO po dokončení každé verze a před jejím nasazením důkladně otestována.

Typ testu	Požadavek na realizaci
Funkční testy (unit testy, regresní testy, UAT).	Funkční testy budou realizovány v průběhu implementace a provozu, po dokončení každé nové verze.
Integrační testy.	Funkční testy budou realizovány v průběhu implementace a provozu, po dokončení každé nové verze a při každé změně mající dopad do integračních funkcionalit a na existující integrace s externími systémy.
Zátěžové testy.	Zátěžové testy budou realizovány v rámci akceptačních testů služby GT FOTO jak v rámci vlastní Implementace, tak v rámci Finální akceptace. Testy budou dále realizovány po všech změnách majících potenciálně výrazný dopad do výkonnosti služby GT FOTO.
Bezpečnostní testy.	Bezpečnostní testy budou realizovány v rámci akceptačních testů služby GT FOTO jak v rámci vlastní Implementace, tak v rámci Finální akceptace. Mimo testy vykonávané Dodavatelem mohou být dále dle potřeb Objednatele připraveny a realizovány bezpečnostní a penetrační testy jiným nezávislým subjektem.
Testy zajištění kontinuity (DRP).	DRP testy budou probíhat po dokončení vlastní Implementace a budou se pravidelně opakovat v průběhu provozu a rozvoje v souladu s plány řízení kontinuity připravenými jako součást předmětu Veřejné zakázky.

Tabulka 7 Přehled typů testů a požadavků na jejich realizaci

7. Informace o technologiích Zadavatele, se kterými bude služba interagovat.

V této kapitole uvedeme informace o technologiích, které ovlivní požadavky nebo možnosti vytváření rozhraní na IS Zadavatele. Jedná se i vlastnosti Integrační platformy IS XXXX a Portálového systému SZIF.

1. Vlastnosti Portálového systému SZIF

Portálový systém SZIF bude v prostředí Zadavatele představovat centrální jednotný systém pro vývoj portálových aplikací. Uživatelské rozhraní XXXX, resp. prezentační vrstva XXXX, bude implementováno jako portálové aplikace implementované v rámci Portálového systému SZIF. Uživatelské rozhraní XXXX bude na úrovni frontend integrováno (propojeno) s webovou aplikací služby GT FOTO. Poskytovatel může za účelem propojení webové aplikace služby GT FOTO s Portálovými aplikacemi XXXX předpokládat vlastnosti Portálového systému SZIF uvedené v tabulce níže.

Ref.	Text
	Portálový systém SZIF představuje na projektu XXXX jednotnou centrální platformu pro vývoj portálových aplikací.
	Portálový systém SZIF poskytuje framework pro vývoj portálových aplikací zahrnující knihovnu komponent, skriptů a kaskádových stylů pro vývoj webových aplikací jednotného vzhledu a ergonomie.
	Podporuje přechod na externí obsah a zobrazení externího obsahu v tomtéž okně či novém okně nebo záložce.
	Umožňuje odkazovat externí obsah v podobě hypertextových odkazů, akcí nad ovládacími prvky či akcemi spouštěnými na základě událostí.
	Podpora publikace obsahu na úrovni portálu či jednotlivých portálových aplikací ve formě formátovaného textu, tabulek, odkazů, dynamického textu načítaného z integrovaných služeb, multimediálního obsahu, tabulek, reportů, grafů a souborů ke stažení.
	Pro přechod na externí obsah jsou podporovány všechny HTTP metody, přičemž u metod akceptujících parametry (GET, POST atd.) lze předávat libovolnou sadu parametrů v těle (body) anebo URL HTTP požadavku.
	Umožňuje vkládat do stránky statické zdroje, jako jsou obrázky, multimediální obsah, styly a skripty.
	Podpora předání souborů do integrovaných systémů.
	Plně podporuje systém jednotného přihlášení (SSO) s podporou IDM řešení Zadavatele (mimo jiné SAML2, OAuth2 a OpenID Connect).
	Bezproblémová funkcionalita webových aplikací v internetových prohlížečích Chrome, Firefox, Safari, Edge na počítačích i mobilních zařízeních. Na počítačích je dále přidána podpora prohlížeče Opera. Na mobilních zařízeních pak podpora prohlížeče Samsung Internet.
	Všechny podporované internetové prohlížeče jsou podporovány v aktuální verzi a minimálně třech (3) předchozích verzích.
	Podpora responzivního designu, možnost neomezeného zobrazení obsahu na zařízeních s menšími rozměry displeje, zejména mobilních zařízeních.
	Podpora tvorby formulářů, i vyhledávacích formulářů.
	Správa uživatelského profilu, preferencí uživatele a nastavení.
	Možnost vykreslování obsahu na straně serveru i na straně klienta, podpora AJAX, asynchronních volání API.
	Podpora federovaného konceptu portálu, jako obsah lze vkládat externí webové aplikace anebo jejich části (za předpokladu vyřešení same origin policy s cross site scripting).
	Pro autentizaci volání API z klientské části webové aplikace podporuje Basic Authentication/Bearer Authentication, API klíče (API Keys), OAuth2, OpenID Connect, JWT.
	Podpora HTML 4 a HTML 5
	Komunikace s klientem je řešena výhradně kanálem zabezpečeným TLS v poslední známé verzi anebo verzi podporované klientem, minimálně však verzí TLS 1.2 nebo TLS 1.3.
	Zabezpečená TLS komunikace je zároveň využita pro přístup ke všem dalším zdrojům načítaným do portálových stránek (není povoleno mixování zabezpečeného a nezabezpečeného obsahu).
	Využití cipher suites s minimálně 128-bitovým šifrováním anebo silnějším, využití AES cipher.
	Podpora perfect forward secrecy (PFS) ve formě Elliptic Curve Diffie-Hellman (EDCHE) nebo Ephemeral Diffie-Hellman protokolů pro výměnu klíčů.
	Podpora obnovení relace TLS - TLS Session Resumption, minimalizace potřeb opakovaného sestavování zabezpečené relace a vyjednávání o využitých klíčích.
	Volitelná podpora poskytování informací o revokovaných certifikátech přímo klientovi (OCSP stapling), minimalizace komunikace klienta s OCSP serverem.
	V případě využití cookies jsou využity secure cookies s nastaveným secure příznakem (secure flag), zároveň je zohledněna možnost přistupovat ke cookies pouze HTTPS (flag HttpOnly) a možnost zamezení cross-site využití cookies nastavením příznaku (SameSite).
	Všechny skripty a další zdroje využité v portálových aplikacích jsou minimalizovány tak, aby při jejich načtení byl minimalizován objem komunikace mezi serverem a klientem.
	Informační část Portálového systému SZIF a portálových aplikací podporuje SEO (search engine optimization), tedy poskytuje informace v podobě srozumitelné robotickým vyhledávačům a indexovacím službám.
	Podpora využití notifikačních kanálů SMS, email, portálové okno (část portálu s přehledem notifikací/upozornění) a rozhraní pro notifikace prostřednictvím externí mobilní aplikace.
	Podpora uživatelského nastavení notifikací s možností definovat cílovou destinaci, četnost a způsob notifikace pro definované typy/kategorie notifikací.
	Podpora trvalého či dočasného potlačení notifikací prostřednictvím notifikačních kanálů email, SMS a mobilní aplikace.
	Zabezpečení proti spamu a zneužití notifikační funkcionality.
	Podpora odeslání textu a v případě kanálů podporujících formátovaný text i formátovaného textu a příloh.
	V případě formátovaného textu podpora odesílání odkazů v notifikacích, zejména odkazů na související informace v portálu a portálových aplikací, po jejichž následování klientem dojde na straně klienta k zobrazení odkazovaných informací v internetovém prohlížeči anebo mobilní aplikaci.
	Podpora klasifikace notifikací dle významu a důležitosti s možností vizuálního odlišení významu události v notifikačním kanálu.
	Řízení oprávnění pro práci s notifikacemi na úrovni uživatele a zastupovaného subjektu.
	Evidence a prezentace příznaku zobrazení/přečtení notifikace volitelně na úrovni uživatele či celého subjektu s možností uživatelské změny hodnoty příznaku.

Tabulka 8 Seznam požadavků, které má splňovat Portálový systém SZIF

Portálové řešení SZIF musí dále naplňovat následující požadavky:

• Podpora federace portálů:

  • Možnost začlenit portál a portálové aplikace do nadřazených střechových portálů veřejné správy ČR, resp. podpora jednotného přihlášení prostřednictvím SAML2 a odkazování konkrétních částí portálových aplikací ze střechových portálů.

  • Podpora odkazování externího obsahu v prostředí Objednatele s přechodem k externímu obsahu a návratem z externího obsahu zpět na Portálový systém SZIF využitím systému jednotného přihlášení (uživatel nemusí opakovaně zadávat přihlašovací informace).

  • Podpora začlenění externího obsahu Objednatele do prezentace publikované v Portálovém systému SZIF (např. portlety, iframe, AJAX API) s využitím systému jednotného přihlášení (příklad – integrace obrazovek jiných webových aplikací Objednatele – Portálu farmáře do nového Portálového systému).

• Auditování přístupů uživatelů:

  • Záznam informací o přistupujících uživatelích do Portálového systému SZIF obsahující zejména:

    • login přistupujícího uživatele,

    • datum a čas přihlášení do systému, datum a čas odhlášení ze systému,

    • IP adresa přistupujícího uživatele,

    • detekovaný prohlížeč a informace o klientovi z hlavičky User-Agent.

  • Generování přehledu/reportu se seznamem uživatelů, kteří ve zvoleném období přistoupili k Portálovému systému SZIF.

  • Možnost zobrazení přehledu aktuálně přihlášených uživatelů (pouze oprávněné role).

Auditování dalších operací v systému (např. operace s dokumenty, správami atd.).

2. Vlastnosti integrační platformy

Poskytovatel může předpokládat tyto vlastnosti Integrační platformy IS XXXX, na kterou se bude jim poskytovaná služba integrovat. Integrační platformu Poskytovatel na základě této VZ nedodává.

Integrační platforma zastává v architektuře celkového řešení XXXX roli zprostředkovatele komunikace. Platforma v rámci celkového řešení XXXX zajišťuje:

• interní komunikaci komponent/modulů IS XXXX a výměnu zpráv mezi těmito moduly,

• přístup uživatelských rozhraní (portálových a případně jiných aplikací) k datům a funkcionalitám IS XXXX a zprostředkování komunikace mezi Portálovými aplikacemi XXXX a back-endem tvořeným IS XXXX,

• zprostředkování komunikace mezi systémy IS XXXX a externími službami SAMAS a službou GT FOTO,

• komunikaci s externími systémy, přičemž platforma je za tímto účelem integrována s existující integrační sběrnicí Zadavatele – SAP PO včetně SAP AAE.

Integrační platforma může být v budoucnu využita i pro integrační úlohy mimo celkové řešení XXXX.

Základní logické schéma integrační platformy je znázorněno na obrázku Obrázek 7 Logické schéma integrační platformy (sběrnice) XXXX. Logický model řešení obsahuje grafické znázornění funkčních komponent řešení a jejich vzájemné spolupráce. Jednotlivé funkční komponenty mohou být v rámci poskytovaného řešení implementovány jedním či více nabízenými systémy.

Integrační platforma musí naplňovat níže uvedené požadavky a poskytovat zmíněné funkcionality rozdělené do několika oblastí uvedených v následujících kapitolách.

Obrázek 7 Logické schéma integrační platformy (sběrnice) XXXX

Architektura

Integrační platforma XXXX musí v oblasti architektury umožňovat:

• nasazení a běh v prostředí s vysokou dostupností tvořeném více uzly v několika geografických lokalitách zapojených do geografického clusteru,

• balancování provozu na samostatné uzly v několika geografických lokalitách a podpora režimu active-active,

• řízeně odstavit jeden uzel v clusteru bez dopadu na rozpracované transakce,

• automatické přepnutí provozu na dostupné uzly v clusteru v případě výpadku jednoho z uzlů tvořících cluster.

1. Využité technologie

Pro výstavbu integrační platformy musí být využity standardní technologie Zadavatele popsané v Příloze č. 6 – Technická dokumentace – NDA této ZD.

Součástí integrační platformy je i ETL nástroj.

2. Integrační funkcionality

Platforma musí poskytovat následující funkcionality a služby:

• Integrace a zajištění vzájemné komunikace mikroslužeb zahrnující:

  • integraci s kontejnerizační platformou,

  • zajištění komunikace mezi mikroslužbami.

• Integrace a zajištění komunikace systémů využitím standardů SOAP a REST (ESB - Enterprise Service Bus) zahrnující:

  • Podporu návrhu, nasazení a provozu integračních služeb v souladu s EIP (Enterprise Integration Patterns) - xxxx://xxx.xxxxxxxxxxx.xxx/xxx.xxxx.

  • Podporu těchto typů služeb:

    • proxy služby - pouze zrcadlení služeb vždy z jednoho zdrojového systému,

    • kompozitní služby - integrující jeden či více systémů provádějící zároveň manipulace a transformace datových zpráv,

    • asynchronní služby - služby, kde je datový tok rozdělen do samostatných volání pro požadavek a odpověď, přičemž odpověď je konzumentskému systému navrácena asynchronně (tedy ne okamžitě).

  • Integraci systémů na bázi webových služeb, umožňujících implementaci SOA.

  • Integraci koncových bodů využívajících různé komunikační protokoly (např. jeden koncový bod vyžaduje JMS a druhý koncový bod podporuje pouze webové služby).

  • Podporu transportů minimálně HTTP/S, JMS, web services (SOAP 1.2, SOAP 1.1, JAX-RPC, JAX-WS, REST, GraphQL).

  • Podporu orchestrace služeb (řízení workflow služeb modelované v BPEL)

    • synchronní a asynchronní orchestrace,

    • řetězení služeb,

    • paralelní volání služeb,

    • validaci zpráv.

  • Zprostředkování a řízení přístupu k API dle standardů REST a GraphQL (API gateway) zahrnující:

    • zabezpečení a řízení volání,

    • validace volání,

    • poskytování definic API (např. Swagger).

  • Doručování zpráv (messaging) zahrnující:

    • podporu synchronního a asynchronního zasílání zpráv,

    • frontování zpráv a práci s frontami,

    • řízení priority zpráv, nastavení timeout volání (QoS - Quality of service),

    • zaručené doručení zpráv, doručení právě jednou,

    • omezení datového toku zpráv pro konkrétní systémy,

    • dávkové zpracování zpráv.

  • Směrování zpráv zahrnující:

    • virtualizaci koncových bodů, využití logických názvů koncových bodů zdrojových služeb,

    • možnost změny koncového bodu zařazeného do virtuálního bodu za běhu,

    • směrování zpráv dle obsahu zpráv, hlaviček zpráv, QoS kritérií, politik a definovaných pravidel.

  • Mediace a transformace zpráv zahrnující:

    • podporu standardizovaných adaptérů a konektorů,

    • transformace zpráv mezi různými datovými formáty,

    • obohacování zpráv o dodatečné informace.

  • Přenos souborů umožňující:

    • přenos objemných souborů v řádu 100 MB i více mezi různými systémy a platformami bez dopadu na kvalitu ostatních komunikačních toků,

    • přenos mimo tělo zprávy.

  • Real-time a dávkové proudové (stream) přenosy objemných dat, podpora ETL zahrnující:

    • vlastní implementaci ETL anebo integraci na externí ETL systém,

    • podporu řízení ETL úloh prostřednictvím volání webových služeb konzumentskými a zdrojovými systémy pro synchronizaci velkých objemů dat mezi systémy.

  • Datové integrace, napojení na zdroje dat a publikace dat ve formě webových služeb zahrnující:

    • podporu konektorů pro běžné databáze, minimálně Oracle, MS SQL, MySQL, PostgreSQL,

    • publikaci dat ve formátu JSON či XML,

    • publikaci dat prostřednictvím SOAP anebo REST webových služeb,

    • podporu pokročilých dotazů na publikovaná data.

  • Transakční zpracování a obsluha chyb zahrnující:

    • podporu volání v rámci transakce,

    • podporu potvrzení (commit) či odvolání transakce (roll-back),

    • podporu vykonání kompenzačních akcí v případě selhání transakce,

    • možnost opakovaného volání (definovatelné) zdrojového systému či služby v případě selhání volání,

    • definovatelné politiky pro obsluhu chyb,

    • zajištění proti duplicitě transakcí ve zdrojových systémech,

    • podporu uložení rozpracovaných transakcí (pro případ restartu).

1. Požadavky na ETL

• Přenos dat z jednoho zdroje do jiného s možností modifikace a výpočtů nad daty. Údaje musí být možno slučovat i rozdělovat, vytvářet vypočtené položky, filtrovat, třídit, grupovat, kombinovat mezi sebou, provádět geometrické operace nad prostorovými daty (např. intersect, join, buffer,atd.), provádět validace geometrií (např. duplicity bodů na liniích).

• Ve standardní dodávce musí být podpora pro minimálně tato rozhraní: SAP, MS SQL (+spatial), Oracle DB (+spatial), PostgreSQL (PostGIS), SHP, GPX, GML, WKT, Excel, ODBC/JDBC, FTP, XML, JSON, LDAP.

• Musí být možno v rámci implementace systému vytvořit další rozhraní na jiné datové zdroje připojené např. prostřednictvím webservices.

• V rámci ETL musí být možno skriptovat a rozšiřovat tak jednoduchým způsobem funkcionalitu, která není v základu v nějakém z rozšířených skriptovacích jazyků. Musí být dodána i dokumentace k rozšiřování ETL pomocí skriptování.

• Podpora pseudonymizace dat s dodržením vazeb záznamů.

• ETL musí podporovat grafický návrh a prezentace prováděných transformací dat a návrh a prezentace workflow.

• Musí podporovat verzování jobů. Ideálně, aby samotné ETL umělo držet verze nebo v GIT, případně jiným způsobem, kde se nechá uživatelsky přívětivým způsobem podívat na provedené změny.

• Jednotlivé tasky musí být možno spojovat do workflow (jobů).

• Musí být možno v rámci prováděných transakcí provádět kontroly dat (kontrola formátů, správnosti hodnot).

• Musí být možno plánovat jednotlivé tasky ETL dle potřeb automatizace práce ETL, spouštět je na základě splnění/nesplnění nějaké podmínky.

• Musí být možno restartovat task po chybě jak ručně, tak automaticky.

• Musí být dostupné dokumentované API ETL tak, aby ETL v co největší možné míře mohly ovládat aplikace případných 3. stran. Minimálně musí být podporované funkce pro spuštění/restart/pozastavení/zastavení jobu, zjištění stavu jobu.

• Musí mít prostředky pro ošetření a reporting chyb.

• Hlášení o chybách, ale i další notifikace nebo alerty musí být možno odeslat minimálně mailem (případně i na další kanály jako Teams, Slack, atd.) na zadané kontakty.

• Musí být možno pracovat s timeouty, časovými limity, a to jak na odezvu zdrojů, tak na dobu běhu tasku (např. běží-li task více než 30 minut, bude zastaven).

• Musí mít možnost pokračování po chybě od zvoleného bodu zpracování, nemusí být nutno pouštět celé zpracování znovu.

• Musí být možno task spustit událostí.

• Task i celé workflow lze parametrizovat předanými parametry.

• ETL musí minimálně v produkčním prostředí běžet minimálně ve 2 instancích, aby byl dodržený přístup high-availibility.

• Práce ETL je logována.

• Je generován report o průběhu zpracování.

• Podpora přenosu definic tasků, workflow a nastavení z jednoho prostředí do jiného (z DEV, do TEST nebo do PRODUKCE)/z jedné instance ETL do jiné. Pokud je task/workflow vytvořen/vytvořené v jednom prostředí, musí existovat proces pro přenos do jiného prostředí tak, aby se nemusel proces vytvářet v novém prostředí znovu ručně.

• Podpora práce se strukturovanými i prostorovými daty (podpora funkcí pro manipulaci, validaci a konverzi prostorových dat v rámci procesů ETL).

• ETL musí podporovat paralelní běh minimálně 20 workflow/jobů a musí být možné tento počet škálovat přidáním instancí ETL (do šířky).

4. Logování, auditování a archivace dat

V oblasti logování, auditování a archivace dat musí platforma umožňovat:

• logovat záznamy o realizovaných voláních,

• opatřit volání korelačním identifikátorem (klienta, integrační platformy a zdroje),

• webové zobrazení a vyhledání informací o realizovaných voláních zejména pro 1. úroveň podpory provozu řešení.

5. Provoz integrační platformy

Pro řádné zabezpečení provozu musí integrační platforma umožňovat:

• začlenění do dohledových systémů (monitoring událostí, výkonnosti, bezpečnosti a E2E),

• monitoring metrik a poskytování dat pro vyhodnocení plnění SLA,

• zobrazit přehledový dashboard (monitoring stránka či více stránek) pro prezentaci souhrnného stavu řešení a jednotlivých implementovaných služeb zejména pro 1. úroveň podpory,

• začlenění do systémů zálohování dat a testování použitelnosti záloh,

6. Zabezpečení integrační platformy

Integrační platforma, resp. tam, kde je to relevantní a v rámci detailní analýzy schválené, i další moduly řešení XXXX, musí v oblasti zabezpečení podporovat:

• bezpečnostní standard WS-Security,

• autentizaci a autorizaci pro volání integračních služeb pro zajištění komunikace mezi systémy využitím klientského certifikátu,

• logování aktivit administrátorů nebo uživatelů obslužných aplikací, a to alespoň pomocí jedné z následujících metod:

• Syslog zabezpečený TLS,

• SNMP TRAP v3,

• Textový soubor,

• JDBC,

• Systémový log (žurnál operačního systému),

• autentizaci a autorizaci pro přístup k obslužným aplikacím využitím identitního systému Zadavatele (LDAP, SAML),

• bezpečný přístup z nedůvěryhodných sítí (možnost využití WAF),

• běh služeb pod neprivilegovanými účty,

• ochrana příchozích a odchozích požadavků prostřednictvím XML firewall z možností nastavit parser limity a rate control,

• podpora TLS 1.2/1.3,

• zapnutí anebo vypnutí kontroly revokace prostřednictvím CRL i OCSP,

• podpora bezpečných kryptografických algoritmů (cipher suites) se zabezpečením komunikace využitím Perfect Forward Secrecy (PFS),

• důvěryhodné předání informací o klientském certifikátu, IP atd. z load balanceru nebo reverse proxy, pokud bude terminace komunikačního kanálu řešena mimo samotnou integrační platformu,

• provoz v IPv6 prostředí, schopnost v překlenovacím období obsluhovat IPv6 i IPv4 jak na listenerech, tak na službách poskytovaných externě,

• plný provoz pouze na IPv6 nebo IPv4 nejen u serverů ale i síťových prvků,

• zabezpečení komunikace mezi Konzumentem a Poskytovatelem služeb prostřednictvím TLS, (volitelně možnost zakončení TLS zabezpečení na TLS akcelerátoru),

• možnost omezit počet zpracovávaných požadavků, ochrana systému před zahlcením.

7. Obslužné aplikace

Řešení musí obsahovat následující obslužné aplikace:

• katalog služeb zahrnující funkcionality:

• poskytující informace o publikovaných službách,

• umožňující konfigurovat základní parametry služeb,

• poskytující základní konfigurační informace pro běh služeb,

• grafický designér integrací a datových toků umožňující vizuálně editovat tok služeb (workflow) obsluhy příchozích volání.

3. Vlastnosti IDM

Zadavatel implementuje Identity Management System (IDM) od firmy IBM - IBM IGI Enterprise. Toto řešení podporuje Activity based SoD (Separation-of-Duties). Proto Zadavatel preferuje i u poskytované služby model, kdy jsou oprávnění vázána na aktivity systému. Přípustné je řešení pracující na straně poskytované služby s rolemi.

Systém IDM podporuje integraci řešení s různými typy autentizace (AD, AD FS, IDM třetích stran, SAML.).

Ref.	Text
	Podporuje Activity based SoD (Separation-of-Duties).
	Podporuje integraci řešení s různými typy autentizace (AD, AD FS, IDM třetích stran, SAML).
	Systém umí časově omezit délku využívání sdíleného účtu.
	Umožňuje měnit hesla sdílených účtů po každém použití pro zachování bezpečnosti.
	Podporuje synchronizaci hesel a účtů v rámci více systémů.
	Komunikace mezi všemi komponentami celého řešení probíhá zabezpečeně (např. certifikáty, TLS, SSO).
	Disponuje širokou škálu API pro možností přizpůsobení celého systému včetně standardů WebService a REST.
	Umí detekovat změny ve zdrojích identit on-line a následně je propagovat do cílových systémů na základě událostí.

Tabulka 9 Seznam požadavků, které splňuje implementace IDM

4. Notifikátor

Notifikátor je sdílená komponenta Portálového systému SZIF zajišťující odesílání všech typů notifikací. Komponenta zahrnuje rozhraní uživatele pro nastavení notifikací. Notifikace oznamují uživateli výskyt události a jsou prezentovány rozhraní v Portálovém systému SZIF po přihlášení uživatele. Notifikace jsou zasílány uživateli kanály, které si zvolí ve svém profilu na Portálu. Může si i nastavit jaké typy notifikací mají být do jednotlivých kanálů zasílány.

Zdrojem alertu může být libovolná aplikace systému IS Zadavatele.

Komponenta Notifikátor obsahuje uživatelské rozhraní umožňující uživatelům nastavit preference notifikací zahrnující:

• jaké typy notifikací odesílat jednotlivými kanály,

• v jakých časových oknech notifikace odesílat,

• jakými kanály notifikace odesílat,

• bude možno nastavit parametry generace alertů pro specifické typy událostí, např. standard s jakým předstihem před termínem splnění úkolu má být generován alert a zda vůbec má být generován),

• jak notifikace seskupovat (např. seskupit všechny notifikace za poslední 2 hodiny do jedné informační zprávy).

Standardním notifikačním kanálem je e-mail, dalším kanálem je mobilní aplikace.

8. Kontext plnění

Stávající informační systém Zadavatele nepodporuje efektivní práci s geografickými informacemi, satelitními snímky, geotagovanými fotografiemi a nepodporuje a ani nemůže podporovat nově navrhované procesy vznikající za účelem splnění požadavků EU na provádění plošných kontrol s využitím satelitního monitoringu. Část procesů, kterých se změna netýká, bude i nadále podporována stávajícím IS Zadavatele. Některé procesy budou pozměněny a jen jejich část bude prováděna mimo stávající IS Zadavatele. Zbylá část procesů bude podporována stávajícím systémem a samozřejmě nově navržené procesy budou podporovány novým informačním systémem XXXX.

Požadavky, které musí informační systém XXXX splnit jsou uvedeny v Příloze č. 6 – Technická dokumentace – NDA této ZD, která je neveřejným dokumentem Zadávací dokumentace.

Řešení IS XXXX má oddělený back-end (BACK-XXXX) realizovaný v rámci dodávky IS XXXX a front-end realizovaný Portálovými aplikacemi XXXX vytvořenou v prostředí nově budovaného portálu (dále Portálový systém SZIF).

Specifikaci níže vytvářeli ze značné části budoucí uživatelé systému a je psána tak, že popisuje požadované funkce systému jako celku vyhovujícímu nově navrhovaným procesům. Přitom se nelze vyhnout situacím, kdy část procesu je podporována aplikací třetí strany, část procesu je podpořena IS XXXX, případně dochází ke komunikaci s novými externími službami SAMAS (Satellite Monitoring and Analysis Service) a službami GT FOTO (služba pro pořizování a správu geotagovaných fotografií) nebo s registry OOP a OVM. Z tohoto důvodu, a také proto, aby si Poskytovatel mohl dělat ucelenou představu o celkovém řešení XXXX, jsou ve specifikaci popsány i funkce a služby, které Poskytovatel na základě této VZ nedodává, ale dodávané řešení je s nimi integrováno a službu pro koncového uživatele spoluvytváří; vyměňuje si se službami a funkcemi třetích stran data, generuje události rozpoznávané těmito službami nebo přijímá události jimi generované.

1. Definice projektu XXXX

   1. Cíle projektu XXXX

Hlavním cílem celkového řešení XXXX je implementace řešení pro splnění povinností obsažených v novele nařízení EK č. 809/2014. 

Dílčími cíli celkového řešení XXXX jsou:

1. Nastavení partnerského vztahu s klienty

Kontroly pomocí monitoringu umožní změnit dosavadní praxi, která je mnohdy vnímána jako represivní, na model partnerský, kdy obě strany (platební agentura a žadatel) mají společný zájem. Kontinuální a proaktivní komunikace s žadateli umožní minimalizaci počtu situací, kdy skutečný stav je v nesouladu s deklarací v žádostech.

2. Snížení nevyčerpaných finančních prostředků z EU v příslušném roce díky snížení chybovosti žádostí

Proaktivní upozorňování na plnění či neplnění podmínek dotačních programů a úkony, které v reakci na upozornění učiní žadatelé, povedou k minimalizaci chybovosti (odchylek deklarací uvedených v žádostech oproti skutečnému stavu).

3. Sjednocení kontrolní zátěže pro všechny žadatele na plošná opatření

Zavedením kontrol pomocí monitoringu dojde u monitorovaných podmínek k narovnání stavu, který je založen na výběru vzorků žadatelů a všichni žadatelé na plošná opatření budou kontrolováni stejně.

4. Snížení rizika vůči fondům

Ze strany Evropské komise jsou kontroly realizované pomocí monitoringu, tzn. systém, kdy dochází k 100% prověření plochy prostřednictvím automatického vyhodnocení družicových dat, vnímány jako méně rizikové vůči fondům. Monitoring celého území zvyšuje pravděpodobnost, že budou odhaleny nezpůsobilé plochy s významnou výměrou.

5. Snížení kontrolní zátěže

Zavedením kontrol pomocí monitoringu dojde u vybraných podpor k nahrazení standardních Kontrol na místě (KNM). Terénními návštěvami budou řešeny pouze případy, kdy nebude možné rozhodnout o plnění monitorovaných podmínek jiným způsobem. Kontroly nemonitorovaných podmínek budou prováděny i nadále na základě výběru vzorku žádostí, ale v rámci těchto kontrol nebude prováděno měření způsobilé plochy. Proto lze předpokládat snížení časové náročnosti kontrolních procesů Zadavatele, zkrácení času provádění kontrol u žadatelů i snížení celkové kontrolní zátěže žadatele.

6. Vytvoření základní GIS platformy (nejen pro potřeby kontrol pomocí monitoringu)

Již stávající procesy IACS generují prostorová data, ale Zadavatel aktuálně nedisponuje odpovídajícími nástroji pro to, aby s nimi mohl efektivně pracovat a tato data spravovat. Implementace kontrol pomocí monitoringu nutně vyžaduje vybudování GIS platformy, která umožní efektivně zpracovávat získaná a nově vytvářená prostorová data, umožní s nimi efektivně nakládat a zároveň umožní prostřednictvím jednotlivých GIS nástrojů maximální výtěžnost a efektivní a názornou prezentaci získaných výsledků, a to jak v interním prostředí Zadavatele, tak v komunikaci s externími partnery (žadatelé, kontrolní orgány).

7. Zefektivnění administrace JŽ a zkvalitnění služeb žadatelům a příjemcům dotací.

1. Základní principy implementace požadavků novely nařízení EK č. 809/2014

1. Princip kontrol pomocí monitoringu je založen na kontinuálním sledování zemědělských pozemků a kontinuálním vyhodnocování zemědělských aktivit pomocí dat dálkového průzkumu Země, zejména dat družic Sentinel, přičemž platí:

1. Monitoring ověřuje plnění zadaných monitorovaných podmínek Zadavatelem zvolených opatření, a to plošně pro všechny žádosti.

2. Výjimkou mohou být parcely, které pro jejich tvar a malou rozlohu nedokáže algoritmus monitoringu vyhodnotit, ale je možno tyto parcely pro účely monitoringu spojovat, pokud je na nich monitorována shodná podmínka. Rozhodnutí o splnění podmínky pro takto vytvořenou virtuální parcelu je pak aplikováno na dílčí parcely, ze kterých byla spojená parcela vytvořena.

3. Vzhledem k tomu, že satelit přelétá nad naším územím v určitých intervalech, není možno stanovit přesné datum, kdy nastala změna, která byla zaznamenána.

4. Vzhledem k tomu, že je území ČR snímáno ve více pásech, nebudou výsledky monitoringu k dispozici pro celé území ČR k jednomu datu.

5. Satelitní monitoring nemusí být schopen u všech monitorovaných parcel rozhodnout, zda je daná podmínka v daném čase na dané parcele splněna nebo nesplněna. Toto je zejména závislé na velikosti a tvaru parcely.

6. Sběr satelitních dat probíhá kontinuálně před podáním žádostí, v průběhu plnění podmínek žádostí i po rozhodnutí o výplatě prostředků. 

7. Pro zpřesnění výsledků monitoringu lze využít další datové zdroje – ortofoto, snímky z jiných satelitů než Sentinel nebo geotagované fotografie pořizované jak žadateli, tak inspektory Zadavatele v rámci terénních šetření.

8. Opatření mohou obsahovat současně monitorované i nemonitorované podmínky. Na kontrolu nemonitorovaných podmínek opatření, která obsahují zároveň monitorované podmínky (KNP), se vztahují jiná (jednodušší) pravidla kontroly, než jsou pravidla standardních kontrol na místě.

9. Existují opatření, která neobsahují žádnou monitorovanou podmínku. Tato opatření budou kontrolována a administrována stávajícími procesy.

2. Terénní šetření se zaměřuje na:

1. Kontrolu pozemků, u nichž služba monitoringu nerozhodla o splnění/nesplnění podmínky.

2. Kontrolu podmínek, které satelitním monitoringem vyhodnotitelné nejsou.

3. Princip kontinuální komunikace s žadatelem

1. Žadatel je průběžně informován o tom, jaký stav plnění podmínek Zadavatel eviduje.

2. Žadatel může dostávat upozornění na blížící se termíny, kdy má mít splněnou nějakou podmínku nebo provést očekávaný úkon, pokud tato podmínka není v určitém časovém intervalu před termínem dle informací získaných Zadavatelem splněna, nebo úkon nebyl proveden.

3. Zadavatel žadateli průběžně poskytuje další informace s cílem zajistit jeho informovanost o případných změnách nebo s cílem zajistit minimalizaci chyb (upozorní na opakující se chyby) nebo o chystaných opatřeních atd.

4. Žadatel se na základě poskytnutých informací může sám rozhodnout, že informace o plnění podmínek opatření zpřesní nebo doloží.

4. Žadatel může plnění podmínky doložit geotagovanými fotografiemi nebo jiným dokladem v závislosti na typu podmínky

1. Doložení může provést na výzvu Zadavatele nebo kdykoli na základě vlastního rozhodnutí (třeba na základě upozornění, že Zadavatel danou podmínku považuje za nesplněnou nebo na základě průběžně poskytované informace, kde vidí, že daná podmínka je zatím nerozhodnutá, nebo je rozhodnutá chybně).  

2. Doložení některých dokladů je třeba provést do zadaného termínu.

5. Žadatel má možnost průběžně (do rozhodnutí o dotaci nebo do termínu uvedeného v dotačním programu) měnit žádost

1. Žádost není možno měnit po datu rozhodnutí nebo po termínu uvedeném v textu, jímž se vyhlašuje dané opatření.  

2. Žádost není dovoleno změnit na základě nálezu porušení nemonitorovatelné podmínky ani v případě ohlášení kontroly na místě.

6. Maximální objem komunikace zajistit elektronicky

1. Pro zjednodušení procesů a zajištění vyšší míry automatizace procesů bude zlepšována a rozšiřována podpora elektronické komunikace.  

2. Preferována bude komunikace strukturovanými daty (formuláře s kontrolami a nápovědou), která lze následně snadno zpracovat.

7. Zvyšování míry automatizace a optimalizace interních procesů Zadavatele  

1. Návrh procesů by měl být vytvářen s ohledem na možnosti automatizace procesu. Vstupní data co nejvíce strukturovat, a tak umožnit jejich snadné počítačové zpracování.  

2. I pro rozhodování, které musí udělat člověk, připravit podklady tak, aby bylo rozhodování co nejvíce usnadněno.  

3. Pro optimalizaci využít toho, že nové moduly budou pracovat s geoprostorovou informací – např. optimalizace kontrol v terénu, kdy lze seskupovat kontroly podle geografické vzdálenosti a optimalizovat trasu inspektora.  

8. Auditovatelnost

1. Proces musí vytvářet auditní stopu tak, aby bylo jasné kdo, kdy a na základě jakých podkladů učinil dané rozhodnutí nebo provedl danou aktivitu. Musí být možno trasovat od výsledku po jeho zdroje.

9. Důvěrnost

1. Přístup k dokumentům a datům musí být řízen tak, aby k nim mohli přistupovat jen oprávnění uživatelé.

10. Flexibilita řešení

1. Procesy a jejich ICT podporu navrhovat a realizovat tak, aby jejich provádění bylo řízeno pravidly a daty, která lze uživatelsky měnit, aniž bude třeba měnit algoritmy zabudované v software.

2. Výchozí stav a principy řešení

   1. Výchozí stav 

Zadavatel zprostředkovává zemědělcům, lesníkům a potravinářům finanční podporu z EU a národních zdrojů a zajišťuje následnou kontrolu oprávněnosti užívání dotací a kontrolu výsledků jejich užití. Část poskytovaných podpor, konkrétně přímé platby a plošná environmentální opatření v rámci programu rozvoje venkova, je povinně administrována a kontrolována systémem IACS.

Dle nařízení (EU) č. 1306/2013 čl. 68 až čl. 73 je IACS (Integrated Administration and Control System) složen z níže uvedených prvků (A-F).

1. počítačová databáze;

2. systém identifikace zemědělských pozemků;

3. systém identifikace a evidence platebních nároků (pozn. v ČR neaplikováno);

4. žádosti o podporu a žádosti o platbu;

5. (integrovaný) kontrolní systém;

6. systém pro identifikaci příjemců intervencí a opatření uvedených v čl. 67 odst. 2.

V rámci stávajícího nastavení IACS probíhají dva typy kontrol – administrativní kontroly a kontroly na místě (KNM).

Administrativní kontroly spočívají v křížových kontrolách dat deklarovaných v žádosti na dostupná data registrů, přičemž všechny žádosti jsou administrativní kontrolou zkontrolovány.

Kontrola na místě spočívá v kontrole plnění podmínek opatření a přeměření způsobilé plochy přímo v terénu. Pro kontrolu na místě se vybírá předem stanovený vzorek žádostí (nejčastěji 5 %).

Kontroly jsou navíc doplněny sankčním systémem, který je nastaven výrazně restriktivně, aby odrazoval žadatele od chybné deklarace. Taktéž platí, že po nalezení nesouladu nemůže žadatel chybnou deklaraci opravit. Nevýhodou stávajícího nastavení IACS je jeho relativní nízká efektivnost, kdy časově a na lidské zdroje náročné kontroly na místě zkontrolují pouze malý vzorek žadatelů a detekují tak jen omezený počet porušení.

Od roku 2015 se rozvíjí nová technologie umožňující plošné sledování (monitoring) celého území pomocí metod dálkového průzkumu Země. Výstupy z výzkumných projektů prokázaly, že při využití dat družic Sentinel je možné úspěšně realizovat sledování zemědělských aktivit na zemědělských pozemcích pomocí automatizovaných algoritmů. Tato družicová data jsou navíc dostupná zdarma a jejich pořízení není zpoplatněno, jak tomu bylo doposud v případně tradičně využívaných družicových dat vysokého a velmi vysokého rozlišení (např. QuickBird, Rapid Eye a další). 

Zvyšující se dostupnost ICT technologií (chytré telefony, internetové připojení, GNSS technologie) dále v sobě skrývá potenciál rozšířit a změnit způsob komunikace s žadatelem a to tak, aby žadatel získával průběžné informace o výstupech z monitoringu a o postupu administrace své žádosti. V případě nesrovnalosti pak žadatel může sám poskytnout validní důkaz o plnění podmínek, případně online opravit deklaraci.

Evropská komise v reakci na výše uvedené skutečnosti a výstupy z výzkumných projektů novelizovala prováděcí nařízení č. 809/2014 a v rámci IACS zavedla nový způsob kontroly, tzv. kontroly pomocí systému sledování plochy, nebo také kontroly pomocí monitoringu, kterými členské státy mohou nahradit kontroly na místě.

2. Principy kontrol s využitím satelitního monitoringu

Princip kontrol pomocí monitoringu je založen na rozdělení podmínek dotace do dvou skupin na monitorovatelné a nemonitorovatelné podmínky.

Příkladem monitorovatelných podmínek jsou: identifikace zemědělské kultury, plodinových skupin, identifikace seče, orby a založení a sklizení plodiny. Příkladem nemonitorovatelné podmínky je počet hospodářských zvířat, nebo identifikace druhu dřeviny.

Zadavatel pro dané období určí, které monitorovatelné podmínky budou v daném období kontrolovány pomocí satelitního monitoringu – určí monitorované podmínky.

Pozemky s monitorovanými podmínkami jsou kontinuálně sledovány a dochází u nich k průběžnému vyhodnocování zemědělských aktivit pomocí dat dálkového průzkumu Země, zejména dat družic Sentinel (konkrétně Sentinel-1 a Sentinel-2). Výsledkem kontroly je buď konstatování splnění podmínky, nebo nesplnění podmínky, případně vyhodnocení satelitních dat o splnění nebo nesplnění podmínky nedokáže rozhodnout. Díky frekvenci pořizování dat Sentinel se natolik rozšířila datová základna, nad kterou lze ověřit definované parametry jednotlivých dotačních titulů, že je možné ve valné většině případů vyhodnotit splnění/nesplnění podmínky pouze na základě dat Sentinel bez nutnosti šetření v terénu. 

V případech, kdy vyhodnocení časové řady dat Sentinel není schopno dát jednoznačný výsledek, je nutné realizovat navazující aktivity tzv. Follow-up. Navazující aktivitou je požádání o dodání důkazů přímo farmářem (systém geotagovaných fotografií), dále vyhodnocení podmínky nad dalšími datovými zdroji (např. aktuální letecké snímky), nebo realizování polní návštěvy pracovníkem Zadavatele (terénním inspektorem). Je-li to možné, o volbě konkrétní navazující aktivity pro daný pozemek a podmínku v některých případech rozhoduje IT systém automaticky. Jinak rozhoduje pracovník Zadavatele v roli, která realizuje navazující aktivity. Výsledkem navazujících Follow-up aktivit musí být konstatování splnění/nesplnění podmínky pro účely výplaty dotace.

Dílčí výsledky kontroly pomocí monitoringu jsou průběžně sdělovány farmáři vizualizací prostřednictvím Portálového systému SZIF (tzv. scoreboard). Díky průběžnému vyhodnocení dílčích podmínek a pozemků je scoreboard průběžně aktualizován. Dále systém generuje notifikace „Alerty“, tj. upozornění na blížící termín splnění podmínky u pozemků, kde ještě daná podmínka splněna nebyla. V okamžiku finálního rozhodnutí o splnění/nesplnění podmínky u všech deklarovaných pozemků daného žadatele a opatření, na která žádal, je vyhotoven dokument s „předběžnými výsledky“, který je zaslán žadateli. 

Žadatel může na stav výsledků, který mu Zadavatel průběžně prezentuje, nebo na obdržené předběžné výsledky reagovat změnou žádosti, nebo zasláním důkazů rozporující vyhodnocení. Zaslané změny systém opětovně vyhodnotí a případně provede úpravu výsledků. Pokud důkazy z jejich podstaty nelze vyhodnotit systémem, budou vyhodnoceny pracovníkem Zadavatele.

U nemonitorovaných podmínek zůstává zachován princip výběru vzorku žádostí a ověření plnění podmínek přímo v terénu. Výsledky této kontroly se žadatel dozví v rámci protokolu o kontrole. Na nálezy porušení nemonitorovaných podmínek žadatel nemůže reagovat úpravou žádosti.

Oproti stávajícím kontrolám na místě se kontroly pomocí monitoringu odlišují v těchto bodech:

1. Kontroly pomocí monitoringu ověřují způsobilost všech žádostí o dotaci zvoleného opatření/platby (tj. 100 % pozemků), nejen vybraného vzorku (např. KNM ověřují obvykle min. 5 % žádostí).

2. Kontrola pomocí monitoringu je založena na průběžném vyhodnocování zemědělských aktivit, tj. na kontrole podmínek způsobilosti. Kontrola výměry vychází z údajů v LPIS a předpokladu, že kvalita LPIS zajišťuje maximální chybovost ve výměře v toleranci ± 2 %. Při kontrole pomocí monitoringu nedochází k přeměřování zemědělských pozemků, což je povinnou složkou kontrol na místě.

3. Vyhodnocení zemědělských aktivit probíhá průběžně (využívá průběžně dodávaná data Sentinel), přičemž je možné analyzovat data, která časově předcházejí podání žádosti a taktéž i data, která byla pořízena po výplatě dotace (v závislosti na podmínkách opatření/platby). Případné nesrovnalosti identifikované po výplatě finančních prostředků jsou řešeny systémem vratek.

4. Terénní šetření je omezeno pouze na nejasné pozemky, u kterých následné kontroly doplňují informace z geotagovaných fotografií, administrativních údajů, případně jiných datových zdrojů.

5. Farmáři je umožněno na základě zjištěných výsledků, které mu Zadavatel průběžně sděluje, opravit původní žádost bez rizika udělení administrativní sankce. Díky stoprocentnímu monitoringu může být sankční mechanismus, který měl odrazovat žadatele od chybné deklarace nebo neplnění podmínek, minimalizován.

6. Proces kontroly pomocí monitoringu předpokládá průběžnou komunikaci s farmářem ve formě sdílení průběžných výsledků administrace, umožnění proaktivního zasílání důkazů ze strany farmáře (typicky geotagované fotografie), nebo preventivní upozorňování farmáře na blížící se termíny nebo možná porušení ze strany platební agentury (tzv. Alerty).

3. Proces administrace žádostí – celkový pohled

V této kapitole je popsán souhrnný pohled na proces zpracování žádostí s využitím satelitního monitoringu. Tento pohled poskytuje přehledovou informaci o celkovém řešení XXXX, do něhož je jím dodávaná služba integrována.

1. Základní pojmy a jejich vztahy

Platí, že dotační program se skládá z jednotlivých opatření, některá opatření se dále dělí na podopatření a dále na tituly (např. opatření Agroenvironmentálně-klimatické opatření, podopatření Ošetřování travních porostů a titul Druhově bohaté pastviny).

Žadatel pro jednotlivá opatření/podopatření/tituly podává žádost o poskytnutí dotace. Pro většinu plošných opatření se žádost o poskytnutí dotace sdružuje do tzv. Jednotné žádosti (JŽ). Jednotná žádost agreguje žádosti o poskytnutí dotace na jednotlivá plošná opatření (nezahrnuje všechna plošná opatření, např. lesnická opatření), na podporu chovu vybraných zvířat a zlepšení životních podmínek zvířat. Využití plošného monitoringu se prozatím předpokládá pouze u vybraných plošných opatření z Jednotné žádosti. Jinými slovy v rámci Jednotné žádosti budou některá opatření kontrolována novým systémem kontrol pomocí monitoringu a některá budou kontrolována „po staru“ pomocí kontrol na místě.

Seznam plošně kontrolovaných podmínek opatření pro daný rok vydává Zadavatel.

Podáním Jednotné žádosti se žadatel zavazuje plnit podmínky pro poskytnutí dotace. Pro všechna opatření/podopatření/tituly jsou předem vydefinované podmínky, které musí žadatel splnit k získání nároku na dotaci. Některé podmínky mohou být shodné pro více opatření, jiné jsou specifické pro daná opatření/podopatření/tituly.

Podmínka může být nastavena tak, že v daném čase má k jejímu splnění dojít, nebo tak, že porušení dané podmínky (např. rozorání travního porostu) způsobí, že nárok na dotaci zanikne. Jednotlivá opatření mohou mít různou délku tzv. kontrolního období, po kterou musí plnit podmínky k poskytnutí dotace. Vyhodnocení plnění podmínky se nemusí vázat pouze na konkrétní pozemek, ale může být vázáno na více pozemků (např. na všechny trvalé travní porosty daného žadatele). V rámci kontroly plnění podmínky mohou probíhat i netriviální výpočty nad obhospodařovanými plochami, např. travní porosty nebo určitý typ plodiny musí být na určitém procentu obhospodařované půdy atd.

Základní jednotkou deklarace v Jednotné žádosti, ke které se vztahuje plnění podmínek a u které se provádí kontroly, je zemědělský pozemek. Dále v textu je pro takový pozemek použit termín agricultural parcel (AP). Platí, že agricultural parcel se musí vždy kompletně nacházet v hranicích referenčního pozemku LPIS, tj. musí být v hranicích dílu půdního bloku (DPB). Při identifikaci AP tak lze použít vazbu na DPB. Velmi často také nastává situace, kdy deklarovaný pozemek (AP) je shodný s referenčním pozemkem (DPB), nicméně při nastavování systému je třeba počítat se situacemi, kdy je deklarována jiná plocha AP, než která je evidována v LPIS jako DPB.

Vyhodnocení kontrolního nálezu (konkrétní podmínky pro konkrétní opatření) se může vztahovat pouze ke kontrolované AP nebo k žadateli.

Kontrolované podmínky jsou pro účely specifikace předmětu plnění rozděleny na ty, jejichž plnění je monitorováno s využitím satelitních dat (tj. jedná se o podmínky uvedené na seznamu monitorovaných podmínek – zkráceně Podmínky XXXX), nebo plnění podmínky monitorované není – Podmínky NEMACH.

V případech, kdy satelitní monitoring nebude schopen rozhodnout o splnění podmínky XXXX na AP, musí být podmínka zkontrolována jinou formou, např. formou místního šetření, pomocí ortofota nebo na základě geotagovaných fotografií.

Geotagované fotografie může pořídit jak sám žadatel, tak terénní inspektor Xxxxxxxxxx (TI). Uživatel je může pořídit na výzvu Zadavatele nebo na základě svého vlastního rozhodnutí.

Nemonitorované podmínky pak lze kontrolovat administrativně proti registrům či jiným evidencím, na základě předložených listinných důkazů, nebo kontrolou v terénu kontrola nemonitorovaných podmínek (KNP).

Nález porušení monitorované i nemonitorované podmínky může být učiněn i náhodně při kontrole opatření kontrolovaných „po staru“ pomocí kontrol na místě. I v takovém případě musí být nález zaznamenán a zohledněn při administraci, nebo musí být udělena vratka (v případě, že pro dané opatření již byla vyplacena dotace).

2. Jednotná žádost – Podání a administrace

   1. Jednotná žádost – formulář žádosti a podání žádosti

Žadatel podává Jednotnou žádost v termínu do 15. 5. (do 9. 6. se sankcí za pozdní podání).

Součástí Jednotné žádosti jsou identifikační údaje o žadateli, které jsou shodné pro všechna deklarovaná opatření. Dále Jednotná žádost obsahuje deklarace pro jednotlivá opatření, kde je uveden seznam AP/DPB, jejich výměra, kultura, případně plodiny a další informace dle druhu opatření/podopatření. Součástí jsou i geoprostorová data (zákresy AP).

Žadatel má povinnost podat žádost prostřednictvím geoprostorového formuláře (GSAA – Geo Spatial Aid Application). Pro vyplnění formuláře GSAA je možné využít (používají skoro všichni) tzv. předtiskovou aplikaci, která vygeneruje prostřednictvím datové sady v LPIS tzv. předtiskový formulář na Portálu farmáře (PF). K vytvoření datových sad a následně pro vytvoření předtiskového formuláře jsou využita data z IS Zadavatelea data z LPIS. Předtisková aplikace umožňuje geoprostorově vymezit plochy, ke kterým se vážou jednotlivé podmínky – zakreslit AP.

Po přípravě předtisku podá žadatel žádost Xxxxxxxxxx, a to buď prostřednictvím Portálu farmáře, datovou schránkou, e-mailem s elektronickým podpisem, poštou nebo osobně. 

Pro žádosti, které nejsou vytvořeny v předtiskové aplikaci a nenesou prostorové vymezení, se vytvoří ex-post dotisk žádosti. Způsob podání je shodný jako při vytvoření předtisku. 

2. Následná administrace 

Po přijetí je žádost založena do IS Zadavatele a následně zkontrolována tzv. SW (softwarovou) kontrolou I (SWK I). Jedná se kontrolu úplnosti a správnosti podané žádosti a jejích příloh. Žadatel může být vyzván k doplnění či opravě údajů v žádosti. Doplnění a opravy žádosti provedené na základě kontroly SWK I nemají dopad na deklarované atributy argicultural parcel. Po provedení této kontroly se Jednotná žádost v systému rozpadne na dílčí žádosti pro jednotlivá opatření a každé opatření je již administrováno samostatně. Termíny pro provádění následných kroků administrace se liší dle opatření. Každé opatření má definovanou svou délku kontrolního období, svůj termín vydávání rozhodnutí atd.

Před výpočtem dotace a vydáním rozhodnutí pro každé opatření, probíhá SW kontrola II (SWK II), která je podporována funkcemi IS SAP. Tato kontrola kontroluje finální plnění podmínek způsobilosti a podmíněnosti – křížově (administrativní kontrola) proti registrům a LPIS a přebírá i výsledky z kontrol na místě (v terénu). K vyhodnocení všech kontrol dojde v jednom okamžiku tak, aby bylo možné vyhodnotit výsledné splnění či nesplnění podmínek na daném AP/DPB i v případě souběhu více nálezů na stejném pozemku. 

Po provedení SWK II se provádí automaticky výpočet dotace, kde se agregují všechny nálezy a uplatňují příslušné sankce. Sankce mohou být vztažené k jednotlivým AP/DPB nebo i případně k větším celkům (např. všechny travní porosty) či k „papírovým“ dokladům (evidence, míchací protokoly apod.).

Poté se vydává pro každé opatření rozhodnutí. Všechny tyto procesy budou zachovány v prostředí IS SAP jako doposud. Do SWK II nově přibude další zdroj pochybení zjištěných kontrolou pomocí monitoringu včetně nálezů z Follow-up aktivit a nálezy z KNP. 

3. Výjimky pro plnění opatření 

V některých případech (stanoveno legislativou), nemusí být obecně platná podmínka pro danou AP/DPB směrodatná, platí pro ni tzv. výjimka.  Tyto výjimky jsou evidovány v Registru souhlasu OOP (Orgán ochrany přírody). Některé výjimky jsou známy již po podání Jednotné žádosti, resp. po jejím založení do IS Zadavatele. Většinou se jedná o souběh více opatření na jednom AP/DPB, přičemž podmínka jednoho opatření má prioritu před ostatními opatřeními. Např. žadatel žádající o dotaci na podopatření Ošetřování travních porostů má u některých titulů posunuté nejzazší termíny sečí (info je v LPIS). Tento posun seče platí následně i pro SAPS. Tento typ výjimek je součástí pravidel poskytování dotací.

Výjimky mohou být také ohlášeny žadatelem a následně ze strany Orgánu ochrany přírody povoleny. Toto povolení výjimky bude nově od 2021 vedeno v LPIS.

4.  Ohlášení vyšší moci 

V případě, kdy žadatel nedodržel podmínku z důvodu vyšší moci, může podat ohlášení vyšší moci. Tato ohlášení jsou součástí registru ohlášení vyšších mocí. Vyšší moc je následně uznána, či neuznána. V případě, kdy je vyšší moc uznána, nepočítá se nesplnění podmínky za důvod pro neposkytnutí dotace či udělení sankce, respektive podmínka se považuje za splněnou.

5. Stažení a změna žádosti 

V období, kdy jsou žádosti kontrolovány, může dojít ke stažení žádosti, případně ke změnám žádostí. K provedení změny musí žadatel podat tzv. změnovou žádost. Změnová žádost se vytváří v LPIS – předtiskové aplikaci, kde si žadatel vytvoří datovou sadu s požadovanými změnami včetně geoprostorových informací. Pak žadatel vytvoří předtisk a žádost o změnu zašle Xxxxxxxxxx, stejným způsobem jako při podání Jednotné žádosti. V případě, kdy žadatel nevyužije vytvoření předtisku v předtiskové aplikaci a vytvoří změnovou žádost jiným způsobem, pracovník Zadavatele vytvoří tzv. ex-post předtisk. 

Ke změnám žádostí může dojít kdykoliv v průběhu kontrolního období. Je předem vydefinováno, které změny a do jakého termínu podané, je možné provést (akceptovat). Po zadání změnové žádosti do IS Zadavatele pracovník Zadavatele přijme či zamítne změnu dle stanovených kritérií. V případě přijetí změny se změna propíše do IS Zadavatele do původní deklarace žádosti a do vrstvy GSAA v LPIS. Při všech následných kontrolách včetně kontroly pomocí monitoringu je nutné vždy pracovat s aktuálními údaji, tedy údaji po provedené změně.

6.   Kontrola podmínek v terénu 

   1. Typy kontrol

Nařízení komise č. 809/2014 definuje dva rozdílné přístupy, jak ověřit plnění podmínek pro poskytnutí dotace v terénu. Jedná se:  

• Systém kontrol na místě (KNM) založený na fyzické kontrole na místě (FKNM). KNM se provádí na vzorku 5 % žádostí. Součástí FKNM je i měření plochy. KNM se provádí u opatření, kde nelze provádět kontrolu monitoringem.

• Systém sledování plochy (dále kontrola pomocí monitoringu) založený primárně na využívání automatického vyhodnocení družicových dat Sentinel.  Provádí se u opatření, kde je alespoň jedna podmínka kontrolována vyhodnocením družicových dat (SAMAS).  Množina kontrolovaných podmínek se může v průběhu let měnit, stejně tak se mohou upravovat používané algoritmy.

V systému sledování plochy se podmínky pro poskytnutí dotace dále dělí do dvou skupin:

• Podmínky monitorované – podmínky, jejichž plnění je v daném období ověřováno na základě dat družicových snímků, jsou kontrolované na úrovni jednotlivých AP pomocí dat ze Sentinel (kontrola službou SAMAS). V případě, kdy je podmínka monitorovaná, ale z nějakého důvodu ji u dané AP nelze vyhodnotit, provádí se Follow-up aktivita, a to prostřednictvím doložených geotagovaných fotografií, ortofota, nebo místním šetřením – polní návštěva (PN). Součástí dokumentace kontrol založených na fyzické kontrole na místě je pořízení geotagovaných fotografií terénním inspektorem.

• Podmínky nemonitorované – podmínky, jejichž plnění není ověřováno na základě dat družicových snímků – kontrola nemonitorovaných podmínek (KNP). Jedná se o obdobu již dříve používaných kontrol na místě (KNM), nicméně se neměří plocha.

2. Výběr ke kontrole

KNM – princip bude shodný jako doposud – výběr vzorku 5 % příjemců kontrolovaného opatření/platby. Výběr je prováděn hromadně na základě náhodného výběru i na základě definovaných kritérií (rizikových faktorů). Nad rámec 5% vzorku jsou žadatelé vybíráni také manuálně cíleným výběrem.  Některé kontroly podmínek jsou předmětem delegování na jiné rezortní organizace. Pro tyto účely Zadavatel využívá v rámci KNM mezisklad zpráv o kontrole na MZe, kam zasílá po výběru ke kontrole plán kontrol a jehož prostřednictvím se vrací i výsledky kontrol (Zprávy o delegované kontrole – ZoDK) zadané příslušnou delegovanou organizací.  Výběr pro KNM probíhá a bude probíhat v IS SAP.

KNP – proces výběru ke kontrole nemonitorovaných podmínek (KNP) bude do značné míry shodný s výběrem ke kontrole na místě.  Bude se vybírat 5 % příjemců monitorovaného opatření/platby, a to na základě náhodného výběru i na základě definovaných kritérii (rizikových faktorů). Nad rámec 5% vzorku budou žadatelé vybíráni také manuálně cíleným výběrem. Kontroly některých podmínek budou také delegovány na jiné resortní organizace. Výběr pro KNP bude probíhat také ve stávajícím informačním systému Zadavatele na platformě SAP.

Kontrola SAMAS – neprovádí se výběr ke kontrole, ani plánování kontroly. Kontrola probíhá u 100 % příjemců, s výjimkou AP, které satelitem nelze kontrolovat pro jejich velikost nebo tvar.

Follow-up aktivita – probíhá u těch AP, pro které kontrola monitoringem nedala jednoznačný závěr a zároveň je AP finančně významná. Proto procesu výběru u tohoto typu kontroly předchází výpočet finančního dopadu možného porušení podmínky při označení dané AP výsledkem žlutý.  Stanovení finančního dopadu se počítá na úrovni AP a zároveň se sčítá na úrovni žadatele, tedy počítá se všemi monitorovanými dotačními tituly na všech AP daného žadatele. Stanovení intervalů EUR pro určení významnosti finančního dopadu může EK ještě upravit.

V případě, že je vypočten významný dopad (více než 250 EUR), bude se vybírat 100 % k Follow-up aktivitě. S vypočteným středním dopadem (více než 50 EUR) se bude vybírat automaticky 5 % AP k Follow-up aktivitě, a to jak náhodně, tak i na základě definovaných kritérií (rizikových faktorů). V případě nevýznamného dopadu (méně než 50 EUR) a nevybraných AP se středním dopadem bude Follow-up aktivita prováděna prostřednictvím kontroly existujících geotagovaných fotografií. Pokud nepůjde z pořízené GEOTAGOVANÉ FOTOGRAFIE podmínka vyhodnotit, nemusí se v případě nevýznamného dopadu provádět žádné další aktivity k potvrzení konečného výsledku splnění či nesplnění podmínky. V tomto případě může také zůstat kontrola podmínky bez konečného výsledku.

Pro KNP i KNM je klíčem výběru žadatel, který je vybrán ke kontrole, se kterým je kontrola zahájena a kterému bude následně předán protokol o kontrole. Pro Follow-up aktivity je jednotkou výběru AP.

3. Plánování kontrol

Proces plánování kontroly lze rozdělit na 4 kroky:

1. Plánování v Zásobníku I – Zásobník I je prostředí, ve kterém se zobrazují všechny založené kontroly (KNM, KNP, aktivity Follow-up), které jsou připravené k naplánování. Tato tabulka obsahuje celou řadu atributů, které je možné filtrovat. U KNM a KNP se budou data dotahovat z IS Zadavatele. U Follow-up aktivit budou údaje již v IS XXXX. S tabulkou budou dynamicky propojené mapy (mapové okno).  Vybírat kontroly pro další práci půjde buď zaškrtnutím v tabulce Zásobníku I nebo výběrem více řádků najednou nebo v mapě geoprostorovými výběry. V druhé fázi projektu rámci zefektivnění plánovacího procesu, který dnes probíhá ručně, požaduje Zadavatel, aby poskytovatel navrhl algoritmy, které dle zadaných pravidel (která bude možno uživatelsky měnit) vygenerují návrh seznamu kontrol k realizaci včetně přiřazení inspektorů. 

2. Plánování v Zásobníku II – Zásobník II je prostředí se seznamem kontrol vybraných v Zásobníku I. Slouží k naplánování kontrol. Ke kontrole se přiřadí inspektoři a stanoví se termín plánovaného zahájení kontroly. Struktura tabulky je shodná jako u Zásobníku I, navíc jsou pouze údaje o přiřazených inspektorech a o termínech kontroly. Po naplánování proběhne systémová kontrola naplánování, která prověří všechna pravidla pro plánování (např. kontrola rotace inspektorů, souběh více kontrol atd.). Dále se odešle naplánování ke schválení vedoucímu oddělení, případně se žádá o schválení výjimek z pravidel plánování na centrálním pracovišti.  Dynamická vazba na mapové okno bude existovat i u Zásobníku II, tj. bude možno dělat výběry jak v tabulce, tak geoprostorové v mapě, pro samotné plánování kontrol. 

3. Schvalování výjimek na centrálním pracovišti – schválení nebo neschválení výjimek z pravidel plánování kontrol bude prováděno pracovníkem centrálního pracoviště. Sloupce tabulky budou shodné se Zásobníkem II. Navíc zde budou sloupce Druh výjimky a Zdůvodnění výjimky. Mapové okno není nutné. 

4. Schvalování naplánování vedoucím oddělení – na závěr se naplánované kontroly odešlou ke schválení naplánování vedoucímu oddělení. Vedoucí oddělení bude mít možnost provést systémovou kontrolu plánu. Dynamické mapové okno bude přítomno i zde. Sloupce tabulky budou shodné se schvalováním výjimek na centrálním pracovišti včetně upozorňujících hlášení. 

4. Provádění kontrol

Proces kontrol se skládá z přípravy kontroly, realizace kontroly, zadání výsledků a jejich schválení KI (kontrolní inspektor) a VOIS (vedoucí oddělení inspekční služby). Dále v případě KNM a KNP může nastat ještě řízení o námitkách, kdy se kontroly v IS vrací zpět k řešení příslušnému pracovníkovi Zadavatele. V rámci těchto procesů je nutné pracovat s aktuálními daty. Je tedy nezbytné mít nastavenou komunikaci se: základními registry, s Business Partnerem, s údaji v žádosti, s údaji v LPIS a jinými registry, využívání meziskladu MZe a napojení na podatelnu.

U KNM je již tato komunikace nastavena. Ze stejných principů bude vycházet i KNP.  Provedení kontrol KNM (kontrola na místě) a KNP (kontrola nemonitorovaných podmínek) a zpracování výstupů bude využívat stávající implementaci KNM v IS SAP a v LPIS. U Follow-up aktivit bude vytvořeno nové prostředí.

KNM – bude probíhat dle stávajících principů. Jsou vytvořeny kontrolní listy, které slouží pro přípravu, realizaci a zadání výsledku z kontroly na místě a řízení o námitkách.

KNP – ověření plnění nemonitorovaných podmínek je shodné s ověřováním prováděným v rámci kontrol na místě. Rozdíl je pouze v tom, že se v rámci kontroly nemonitorovaných podmínek neprovádí ověřování způsobilé plochy. Pokud při KNP inspektor zjistí nezpůsobilou plochu, musí ji v rámci KNP změřit; dále musí zaznamenat i porušení monitorované podmínky, pokud porušení nebylo zjištěno XXXX a je zároveň období, kdy podmínka má být plněna či splněna.

Follow-up aktivity – tyto aktivity se mohou provádět buď v terénu – tzv. Polní návštěva (PN) nebo prostřednictvím ověřování geotagovaných fotografií, kdy bude žadatel vyzván k dodání nebo se ověří již existující geotagované fotografie. Nové prostředí umožňuje uživateli zobrazení přidělených Follow-up aktivit, jejich naplánování, zpracování, přípravu podkladů na výjezd do terénu.  Zároveň poskytuje uživateli nástroje pro zaznamenání výsledků Follow-up aktivit, zejména nastavení hodnoty semaforu pro AP a danou podmínku. Dále bude možné propojení s mobilní aplikací pro pořizování geotagovaných fotografií.  Kromě seznamu bude součástí interaktivní mapa.

Kontrola SAMAS – principy kontroly jsou popsány níže (kontroly pomocí satelitu).

3. Komunikace se žadatelem při kontrole monitorováním 

Komunikace mezi žadatelem a Zadavatelem je vícekanálová a kontinuální – Portálový systém SZIF, mobilní aplikace služby GT FOTO, datové schránky, osobní komunikace s regionálními pracovišti nebo s inspektory Zaxxxxxxxx.  Uživatel je průběžně informován o postupu vyřizování svých žádostí a o stavu kontroly plnění podmínek opatření, na která žádal.

Hlavním nástrojem kontinuální komunikace se žadatelem je Portálový systém SZIF, který čerpá aktuální data z databáze IS XXXX. Žadatel je v průběhu celého období, kdy probíhá monitoring, informován o stavu plnění monitorovaných podmínek na daných AP, na které žádal dotace. Žadatel má informaci, jaký je stav plnění podmínky k určitému datu. Žadatel může dodat vlastní podklady, které přispějí ke konečnému vyhodnocení plnění podmínek na AP. Také může změnit žádost nebo ji vzít zpět. 

Žadatel může také sám iniciovat komunikaci se Zadavatelem zasláním dokumentů prostřednictvím Portálového systému SZIF nebo zasláním geotagovaných fotografií prostřednictvím služby GT FOTO.

1. Scoreboard

Informace se stavy podmínek k jednotlivým AP (hodnoty semaforu) budou zobrazeny v rozsahu oprávnění přihlášeného žadatele na Portálovém systému SZIF v přehledné tabulce tzv. scoreboardu. U každé AP bude zaznamenán stav plnění podmínek. Stav plnění bude zároveň agregován na úrovni DPB a na úrovni jednotlivých dotačních titulů. U monitorovaných podmínek, u kterých je to relevantní, bude možné vyvolat graf (časovou řadu) vyhodnocovaných hodnot ze satelitních dat.

Scoreboard se vytvoří hned po načtení žádosti do IS XXXX a bude se aktualizovat hned po každé změně AP v rámci GSAA, včetně informace o zapracované změně. Bude možné zobrazit historii změn stavů. Scoreboard bude obsahovat proklik na vytvoření změnové žádosti v předtiskové aplikaci či žádosti o zpětvzetí.

Scoreboard se také aktualizuje, jakmile dojde ke změně výsledků kontrol pro danou AP, nebo když k ní bude zadaný požadavek na geotagované fotografie, případně pořízená geotagovaná fotografie nebo bude Zadavatelem akceptována výjimka či vyšší moc.

Informace na Scoreboardu budou zobrazovány jak na úrovní celé žádosti, tak i pro jednotlivé AP:

• Informace celá žádost – číslo žádosti, datum podání žádosti, přijetí změnové žádosti, přijetí ohlášení vyšší moci, stav semaforu na úrovni jednotlivých dotačních titulů. Informace o blížících se důležitých termínech.

• Informace k AP – jednoznačný identifikátor AP, výměra AP, plodina, opatření/podopatření (SAPS, EZ atd.), monitorovaný scénář, stav semaforu u jednotlivých podmínek, datum, kdy se hodnota semaforu změnila, přijetí ohlášení vyšší moci nebo výjimky, informace o změně žádosti. Dále kód dílu půdního bloku (DPB) (popř. zbytková plocha – kód), výměra způsobilé plochy, kultura DPB.

Scoreboard vhodným způsobem integruje mapové okno tak, aby bylo možné z úrovně AP zazoomovat a zvýraznit dané AP v mapovém okně, kde bude AP zobrazena v kontextu s dalšími daty, která poskytuje Ministerstvo zemědělství z LPIS (MZe), Ortofoto (ČÚZK) atd.  Zároveň bude k dispozici služba, která dodá data pro mapovou službu, zobrazující, kde byly identifikovány nehomogenní plochy, které způsobily nesplnění podmínky (stejná služba popsána v kapitole Přenos dat ze SAMAS do LPIS).

Další informací u jednotlivých AP bude informace týkající se geotagovaných fotografií: existuje pro AP požadavek na dodání geotagovaných fotografií od žadatele, případně, že je k dané AP geotagovaná fotografie již pořízena. Geotagované fotografie půjde zobrazit v mapovém okně v kontextu AP. Více ke geotagovaným fotografiím uvádí samostatná kapitola dále.

Současně bude možné k jednotlivým AP nahrát různé dokumenty a doplňující informace.  Ke každé AP si bude moci žadatel přidat místní název a poznámku.

Na scoreboardu u každého DPB (AP) bude odkaz do předtiskové aplikace, kde si žadatel bude moci vytvořit změnovou žádost či provést zpětvzetí.  Možnost podat změnu bude umožněna pouze do konečného termínu pro podání změny.

Současně bude možné přímo ze scoreboardu proklikem podat stažení DPB ze žádosti (je součástí změnové žádosti) nebo celé žádosti.  Stažení musí být umožněno i po konečném termínu pro změnu, resp. až do vydání rozhodnutí o poskytnutí/zamítnutí dotace.

2. Zasílání alertu (upozornění) žadateli

V některých případech (dle typu podmínky plnění) se budou žadateli zasílat tzv. alerty (upozornění). Cílem těchto alertů je upozornit žadatele, že se pro danou podmínku blíží termín plnění, a zároveň ho informovat, co má provést, aby podmínka byla splněna. Alert se bude zobrazovat automaticky v Portálovém systému SZIF a zároveň bude zasílán žadateli e-mailem. Kritéria pro zasílání alertu budou založena na stavu semaforu vůči blížícímu se datu plnění podmínky relevantní k dané AP.  Jedná se o upozornění, od žadatele není očekávána žádná odpověď. Alerty se budou zasílat buď hromadně anebo pro jednotlivé AP. Některé alerty bude moci uživatel filtrovat nebo si ve svém profilu nastavit předstih před termínem, ve kterém mu má být alert zaslán, ale bude existovat skupina alertů, které nebude možné potlačit ze strany uživatele.

3. Zaslání žádosti o spolupráci

V případě, kdy u dané AP vyšla kontrola monitoringu (semafor) žlutě a po výpočtu finančního dopadu byl u dané AP založen objekt Follow-up aktivity, pracovník Zadavatele rozhodne, zda bude žadateli zaslána žádost o spolupráci či nikoliv.

Součástí žádosti je automaticky dotažený text stanovený dle konkrétní podmínky. Ve výzvě je žadatel požádán o konkrétní spolupráci, s cílem jasně určit konečný stav plnění podmínky. Výzva bude zobrazena na scoreboardu, objeví se provazba v aplikaci na geotagované fotografie a zároveň bude zaslána žadateli emailem.

4. Dokument s předběžnými výsledky

Po ukončení kontrol monitoringem se bude automaticky generovat pro jednotlivé dotační opatření/tituly dokument s předběžnými výsledky. Pravidla, kdy je kontrola ukončena, stanoví každoročně metodik Zadavatele.

V dokumentu bude přehled DPB (popř. AP) a informace o výsledku monitoringu pro daný dotační titul/tituly. Součástí dokumentu bude informace, že Zaxxxxxxx xokončil kontrolu pomocí monitoringu. V dokumentu bude poučení, jak a do kdy může žadatel reagovat na nesplnění podmínky (červené semafory). Dokument bude opatřen časovým razítkem a kvalifikovanou elektronickou pečetí, bude mu přiděleno číslo jednací a bude založen do spisu žádosti v rámci spisové služby Zadavatele.

Žadateli bude odeslán dokument s předběžnými výsledky dle pravidel doručování dokumentů Zadavateli, tzn. buď prostřednictvím datové schránky, nebo prostřednictvím Portálového systému SZIF, a zároveň daný žadatel obdrží notifikaci do emailu. Tuto notifikaci nebude možné vypnout.

4. Geotagované fotografie

   1. Pořízení a odeslání geotagovaných fotografií

Pořízení geotagované fotografie probíhá prostřednictvím mobilní aplikace služby GT FOTO. Uživatel může pořizovat geotagované fotografie buď na základě založeného úkolu ze strany Zadavatele, nebo může pořizovat geotagované fotografie ve „volném režimu“ bez vazby na úkol. Pro každou fotografii bude možné zadat parametry úkolu (např. poloha, směr, typ). Úkoly budou zadávány ze strany Zadavatele prostřednictvím webového klienta. Pro žadatele budou viditelné v mobilní aplikaci a na Portálovém systému SZIF.

2. Ukládání geotagovaných fotografií

Pořízenou geotagovanou fotografii nebude možné editovat ani měnit.  Geotagované fotografie budou uloženy včetně všech metadat (časové razítko, souřadnice, azimut, uživatelský účet, zařízení, informace o kalibraci zařízení, přesnost polohy, počet satelitů, popř. další zdroje polohy, …). Fotografie nepůjde z mobilu exportovat, jediný přístup k němu bude mít mobilní aplikace, pro prohlížení a synchronizační služba, která foto bude odesílat na úložiště služby GT FOTO.  Fotografie, které vedly ke změně semaforu (fotografie označené pracovníkem Zadavatele) budou uloženy včetně metadat v IS Zadavatele a archivovány po dobu 10 let. 

Mobilní aplikace – hlavní funkce jsou:

• Pořízení geotagovaných fotografií, při kterém bude hlídána kvalita správnost pořizované fotografie. Pořizovat fotografie bude možné i mimo „režim úkolu“ na základě vlastního rozhodnutí uživatele. K fotografii bude možné uložit komentář.

• Mapová prohlížečka zobrazující podkladová data s vyobrazením jednotlivých úloh.

• Přehled úkolů s vazbou na již pořízené fotografie.

• Navigace na bod výběrem bodu v rámci úkolu. Kolem každého bodu bude zvolen vhodný buffer, do kterého se musí žadatel dostat, jinak mu aplikace neumožní splnit konkrétní úlohu.

3. Vyhodnocení geotagovaných fotografií a jejich správa v IS Zadavatele

Automatické vyhodnocení kvality – bude v základní verzi probíhat již v mobilní aplikaci. Po odeslání geotagované fotografie se znovu automaticky zkontroluje v úložišti služby GT FOTO její kvalita. Pokud bude nevyhovující, otevře se znovu úloha a žadatel bude požádán o pořízení nové fotky.

Automatické vyhodnocení obsahu – bude nastaven mechanismus, který zajistí automatické vyhodnocení obsahu fotografie. Pakliže automat bude schopen stanovit, zda se na snímku nachází konkrétní plodiny, lze na něm rozpoznat provedenou zemědělskou operaci a podobně, nebude již nutné fotografii manuálně prohlížet, a ta bude automaticky uložena v úložišti služby GT FOTO. Zároveň bude v jejích atributech označeno, že prošla automatickým vyhodnocením a bude zaznamenán výsledek tohoto vyhodnocení.

Manuální vyhodnocení obsahu fotografie – manuální vyhodnocení provádí pracovník Zadavatele, který bude mít k dispozici všechny fotografie, které již předtím prošly automatickým vyhodnocením kvality i obsahu službou GT FOTO. Pracovník Zadavatele na základě fotografií může změnit semafor pro danou AP a kontrolovanou podmínku.  V případě, že fotografie nebudou průkazné, musí pracovník Zadavatele zajistit nové důkazy – opět požádá žadatele o novou fotografii nebo bude provedeno místní šetření.

4. Vyhodnocení přesnosti a správnosti automatického vyhodnocení geotagované fotografie

Pro prověření správného nastavení automatického vyhodnocení obsahu fotografií službou GT FOTO musí probíhat validace výsledků algoritmů.  Ve speciálním uložišti bude uloženo určité procento vyhodnocených snímků s různými výsledky vyhodnocení. Tyto fotografie pak bude nutné manuálně posoudit a vyhodnotit úspěšnost daného algoritmu.

4. Požadavky na uživatelské rozhraní

Uživatelské rozhraní služby GT FOTO včetně všech uživatelských komponent bude kompletně lokalizováno v českém jazyce.

Administrátorská rozhraní SW modulů nebo technologií třetích stran mohou být v anglickém jazyce.

Musí být možné pracovat na standardní pracovní stanici (operační systém Microsoft Windows, 8 GB RAM, CPU Passmark 7000, max. 30 GB diskového prostoru).

9. Pojmy a zkratky

Pojmy a zkratky použité v tomto dokumentu jsou definované v příloze č. 9 Smlouvy.

1 Jeho případné vytištění zajistí prohlížeč.

S tátní zemědělský intervenční fond

Xx Xxxxxxxx 00, 000 00 Xxxxx 0 Xxxxxx 3/113