}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya Masarykova univerzita Fakulta informatiky Portál úředníka Diplomová práce Bc. Vlasta Žáková Brno, jaro 2014

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Bc. Vlasta Žáková Vedoucí práce: RNDr. Jaroslav Ráček Ph.D. ii

3 Poděkování Ráda bych tímto poděkovala panu doktoru Ráčkovi za jeho vedení a trpělivost. Dále pak všem, kteří mi pomáhali a podporovali mě, zejména mému muži. iii

4 Shrnutí Práce se zabývá problematikou Portálu úředníka pro kraje a statutární města. Definuje veřejnou správu, popisuje informační infrastrukturu úřadu. Porovnává aktuální portálové technologie z hlediska použitelnosti pro územní samosprávu. Pozornost věnuje především portálu Liferay. Dále detailně popisuje požadavky krajů a statutárních měst na Portál a jeho portlety. V závěrečné části práce jsou umístěny návrhy a UML modely Portálu a jeho komponent. iv

5 Klíčová slova Portál úředníka, Liferay, IS veřejné správy, Portlety, UML, Návrh IS v

6 Obsah 1 Úvod Veřejná správa Územní samospráva Strategie Smart Administration Implementace strategie Smart Administration Vnitřní integrace úřadu Portálové řešení Portálu úředníka Podnikové portály Porovnání jednotlivých portálových řešení Porovnání portálu z hlediska zastoupení na úřadech ČR Portlety Funkční požadavky na Portál úředníka Portlety a integrované funkce portálu Liferay vyžadované v Portálu úředníka Nefunkční požadavky na Portál úředníka Návrh portálu úředníka Návrh Portálu úředníka v Liferay Návrh portletů do Portálu úředníka DMS Docházka Dohled nad příspěvkovými organizacemi Kalendář Úřední deska Service desk Úkolník Manažerský IS Systém pro definování workflow Závěr A Popisy diagramů užití A.1 Service desk - popis A.2 Úkolník - popis A.3 Manažerský IS - popis A.4 Dohled nad příspevkovými organizacemi - popis A.5 Docházka - popis A.6 Kalendář - popis A.7 Úřední deska - popis A.8 Systém pro definování workflow

7 A.9 DMS B Návrhy obrazovek portletů

8 1 Úvod V posledních letech se událo ve fungování úřadů množství zásadních změn, zavádění datových schránek, elektronické spisové služby a na ní navázané elektronické podatelny, nové množství legislativy, nové postupy vyplývající z legislativy, velké množství nových aplikací, evidencí a systémů nutných pro práci úředníka. Ne všechny úřady dokázaly na vytyčené změny dostatečně pružně reagovat, a tak mnoho z nich dosud pracuje napůl elektronicky a napůl vyřizuje dokumenty v listinné formě. V praxi to může vypadat tak, že občan sice podá elektronický dokument přes datovou schránku, ten ale musí být vytisknut a vyřízen v listinné formě, aby se poté naskenoval a odeslal v příloze datové zprávy občanovi. Jak elektronická, tak listinná forma se také archivuje a vzniká tak mnoho duplicitních dokumentů. Kraje si jako první uvědomily dlouhodobou neudržitelnost situace a začaly realizovat vládní strategii Smart Administration, která vyzývá úřady k modernizaci a postupnému přechodu k elektronickému zpracování všech agend. Tato strategie vytyčuje plány až do roku V tomto roce by měly všechny úřady fungovat z větší části elektronicky. Neznamená to ale konec rozvoje egovernmentu v České republice. Vláda vypracovala pokračování strategie až do roku 2020, která počítá s další integrací systémů navzájem, především sdílení dat mezi nimi, a převedením listinné agendy na elektronickou v co možná nejširší míře. Vytyčeným měřitelným cílem je, že 85 % podání bude v roce 2020 elektronicky.[43] Po aktivitě krajů se pomalu rozhodly dodržet strategii i statutární města. Cílem diplomové práce je analyzovat jejich požadavky a navrhnout pro ně univerzálně použitelné portálové řešení obsahující všechny komponenty, které zaměstnanec kraje a statutárního města potřebuje ke své práci. Použitá technologie byla definována již v zadání práce, jedná se o portál společnosti Liferay. První kapitola definuje státní a veřejnou správu ČR a její části. Popisuje rozdíly mezi agendami krajů a statutárních měst. Další kapitola se věnuje přímo vládním strategiím a jejím důsledkům pro úřad. Popisuje nejvýraznější komponenty, které mají úřady veřejné správy povinnost využívat. V další kapitole vymezuji pojem portálu a zdůvodňuji proč je portálové řešení pro úřad vhodné. Analyzuji portálová řešení jednotlivých poskytovatelů, jejich silné a slabé stránky a zastoupení na úřadech územní samosprávy v ČR. Přikládám případovou studii pro konkrétní statutární město. V rámci portálu se věnuji i portletům, definuji jejich standardy a použití. V další kapitole rozsáhle analyzuji požadavky statutárních měst a krajů na portlety v rámci Portálu úředníka. Dále se věnuji těm z nich, které jsou nejčastěji požadované. 3

9 1. Úvod Rozlišuji, které již existují v rámci Liferay a definuji ty, které bude nutné doplnit. Krátce zmiňuji i nefunkční požadavky a jejich řešení v prostředí Liferay. V poslední kapitole se věnuji samotnému návrhu portálu a těchto portletů a dodávám jednotlivé vývojové diagramy UML. 4

10 2 Veřejná správa Veřejná správa je soubor institucí obstarávající věci veřejného zájmu. Mezi její hlavní náplně činnosti patří ochrana veřejného pořádku, bezpečnost a obrana státu, zahraniční a hospodářská politika a zdravotní, sociální a školská sféra. Nejdůležitějším subjektem veřejné správy je státní správa a dále pak jednotlivé územní samosprávy. [15] Státní správa Státní správa se celkem skládá z 15 ministerstev a 11 dalších správních úřadů (například Český statistický úřad, Český zeměměřičský úřad, Energetický regulační úřad, Rada pro rozhlasové a televizní vysílání atd.). Dohromady se označují jako takzvané ústřední správní úřady. Tyto úřady mají dalších 478 podřízených správních úřadů (například Finanční úřady, Katastrální úřady, Úřady práce atd.). [38] Zákon č. 2/1969 Sb. říká, že nejvyšším orgánem je vláda, která řídí a kontroluje činnost ministerstev a jiných ústředních orgánů státní správy České republiky. Konkrétně působnost ministerstva vymezuje 12 téhož zákona.každé ministerstvo vede ministr, to se dále člení na další odbory vedenými náměstky ministra. [1] 2.1 Územní samospráva Obce a ORP Základním stavebním kamenem územní samosprávy jsou obce upravené zákonem č. 128/2000 Sb. [4], o obcích. Každá obec vystupuje jako suverenní správní jednotka, své záležitosti spravuje samostatně, volně nakládá s vlastním majetkem a za svoji správu nese vlastní zodpovědnost. Přímo volené obecní zastupitelstvo obec spravuje a ze svého středu si volí starostu, místostarostu a radu obce, která má v obci výkonnou moc. Rada připravuje návrhy pro zasedání zastupitelstva, zastupitelstvo schvaluje vyhlášky. Každá obec musí mít vždy zřízen finanční a kontrolní výbor. Navíc v případě, že v dané obci žije více než 10 % obyvatel jiné národností než české, i výbor pro národnostní menšiny. Obce se dále dělí podle rozsahu výkonu správy. Když obce spravují i jiné celky mimo vlastní místo obce, lze dále rozdělovat podle míry přenesení státní správy. Jedná se zejména o pověřené obecní úřady nebo obce s rozšířenou působností (ORP). 5

11 2. Veřejná správa Vyšší územně správní celky kraje Kraje byly vymezeny ústavním zákonem č. 347/1997 Sb. o krajích. Na území České republiky bylo zřízeno 14 vyšších územních samosprávných celků. Orgán spravující kraj je stejně jako u obcí zastupitelstvo, z jeho středu je volen hejtman, jeho náměstci a rada kraje s výkonnou mocí. Jednotliví radní mají přiděleny odbory působnosti. Zastupitelstvo musí vždy zřídit výbory finanční, kontrolní a výbor pro výchovu, vzdělávání a zaměstnanost, může zřídit i další. [2] Dalším orgánem kraje je krajský úřad, který plní úkoly přidělené zastupitelstvem a realizuje správu kraje. Do samostatné působnosti podle zákona o krajích mimo jiné patří: hospodaření kraje, vydávání vyhlášek, zákonodárná iniciativa vůči Poslanecké sněmovně, program rozvoje kraje. Dále pak rozvoj koncepce památkové péče, správa školství (střední školy, učiliště, základní školy) na území kraje, zřizování nemocnic, záchranné služby atd.[38] Statutární města Zákon o obcích č. 128/2000 Sb. [4] ošetřuje zvláštní kategorii měst nazvanou jako územně členěná statutární města. V České republice existuje aktuálně 28 takových měst. Jejich seznam je uveden v zákoně a od běžných měst se liší tím, že se řídí vlastním statutem a hlavně se dále dělí na městské části, které se samostatně spravují. Každý městský obvod je spravován zastupitelstvem městské části, které ze svého středu volí starostu městské části. Statutární město samotné je spravováno zastupitelstvem, z něj je volen primátor, jeho náměstek a rada města, která slouží jako výkonný orgán. Úřední zajištění chodu města zajišťuje magistrát. Magistrát se dělí na jednotlivé specializované úseky, které zřídila rada města a pracuje na úkolech svěřených zastupitelstvem. Jeho vnitřní organizaci upravuje organizační řád. Ve vztahu k jednotlivým městským obvodům kontroluje jejich činnost, přezkoumává rozhodnutí orgánů městských obvodů vydaná ve správním řízení. [4] Některá statutární města jsou zároveň městy krajskými, ale mnoho z nich má práva a povinnosti obce s rozšířenou působností (ORP). Rozsah pravomocí a agendy ORP a kraje Následující tabulka ilustruje rozdíly mezi pravomocemi ORP a krajů v různorodých oblastech působení. 6

12 Tabulka 2.1: Tabulka pravomocí ORP a kraje [56] Oblast pravomocí ORP Kraje Hasiči Zřizování sboru dobrovolných hasičů obce Sociální služby Vyhledávání a mapování potřeb na daném území, vykonávání sociální práce v oblasti hmotné nouze a zřizování sociálních zařízení Zdravotnictví Mohou zřizovat jesle, obecní nemocnice a lékarny. Školství Zřizování a rušení mateřských škol. Obec je povinna zajistit podmínky pro plnění povinné školní docházky dětí s místem trvalého pobytu na jejím území, z toho důvodu může založit základní školu. Voda Řešení dodávek pitné vody, kanalizace, čištění odpadních vod a ochrany vod před znečištěním (např. čističkou vody). 2. Veřejná správa HZS kraje Povinnost zřizovat sociální služby a instituce. Zřizovatelská povinnost pro zřizování nemocnic, rychlé záchranné služby a dalších příspěvkových organizací (zachytná stanice, léčebné a kojenecké ústavy). Zřizování nebo rušení středních škol, vyšších odborných škol, speciálních škol, dětských domovů. Zřizování koupališť, řešení povodňových plánů. 7

13 2. Veřejná správa Lesnictví Rybářsví Odpady Vydávání povolení na kácení stromů. Pokud je vlastníkem lesů, tak musí zpracovávat tzv. lesní hospodářské plány a mít odborného lesního hospodáře. Ustanovení rybářských stráží a vedení evidenci všech rybářských stráží ve své působnosti. Řešení sběru, shromažďování, přepravy, odstraňování a evidence odpadů vytvořených jejími občany. Vydává vlastní vyhlášku o odpadech. Tvoření koncepce systému a rozvíjení potřebné infrastruktury k nakládání s komunálními odpady. MHD Zavedení není povinné. Řešení integrovaného dopravního systému kraje. Veřejná doprava Na bázi dobrovolnosti. Zajišťují veřejnou dopravu v kraji. Policie Obecní (městská) policie. Kultura Nepovinné zřizování příspěvkových organizací (knihovna, divadlo, kino). Zřizování příspěvkových organizací, přidělování dotací. 8

14 3 Strategie Smart Administration Struktura ICT veřejné správy je významně ovlivněna dokumentem Strategie Smart administration, který si na roky vytyčil cíl sjednotit a zefektivnit veřejnou správu pomocí elektronizace agend a využívání informačních technologií a IS veřejné správy. Strategie přímo vyzývá úřady, aby hledaly rovnováhu mezi přiblížením veřejné správy občanovi a efektivní vynakládáním veřejných prostředků. Dokument definuje veřejnou správu jako hexagon navzájem propojených entit: Legislativa, Organizace, ICT, Občan, Úředník a Financování 3.1. Občan je v této strategii brán jako klient veřejné správy. Je nutné mu usnadnit styk s úřady a co možná nejméně znepříjemňovat život nadbytečnou regulací. Zároveň je třeba veřejnou správu pro občana zprůhlednit, učinit ji otevřenou a umožnit tak občanům participovat na jejích rozhodnutích a kontrolovat její fungování. [38] Obrázek 3.1: Hexagon efektivní veřejné správy, Smart administration [38] V rámci tohoto dokumentu bylo kromě jiného naplánováno vytvoření množství ICT systémů, které budou vzájemně synergicky spolupracovat. Aktuálně na něj navazuje nový dokument Smart administration 2014+, který se zaměřuje především na další propojování systémů veřejné správy, 9

15 3. Strategie Smart Administration vzájemném sdílení dat a služeb. Největší změnou by mělo být vzájemné sdílení informací o občanovi i mezi jednotlivými agendovými informačními systémy. Další myšlenkou, kterou strategie rozvíjí, je plně elektronické podání dokumentů. Konkrétní cíl je dokonce formulován jako realizovat plně elektronické podání u 85% případů do roku U těchto podání budou navíc údaje, které jsou už obsaženy v základních registrech nebo AIS 1 vyplňovány automaticky bez nutnosti je znovu dokládat občanem. [43] 3.1 Implementace strategie Smart Administration Následující systémy se řadí mezi strategické projekty egovernmentu v rámci Smart Administration. Tyto systémy významné pro veřejnou správu mají úředníci povinnost používat. Systémy jsou provozovány Ministerstvem vnitra ČR a slouží zejména pro centrální evidenci a správu dat. [36] Czech POINT Czech point Český Podací Ověřovací a Informační Národní Terminál, používaný pro výpisy z centrálních registrů. Existuje ve dvou odnožích. CzechPOINT@home kontaktní místo pouze pro občany ČR. Umožňuje získat výpisy ze základních registrů, Obchodního rejstříku, Živnostenského rejstříku a dalších rejstříků v elektronické podobě bez nutnosti navštívit daný úřad. Blíží se vizi egovernmentu podle které bude mít občan bezpečný a jednoduchý přístup k veřejným službám prostřednictvím sítě internet. Kontaktní centra jsou rozmístěna na úřadech po celé ČR i v zahraničí [35] CzechPOINT@office je vytvořeno pro potřeby samotného úřadu. Spravuje agendy matriky, ohlašovny, soudy a plánuje se rozšířit jeho pravomoce i na další agendy. Pod CzechPOINT@office je zahrnut i tzn. Institut automatizované konverze písemnosti. V této aplikaci úředník přiznává stejné právní účinky dokumentu, který byl převeden z listinné formy do elektronické a naopak. Rozhraní CzechPOINT@office je také napojeno na základní registry, ze kterých úředník získává potřebná data. [35] 1. Agendový informační systém úřednící využívají ke správě agend, např. Informační systém občanských průkazů nebo Informační systém cestovních dokladů 10

16 3. Strategie Smart Administration Základní registry Základní kámen registrů byl položen na základě dokumentu Efektivní veřejná správa a přátelské veřejné služby a zákona č. 111/2009 Sb. Zákon stanoví povinnost úřadům a dalším orgánům veřejné správy využívat data v registrech obsažená. Nejvíce podporovaný přístup k datům je ovšem využití vlastního agendového IS, který odpovídá zákonu č. 365/2000 Sb., jedině pak je úředník schopen využít plně funkcionality základních registrů. [9][5] Hlavním cílem základních registrů je zjednodušit práci občanovi s dokládáním různých referenčních údajů. Tyto údaje si úřad nově zjistí ze základních registrů. Jedinou nutností je identifikovat se jako občan prostřednictvím elektronicky čitelných dokladů jako je občanský průkaz, cestovní pas, případně průkaz o povolení k pobytu. Podle 36 zákona č. 500/2004 Sb. lze identifikovat občana i kombinací údajů: jméno, datum narození a adresa místa trvalého pobytu. [54] Základní registry jsou celkem čtyři, jejich ovládání zajišťuje Informační systém základních registrů (ISZR). Fyzických osob (ROB) obsahuje základní údaje (jméno a příjmení, datum a místo narození a úmrtí a státní občanství) o občanech a cizincích s povolením k pobytu. Právnických osob (ROS) obsahuje údaje o právnických osobách, podnikajících fyzických osobách, orgánech veřejné moci, občanských sdruženích a církvích. Územní identifikace, adres a nemovitostí (RÚIAN) obsahuje údaje o základních územních prvcích, jako jsou například obce, části obcí, ulice, parcely, katastrální území a další. Orgánů veřejné moci (OVM) a jejich rozhodnutích definuje rozsah působnosti orgánů veřejné moci a oprávnění přístupu k jednotlivým údajům, informace o změnách provedených v těchto údajích apod. Garantuje bezpečnou správu údajů obsažených v jednotlivých registrech. Obsahuje Katalog působností orgánů veřejné moci. [9] Poslední komponentou základních registrů je registr identifikátorů (ORG). ORG je převodník identifikátorů do jednotlivých agend základních registrů. Jeho zavedení bylo motivováno snahou nahradit používání rodného čísla bezvýznamovými identifikátory. Tyto identifikátory se v každé agendě liší, tudíž není možné znalostí jednoho zjistit údaje o občanovi i z ostatních agend, což významně snižuje riziko zneužití dat. 11

17 3. Strategie Smart Administration Data ze základních registrů je možno získávat pomocí ISZR, nebo využít již zmíněný způsob napojení přímo na agendové informační systémy úřadu. [9] Datové schránky a Informační systém datových schránek (ISDS) Zákon 300/2008 o datových schránkách říká "Datová schránka je elektronické úložiště, které je určeno k doručování orgány veřejné moci a k provádění úkonů vůči orgánům veřejné moci." [7] Doručování dokumentů datovou schránkou je rovnocenné s doručením dokumentu v listinné podobě. Všechny úřady a právnické osoby mají povinně zřízenou datovou schránku, ostatním je datová schránka zřízena na žádost. ISDS je informační systém zajišťující provoz datových schránek, doručování dokumentů mezi schránkami a práci s dokumenty. [40] Elektronický portál územních samospráv (epusa) Jedná se o informační systém se základními údaji orgánů veřejné správy kraje, ORP a obce jehož cílem je být garantovaným zdrojem informací o těchto subjektech samosprávy. [32] Za správnost a aktuálnost dat nese odpovědnost daný úřad, který má povinnost udržovat údaje aktuální. Příkladem uložených dat je adresa, číslo bankovního účtu, telefon, úřední hodiny, webové stránky, struktura obce, kontaktní osoby, správní obvody a úřady a zřizované organizace. [37] Portál veřejné správy(pvs) Portál, který slouží jako jednotný portál agregující informace o všech službách veřejné správy jak pro občana, tak i pro firmu nebo orgány veřejné moci. Digitální mapa veřejné správy Je projekt Ministerstva vnitra, jehož cíl je "Vybudovat jednotný aktualizovaný (referenční) digitální mapový podklad za celé území ČR pro potřeby agend a informačních systémů veřejné správy (RÚIAN)". [42] Toto mapové dílo vznikne složením digitálních ortofotomap, existujících digitálních a digitalizovaných katastrálních map, digitálních účelových katastrálních map společně s údaji z registru RÚIAN, který bude dodávat identifikační údaje jednotlivých zobrazovaných celků. Zamyšlení uživatelé systému budou občané, složky Integrovaného záchranného systému České republiky a Policie ČR a samozřejmě subjekty veřejné správy. [39] 12

18 3. Strategie Smart Administration KIVS KIVS (Komunikační infrastruktura veřejné správy) je jednotná komunikační infrastruktura sloužící k propojení všech agend s úřady a veřejností. Lze si ho zjednodušeně představit jako intranet provozovaný státem. KIVS také zajišťuje potřebné datové služby pro subjekty veřejné správy. Všem Technologickým centrům (TC kraje, TC ORP), které jsou na ně napojeny poskytuje následující služby: [16] Adresářové služby 2, Identity management 3, DNS 4 v prostředí Technologických center, Synchronizace přesného času, Poštovní server, Antivir, Centrální dohledový systém pro zajištění kontroly a dostupnosti Technologických center. Technologická centra Státem je také podporován vznik nebo úprava Technologických center na úrovni krajů a ORP, aby byla zaručena jejich návaznost na předchozí IT služby a byla umožněna integrace všech důležitých komponent. Technologická centra jsou spojena Komunikační infrastrukturou veřejné správy (KIVS). Tabulka 3.1: Povinné požadavky na Technologické centrum Požadavek Kraje ORP Negarantované úložiště nevyřízených a neuzavřených povinné povinné spisů Garantované úložiště (espisovna) povinné nepovinné Elektronická spisová služba povinné povinné Vnitřní integrace úřadu povinné povinné 2. Adresářová služba aplikace obsahující údaje o subjektech, např. LDAP nebo Active Directory 3. Identity management centrální správa uživatelských účtů 4. DNS databáze doménových jmen a překlad IP adres na jména 13

19 3. Strategie Smart Administration 3.2 Vnitřní integrace úřadu Po vytvoření základních registrů, služby CzechPOINT, datových schránek a dalších aplikací je potřeba změnit fungování úřadu tak, aby je dokázal správně a efektivně využívat a zapojit do svého chodu. Cílovým stavem je snížení administrativní zátěže pro občana i úředníka. Je kladen důraz na postupnou digitalizaci veřejné správy, zpracování formulářů elektronickou cestou, jejich zasílání přes datové schránky, evidenci v elektronické spisové službě a nakonec uložení v espisovně. [38] Systém integrovaného úřadu musí obsahovat následující základní komponenty: [41] systém řízení organizační struktury systém pro evidenci přístupů, oprávnění, uživatelských rolí a celkové struktury organizace. systém řízení zdrojů měření kvality, efektivity a výkonnosti úřadu. systém řízení služeb integrace všech agendových informačních systémů, definice workflow pro jednotlivé služby, řízení komunikace s dalšími úřady. vnější integrace systému integrace s centrálními systémy Czech- POINT, epusa, PVS a základními registry klíčové databáze systému databáze pracovníků, databáze workflow, databáze práv a povinností napojená na Registr práv a povinností. Dalším aspektem vnitřní integrace úřadu je jednotné prostředí a standardizace procesů vykonávaných na jednotlivých úřadech. To je základ tzvn. Portálu úředníka, který bude jednotnou pracovních plochou pro každého zaměstnance úřadu. Portál úředníka V rámci projektu Vnitřní integrace úřadu má vzniknout neveřejný webový portál, který bude sloužit jako rozcestník pro potřeby úředníka. Tento portál by měl agregovat přístup do jednotlivých agend úředníka, vnějších i vnitřních aplikací kraje, centrálních projektů a zároveň by měl úředníkovi práci co nejvíce usnadnit díky vzájemné integraci systémů. 14

20 3. Strategie Smart Administration Základem by mělo být jednotné, personifikovatelné rozhraní, kde by každému uživateli měly být nabídnuty aplikace potřebné k výkonu práce (například kalendář, , seznam úkolů, rezervační systém, elektronická spisová služba nebo přístup ke správě předpisů a norem). [44] Portál by měl obsahovat systém pro sdílení dokumentů s definovaným workflow dokumentu a Service desk pro podávání a evidenci požadavků. [25] Další funkce jsou uvedeny ve Studiích proveditelnosti zpracovaných na zakázku každého města. Samozřejmostí je ukládání informací o přístupech a změnách v portálu. Jako vedlejší benefit úřad očekává zrychlení a zefektivnění procesů uvnitř úřadu a při sdílení dat úřadu a jeho příspěvkových organizací. [17] Obrázek 3.2: Začlenění všech komponent v rámci statutárního města, Studie proveditelnosti Děčín [30] Začlenění Portálu úředníka do struktury úřadu Základem struktury úřadu je integrační sběrnice (ESB), 3.2 která propojuje především následující komponenty: Portál úředníka Systém pro správu identit Portál občana 15

21 3. Strategie Smart Administration Centrální systémy egovernmentu (základní registry, CzechPOINT, PVS atd.) Agendové informační systémy úřadu 16

22 4 Portálové řešení Portálu úředníka Portál Portál je možno definovat jako široce personalizovatelnou webovou stránku, univerzální integrační rozhraní, které sdružuje přístupy k informačním systémům, k databázím a dalším aplikacím potřebným k pracovním úkonům a zpřístupňují je dále různým uživatelům. Každý, koho se činnost organizace nějakým způsobem dotýká, může portál využívat a získávat z něj informace odpovídající jeho roli. Na základě této role se určuje jaký obsah a aplikace uživateli zpřístupnit. [12] Internetové portály agregují velká množství dat, mají širokou základnu uživatelů a poskytují obecné služby jako je , kalendář nebo vyhledávač, [57] naproti tomu podnikové portály jsou úzce zaměřeny na potřeby dané společnosti a věnují se agregaci jejích systémů a aplikací. Podle typu uživatele je možné podnikové portály rozdělit na: [14] B2E Podnik k zaměstnanci, v rámci veřejné správy do této části bude patřit i Portál úředníka B2C Podnik k zákazníkovi, v rámci veřejné správy se do něj dá zařadit Portál občana B2B Komunikace mezi dvěma partnery vzájemně, v rámci veřejné správy do něj zapadá vzájemná komunikace úřadů Portály je dále možné dělit podle zaměření na horizontální či vertikální. Vertikální portály mají specifické zaměření a shromažďují informace pouze z daného odvětví, kdežto horizontální portály mají mnohem širší zaměření a sdružují různé druhy aplikací.[57] Portálové řešení využité pro potřeby úřadu má nejblíž k horizontálnímu, podnikovému portálu zejména z důvodu velké různorodosti agregovaných aplikací. Portálové řešení se zvláště se hodí v situaci, kdy zaměstnanci společnosti používají celou řadu aplikací a agend ke své práci, protože jejich agregování zjednodušuje a zefektivňuje výkon práce. Portály podporují funkci Single Sign-on, což je jednotné přihlášení do všech systémů integrovaných v portálu. Veškerý obsah portálu může být zobrazen pomocí navázaných webových stránek, portletů, widgetů a dalších webových aplikací. Portály obsahují mnoho těchto modulárních aplikací již ve své základní verzi. V případě, že jejich funkcionalita nestačí, je možné je doplnit dalšími portlety v rámci rozšířené nabídky výrobce. Další možností je vyvinout portlet na míru ať už dodavatelem portálu nebo třetí stranou. 17

23 4. Portálové řešení Portálu úředníka Pokud je požadovaná aplikace příliš rozsáhlá, specifická pro vlastní vývoj nebo existuje již pořízené externí řešení, pak ji portál integruje pomocí navázané integrační sběrnice. Administrátor je díky tomuto řešení schopen takto sestavit pracovní stránku uživateli na míru bez nutnosti umět programovat. Agendy jsou vybírány podle zařazení a náplně práce uživatele. On sám si může částečně upravit skladbu svého portálu, vytvořit nové stránky a určit s kým je bude sdílet a komu budou dostupné. Velmi se tak usnadňuje kolaborativní práce na projektech. Vysoká míra personalizace je jedním z typických znaků všech portálových řešení. Portál může být zobrazovat určitý obsah i nepřihlášenému uživateli, který se po přihlášení uživatele rozšíří o definované agendy. [52] Shrnutí Základní vlastnostní portálového řešení: vnitřní integrace různých zdrojů a z toho plynoucí zefektivnění práce, personalizace v závislosti na agendě uživatele a jednotné přihlášení do všech systémů odpovídají vládou vytyčeným cílů strategie Smart administration.[38] Na úřadech se často stává, že každý agendový IS byl pořízen na základě jiné zakázky od jiné společnosti. Neumí vzájemně pracovat a navíc se princip práce s nimi liší. Autentizace pomocí LDAP 1 nebo Active directory 2 není často podporována nebo do ní nejsou zapojeny všechny aplikace, takže v extrémním případě se úředník musí do každé agendy přihlašovat zvlášť. [30] Pokud portálové řešení tyto AIS integruje a spojí integrační sběrnicí, bude celkový dojem uživatele podobný, jako když by pracoval s homogenní aplikací. Sjednocení počítačového prostředí úředníků je jedním z požadavků na Portál úředníka.[16] 4.1 Podnikové portály Společnost Gartner každý rok provádí výzkum týkající se vzájemného porovnání dodavatelů horizontálních portálů. Výsledky šetření jsou zveřejněny v podobě tzv. Gartnerova magického kvadrantu, který popisuje vývoj v oblasti portálových technologií za dané časové období. Kvadrant hodnotí výrobce podle jejich vize a schopnosti ji realizovat v praxi. Gartner dělí dodavatele portálů do čtyř kvadrantů. 4.1 Kvadrant Leaders (lídři) obsahuje velké hráče na trhu nabízející kvalitní, robustní a mnoha 1. Lightweight Directory Access Protocol protokol pro komunikaci s adresářovým serverem 2. Active directory verze protokolu LDAP vyvinutá společností Microsoft. 18

24 4. Portálové řešení Portálu úředníka Obrázek 4.1: Magický kvadrant horizontálních portálů, Gartner 2013 [19] firmami prověřené produkty, zároveň si udržují vizi potřebnou pro udržení produktu na vedoucí pozici. Visionaries (vizionáři) představují nové trendy a mechanizmy na poli vývoje portálů, nicméně není jisté, zda je vyvinoutý produkt bude splňovat. Niche players (specializovaní hráči) jsou producenti zaměření na úzký segment trhu, například na specifickou funkcionalitu nebo geografický region. Challengers (vyzyvatelé) mají dobrou pozici k vývoji svého produktu, ale nedostatky mohou být v oblasti jejich vize. [19] Podle Garnetovova čtverce pro rok 2013 jsou lídry na poli podnikových portálů následující portáloví výrobci: IBM WebSphere Portal Má historicky silnou pozici na poli podnikových portálů (první verze byla vydaná již v roce 2001). Portál IBM je znám jako velmi robustní a spolehlivé řešení. Mezi nevýhody patří velmi vysoká cena, komplikovaný model cen za používané licence a vysoká složitost použití, která pro klienty vyžadující lehčí řešení je až zbytečná. Portál je možné poskládat z velkého množství aplikací pod hlavičkou Websphere, což je výhodné pro opravdu velké projekty s rozmanitými požadavky. [19] [24] 19

25 4. Portálové řešení Portálu úředníka Základním kamenem jsou IBM WebSphere Portal Server a WebSphere Portal Enable, který slouží ke správě obsahu portálu, umožňuje vytvářet články, blogy a stránky na integrované Wiki a slouží jako DMS 3. Další výhodou je mnoho aplikací zaměřených na BPM 4. V této oblasti byla IBM označena společností Gartner jako lídr pro rok [23] Liferay Na rozdíl od Websphere je Liferay koncipovaný jako nekomplikované, open-source řešení, které ovšem neztrácí svoji robustnost a širokou použitelnost. V posledních letech získává na stále větší popularitě a oblíbenosti mezi zákazníky i díky tomu, že je v základní verzi (CE) distribuován v rámci licence LGPL 5 zdarma. Platí se pouze za rozšířenou verzi (EE), která na rozdíl od základní verze zahrnuje vzdálenou podporu. [19] Portál je široce kompatibilní s mnoha systémy. V této oblasti je vidět opačný vývoj, než kterým si prošli jeho konkurenti ti vycházeli z portálu uzpůsobeného pro vlastní aplikace a postupně dodávají kompatibilitu se software třetích stran. Funkcionalita Liferay portálu se zaměřuje především na správu obsahu portálu a dokumentů, dále pak obsahuje nástroje pro vzájemnou spolupráci a aplikace pro tvorbu a použití sociální sítě v rámci portálu. Umožňuje tvořit veřejné i privátní webové stránky, vytvářet template a plnit stránky za pomocí WYSIWYG 6 editoru, spravovat uživatele a řídit přístup k jednotlivým stránkám za pomoci rolí přiřazeným uživatelům. Liferay chybí zázemí velkého výrobce, který by vydával celou řadu rozsáhlých aplikací spolupracujících s portálem, je ale založen na velkém množství portletů, jejichž funkcionalitu je možné skládat a synergicky využívat. Microsoft SharePoint SharePoint byl jedním z prvních podnikových portálů, který vstoupil na trh (první verze vznikla v roce 2001). Prošel si dobou velké popularity a masivního rozšíření a dosud ho mnoho firem úspěšně používá.[19] Široce rozšířený je i ve státní správě České republiky. Sharepoint pokrývá celou řadu produktů (SharePoint Online, SharePoint Foundation, SharePoint Server, SharePoint Designer, 3. Document management system Systém pro správu dokumentů 4. Business process management Správa firemních procesů 5. Lesser GNU Public Licence je licence svobodného software 6. What you see is what you get. Tvorba stránek v grafickém editoru, který po uložení vygeneruje její kód 20

26 4. Portálové řešení Portálu úředníka SharePoint Workspace). Přičemž základní aplikace SharePoint Foundation slouží pro vytváření webů a ukládání, sdílení a spolupráci na dokumentech, kalendářích a seznamech. Pro další úpravy je navržen SharePoint Designer, zatímco SharePoint Workspace slouží, jak už z názvu vyplývá, k vytvoření kolaborativního prostředí. [33] Produkty SharePoint jsou pouze hrstka z širokého portofia společnosti Microsoft, proto je portálové řešení koncipované tak, aby fungovalo pouze společně s dalšími produkty společnosti Microsoft jako je MS Window Server, MS SQL Server, Windows Identity Foundation, MS Office, MS Project, MS Visio atd. [34] Oracle Web Center Portal Portál je možné zakoupit ve formě modulů s definovanými funkcemi (tzn. Sites, Portal, Social, Content) nebo jako ucelené řešení.[13] Celé řešení slouží zejména jako agregátor komponent Oracle Fusion, ale umožňuje i začlenění aplikací třetích stran. Jeho nevýhodou je vysoká složitost při počáteční konfiguraci a provozování portálu. [19] SAP NetWeaver Portal SAP patří mezi zavedená portálová řešení, první portál vyvinul už v roce [57] Portál je součástí produktů společností Netweaver a tvoří jednotný vstup do informačních systémů SAP. Samostatně se nepoužívá, pro jeho optimální využití by bylo nutné pořídit další systémy od společnosti SAP. Silnou stránkou SAPu je zaměření na definici procesů a uživatelských rolí v podniku. [19] Porovnání jednotlivých portálových řešení Aktuální verze Tabulka 4.1: Porovnání portálových řešení Liferay IBM Web- Sphere Liferay 6.2 WebSphere Microsoft Sharepoint SharePoint 2013 Oracle Web- Center Portal Oracle Web- Center Portal 11g R1 ok Standard JSR-168 ok ok Založeno na.net ok Standard ok ok Založeno na ok JSR-268.NET WSRP 2.0 ok ok ok ok ok SAP SAP Net Weaver 7.4 ok (od verze 7.2) 21

27 4. Portálové řešení Portálu úředníka Funkcionalita v kostce Tvorba aplikací a portletů uživateli Cena Aplikační servery Sociální API, portlety pro spolupráci a sdílení práce, podniková sociální síť. Velká, neustále se vyvíjející nabídka portletů. Otevřený kód, tvorba portletů vyžaduje znalosti programování, ale je dobře zdokumentovaná. Komerční Enterprise edice, Open Source Community edition. Podpora pro správu workflow, automatizaci procesů v organizaci, spolupráce uživatelů, podpora IM WebSphere Portlet Factory (WY- SIWYG tvorba portletů), IBM Portlet API Bez znalosti technologií nejsou úpravy možné. Processor value units (PVUs) pro každé jádro a každou komponentu řešení zvlášť. WebSphere Application Server Portlety pro spolupráci, sociální sítě, business inteligence, business aplikace. Platba za uživatele + poplatek za server. Standardní a Enterprise licence. Windows server, Microsoft SQL server správa webových stránek, sociální aplikace, správa obsahu Kompozice portletů i bez znalosti programování. WebCenter Framework pro vytváření vlastních portletů. Široce kompatibilní Databázový server společnosti Oracle (Oracle WebLogic Server). Kolaborativní nástroje, správa workflow, správa informací z dalších SAP systémů. Licence vázaná na procesor. Součástí platformy SAP NetWeaver, není možné pořídit samostatně. Součástí komplexní integrující platformy Netweaver. 22

28 4. Portálové řešení Portálu úředníka Podporované platformy Linux, Unix, Window Linux, Windows Windows Windows, Linux Linux Porovnání portálu z hlediska zastoupení na úřadech ČR Z dostupných studií proveditelnosti a popisů infrastruktur jednotlivých úřadů je možné popsat zastoupení jednotlivých typů portálů následovně. MS Sharepoint Úřady preferující portál společnosti Sharepoint vlastní kompletní řešení této značky (MS Window Server, Microsoft SQL) a mají s produkty Microsoft dobré zkušenosti. Logickým krokem je pro ně pokračovat v produktové řadě Microsoft a udržet si tak homogenní prostředí navzájem kompatibilních produktů. Takových úřadů je ve veřejné správě zastoupeno nejvíce, Sharepoint tak má v ČR velmi dobrou výchozí pozici. Příkladem takového úřadu je statutární město Hradec Králové[27], které provozuje intranet na platformě SharePoint Server 2010, dalším statutárním městem používajícím Sharepoint je Most[20]. Také kraje Vysočina nebo Ústecký kraj používají tuto platformu jako svůj webový portál.[26][59] IBM Websphere Portál společnosti IBM nejčastěji volí úřady, které svoji hardwarovou architekturu staví na serverech stejné značky. Mnoho úřadů v rámci projektu Technologické centrum nahradilo svůj často značně zastaralý a nepříliš vyhovující hardware novými servery IBM Blade. Úřady spokojené s výměnou a vybudováním Technologického centra následně chtějí opět využít služeb stejné společnosti i při Vnitřní integraci. Společnost IBM tak poskytla jak softwarové, tak hardwarové vybavení mnoha statutárním městům, krajům i obcím (například: Děčínu, Havířovu, Karviné, Liberci, Lovosicím, Opavě, Plzni, Tachovu, Třebíči a Vyškově).[55] Ve statutárním městě Liberci vznikl portál Otevřené město kombinací technologií IBM WebSphere Portal spolu s nástrojem IBM Lotus Web. Jedná se o Portál města, kde občané najdou důležité informace spojené s jednoduchou funkcionalitou (například aktuální záběry z webových kamery, ankety nebo diskuze). Nespornou výhodou je i systém pro řízení přístupových práv Tivoli Identity Management, který IBM nabízí v rámci svého řešení. [55] 23

29 Nevyhraněné úřady 4. Portálové řešení Portálu úředníka Máme na mysli většinou menší úřady, které vlastní uzavřený portál dodaný poskytovatelem. Úřady nejsou s portálem spokojeny a nechtějí ho rozšiřovat, nebo ho rozšířit ani není možné. Příkladem úřadu je statutární město Chomutov. [31] Takové úřady shání nového dodavatele portálového řešení, kde velmi důležitým kritériem je konečná cena řešení. Liferay Z výše uvedeného vyplývá, že portál Liferay je při nabízení svých služeb úřadům spíše v nevýhodě. Portál nemá tolik potřebnou tradici použití a zazemí velkého výrobce, na základě kterého se mnoho úřadů rozhoduje. Se zmiňovanými portály může ale soutěžit nízkou cenou (pořízení celého řešení Enterprise Edice vyjde levněji než cena IBM Websphere za jeden procesor[29]), jednoduchým, srozumitelným rozhraním a nezávislostí na dalších aplikacích. Použití Liferay by bylo přínosné nejen pro nevyhraněné úřady, ale i pro ty, které svůj úřad staví na produktech společnosti Microsoft, protože podporuje integraci s portálem Sharepoint a produkty MS Office. Liferay asi nejvíce ze všech zmiňovaných portálů funguje jako agregátor již hotového obsahu vytvořeného třetími stranami a přidává nejmenší množství vlastních rozšiřujících aplikací. Což je velká výhoda v prostředí úřadu, který už má všechny důležité komponenty vlastně pořízené, ale jejich použití a vzájemná spolupráce silně pokulhává. Jednou z nevýhod Liferay je, že neobsahuje vlastní Identity management, a proto je potřeba využít produkt třetích stran (nejčastěji Active Directory nebo LDAP). Jeden z prvních úřadů, kde byl Liferay zaveden, je v Moravskoslezském kraji.[46] Portál SAP nebo Oracle Toto řešení se objevuje pouze zřídka, nejčastěji pro procesní řízení ve velkých úřadech (například v krajském městě Plzeň). [55] Případová studie použití portálu ve statutárním městě Děčín Případová studie popisuje realizaci strategie Smart Administration ve statutárním městě Děčín. 24

30 4. Portálové řešení Portálu úředníka Výchozí stav V roce 2011 vznikl dokument Studie proveditelnosti vnitřní integrace úřadu statutárního města Děčín, kde se výchozí stav popisuje jako velké množství systémů, pořízených bez promyšlenější koncepce, navzájem nepropojených. Úřad pro řízení přístupů pořídil systém Active directory, ale je na něj reálně napojeno pouze několik aplikací. Nefunguje přenášení dat mezi systémy, takže je úředník musí ručně přepisovat z jedné aplikace do druhé. Nejsou nastavené schvalovací procesy, což negativně ovlivňuje fungování úřadu (například promeškáním lhůt pro schvalování žádostí). Celková efektivita práce je nízká.[30] Cíle projektu Elektronizace a automatizace některých interních procesů úřadu, které byly řešeny oběhem dokumentů v listinné podobě. Snadná a pohodlná elektronická komunikace s občany a podnikateli. Popis řešení Nasazení elektronických formulářů, které může občan vyplnit i podat z pohodlí domova. [53] Elektronizace formulářů i v rámci Portálu úředníka a nastavení procesů při jejich schvalování. Formulářové řešení bylo vyvinuté společností Software602. [53] Modernizace a sjednocení technologického vybavení úřadu produkty společnosti IBM. [55] Vznik informačního portálu (IBM Websphere) pro komunikaci s občanem. [55] Přínosy řešení Informační portál pro komunikaci s úřadem usnadňuje přístup k vyřizování úředních věcí a k informacím, které obyvatelé a firmy potřebují.[55] Elektronické formuláře usnadňují a zefektivňují práci úředníka a usnadňují občanovi podání žádosti.[53] 25

31 4. Portálové řešení Portálu úředníka 4.2 Portlety Portlet a Portletlový kontejner Portlet je komponenta webového portálu, založená na jazyce Java, která umí zpracovávat požadavky a dynamicky generovat svůj obsah. Obsahem bývá nejčastěji webová stránka nebo aplikace. Portlet obsluhuje tzv. portletový kontejner, který může být koncipován jako součást portálu nebo jako samostatná vrstva. V případě Liferay se jedná o pevně integrovanou součást portálu. Kontejner zpracovává požadavky a aktualizuje obsah portletu. Vzhled a obsah portletů je široce konfigurovatelný podle potřeb a nastavení uživatelů. [48] Portletový kontejner zajišťuje komunikaci mezi portletem a portálem, kontroluje životní cyklus portletu. Podobně se stará o inicializaci a zrušení portletu. V rámci portálu Liferay se používá OpenPortal Portlet Container, který podporuje oba standardy JSR. [48] Standardy portletů Tyto dokumenty popisují standardy pro vývoj a práci s portlety a zajišťují, že vyvinutý portlet bude schopen komunikace s jakýmkoli portálem podporující danou specifikaci. Standardy byly vydány mezinárodní společností Java Community process v říjnu roku 2003 a následně v červnu JSR 168 První ze dvou standardů přináší základní programovací model. Zabývá se architekturou portletu podporuje architekturu MVC (Model- View-Controller) pro implementaci webového rozhraní. Pomocí knihovny značek definovaných a značek knihovny JSTL (JavaServerPages Standard Tag Library) portlet zpracovává a vykresluje objekty na portletovou stránku. Standard pak dále definuje komunikaci portletu s portletovým kontejnerem v portálu a samotný vývoj portálu tak, aby podporoval vzájemnou kompatibilitu. Přidává možnost agregovat různé portlety v jednom portálu a tvořit z nich další komplexní celky. [11] Jelikož ke standardu bylo vzneseno mnoho připomínek, a zároveň bylo potřeba i dodat novou funkcionalitu, byl následně vypracován druhý standard. 26

32 4. Portálové řešení Portálu úředníka JSR 286 Rozšiřuje možnosti původní specifikace, přidává především možnost komunikace mezi portlety a jejich vzájemné koordinace. Díky možnosti koordinace je možné vytvářet nové portlety kombinováním již existujících. Podporuje tzv. Události, kdy jednotlivé komponenty mezi sebou mohou vytvářet, zasílat a přijímat události. Další novou funkcionalitou je možnost navzájem sdílet parametry portletu pomocí tzv. Public render parameters. [21] [22] WSRP Web Services for Remote Portlets je webové rozhraní umožňující komunikaci kontejneru a vzdáleného portletu, a také protokol definující komunikaci vzdálených portletů a jim příslušných kontejnerů umístěných v portálu. V rámci portálu může být použít společně se standardem JSR 168, který se využije pro portletovou část, zatímco WSRP slouží pro spolupráci na straně portálu. Hlavním přínosem WSRP je, že umožňuje portálu začlenit velké množství vzdálených portletů bez nutnosti integrovat každou komponentu zvlášť dopisováním dalšího kódu, takže jeho použití nevyžaduje velké znalosti programování. [58] 27

33 5 Funkční požadavky na Portál úředníka V rámci průzkumu jsem analyzovala dostupné Studie proveditelnosti, Technické zprávy a další dokumenty o plánované vnitřní integraci krajů a statutárních měst na území ČR. Zejména se jedná o kraje: Moravskoslezský kraj [44] Ústecký kraj [59] Kraj Vysočina [26] Pardubický kraj [47] Královéhradecký kraj [27] Zlínský kraj [16] Olomoucký kraj [17] Jihomoravský kraj [25] Statutární města: Přerov [50] Děčín [30] Chomutov [31] Most [20] Kladno [51] U zbytku statutárních měst je Portál úředníka zatím hudbou budoucnosti, města často řeší z pohledu fungování úřadu základnější věci, například vybudování technologického centra, integrační sběrnice nebo řízení přístupových práv. O Portálu úředníka se ale mluví jako o důležitém prvku v kontextu vnitřní integrace úřadu. 28

34 5. Funkční požadavky na Portál úředníka 5.1 Portlety a integrované funkce portálu Liferay vyžadované v Portálu úředníka Na základě požadavku krajů a statutárních měst jsem sestavila následující tabulky požadovaných portletů. Tabulka 5.1: Nejčastěji poptávané portlety Název Kraje Statutární města Název portletu v Liferay ok ok ok Kalendář ok ok Calendar CE/Social Office Manažerský IS ok ok Portal Statistics, Activity tracking Nahraditelné externí aplikací Existují externí aplikace. Úřední deska ok ok Portlet chybí. Existují externí aplikace. DMS ok ok DMS portlet Existují externí aplikace. Service desk ok ok Portlet chybí. Existují externí aplikace. Úkolník ok ok Částečně My Workflow Tasks. Docházkový systém Dohled nad zřizovanými příspěvkovými organizacemi. ok ok Portlet chybí. Existují externí aplikace. ok ok Portlet chybí. 29

35 5. Funkční požadavky na Portál úředníka Elektronická spisová služba a epodatelna ok ok Portlet chybí. Existují externí aplikace. Tabulka 5.2: Méně často poptávané portlety Název Kraje Statutární města ok ok Social office, Contact center ok ok Web Form Existují externí aplikace. ok ok DMS/Wiki Evidence pracovníků s kontakty Systém pro oběh formulářů. Znalostní databáze vyhlášek Nástroj pro modelování procesů Rezervační kalendář Nástroj pro definování workflow Rezervační systém na schůzky s úředníkem Prohlížeč PDF Součást Liferay (název portletu) Nahraditelné externí aplikací ok ok BonitaBPM Existují externí aplikace. ok ok Calendar ok ok Kaleo Workflow ok ok Portlet chybí. Existují externí aplikace. ok ok PDF Viewer Existují externí aplikace. 30

36 Integrované portlety 5. Funkční požadavky na Portál úředníka Podobně jako ostatní portálové technologie, Liferay využívá portlety pro rozšíření samotného obsahu portálu. Samozřejmostí je možnost kombinovat vzájemně více prvků k dosažení požadované komplexní funkcionality a možnost vkládat jiné stránky do portálu ve formě portletu. V základní verzi obsahuje více jak šedesát různých portletů, které umožňují jak vzájemnou spolupráci uživatelů, tak správu obsahu portletu. DMS Document management systém slouží pro správu dokumentů. V rámci Liferay existuje interní Documents and Media library. V případě potřeby je možné i integrovat DMS třetí strany. Umožňuje správu obrázků, videa, audia a samozřejmě dokumentů, podporuje integraci s MS Office. Umožňuje vytváření verzí dokumentů a podporuje definici workflow pro oběh dokumentu (portletem Kaleo). Pro úřad důležitou funkcí, která bude muset být do portletu přidána, je možnost zveřejnit dokument na Úřední desce přímo z DMS. Pro společnou práci na dokumentu je možné využít funkci Document library portletu Social Office. Díky podpoře protokolu IMAP 1 může ová schránka agregovat poštu ze všech mailboxů uživatele. Podporuje integraci s Gmailem 2. Poštu je možné číst přímo v okně portálu. Několikrát se objevil požadavek na integraci s MS Outlook[16][27], která v tomto portletu zatím chybí. Kalendář Všechny subjekty územní samosprávy požadují Kalendář jako základní funkcionalitu, ať už osobní, rezervační, kalendář odboru nebo organizace jako celku. Kalendář obsahuje upozornění na nadcházející události, definici přístupových práv. Možné je i exportovat a importovat kalendáře do systémů nezačleněných do portálu Liferay. Rezervační kalendář je možné nakonfigurovat pro každou položku (místnost, zařízení atd.) zvlášť. Kalendář pracovní skupiny uživatel získá v portletu Social Office. Kalendář by bylo možné využít i jako zmíněný Rezervační systém pro občana. Kalendář obsahující úřední hodiny daného úředníka s vyznačením volných a obsazených termínů, by byl umístěn na 1. IMAP protokol pro přístup k mailové schránce 2. Gmail provozovaný společností Google 31

37 5. Funkční požadavky na Portál úředníka veřejně dostupné části odboru. Občan by se na volný termín mohl objednat pomocí veřejně dostupného formuláře z Formulářového systému nebo poslat žádost o schůzku do Service desk. Dalším požadavkem na Kalendář je možnost jej zobrazit na veřejně dostupné webové stránku úřadu, nejen kvůli zmíněným rezervacím, ale i pro zveřejňování plánovaných volnočasových akcí města (výstavy, sportovní události). Znalostní databáze vyhlášek Úřady pracují s celou řadou vyhlášek, předpisů a norem, které chtějí přehledně ukládat do informační databáze. Wiki je portlet, který dovoluje uživatelům sdílet informace a přehledně je katalogizovat. Obdobnou službu by mohl poskytnout i dokumentový systém s jasně danou strukturou, kam by se daly tyto dokumenty zařadit a nasdílet uživatelům. Zajímavý byl jeden požadavek na dodatečnou funkci ve formě tlačítka, kterým by uživatel po přečtení dokumentu potvrdil, že je s celou věcí seznámen a souhlasí s ní. Portlety dostupné v Marketplace Marketplace je koncipován jako e-shop, kde je možné získat další portlety rozšiřující základní funkcionalitu Liferay portálu. Dají se stáhnout přímo nebo prostřednictvím již nainstalovaného portálu. Většina z nich je dostupná v obou variantách portálu CE i EE. Portlet verze CE je možné volně stáhnout a nainstalovat, kdežto komerční verze portletů obsahují další rozšíření navíc. Tvůrcem portletů je buď samotná společnost Liferay, nebo ověřená komunita vývojářů. Žádný portlet by neměl znamenat nebezpečí nebo poškození pro již nainstalovaný portál a měl by být plně kompatibilní s jeho součástmi. Nástroj pro definování workflow Nástroj by podle požadavků měl obsahovat přehledné grafické rozhraní pro vytvoření workflow a možnost navázat je na libovolný prvek portálu. Možnost tvořit a editovat nová workflow by měl mít pouze administrátor. Pro interní definici workflow je vhodné použít nástroj Kaleo, který umožňuje definovat workflow pro řadu prvků portálu (např Wiki, DMS). Pro definování pokročilých workflow mimo rámec Liferay entit je možné použít open-source nástroj Bonita, který má i portlet integrující ho do Liferay. Bonita pracuje s technologií BPM Bussiness process management 32

38 Formulářový systém 5. Funkční požadavky na Portál úředníka Cílem mnoha subjektů územní samosprávy je zefektivnit oběh dokumentů v rámci úřadu jejich elektronizací a zavedením workflow. Portál Liferay nabízí řešení v podobě portletu Web Form EE, který umožňuje vytvářet formuláře, které jsou po vyplnění odeslány na danou ovou adresu nebo uloženy do databáze. Další funkcionalitu, o kterou by se portlet měl rozšířit, aby splňoval požadavky statutárních měst a krajů, je možnost definovat workflow nad každým z formulářů, spojit formuláře s odpovídajícími agendovými informačními systémy (například žádost o řidičský průkaz spojit s agendou vydávání řidičských průkazů nebo formulář žádosti o dovolenou s docházkovým systémem). Formuláře by měly umět i validovat jednotlivá vyplňovaná pole a dokonce automaticky některá pole vyplnit v závislosti na hodnotách již vyplněných uživatelem. Jedná o velmi komplexní projekt, který je možné řešit pomocí rozšíření portletu Web Form o mnoho dalších funkcí. Úřady, ale pořízení této komponenty často poptávají v odděleně od poptávky na Portál úředníka, proto doporučuji použít externí aplikací integrovanou s Portálem úředníka. V rámci úřadů je nejčastěji používaným řešením aplikace FormServer společnosti Software602. Evidence pracovníků Portlet Social Office, funkce Contact center umožňuje vyhledávání pracovníků v organizaci a sledování jejich stavu a základních údajů. Portlety nutné vyvinout nebo pořídit z externích zdrojů Jak vyplývá z funkčních požadavků úřadu, je nutné doplnit následující portlety. Service Desk Service desk slouží pro sběr požadavků, které se dále rozdělují mezi úředníky, kteří požadavky vyřizují. Využití bude především pro kontakt občana s úřadem, případně na vkládání vnitřních požadavků na úředníka přímo nevyplývajících z jeho náplně práce. [25] Do Service desku může vložit požadavek kdokoli a to posláním mailu, datové zprávy nebo založením požadavku na hlavní straně Service desk. Občan může podat požadavek i vyplněním formuláře přístupného na webových stránkách úřadu. Každý požadavek bude mít tvůrce, stav, termín vyřízení a přiděleného vlastníka. Vlastník požadavku 33

39 5. Funkční požadavky na Portál úředníka bude zodpovědný za jeho vyřešení. Vlastníkovi se požadavek uloží do jeho Úkolníku. Po vyřešení požadavku se žadateli odešle ová notifikace o vyřešení požadavku. Nad celým systémem bude možné realizovat fulltextové vyhledávání. [45] Úkolník Jednoduchý portlet sloužící k přehlednému zobrazení a správě úkolů, které úředník vlastní. Seznam úkolů na hlavní straně je možné řadit podle priority, termínu vyřešení a dalších atributů úkolu. Po rozkliknutí úkolu úředník vidí obsah úkolu, prioritu a odkaz na původní požadavek v Service desk. Funkci částečně pokrývá portlet My Workflow, který úředníkovi zobrazuje úkoly vyplývající z workflow pro jednotlivé portlety a aplikace. Výhodná by byla integrace Úkolníku a tohoto portletu. Manažerský IS Účel manažerského IS získání dat o výkonu úřadu. Mezi hodnoty, které by se měly sledovat jsou například: počty podání, doba odpovědi, dodržování zákonných lhůt při odpovídání, efektivita práce jednotlivých odborů i jednotlivých úředníků. Existují sice portlety Portal Statistics, Activity tracking, ty ale zobrazují statistiky zaměřené na fungování samotného portálu. Úřední deska Úřední deska se skládá z portletu a veřejné webové stránky, kde se zveřejňují dokumenty daného úřadu. Požadované je propojení se spisovou službou, datovou schránkou a DMS, kde bude u všech dokumentů existovat možnost "Zveřejnit na Úřední desce". Po exspiraci se příspěvky z Úřední desky musí archivovat podle příslušné vyhlášky. [10] Docházka Portlet slouží jako přehled docházky daného uživatele za vybranou dobu, výpis všech průchodů, výpočet odpracované doby a přesčasů, přehled nepřítomnosti uživatele (např. z důvodu dovolené). Dalším prvkem je možnost plánování a schvalování docházky nadřízeným. Je vhodná integrace s Personálním a mzdovým systémem (odpracovaná doba bude základní vstupní údaj pro výpočet mzdy), systémem pro správu interních formulářů na úřadě (např. kvůli elektronické žádosti o dovolenou, která se po schválení uloží do systému) a systémem, který zaznamenává příchody a odchody uživatele. 34

40 5. Funkční požadavky na Portál úředníka Dohled nad příspěvkovými organizacemi Úřady zřizují velké množství příspěvkových organizací (divadla, nemocnice, základní a mateřské školy atd.). V rámci těchto příspěvkových organizací zřizovaných ORP či krajem je potřeba dohledu a kontroly nad provozem těchto organizací. Do portletu se zavádějí zápisy, závěrečné zprávy, rozpočty a další dokumenty ilustrující běh organizace. Elektronická spisová služba Spisovou službu upravuje zákon č. 190/2009 Sb., který částečně upravuje předchozí zákon č. 499/2004 Sb. Dle zákona se tedy spisovou službou rozumí: "Zajištění odborné správy dokumentů došlých i dokumentů vzniklých z činnosti původce, popřípadě z činnosti jeho právních předchůdců, zahrnující jejich řádný příjem, evidenci, rozdělování, oběh, vyřizování, vyhotovování, podepisování, odesílání, ukládání a vyřazování ve skartačním řízení, a to včetně kontroly těchto činností ( 2 k) zákona 499/2004 Sb.)"[6] Povinnost vést spisovou službu mají ze zákona mimo jiné organizační složky státu, státní příspěvkové organizace, územní samosprávné celky, vytvářejí-li dokumenty vyjmenované v zákoně. Mezi tyto dokumenty zejména patří: Zápisy ze zasedání orgánů zákonodárné, vládní a výkonné moci a orgánů územní samosprávy na všech stupních Zakládací listiny Statuty Organizační řády a další dokumenty o organizační struktuře, vedení, správě, řízení, kontrole, činnosti a jejich výsledcích [8] S ohledem na komplexnost aplikace a množství nabízených hotových řešení, kdy aktuálně každý úřad nějakou elektronickou spisovou službu ze zákona používá[6], doporučuji zůstat u již pořízeného systému, který se do portálu integruje. Hotové řešení musí disponovat propojením do Úřední desky s možností zveřejnit dokumenty z esps na Úřední desce. Nejčastěji se používá spisová služba společnosti GINIS. epodatelna epodatelna slouží pro přijímání a evidenci přijímaných dokumentů. Úřad má elektronickou podatelnu ( ovou adresu), kam může občan poslat 35

41 5. Funkční požadavky na Portál úředníka elektronický dokument. Označování dokumentů v digitální podobě zajišťuje elektronická Spisová služba jednoznačným identifikátorem elektronické podatelny. Pracovník si z datové schránky stáhne nové zprávy, ověří jejich platnost a čitelnost, zaeviduje je do Spisové služby a předá konkrétním osobám k vyřízení přes Service desk. Neelektronické dokumenty jsou zaznamenány v podacím deníku, elektronické v evidenci esps. [3] epodatelna bývá součástí elektronické spisové služby a je vhodné ji do portálu integrovat společně s pořízenou esps. 5.2 Nefunkční požadavky na Portál úředníka Podpora Portál Liferay je distribuován ve dvou variantách. První je Custom edition (CE), kterou je možné získat pod open-source licencí, je jí možné stáhnout, nainstalovat a používat, ale neposkytuje žádnou podporu uživateli, které ale úřady vyžadují. Druhou, profesionální verzí je Enterprise. Ta se dále dělí na zlatou a platinovou edici. Jejich rozdíl je v rozsahu technologické podpory a rychlosti odpovědi. Pro zlatou je to 8 hodin denně v rozsahu pracovního týdne, pro platinovou je to plná 24/7. Požadavky úřadů na podporu jsou mezi 12/5 (statutární města) až 24/7 (kraje) x 365 s maximální dobou odezvy 4 hodiny doporučuji platinovou edici. Liferay Enterprise edition navíc obsahuje množství sofistikovaných portletů, které může úřad využít. Minimální doba záruky na Portál by měla být shodná s udržitelností projektu, tedy 5 let. Tento požadavek Liferay také splňuje, daná verze Liferay EE je v prodeji maximálně dva roky a poté je jí 5 let poskytována podpora.[28] Tabulka 5.3: Podpora Liferay[28] Zlatá edice Platinová edice Telefonní podpora 8 x 5 (Po-Pá) 24 x 7 (365 dní v roce) Maximální čas telefonické odpovědi 4 hodiny 2 hodiny Pohotovostní čas odpovědi nespecifikovaný 1 hodina 36

42 6 Návrh portálu úředníka Role Každý uživatel má v rámci portálu přiřazenou roli. 6.1 V rámci portálu Liferay je jich několik předdefinováno. Host nepřihlášený uživatel, v případě úřadu je to občan. Občan nemá do vnitřní části portálu úředníka vůbec přístup, zobrazeny jsou mu pouze veřejné stránky úřadu (například veřejná část Úřední desky, rozhraní pro zadání dotazu do Service desk). User zaměstnanec úřadu, běžný uživatel portálu. Power User úředník Administrátor zaměstnanec úřadu, který portál nejen využívá, ale má oprávnění ho konfigurovat a upravovat. Nejčastěji to budou pracovníci odboru informačních technologií a nadřízení, kteří budou vykonávat pokročilé funkce v portletech. Rozsah rolí může být definován v pouze v rámci organizace, v rámci domény, nebo v rámci celého portálu. [52] Obrázek 6.1: Role v systému Ve Studiích proveditelnosti se často zmiňuje informace o tom, že by Portál úředníka měl být nabídnut k používání i příspěvkovým organizacím a jednotlivým obcím v rámci oblasti. Tyto organizace by ale obdržely samostatnou instanci Portálu úředníka, případně by jim byla v rámci portálu založena vlastní organizace, jejíž funkce nebudou propojeny s funkcemi úřadu. V rámci jejich Portálu úředníka by jim byly zpřístupněny takové systémy a portlety, které ke svoji práci potřebují. Ze zákona je to esps, dále pak jistě CMS, DMS a další zvolené AIS. 37

43 Organizace úřadu v portálu Liferay 6. Návrh portálu úředníka Základní prvek portálu je uživatel. Uživatel patří do tzv. organizace, což je uskupení uživatelů v Liferay. Organizace má definovanou hierarchickou vnitřní strukturu, v našem případě kopírující vnitřní strukturu úřadu. Každý odbor úřadu bude tvořit organizaci, v ní budou obsaženi všichni jeho zaměstnanci. Pro zlepšení vnitřní kolaborace je v rámci organizace možné tvořit týmy spolupracující na společném projektu. Každý uživatel má přidělen svůj prostor, který může upravovat pomocí portletů, sdílet s dalšími uživateli, vytvářet v něm stránky, nahrávat dokumenty a mnoho dalších operací, přesně definovaných v jeho roli. Funguje jako jakýsi osobní rozcestník uživatele. Tato osobní stránka tvoří jádro Portálu úředníka. [52] Úřad a všechny jeho součásti (odbory), které jsou v portálu znázorněny organizací, mohou mít vlastní webový prostor. Ten obsahuje jak veřejné stránky (dostupné volně občanům), tak stránky interní. Na veřejných stránkách mohou být umístěny informace o úřadu, novinky, výzvy občanům, kontakt na úřad, přehled pravomocí a prostor na publikování vybraných dokumentů. V rámci interní části odboru budou uloženy společné dokumenty odboru, rozcestník na další portály, důležité informace pro zaměstnance nebo například společné diskuzní fórum. 6.1 Návrh Portálu úředníka v Liferay Vstupní strana pro Portál úředníka bude veřejně dostupná pro všechny uživatele portálu. Do Portálu se uživatel přihlásí pomocí LDAPu nebo Microsoft Active Directory. Po přihlášení se mu zobrazí jeho osobní stránka, Portál úředníka. Na svoji osobní stránce bude mít portlety podle jeho pracovního zařazení a role v portálu. Pro všechny uživatele to bude minimálně Úkolník, Kalendář, DMS a . Integrované budou i ostatní agendové aplikace, které uživatel ke svojí práci potřebuje. Samozřejmostí je přístup úředníka ke všem prvkům egovernmentu. Portál úředníka 6.3 bude fungovat jako vstupní brána ke všem dalším, externím komponentám portálu Vše bude fungovat na principu Single Sign-on. Hlavičku hlavní strany Portálu úředníka tvoří Název úřadu a odboru, kde uživatel pracuje. Kliknutím na ně se uživatel dostane na interní hlavní stranu úřadu 6.6 nebo odboru 6.7. V hlavičce je také uvedeno jméno uživatele, po kliknutí na jeho jméno se mu zobrazí jeho profil 6.5. Údaje Portál bere ze Systému pro správu identit. Důležité je i vyhledávací políčko, které umožňuje fulltextové vyhledávání v jeho portálu. V levém menu portálu jsou všechny integrované portlety a aplikace. V těle 38

44 6. Návrh portálu úředníka Portálu se na hlavní straně zobrazují novinky pro daný úřad a odbor. Jedná se o jednoduchá krátká sdělení, která může odesílat Administrátor všem zaměstnancům úřadu/odboru. Zprávy se nearchivují, ale je k nim možné připojit přílohu. Evidence pracovníků 6.8 z levého menu k vybranému odboru vypíše seznam jeho zaměstnanců, jejich telefonní čísla, číslo kanceláře a aktuální přítomnost na pracovišti. Detail zaměstnance se zobrazí po kliknutí na jeho jméno v Evidenci. Při spouštění portletů se v horní části portálu řadí odkazy na postupně spuštěné aplikace (tzvn. breadcrumbs). Kliknutím na kořenový odkaz "Portál úředníka"se uživatel dostane zpět na hlavní stranu jeho Portálu. Obrázek 6.2: Hlavní obrazovka Portálu úředníka zobrazená úředníkovi 6.2 Návrh portletů do Portálu úředníka Návrh portletů vyplývá z předchozích funkčních požadavků. Pomocí jazyka UML 1 jsem namodelovala nejčastěji požadované portlety do Portálu úředníka. Případ užití Případ užití (neboli Use case) se považuje za vysokoúrovňový model, který definuje základní požadavky uživatelů, jednotlivé aktéry a jejich propojení. Zobrazuje interakci mezi systémem a uživateli. [18] 1. Universal model language 39

45 6. Návrh portálu úředníka Obrázek 6.3: Přehled agend a rolí pro Portál úředníka Obrázek 6.4: Hlavní obrazovka Portálu úředníka zobrazena Administrátorovi Návrhy obrazovek Případy užití jsou dobré pro definici počátečních požadavků, ale nejsou dostatečně konkrétní. Dalším krokem je proto navrhnout obrazovky, které 40

46 6. Návrh portálu úředníka Obrázek 6.5: Detail uživatele portálu Obrázek 6.6: Hlavní interní stránka úřadu ukážou zjednodušenou podobu portletů. Návrhy mohou sloužit jako ověření, zda je budoucí zákazník spokojen s navrženou podobou Portálu a jeho portletů. [49] 41

47 6. Návrh portálu úředníka Obrázek 6.7: Hlavní interní stránka odboru Obrázek 6.8: Evidence pracovníků ve vybraném odboru. Diagram tříd Popisuje statickou strukturu systému, definuje jednotlivé třídy systému a vztahy mezi nimi. Tyto diagramy slouží především budoucím vývojářům 42

48 6. Návrh portálu úředníka příslušného portletu, proto diagram tříd uvádím u portletů, u kterých bude nutná rozsáhlejší modifikace nebo vývoj. [18] Sekvenční diagram Sekvenční diagramy zachycuje chování a interakci mezi jednotlivými třídami, které byly definovány v diagramu tříd, v rámci jednoho případu užití. [18] DMS Případ užití DMS Případ užití DMS 6.9 znázorňuje požadovanou funkcionalitu. Jedná se především o práci s dokumenty jejich sdílení, přiřazení worflow a zobrazení dokumentů na Úřední desce. Obrázek 6.9: Případ užití DMS Návrhy hlavní obrazovky portletu DMS Obrázek ukazuje hlavní obrazovku systému Uživatel má v levém panelu zobrazeny jemu přístupné složky. Nejprve ty, které sám vytvořil, posléze složky, které s ním někdo sdílí. Poslední složka slouží pro smazané dokumenty. Ve středu obrazovky se zobrazuje obsah aktuálně otevřené složky. Kliknutím na název dokumentu se dokument zobrazí v programu podle přípony dokumentu. 43

49 6. Návrh portálu úředníka Nejčastěji je zmiňován požadavek, aby to byl program z rodiny MS Office. Dokument je v něm možné editovat, pokud to přípona dovolí. Jednotlivé případy užití jsou rozepsány v příloze A diplomové práce. Obrázek 6.10: Návrh hlavní obrazovky portletu DMS Tlačítka na pravém panelu slouží k práci s dokumenty. První dvě tlačítka slouží k vytvoření/zavedení nového dokumentu do systému. Další tlačítka operují s již vytvořenými dokumenty. Nejprve se označí dokument, pak se stiskne tlačítko, které vykoná patřičnou operaci nebo zobrazí kontextovou nabídku (nasdílí dokument, smaže dokument, publikuje ho na Úřední desce nebo k němu připojí workflow). Kliknutím na tlačítko Portál úředníka se uživatel dostane na hlavní stranu Portálu úředníka Docházka Případ užití portletu Docházka Portlet Docházka má především zobrazovat docházku pro každého z uživatelů a umožňovat Administrátorům dohlížet na ní Docházka by měla být spojena se systémem zaznamenávajícím příchody a odchody, který tvoří jednotlivé položky docházky. Dále je vhodné ji integrovat s Formulářovým systémem, který slouží pro podávání a schvalování žádostí o dovolenou, a Personálním a mzdovým systémem, kam se nakonec schválená docházka exportuje. Jednotlivé případy užití a k nim příslušející obrazovky portletu 44

50 jsou rozepsány v příloze A a B diplomové práce. 6. Návrh portálu úředníka Obrázek 6.11: Případ užití portletu Docházka Návrh hlavní obrazovky portletu Docházka. Hlavní strana 6.12 zobrazuje na samostatných řádcích jednotlivé položky docházky. Každá položka odpovídá jednomu pracovnímu dni. U položek se kontroluje především délka pracovní doby a to zda pracovní doba odpovídá naplánované. Pokud není uvedeno jinak, jsou to položky za poslední měsíc. Změnit měsíc a rok zobrazené docházky je možné v levém menu. Administrátorské rozhraní navíc obsahuje nástroj pro plánování docházky a přehled docházky pro každého z uživatelů. Diagram tříd portletu Docházka Třída Docházkový systém 6.13 agreguje jednotlivé Položky docházky a Naplánovanou docházku. Třída Položka docházky obsahuje atributy popisující docházku pro jednoho uživatele za jeden konkrétní pracovní den. Atributy saldo a přesčas systém počítá jako rozdíl naplánované a skutečné docházky za daný den. Obdobně třída Naplánovaná docházka obsahuje naplánovanou docházku pro jeden pracovní den. Atribut Přestávka říká, zda má uživatel nárok na přestávku. Atribut Nepřítomnost je důvod nepřítomnosti na pracovišti (například nemocenská, dovolená, OČR,...). Uživatel může vyhledat svoji docházku a naplánovanou docházku za zadané časové období. Administrátor docházku plánuje, edituje a schvaluje. 45

51 6. Návrh portálu úředníka Obrázek 6.12: Návrh hlavní obrazovky portletu Docházka pro uživatele. Obrázek 6.13: Diagram tříd portletu Docházka Sekvenční diagram portletu Docházka Sekvenční diagram Docházky 6.14 ukazuje plánování docházky administrátorem a zobrazení naplánované docházky uživatelem. Dále pak znázorňuje 46

52 6. Návrh portálu úředníka zobrazení skutečné docházky uživatelem. Nakonec docházku administrátor schvaluje a ta se po schválení exportuje do Personálního a mzdového systému. Obrázek 6.14: Sekvenční diagram portletu Docházka Dohled nad příspěvkovými organizacemi Případ užití pro portlet Dohled nad příspěvkovými organizacemi Případ užití 6.15 zobrazuje poptávanou funkcionalitu kontroly příspěvkových organizací. Jelikož není jisté, zda všechny příspěvkové organizace chtějí používat Portál úředníka, počítá se s univerzálně použitelnou variantou, kdy příspěvkové organizace budou odesílat jednotlivé dokumenty na adresu úřadu, který je uloží do DMS/eSps odkud se následně založí do portletu. V případě, že se realizace Portálu úředníka bude řešit i pro příspěvkové organizace, bylo by vhodné jejich Portál doplnit o portlet, který by umožnil automatické vkládání sledovaných dokumentů příspěvkových organizací do dohledového portletu úřadu. Jednotlivé případy užití a k nim příslušející obrazovky portletu jsou rozepsány v příloze A a B diplomové práce. Návrh hlavní obrazovky portletu Dohled nad příspěvkovými organizacemi V levém menu úředník vybere příspěvkovou organizaci, po kliknutí na její název se rozbalí nabídka typů dokumentů, které se k vybrané příspěvkové organizaci vztahují. Na hlavní obrazovce se zobrazí obecné informace o příspěvkové organizaci. Kliknutím na typ dokumentu jsou úředníkovi zobrazeny všechny dokumenty daného typu pro vybranou příspěvkovou organizaci seřazené podle data vytvoření od nejaktuálnějších po nejstarší. Další návrhy 47

53 6. Návrh portálu úředníka Obrázek 6.15: Případ užití pro portlet Dohled nad příspěvkovými organizacemi obrazovek portletu jsou v příloze B diplomové práce Obrázek 6.16: Návrh hlavní obrazovky portletu Dohled nad příspěvkovými organizacemi 48

54 6. Návrh portálu úředníka Diagram tříd portletu Dohled nad příspěvkovými organizacemi Diagram tříd 6.17 obsahuje třídu Dohled nad příspěvkovými organizacemi, která představuje rozhraní pro správu příspěvkových organizací úředníkem. Třída Příspěvková organizace obsahuje jméno organizace, údaje o příspěvkové organizaci a seznam dokumentů vztahujících se k příspěvkové organizaci. Třída Dokument, reprezentující dokumenty přiřazené k příspěvkové organizaci, může mít nastavený typ, který dokument popisuje. Typ dokumentu může být například Rozpočet, Zápis nebo Závěrečná zpráva. Obrázek 6.17: Diagram tříd portletu Dohled nad příspěvkovými organizacemi Sekvenční diagram portletu Dohledu nad příspěvkovými organizacemi Diagram ukazuje úředníka, který vybral příspěvkovou organizaci, a zobrazil si k ní přiřazený dokument Kalendář Případ použítí portletu Kalendář Diagram ukazuje požadované operace k práci s kalendářem, 6.19 jedná se především o vytvoření a sdílení kalendáře, tvorbu a sdílení událostí. Vytvořit událost je možné i exportem úkolu z Úkolníku. Jednotlivé případy užití jsou rozepsány v příloze A diplomové práce. 49

55 6. Návrh portálu úředníka Obrázek 6.18: Sekvenční diagram portletu Dohled nad příspěvkovými organizacemi Obrázek 6.19: Případ užití portletu Kalendář Návrh hlavní obrazovky portletu Kalendář Hlavní strana kalendáře 6.20 ukazuje grafickou reprezentaci Kalendáře pro vybrané časové období. Zobrazeny jsou defaultně všechny dostupné kalendáře, přepínat nebo vypínat jejich zobrazení je možné v levém panelu po zaškrtnutí políčka u názvu kalendáře. V kalendáři se zobrazují naplánované události. Nová událost se vytvoří vyznačením patřičného času v kalendáři a zadáním textu události do formuláře, který se zobrazí. Návrh tohoto formuláře je k nalezení v příloze B. 50

56 6. Návrh portálu úředníka Obrázek 6.20: Návrh hlavní obrazovky portletu Kalendář Úřední deska Případ užití pro portlet Úřední deska Případ užití pro portlet Úřední deska 6.21 popisuje operace s příspěvkem. Příspěvek lze vytvořit jak v rozhraní úřední desky, tak i v DMS a esps. Systém zveřejňuje příspevek ve veřejné části Úřední desky. Po té, co příspěvek expiruje, archivuje se podle příslušné vyhlášky. Obrázek 6.21: Případ užití pro portlet Úřední deska 51

57 Návrh hlavní obrazovky portletu Úřední deska 6. Návrh portálu úředníka Na hlavní obrazovce 6.22 je zobrazen aktuální seznam příspěvků, které jsou buď už zveřejněné, ale ještě neexspirovaly, nebo zatím čekají na zveřejnění. Dvojklikem na název příspěvku je možné ho editovat. V pravém panelu je tlačítko pro vytvoření příspěvku. Příspěvek se naopak smaže, pokud uživatel zaškrtne políčko u příspěvku a zmáčkne Smazat. Rozepsané případy užítí a návrhy obrazovek jsou k nalezení v příloze A a B diplomové práce. Obrázek 6.22: Návrh hlavní obrazovky portletu Úřední deska Diagram tříd pro portlet Úřední deska Diagram tříd 6.23 definuje jednotlivé třídy. Třída Úřední deska slouží jako rozhraní pro administraci jednotlivých příspěvků. Příspěvky se zveřejňují ve veřejné části Úřední desky a po uplynutí doby exspirace se archivují v Archivu. Příspěvek má nadpis, text a může mít i nastavenou přílohu. Sekvenční diagram pro portlet Úřední deska Sekvenční diagram 6.24 zobrazuje vytvoření, zveřejnění a archivaci příspěvku na Úřední desce. 52

58 6. Návrh portálu úředníka Obrázek 6.23: Diagram tříd pro portlet Úřední deska Obrázek 6.24: Sekvenční diagram pro portlet Úřední deska Service desk Případ užití pro portlet Service desk Případ užití 6.25 zobrazuje požadovanou funkcionalitu, zejména práci s požadavky, jejich přidělování uživatelům a řešení. Rozepsané případy užítí a návrhy obrazovek jsou k nalezení v příloze A a B diplomové práce. 53

59 6. Návrh portálu úředníka Obrázek 6.25: Případ užití pro portlet Service desk Návrh hlavní obrazovky pro portlet Service desk Hlavní strana portletu Service desk 6.26 zobrazuje všechny nevyřešené požadavky vložené do systému. Je možné je řadit podle několik atributů. Kliknutím na číslo požadavku nebo na název požadavku se zobrazí detail požadavku. Uživatel může požadavky prohlížet a přiřazovat jim vlastníka. Požadavky, které uživatel vlastní, najde ve svém Úkolníku. Případ užití zobrazení úkolu a obrazovka detailu úkolu je k nalezení v příloze A a B diplomové práce. Diagram tříd pro portlet Service desk Diagram tříd 6.27 zobrazuje jako nejrozsáhlejší třídu Požadavek, která může mít připojenou přílohu, komentář nebo zprávu žadateli. Požadavek má atribut typ, který definuje čeho se požadavek týká a který usnadňují orientaci v požadavcích. Atributy datum předpokládaného vyřešení a priorita jsou ukazateli, jak moc požadavek spěchá při řešení. Požadavek má svůj stav, který se mění v závislosti na vytvoření/přidělení vlastníka/vyřešení požadavku. Jakmile se požadavku nastaví vlastník, exportuje se do Úkolníku vlastníka jako úkol. Jakákoli událost, kterou se požadavek změní (například přidělení vlastníka, vyřešení) se ukládá v podobě záznamu (logu). Z těchto záznamů se posléze tvoří databáze údajů pro Manažerský IS. 54

60 6. Návrh portálu úředníka Obrázek 6.26: Návrh hlavní obrazovky pro portlet Service desk Sekvenční diagram pro portlet Service desk Sekvenční diagram 6.28 zobrazující vložení, přidělení a vyřešení požadavku uživatelem Úkolník Případ užití pro portlet Úkolník Případ užití 6.29 popisuje nejčastější operace prováděné s úkolem v Úkolníku. Oproti Požadavkům z portletu Service desk, je možné úkoly sdílet a nastavovat jim označení v podobě miniatury obrázku (například vykřičníky, hvězdičky, otazníky, obálky atd.). Vyřešení úkolu je možné v rámci rozhraní Úkolníku nebo po zobrazení detailu úkolu v Service desk. Do Úkolníku také Systém ukládá úkoly, které vyplývají z uživatelovi pozice ve workflow. Rozepsané případy užití a návrhy obrazovek jsou k nalezení v příloze A a B diplomové práce. Návrh hlavní obrazovky pro portlet Úkolník Obrazovka ukazuje hlavní stranu 6.30 portletu Úkolník. Uživatel v ní vidí seznam svých úkolů, datum jejich vytvoření, předpokládaný termín vyřešení a jejich prioritu. Ke každému úkolu si může přiřadit popisující značku. Klik- 55

61 6. Návrh portálu úředníka Obrázek 6.27: Diagram tříd pro portlet Service desk Obrázek 6.28: Sekvenční diagram pro portlet Service desk 56

62 6. Návrh portálu úředníka Obrázek 6.29: Případ užití pro portlet Úkolník nutím na název úkolu se zobrazí detail úkolu. Případ užití zobrazení úkolu a obrazovka detailu úkolu je k nalezení v příloze A a B diplomové práce. Obrázek 6.30: Návrh hlavní obrazovky pro portlet Úkolník 57

63 Diagram tříd pro portlet Úkolník 6. Návrh portálu úředníka Každý uživatel portálu má přidělený vlastní Úkolník, kde se shromažďují jeho úkoly. Ať už mu byly přiděleny v rámci Service desk nebo vyplynuly z jeho pozice ve workflow. V Úkolníku může uživatel definovat jeho nastavení, které se týká především upozornění na blížící se úkoly. Jelikož Úkolník převážně pracuje s požadavky, které vznikly v Service desk, v diagramu tříd 6.31 jsem zobrazila i třídu Požadavek (zjednodušeně bez metod). Úkol může být následně exportován jako událost do kalendáře vlastníka. Obrázek 6.31: Diagram tříd pro portlet Úkolník Sekvenční diagram pro portlet Úkolník Sekvenční diagram 6.32 ukazuje zobrazení úkolu uživatelem, přiřazení označení a export úkolu do portletu Kalendář. 58

64 6. Návrh portálu úředníka Obrázek 6.32: Sekvenční diagram pro portlet Úkolník Manažerský IS Případ užití pro Manažerský IS Případ užití portletu Manažerského IS 6.33 zobrazuje dvě nejdůležitější funkce systému a to zobrazení statistik uživatelem a správu statistik administrátorem. Data pro vykreslení statistik se berou z databáze, do které se ukládají záznamy o událostech z portletu Service desk. V případě potřeby se mohou přidat další databáze dat, nad kterými se budou klást dotazy a vykreslovat statistiky. Obrázek 6.33: Případ užití pro Manažerský IS 59

65 Návrh hlavní obrazovky pro Manažerský IS 6. Návrh portálu úředníka Obrazovka ukazuje hlavní stranu portletu, 6.34 která se zobrazuje pro běžného uživatele. Uživatel vybere statistiku a její rozsah. Systém vypíše statistiku na obrazovku portletu. Pokud chce uživatel statistiky stáhnout, pak je po zobrazení nechá exportovat do souboru. Případ užití exportu statistiky a příslušná obrazovka je k nalezení v příloze. Obrázek 6.34: Návrh hlavní obrazovky pro Manažerský IS Diagram tříd pro portlet Manažerský IS Diagram tříd 6.35 ukazuje vztahy Manažerského IS a databáze. Manažerský IS bere data z databáze, zpracovává je a vykresluje statistiky. Databáze analyzuje logy požadavků a ukládá data z nich ve snadno dohledatelné formě. Sekvenční diagram pro portlet Manažerský IS Sekvenční diagram 6.36 popisuje situaci, kdy si uživatel nechá vygenerovat statistiku a exportovat ji do zvoleného formátu. 60

66 6. Návrh portálu úředníka Obrázek 6.35: Diagram tříd pro portlet Manažerský IS Obrázek 6.36: Sekvenční diagram pro portlet Manažerský IS Systém pro definování workflow Případ užití portletu Systému pro definování workflow Systém slouží pro definici workflow pro vybrané portlety. Workflow je možné vytvořit, editovat a samozřejmě přiřadit k předem definovaným portletům. 61

67 6. Návrh portálu úředníka Aktuálně je požadavek na workflow explicitně zmíněn pouze při oběhu dokumentů v DMS Obrázek 6.37: Případ užití portletu Systému pro definování workflow Návrh hlavní strany portletu Systému pro definování workflow Návrh obrazovky 6.38 ukazuje hlavní obrazovku, kde je možné připojit již nadefinované workflow k portletům v rámci jednoho odboru. Pomocí tlačítek v menu může uživatel workflow vytvářet, odstraňovat a editovat. Obrázek 6.38: Návrh hlavní strany portletu Systému pro definování workflow 62

68 7 Závěr Tato diplomová práce se věnuje problematice portálového řešení pro úřady v krajských a statutárních městech. Zejména pak možnostem portálu Liferay pro vytvoření portálu, který bude sloužit zaměstnancům úřadu Portálu úředníka. V první části diplomové práce jsem nadefinovala veřejnou správu a její specifika, a následně popsala vládní strategie pro rozvoj veřejné správy a jejich nejdůležitější komponenty. Dále jsem se věnovala problematice portálů, jejich použití, silným a slabým stránkám a poté zdůvodnila proč je portálové řešení nejlepší pro použití na úřadech krajů a statutárních měst. Představila jsem výrobce portálových řešení a porovnala jsem je podle mnoha parametrů. Nadefinovala jsem silné a slabé stránky portálu Liferay v porovnání s ostatními. Po analýze aktuálně dostupných studií proveditelnosti jak krajských, tak statutárních měst jsem vymezila množinu aplikací, které úřady nutně vyžadují ke své činnosti. Tyto aplikace jsem porovnala s možnostmi portálu Liferay, především jeho portlety a pomocí diagramů UML jsem navrhla jejich podobu a celkový vzhled Portálu úředníka. Vzhledem k tomu, že strategie Smart Administration o modernizaci veřejné správy bude trvat do roku 2020, je očekáván v této oblasti ještě další rozvoj. Projekty, které mohou být v rámci strategie dále realizovány: Portál občana. V tomto portálu bude hlavním uživatelem občan. V Portálu bude mít dostupnou svoji datovou schránku, Formulářový systém pro podávání žádostí online, sledování stavu jeho podaných žádostí a historii jeho žádostí. Dále pak bude mít přes portál přístup do systému CzechPOINT@office a do systému pro rezervaci schůzek s úředníkem. Komplexní Portál města. Portál, který by měl obsahovat nejen informace o městě a prvky, které musí úřad ze zákona zveřejnit (například úřední desku), ale i postupy pro řešení životních situací občana, ankety, diskuzní fóra, možnost veřejně se vyjádřit k práci úřadu. Portál by měl komplexně pokrýt všechny skupiny obyvatel vyhledávající informace o městě. Ať už je to občan města, turista nebo úředník. Portál majetku města. Portál, jehož uživatelé budou úředníci, kteří budou z jednoho místa kontrolovat a spravovat majetek města. Portály pro příspěvkové organizace a obce s rozšířenou působností. Je pravděpodobné, že i příspěvkové organizace a ORP budou postupem 63

69 7. Závěr času chtít vlastní řešení Portálu úředníka pro usnadnění vzájemné komunikace s úřady vyšší instace, sjednocení agend, elektronické Spisové služby a datové schránky v rámci jednoho portálového řešení. 64

70 Literatura [1] Zákon č. 2/1969 Sb., o zřizení ministerstev a jiných ústř. orgánů státní správy ČR [2] Zákon č. 347/1997 Sb., o vytvoření vyšších územních samosprávných celků [3] Vyhláška č. 496/2004 Sb., o elektronických podatelnách [4] Zákon č. 128/2000 Sb., o obcích [5] Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů [6] Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů [7] Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů [8] Zákon 190/2009 Sb., kterým se mění zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů [9] Zákon č. 111/2009 Sb., o základních registrech [10] Předpis č. 259/2012 Sb.,Vyhláška o podrobnostech výkonu spisové služby [11] ABDELNUR, A. a S. HEPPER: JSR 168: Java Portlet Specification, version 1.0. online, 2003, [cit ]. URL [12] AREVOLO, W.: The Future of Portals. Gartner, [13] DESBIENS, F., P. MOSKOVITS, a P. WECKERLE: Oracle WebCenter 11g Handbook: Build Rich, Customizable Enterprise 2.0 Applications. Unites States of America: McGraw-Hill Companies, [14] DigitSmith Embroidery and Screen Printing: Ecommerce definition and types of ecommerce. online, [cit ]. URL 65

71 Literatura [15] DVOŘÁK, V.: Teoretické principy sociální správy - Správa, veřejná správa a samospráva. online, [cit ]. URL [16] EUNICE CONSULTING a.s: Studie proveditelnosti pro projekt Rozvoj služeb egovernmentu v krajích Zlínský kraj. Praha, [17] EUNICE CONSULTING a.s: Studie proveditelnosti pro projekt Vnitřní integrace úřadu a integrace s ISVS Olomouckého kraje. Praha, [18] FOWLER, M.: UML Distilled: A Brief Guide to the Standard Object Modeling Language. 3. edition. Addison-Wesley Professional, [19] Gartner: Magický kvadrant horizontálních portálu. online, 2013, [cit ]. URL 1-1KH0XVB&ct=130917&st=sg&submissionGuid=3f51a4b3-729d- 4b30-99da-a4f9806fcfaa [20] HAVELKA, Z., aj.: Studie proveditelnosti Technologické centrum, elektronická spisová služba a vnitřní integrace úřadu v území pro město Most. Moravská Třebová, [21] HEPPER, S.: JSR 286: Java Portlet Specification, version 2.0. online, 2008, [cit ]. URL techarticles/0803_hepper/0803 [22] HEPPER, S. a O. KÖTH: What s new in the Java Portlet Specification V2.0 (JSR 286)? online, 2010, [cit ]. URL techarticles/0803_hepper/0803 [23] International Business Machines Corporation (IBM): WebSphere Portal family. online, [cit ]. URL [24] International Business Machines Corporation (IBM): WebSphere Portal Version Reviewer s Guide. United States of America: IBM Corporation, [25] Jihomoravský kraj: Studie proveditelnosti pro projekt Vnitřní integrace úřadu a integrace s ISVS Jihomoravského kraje. Brno,

72 Literatura [26] KROTKÝ, J.: Vnitřní integrace úřadu Kraje Vysočina dokončena. online, 2013, [cit ]. URL [27] Královéhradecký kraj: Komplexní integrace Krajského úřadu Královéhradeckého kraje. Hradec Králové, [28] Liferay Inc.: Liferay Portal Enterprise Subscription, Service Levels Liferay. online, [cit ]. URL service-levels [29] Liferay Inc.: Liferay Portal Overview. online, [cit ]. URL [30] LÁTAL, J.: Studie proveditelnosti v rámci projektu Technologické centrum ORP Děčín Vnitřní integrace úřadu. Česká Lípa, [31] Magistrát statutárního města Chomutov: Implementace rozvoje služeb egovernmentu statutární město Chomutov. Chomutov, [32] Marbes Consulting: Uživatelská příručka epusa. Praha, [34] Microsoft: SharePoint Software Requirements. online, [cit ]. URL office.15).aspx [35] Ministerstvo vnitra ČR: czechpoint. [cit ]. URL [33] Microsoft: Co je SharePoint? online, [cit ]. URL [36] Ministerstvo vnitra ČR: Implementace Strategie Smart Administration. online, [cit ]. URL [37] Ministerstvo vnitra ČR: Metodika upravující postup při správě informačního systému Elektronický portál územních samospráv - epusa, a nakládání s daty v něm obsaženými. Praha,

73 Literatura [38] Ministerstvo vnitra ČR: EFEKTIVNÍ VEŘEJNÁ SPRÁVA A PŘÁTEL- SKÉ VEŘEJNÉ SLUŽBY: Strategie realizace Smart Administration v období [39] Ministerstvo vnitra ČR: Memorandum o spolupráci při přípravě, řešení, testování a realizaci projektu Digitální mapa veřejné správy online. Praha, [40] Ministerstvo vnitra ČR: Informační systém datových schránek, základní informace. Praha, [41] Ministerstvo vnitra ČR: Vnitřní integrace úřadu, Typizovaný projekt. Praha, [42] Ministerstvo vnitra ČR: Aktuální stav projektu DMVS Ministerstvo vnitra, Sekce veřejné správy a egovernmentu. Praha, [43] Ministerstvo vnitra ČR: Strategický rámec rozvoje egovernmentu Praha, [44] Moravskoslezský kraj, Krajský úřad, odbor informatiky: Návrh technické specifikace Vnitřní integrace úřadu Moravskoslezský kraj. Ostrava, [45] Moravskoslezský kraj, Krajský úřad, odbor informatiky: STRATEGIE E-GOVERNMENT SLUŽEB V MORAVSKOSLEZSKÉM KRAJI. Ostrava, [46] Moravskoslezský kraj, Krajský úřad, odbor informatiky: Datové sklady - SW Technologie a metadatový systém, Datová tržiště ekonomiky, Školství, statistiky, zdravotnictví. Ostrava, [47] Pardubický kraj: Vnitřní integrace úřadu a integrace s ISVS [48] PATIL, S.: What Is a Portlet? online, 2005, [cit ]. URL [49] ROGERS, Y., H. SHARP, a J. PREECE: Interaction design: Beyond human-computer interaction (3rd edition). Chichester, [50] RPSC ideas s.r.o.: Studie proveditelnosti. Přerov, [51] RÁKOSOVÁ, S. a P. ROUS: Statutární město Kladno a strategie implementace egovernmentu. Kladno,

74 Literatura [52] SEZOV, R.: Liferay in Action: The Official Guide to Liferay Portal Development. Shelter Island: Manning Publications, [53] Software 602: Elektronizace životních situací a interních procesů magistrátu okresního města. online, 2012, [cit ]. URL [54] Správa základních registrů: Příručka pro obce. Praha, [55] Svaz měst a obcí České republiky: Chytřejší města v České Republice. Praha, [56] Svaz měst a obcí České republiky: Příručka pro člena zastupitelstva obce, Aktualizované znění Praha, [57] TATNALL, A.: The new gateways to internet information and services. Idea Group Publishing, [58] THOMPSON, R.: Web Services for Remote Portlets Specification v2.0. online, 2008, [cit ]. URL [59] Ústecký kraj: Studie proveditelnosti a zpracování projektové žádosti dle výzvy č. 08 k předkládání žádostí o finanční podporu v rámci integrovaného operačního programu na Rozvoj služeb egovernmentu v krajích. Ústí nad Labem,

75 A Popisy diagramů užití A.1 Service desk - popis Tabulka A.1: Vložení nového požadavku Krátký popis: Use case umožňuje Uživateli a Občanovi vkládat nové požadavky do Systému. Aktéři: - Uživatel - Občan - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Základní tok: 1. Uživatel klikne na základní obrazovce na tlačítko Vytvořit nový požadavek. 2. Systém zobrazí rozhraní pro vytvoření nového požadavku. 3. Uživatel vytvoří ve formulářovém okně Service desk nový požadavek. Zadá název, text, prioritu, předpokládaný termín vyřešení, z nabídky vybere typ požadavku a vybere přílohy z DMS nebo esps. 4. Uživatel může nastavit i vlastníka požadavku, nebo ho nastavit až později (viz use case Přidělení požadavku) 5. Uživatel uloží požadavek. 6. Systém Uživateli zobrazí informace o úspěšném uložení požadavku. 7. Systém uloží požadavek s jménem a kontaktem na Uživatele a časem vytvoření požadavku. 8. Systém vygeneruje unikátní ID a přiřadí ho k požadavku. 9. Systém nastaví stav požadavku na Nový. 10. Systém požadavek zobrazí v seznamu požadavků na hlavní straně portletu Service desk. Alternativní tok 1: Občan podává požadavek s přílohami přes podatelnu 1.1. Občan pošle požadavek datovou schránkou nebo em se zaručeným elektronickým podpisem na e-podatelnu, která zaeviduje v Elektronické spisové službě všechny dokumenty, žádosti a formuláře, které občan elektronicky podal. Úředník z podatelny vloží požadavek do Systému Service desk. Pokračování bodem 1 základního toku. 70

76 A. Popisy diagramů užití Alternativní tok2: Občan podává dotaz přes webové rozhraní v portálu města 1. Občan si zobrazí veřejně dostupný webový formulář. Zadá svoje osobní údaje (jméno, přijmení, ). Zadá název, text, z nabídky vybere typ požadavku a požadavek odešle tlačítkem "Odeslat". 2. Systém nastaví termín vyřešení automaticky dle vyhlášky (30 dní od podání), střední prioritu. Systém uloží požadavek s jménem a kontaktem na Občana a časem vytvoření požadavku. 3. Systém Občanovi zobrazí informaci o úspěšném uložení požadavku. Pokračování bodem 8 základního toku. Podmínky dokončení: Požadavek se uloží do Systému. Tabulka A.2: Vyhledání požadavku podle ID nebo klíčových slov Krátký popis: Uživatel může vyhledávat mezi požadavky podle ID nebo podle klíčových slov. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Základní tok: 1. Uživatel si zobrazí základní obrazovku Systému. 2. Uživatel zadá do vyhledávacího pole ID požadavku nebo klíčová slova, podle kterých chce vyhledávat. 3. Uživatel klikne na tlačítko Vyhledat. 4. Systém Uživateli na obrazovku vypíše všechny odpovídající požadavky. 5. Uživatel může klikem na šipky u názvu sloupce seřadit požadavky podle hodnot v daném sloupci. 6. Uživatel dvojklikem na název požadavku zobrazí detail požadavku. Alternativní tok: Požadavek nenalezen. 4. Systém Uživateli zobrazí prázdnou tabulku. Pokračování bodem 1 základního toku. Podmínky dokončení: Vyhledání požadavku. 71

77 A. Popisy diagramů užití Tabulka A.3: Přidělení vlastníka požadavku Krátký popis: Use case popisující přiřazení požadavku Uživateli k vyřešení. Aktéři: - Uživatel - Úkolník - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Základní tok: 1. Uživatel si zobrazí požadavek podle use case Zobrazení požadavku. 2. Uživatel přidělí požadavek sobě nebo jinému Uživateli vybráním Uživatele ze seznamu Uživatelů u atributu Vlastník požadavku a kliknutím na tlačítko Uložit. 3. Pokud už existoval vlastník požadavku, Systém odstraní požadavek z jeho Úkolníku a Kalendáře. Pokud původní vlastník v rámci Úkolníku nasdílel úkol dalším Uživatelům, zůstane jim úkol nasdílen, ale přijde jim o změně vlastníka požadavku. 4. Uživateli, kterému byl požadavek přidělen, se požadavek s odkazem do Service desk uloží do Úkolníku a Systém mu odešle ové upozornění. 5. Systém udržuje informaci o vlastníkovi v atributu Vlastník požadavku. 6. Systém změní stav požadavku na Řeší se. Alternativní tok: Podmínky dokončení: Úkol je přiřazen. Tabulka A.4: Vyřešení požadavku Krátký popis: Use case popisuje vyřešení a archivaci požadavku. Aktéři: - Uživatel - Žadatel - Systém 72

78 A. Popisy diagramů užití Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Uživatel je vlastník požadavku. Základní tok: 1. Uživatel si zobrazí požadavek (viz use case Zobrazení požadavku). 2. Uživatel klikne na tlačítko Vyřešit požadavek. 3. Systém změní stav požadavku na Vyřešený. 4. Systém na adresu Žadatele odešle ovou notifikace o vyřešení požadavku. 5. Systém odstraní požadavek z hlavní strany Service desk a přesune ho do sekce Vyřešené požadavky. Systém odstraní požadavek z Úkolníku a Kalendáře a to i všem Uživatelům, kteří ho měli nasdílený, dokumenty a spisy příslušející k požadavku se archivují v espisovně podle patřičné vyhlášky. Alternativní tok: Podmínky dokončení: Požadavek je archivován. Tabulka A.5: Zobrazení požadavku Krátký popis: Zobrazení vybraného požadavku. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Základní tok: 1. Uživatel si zobrazí hlavní stranu Systému. 2. Systém v základní obrazovce zobrazí všechny aktuální požadavky. 3. Uživatel je může prohlížet, kliknutím na název sloupce se požadavky seřadí podle hodnot v něm uvedených. 4. Uživatel dvojklikem na název požadavku získá detail požadavku. Alternativní tok 1: Zobrazit Uživatelem vytvořené požadavky 2.1 Uživatel vybere v portletu možnost Zobrazit mnou vytvořené požadavky. 2.2 Systém vypíše seznam požadavků, kde je Uživatel uveden jako žadatel. 2.3 Uživatel dvojklikem na název požadavku získá detail požadavku. 73

79 A. Popisy diagramů užití Alternativní tok 2: Zobrazit vyřešené požadavky 2.1 Uživatel vybere v portletu možnost Zobrazit vyřešené požadavky. 2.2 Systém vypíše seznam vyřešených požadavků. 2.3 Uživatel dvojklikem na název požadavku získá detail požadavku. Podmínky dokončení: Zobrazení požadavku. Tabulka A.6: Vrátit vyřešený požadavek zpět k řešení Krátký popis: Use case popisující vrácení vyřešeného požadavku zpět k řešení. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Základní tok: 1. Uživatel si zobrazí hlavní stranu Systému. 2. Uživatel klikne na tlačítko Zobrazit vyřešené požadavky. 3. Systém mu vypíše seznam požadavků, které jsou ve stavu Vyřešený. 4. Uživatel dvojklikem na název požadavku získá detail požadavku. 5. Uživatel klikne na tlačítko Zpět k řešení. 6. Systém změní stav požadavku na Řeší se a vrátí ho zpátky do seznamu požadavků na hlavní straně portletu. Pokud má požadavek vlastníka, požadavek se opět uloží do jeho Úkolníku. Alternativní tok: Podmínky dokončení: Požadavek je zpět ve stavu Řeší se (pokud měl vlastníka) nebo Nový (pokud vlastníka neměl) a zobrazí se na hlavní straně portletu Service desk. 74

80 A. Popisy diagramů užití Tabulka A.7: Editovat požadavek administrátorem Krátký popis: Use case popisující možnost editace požadavku Administrátorem. Editovat je možné atributy priorita, typ a datum předpokládaného vyřešení požadavku. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen v portálu. Administrátor má autentizovaný přístup do Service desk. Administrátor má spuštěný Service desk. Základní tok: 1. Administrátor si zobrazí detail požadavku (viz use case Zobrazení požadavku). 2. Administrátor může editovat atributy priorita, typ a datum předpokládaného vyřešení požadavku. 3. Administrátor provede editaci a stiskne tlačítko Uložit změny. 4. Systém uloží změny a zobrazí Administrátorovi zprávu o úspěšném uložení změn do Systému. 5. Pokud je požadavek uložen v Úkolníku zaměstnance, změna se vypropaguje i do úkolu v Úkolníku. Alternativní tok: Podmínky dokončení: Úspěšné uložení změny atributů. Tabulka A.8: Přidání komentáře k požadavku Krátký popis: Uživatel může komentovat požadavek. Komentář se uloží v detailu požadavku. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. V Systému existuje aspoň jeden požadavek. 75

81 A. Popisy diagramů užití Základní tok: 1. Uživatel si vyhledá požadavek (viz use case Zobrazení požadavku). 2. Uživatel vyplní komentář v poli Nový komentář a klikne na Komentovat. 3. Systém uloží komentář k požadavku a zobrazí ho v detailu požadavku. 4. Systém zobrazí informaci o úspěšném uložení komentáře. Alternativní tok: Podmínky dokončení: Uložení komentáře. Tabulka A.9: Odeslání zprávy žadateli přes Service desk Krátký popis: Uživatel může komunikovat s Žadatelem přes Service desk, komunikace probíhá přes kontakt uvedený v požadavku. Aktéři: - Uživatel - Žadatel - Systém Podmínky pro spuštění: V požadavku musí být uveden kontakt na Žadatele. Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Service desk. Uživatel má spuštěný Service desk. Základní tok: 1. Uživatel si zobrazí požadavek (viz use case Zobrazení požadavku). 2. Uživatel vyplní zprávu v poli Nová zpráva a klikne na Napsat žadateli zprávu. 3. Systém odešle zprávu a zobrazí její text v detailu požadavku. 4. Pokud Žadatel na zprávu odpoví, uloží se odpověď pod text zprávy v detailu požadavku. Pokud Uživatel vyřešil požadavek a po té mu Žadatel poslal odpověď, stav vyřešeného požadavku se přijetí odpovědi změní na Řeší se. Systém vrátí požadavek zpět na hlavní stranu Service desku a do Úkolníku vlastníka požadavku. Alternativní tok: Podmínky dokončení: Odeslání zprávy a její uložení k požadavku. 76

82 A. Popisy diagramů užití Tabulka A.10: Odstranění požadavku Krátký popis: Administrátor může požadavek smazat. Vhodné pro případ, že přijde do Service desku spam. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen v portálu. Administrátor má autentizovaný přístup do Service desk. Administrátor má spuštěný Service desk. Základní tok: 1. Administrátor si zobrazí požadavek (viz use case Zobrazení požadavku). 2. Administrátor klikne na tlačítko Smazat požadavek. 3. Systém zobrazí upozornění o smazání požadavku. Kliknutím na OK je požadavek odstraněn ze Systému Service desk, Úkolníku a Kalendáře, kliknutím na Zpět se Administrátorovi zobrazí detail požadavku. Alternativní tok: Podmínky dokončení: Požadavek je smazán A.2 Úkolník - popis Tabulka A.11: Vytvoření úkolu Krátký popis: Use case popisující vytvoření úkolu v rozhraní Úkolníku. Aktéři: - Uživatel - Service desk - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. 77

83 A. Popisy diagramů užití Základní tok: 1. Uživatel si zobrazí základní obrazovku Úkolníku. 2. Uživatel klikne na tlačítko Vytvořit nový úkol. 3. Systém Uživatele přesměruje do Service desk, sekce vytvoření požadavku. Pokračování use case Vytvoření požadavku v Service desk. Alternativní tok: Podmínky dokončení: Úkol je uložen do Systému. Tabulka A.12: Zobrazení úkolu Krátký popis: Uživatel si zobrazí jeho úkoly v Systému. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Základní tok: 1. Uživatel má na základní obrazovce Úkolníku zobrazeny jemu přidělené úkoly. Pokud Uživatel nemá žádný přidělený úkol, je mu zobrazena prázdná tabulka. 2. Uživatel klikne na název úkolu. 3. Systém Uživateli zobrazí detail úkolu. Alternativní tok: Podmínky dokončení: Zobrazení úkolu. Tabulka A.13: Vyhledání úkolu ze seznamu Krátký popis: Vyhledání konkrétního Uživatelova úkolu ze seznamu jeho úkolů. Aktéři: - Uživatel - Systém 78

84 A. Popisy diagramů užití Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Základní tok: 1. Uživatel si zobrazí základní obrazovku Systému. 2. Uživatel do vyhledávacího políčka zadá číslo požadavku nebo klíčové slovo 3. Uživatel stiskne tlačítko Hledej. 4. Systém vyhledá seznam odpovídajících úkolů. Alternativní tok: Požadavek nenalezen. 4. Systém Uživateli zobrazí prázdnou tabulku. Pokračování bodem 1 základního toku. Podmínky dokončení: Vyhledání úkolu. Tabulka A.14: Označení úkolů Krátký popis: Use case popisující označení úkolů v úkolníku značkou. Značky slouží Uživatelům pro lepší orientaci v úkolech Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Uživatel má v Úkolníku alespoň jeden úkol. Základní tok: 1. Uživatel si zobrazí úkol podle use case Zobrazení úkolu. 2. Uživatel kliknutím na první část řádku s názvem úkolu může přidat značku podle vlastního uvážení. Symboly budou pokrývat základní požadavky Uživatelů. Klikáním na místo značky se zobrazené značky budou měnit. Po vyčerpání všech značek následuje opět prázdná značka Alternativní tok: Podmínky dokončení: Označení úkolu. 79

85 A. Popisy diagramů užití Tabulka A.15: Vyřešení úkolu Krátký popis: Use case popisující vyřešení úkolu Uživatelem. Aktéři: - Uživatel - Žadatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Uživatel má v Úkolníku alespoň jeden úkol. Základní tok: 1. Uživatel si zobrazí úkol podle use case Zobrazení úkolu. 2. Uživatel klikne na tlačítko Vyřešit úkol. 3. Systém odešle informaci o vyřešení do Service desk. 4. Service desk změni stav požadavku na Vyřešený. 5. Service desk na adresu Žadatele se odešle ová notifikace o vyřešení požadavku. 6. Požadavek se v Service desk přesune do sekce vyřešených požadavků. Odstraní se z Úkolníku a Kalendáře. Alternativní tok 1: Vyřešení úkolu v rámci Service desk 1. Úředník si zobrazí úkol podle use case Zobrazení úkolu. 2. Úředník klikne na odkaz do Service desk. 3. Systém mu zobrazí detail požadavku v Service desk. Úředník klikne na Vyřešit požadavek. 4. Systém změní stav požadavku na Vyřešený. 5. Systém na adresu Žadatele odešle ovou notifikace o vyřešení požadavku. 6. Požadavek se v Service desk přesune do sekce vyřešených požadavků. Odstraní se z Úkolníku a Kalendáře. Alternativní tok 2: Vyřešení úkolu plynoucího z workflow 1. Úředník si zobrazí úkol podle use case Zobrazení úkolu. 2. Uživatel klikne na tlačítko Vyřešit úkol. 3. Systém na adresu Žadatele (pokud je v tomto případě zadána) odešle ovou notifikace o vyřešení úkolu tímto Uživatelem. 3. Systém postoupí úkol dalšímu Uživateli podle toho, jak je to definováno ve workflow. 6. Požadavek se Odstraní se z Uživatelova Úkolníku a Kalendáře. Podmínky dokončení: Vyřešení úkolu. 80

86 A. Popisy diagramů užití Tabulka A.16: Zaslání upozornění Krátký popis: Use case popisující odeslání upozornění na blížící se termín úkolu. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Uživatel má v Úkolníku alespoň jeden úkol. Základní tok: 1. Systém vyhodnotí, že úkol splňuje pravidla pro zaslání upozornění Uživateli. 2. Systém pošle upozornění na Uživateli. 3. Systém zvýrazní úkol v seznamu úkolů. 4. Systém zobrazí upozornění na hlavní obrazovce portálu. Alternativní tok: Podmínky dokončení: Zobrazení upozornění. Tabulka A.17: Nastavení Krátký popis: Use case popisující možnosti Uživatelského nastavení Úkolníku. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. 81

87 A. Popisy diagramů užití Základní tok: 1. Uživatel si zobrazí hlavní obrazovku Systému. 2. Uživatel klikne na Nastavení. 3. Systém zobrazí nastavení jeho Uživatelského účtu. 4. Uživatel vyplní za jakých podmínek se mu má odesílat upozornění na vyřešení úkolů a jeho periodicitu. 5. Uživatel nastavení uloží tlačítkem Uložit. 6. Systém uloží nastavení a zobrazí zprávu o úspěšném uložení nastavení. Alternativní tok: Podmínky dokončení: Nastavení proměnných. Tabulka A.18: Sdílení úkolu dalším Uživatelům Krátký popis: Use case popisující možnosti sdílení úkolu mezi více Uživateli. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Uživatel má v Úkolníku alespoň jeden úkol. Uživatel je vlastník úkolu. Základní tok: 1. Uživatel si zobrazí detail úkolu podle use case Zobrazení úkolu. 2. Uživatel klikne na tlačítko Sdílet úkol dalším Uživatelům. 3. Uživatel z nabídky vybere Uživatele, se kterými chce úkol sdílet. 4. Uživatel stiskne tlačítko OK. 5. Systém vybraným Uživatelům vloží úkol do Úkolníku. 6. Systém odešle Uživatelům ové upozornění o sdílení úkolu. Alternativní tok 1: Odstranění Uživatelů z výběru Uživatel klikne na křížek u jména vybraného Uživatele Uživatel klikne na tlačítko OK Systém vybraným Uživatelům odebere úkol z Úkolníku Systém odešle Uživatelům oznámení o odebrání úkolu. Podmínky dokončení: Změna ve sdílení úkolu. 82

88 A. Popisy diagramů užití Tabulka A.19: Vložení úkolu do Kalendáře Krátký popis: Use case umožňující vložit úkol z Úkolníku do kalendáře uživatele. Aktéři: - Uživatel - Systém - Kalendář Podmínky pro spuštění: Uživatel je přihlášen v portálu. Uživatel má autentizovaný přístup do Úkolníku. Uživatel má spuštěný Úkolník. Uživatel má vytvořený alespoň jeden úkol. Uživatel má vytvořený alespoň jeden kalendář. Základní tok: 1. Uživatel si zobrazí detail úkolu podle use case Zobrazení úkolu. 2. Uživatel klikne na Nasdílet do kalendáře. 3. Uživatel vybere název kalendáře, kam se úkol nasdílí. 4. Systém vloží úkol jako událost do vybraného kalendáře. Datum a čas události bude předpokládaný termín vyřešení úkolu, do textu události se uloží text úkolu a odkaz do Service desk, jako název události se uloží název úkolu. Alternativní tok: Podmínky dokončení: Vložení události do Kalendáře. A.3 Manažerský IS - popis Krátký popis: Uživatel si zobrazí vybrané statistiky. Aktéři: - Uživatel - Systém - Databáze požadavků Tabulka A.20: Zobrazení statistik 83

89 A. Popisy diagramů užití Podmínky pro spuštění: Uživatel je přihlášen v portálu, Uživatel má oprávnění pracovat se Systémem (portletem). Uživatel má spuštěný Systém. Základní tok: 1. Uživatel si zobrazí hlavní stranu Systému. 2. Uživatel vybere z nabídky statistiku, kterou chce zobrazit. Statistiky na výběr jsou například: počet úkolů, doba řešení úkolů za Úředníka/oddělení, seznam úkolů, které se aktuálně řeší a kdo je řeší, průměrná doba řešení úkolů (čas vytvoření - vyřešení), úkoly jejichž doba řešení přesáhla termín, Gantův diagram práce na úkolech v Service desku, a další podle požadavků úřadu. 3. Systém vypíše zvolenou statistiku na obrazovku. Alternativní tok: Podmínky dokončení: Uživatel získá požadovaná data. Tabulka A.21: Export statistik Krátký popis: Use case popisující export vygenerovaných statistik. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu, Uživatel má oprávnění pracovat se Systémem (portletem), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel provede use case Zobrazení statistik. 2. Uživatel vybere možnost exportovat statistiky a vybere požadovaný formát. 3. Systém provede export a nabídne Uživateli statistiky ke stažení. Alternativní tok: Podmínky dokončení: Export statistik. 84

90 A. Popisy diagramů užití Tabulka A.22: Správa statistik Krátký popis: Use case umožňující Administrátorovi spravovat statistiky v Systému. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen v portálu, Administrátor má oprávnění pracovat s Systémem (portletem), Administrátor má spuštěný Systém. Základní tok: 1. Administrátor si zobrazí základní obrazku Systému, oproti běžnéu Uživateli obsahuje navíc tlačítko "Přidat statistiku."administrátor na tlačítko klikne. 2. Systém zobrazí Administrátorovi rozhraní, kde může z nabízených možností sestavit dotaz na vykreslení nové statistiky z databáze. 3. Administrátor po nastavení požadované statistiky klikne na Uložit statistiku. 4. Systém statistiku uloží. Alternativní tok: Podmínky dokončení: Uložení nové statistiky. A.4 Dohled nad příspevkovými organizacemi - popis Tabulka A.23: Vypsání dokumentů a informací o příspěvkové organizaci Krátký popis: Use case umožňuje Úředníkovi dohled a kontrolu nad fungováním zřízené příspěvkové organizace. Kontrolované položky bývají zejména hospodaření a čerpání rozpočtu, správa majetku, kontrola plnění činnosti, zápisy a závěrečné zprávy organizace. Aktéři: - Úředník - Systém Podmínky pro spuštění: Úředník je přihlášený do portálu, Úředník má spuštěný Systém (portlet), Úředník má autentizovaný přístup do Systému. 85

91 A. Popisy diagramů užití Základní tok: 1. Úředník ze seznamu na hlavní straně Systému vybere příspěvkovou organizaci. Pokud v Systému není žádná příspěvková organizace, je seznam prázdný. 2. Systém mu zobrazí její detail. 3. Úředník klikne v menu na oblast kontroly příspěvkové organizace. 4. Systém Úředníkovi zobrazí vybranou část. Alternativní tok: Podmínky dokončení: Úředníkovi se zobrazí požadovaná informace. Tabulka A.24: Vložení dokumentů do Systému. Krátký popis: Use case popisující vložení dokumentů (zápisů, závěrečných zpráv, rozpočtů) příspěvkové organizace do Systému. Aktéři: - Úředník - Systém - Podatelna - Zástupce příspěvkové organizace - DMS/eSps - Service desk Podmínky pro spuštění: Úředník je přihlášený do portálu, Úředník má spuštěný Systém (portlet), Úředník má autentizovaný přístup do Systému. Základní tok: 1. Zástupce příspěvkové organizace pošle dokumenty a data em nebo datovou schránkou. 2. Podatelna data přijme, dokumenty uloží do esps/dms. 3. Podatelna postoupí data do Service desk jako požadavek. 4. Úředníkovi je přidělen požadavek a stal vlastníkem požadavku. 5. Úředník provede use case Vypsání dokumentů o příspěvkové organizaci. 6. Úředník klikne na tlačítko Nahrát nový soubor. 7. Úředník vybere soubor a volbu potvrdí. 8. Úředník vybere typ dokumentu a rok, ke kterému se vztahuje. 9. Systém dokument uloží a připojí k příspěvkové organizaci. Alternativní tok: 86

92 A. Popisy diagramů užití Podmínky dokončení: Vložení souboru do Systému. Tabulka A.25: Vytvoření příspěvkové organizace Krátký popis: Use case popisující zavedení nové příspěvkové organizace do Systému. Aktéři: - Úředník - Systém Podmínky pro spuštění: Úředník je přihlášený do portálu, Úředník má spuštěný Systém (portlet), Úředník má autentizovaný přístup do Systému. Základní tok: 1. Úředník si zobrazí hlavní stranu Systému. 2. Úředník klikne na tlačítko Vytvořit novou příspěvkovou organizaci. 3. Úředník zadá název organizace a informace o organizaci. Úředník klikne na tlačítko Uložit. 4. Systém uloží novou příspěvkovou organizaci do seznamu příspěvkových organizací. Alternativní tok: Podmínky dokončení: Uložení nové příspěvkové organizace. Tabulka A.26: Odstranění příspěvkové organizace Krátký popis: Use case popisující odstranění příspěvkové organizace ze Systému. Aktéři: - Úředník - Systém Podmínky pro spuštění: Úředník je přihlášený do portálu, Úředník má spuštěný Systém (portlet), Úředník má autentizovaný přístup do Systému. 87

93 A. Popisy diagramů užití Základní tok: 1. Úředník klikne na tlačítko Odebrat příspěvkovou organizaci na hlavní obrazovce Systému. 2. Systém mu nabídne seznam příspěvkových organizací. 3. Úředník ze seznamu vybere příspěvkovou organizaci. 4. Systém zobrazí otázku, zda si opravdu přeje organizaci odstranit. 5. Úředník klikne na Ano. 6. Systém odstraní příspěvkovou organizaci. Alternativní tok1: Příspěvková organizace obsahuje dokumenty 4.1. Systém položí otázku, zda si Úředník přeje odstranit příspěvkovou organizaci i se všemi jejími dokumenty Úředník klikne na Ano, pak se dokumenty buď odstraní nebo pokud se na ně vztahuje patřičná vyhláška, archivují. Pokračování bodem 6 základního toku. Podmínky dokončení: Odstranění příspěvkové organizace ze Systému. Tabulka A.27: Editace příspěvkové organizace Krátký popis: Use case popisující editaci informací o příspěvkové organizaci. Aktéři: - Úředník - Systém Podmínky pro spuštění: Úředník je přihlášený do portálu, Úředník má spuštěný Systém (portlet), Úředník má autentizovaný přístup do Systému. Základní tok: 1. Úředník v Systému ze seznamu vybere příspěvkovou organizaci. 2. Systém mu zobrazí její detail. 3. Úředník klikne na tlačítko Editovat. 4. Systém Úředníkovi zobrazí editační WYSIWYG rozhraní. 5. Úředník provede editaci a stiskne tlačítko Uložit. 6. Systém změny uloží. Alternativní tok: Podmínky dokončení: Uložení změn o příspěvkové organizaci. 88

94 A. Popisy diagramů užití A.5 Docházka - popis Tabulka A.28: Přehled mojí docházky Krátký popis: Use case umožňující sledovat Uživatelovi svoji docházku. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen v portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do Systému. Základní tok: 1. Uživatel si zobrazí hlavní stranu Systému nebo klikne na Přehled mé docházky. 2. Systém zobrazí docházku Uživatele. 3. Uživatel vidí tabulku se sloupci: den označující den v týdnu, datum, příchod skutečný příchod do práce, odchod skutečný odchod z práce, přestávka zda je v rámci pracovní doby nárok na přestávku, naplánovaný začátek pracovní doby začátek pracovní doby naplánovaný, konec pracovní doby naplánovaný konec, úvazek počet hodin úvazku, přesčas přesčas za daný den, saldo chybějící doba do plné pracovní doby, důvod nepřítomnosti dovolená, lékař, služební cesta, nemoc, neplacené volno, očr, školení, paragraf, posledním atributem je poznámka. Alternativní tok: Podmínky dokončení: Zobrazení docházky. Tabulka A.29: Moje naplánovaná docházka Krátký popis: Use case popisující přehled naplánované docházky. Aktéři: - Uživatel - Systém 89

95 A. Popisy diagramů užití Podmínky pro spuštění: Uživatel je přihlášen v portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do Systému. Základní tok: 1. Uživatel na hlavní straně portletu klikne na tlačítko Moje naplánovaná docházka. 2. Systém mu zobrazí naplánovanou docházku na příští měsíc. 3. Uživatel může měnit rok a měsíc zobrazované naplánované docházky. Alternativní tok 1: Uživatel nemá ve vybraném období naplánovanou docházku. 2.1 Uživatel vidí v přehledu docházky pouze řádky s údaji Den a Datum. Podmínky dokončení: Systém zobrazí Uživateli naplánovanou docházku. Tabulka A.30: Zobrazení naplánované docházky ostatních Uživatelů. Krátký popis: Use case popisující plánování docházky Administrátorem. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen v portálu, Administrátor má autentizovaný přístup do Systému (portletu). Administrátor má spuštěný Systém. Základní tok: 1. Administrátor na hlavní straně Systému klikne na tlačítko Plánování docházky. 2. Systém mu zobrazí naplánovanou docházku na příští měsíc pro vybraného zaměstnance. 3. Administrátor může měnit rozsah zobrazované naplánované docházky. Alternativní tok1: Úředník nemá ve vybraném období naplánovanou docházku. 2.1 Administrátorovi se zobrazí v tabulce docházky pro každý den bez zadané docházky údaje : Den, Datum. Ostatní položky jsou prázdné. Podmínky dokončení: Zobrazení tabulky s docházkou. 90

96 A. Popisy diagramů užití Tabulka A.31: Vytvoření a editace naplánované docházky. Krátký popis: Use case umožňující editovat naplánovanou docházku. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen v portálu. Administrátor má autentizovaný přístup do Systému (portletu). Administrátor má spuštěný Systém. Základní tok: 1. Administrátor si zobrazí docházku podle use case Zobrazení naplánované docházky ostatních Uživatelů. 2. Systém zobrazí buď již naplánovanou docházku nebo řádky ve formátu: Den, Datum přičemž ostatní položky na řádku jsou prázdné. 3. Administrátor zadá docházku Administrátor může zadat docházku pro první den v měsíci a stisknout tlačítko Zkopírovat první řádek všude. Všechny položky kromě Den a Datum se zkopírují do všech dalších řádků Administrátor může dvakrát kliknout na řádek docházky a údaje editovat ručně jejich přepsáním (např: přidat dovolenou). 4. Administrátor docházku uloží tlačítkem Uložit změny v docházce. 5. Systém změny v docházce uloží. 6. Systém zobrazí zprávu o úspěšném uložení docházky. Alternativní tok: Podmínky dokončení: Uložení změn v naplánované docházce. Tabulka A.32: Přehled docházky Uživatele. Krátký popis: Use case ukazující zobrazení přehledu docházky vybraného Uživatele. Aktéři: - Administrátor - Systém 91

97 A. Popisy diagramů užití Podmínky pro spuštění: Administrátor je přihlášen v portálu. Administrátor má spuštěný Systém (portlet). Administrátor má autentizovaný přístup do Systému. Základní tok: 1. Administrátor na hlavní straně portletu klikne na tlačítko Přehled docházky. 2. Administrátor vybere jméno Uživatele ze seznamu jmen Uživatelů, vybere období za které má být docházka zobrazena. 3. Systém Administrátorovi zobrazí docházku vybraného Uživatele. 4. Administrátor může poklepáním na údaj z tabulky údaj editovat. Alternativní tok: Podmínky dokončení: Zobrazení docházky vybraného Uživatele. Tabulka A.33: Schválení docházky Krátký popis: Use case ukazující schválení docházky vybraného Uživatele. Aktéři: - Administrátor - Systém - Personální a mzdový systém Podmínky pro spuštění: Administrátor je přihlášen v portálu. Administrátor má spuštěný Systém (portlet). Administrátor má autentizovaný přístup do Systému. Základní tok: 1. Administrátor si zobrazí docházku podle use case Zobrazení docházky Uživatele. 2. Administrátor klikne na tlačítko Schválit u každé položky docházky. 3. Systém postoupí schválenou docházku do Personálního a mzdového systému. Alternativní tok1: Editace docházky 1.1. Administrátor dvakrát klikne na položku docházky a edituje příchod/odchod/důvod nepřítomnosti Administrátor zmáčkne tlačítko Uložit změny v docházce a Systém uloží provedené změny. Nově editovaná docházka se zobrazí v Systému. Pokračování bodem 1 základního toku. Podmínky dokončení: Schválení docházky vybraného Uživatele. 92

98 A. Popisy diagramů užití A.6 Kalendář - popis Tabulka A.34: Vytvoření události Krátký popis: Use case zobrazující vytvoření události v Kalendáři. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do Systému. Uživatel je vlastník kalendáře nebo mu je nasdílen. Základní tok: 1. Uživatel si zobrazí hlavní stranu Systému. 2. Uživatel si zobrazí kalendář, do kterého chce událost zapsat, zaškrtnutím kalendáře v tabulce dostupných kalendářů. Kalendářů může Uživatel zaškrtnout více. 3. Uživatel zapíše událost do kalendáře tak, že tahem vyznačí rozsah události. 4. Systém zobrazí rozhraní, kde Uživatel může vložit popisek, název události, odkaz na požadavek v Service desk nebo editovat rozsah události. 5. Uživatel může sdílet událost mezi ostatními Uživateli. 6. Uživatel události uloží. 7. Systém zobrazí událost ve vybraném kalendáři. Alternativní tok 1: Rezervace místnosti 1. Uživatel si vybere kalendář místnosti, kterou chce rezervovat. 2. Uživatel vybere datum, čas a název události, může přidat poznámku nebo odkaz na požadavek v Service desk. 3. Uživatel uloží událost do kalendáře. 4. Systém zobrazí událost ve vybraném kalendáři. 93

99 A. Popisy diagramů užití Alternativní tok 2: Vytvoření události v kalendáři viditelném z webové stránky úřadu. 1. Uživatel si vybere kalendář, který je veřejně přístupný z webu úřadu. 2. Uživatel vybere datum, čas a název události, může přidat poznámku nebo odkaz na webovou stránku. 3. Uživatel uloží událost do kalendáře. 4. Systém zobrazí událost ve vybraném kalendáři. Podmínky dokončení: Úspěšné uložení události a její zobrazení v kalendáři Tabulka A.35: Vytvoření kalendáře Krátký popis: Use case umožňující vytvořit nový kalendář. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do systému. Základní tok: 1. Uživatel na hlavní straně portletu klikne na Vytvořit nový kalendář. 2. Uživatel do políčka název zadá název kalendáře. 3. Uživatel klikne na Uložit. 4. Systém uloží kalendář, jako vlastník se určí Uživatel, který kalendář vytvořil. Alternativní tok1: Kalendář Uživatele se stejným názvem už existuje Systém zobrazí chybovou zprávu o existenci kalendáře se stejným názvem. Pokračování bodem 2 základního toku. Podmínky dokončení: Vytvoření nového kalendáře. 94

100 A. Popisy diagramů užití Tabulka A.36: Zobrazení události Krátký popis: Use case popisující zobrazení události. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do Systému. Uživatel je vlastník kalendáře nebo mu je nasdílen. Základní tok: 1. Uživatel klikne na tlačítko Detail události v události v kalendáři zobrazeném na hlavní straně portletu. 2. Systém Uživateli zobrazí detail události. Zobrazené atributy budou název události, text události, datum a čas události a případně odkaz do Service desk. Alternativní tok: Podmínky dokončení: Zobrazení události. Tabulka A.37: Editace události Krátký popis: Use case umožňující editovat už existující události. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do systému. Uživatel je vlastník kalendáře, kde je událost zobrazena, nebo mu je nasdílen. Základní tok: 1. Uživatel zobrazí událost podle use case Zobrazení události 2. Uživatel klikne na tlačítko Editovat. 3. Uživatel provede editaci a uloží ji tlačítkem Uložit. 4. Systém změny uloží. Alternativní tok: 95

101 A. Popisy diagramů užití Podmínky dokončení: Uložení změny Tabulka A.38: Odstranění události Krátký popis: Use case umožňující odstranit existující události Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do Systému. Uživatel je vlastník kalendáře nebo mu je nasdílen. V kalendáři je alespoň jedna událost. Základní tok: 1. Uživatel zobrazí událost podle use case Zobrazení události. 2. Uživatel klikne na tlačítko Smazat. 3. Systém událost odstraní z kalendáře. Alternativní tok: Podmínky dokončení: Odstranění události. Tabulka A.39: Přejmenování kalendáře Krátký popis: Use case umožňující přejmenování již vytvořeného kalendáře Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do portletu. Uživatel je vlastník kalendáře nebo mu je nasdílen. 96

102 A. Popisy diagramů užití Základní tok: 1. Uživatel provede use case Zobrazení kalendáře. 2. Uživatel poklepe na název kalendáře v seznamu dostupných kalendářů. 3. Uživatel napíše nové jméno kalendáře a stiskne Enter. 4. Systém změny uloží. Alternativní tok: Podmínky dokončení: Uložení nového jména kalendáře. Tabulka A.40: Sdílení události Krátký popis: Use case umožňující sdílet již vytvořenou událost s dalšími Uživateli. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel má autentizovaný přístup do portletu. Uživatel je vlastník kalendáře, kde je alespoň jedna událost, nebo mu je nasdílen. Základní tok: 1. Uživatel si zobrazí událost podle use case Zobrazení události 2. Uživatel tlačítkem Sdílet zobrazí okno, kde vybere Uživatele, kterým chce události sdílet. Pokud už s Uživatelem událost sdílel, může sdílení zrušit kliknutím na křížek u jména uživatele. 3. Uživatel potvrdí výběr tlačítkem OK. 4. Systém nasdílí událost do kalendářů vybraných Uživatelů. 5. Systém rozešle Uživatelům informační o nasdílení události. Alternativní tok: Podmínky dokončení: Nasdílení události Uživatelům. 97

103 A. Popisy diagramů užití Tabulka A.41: Zobrazení kalendáře Krátký popis: Use case popisující zobrazení kalendáře Uživatele. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má otevřený Systém (portlet), Uživatel má autentizovaný přístup do systému. Uživatel je vlastník kalendáře nebo mu je nasdílen. Základní tok: 1. Uživatel si zobrazí základní obrazovku v rámci základní obrazovky jsou zobrazeny kalendáře jejichž je vlastníkem nebo je má nasdílené. 2. Uživatel zaškrtnutím políčka u názvu kalendáře vybere k zobrazení konkrétní kalendář. Alternativní tok: Podmínky dokončení: Zobrazení kalendáře. Tabulka A.42: Sdílení kalendáře Krátký popis: Use case umožňující Uživateli sdílet jeho kalendář s dalšími Uživateli. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do Systému, Uživatel má spuštěný Systém (portlet), Uživatel je vlastníkem kalendáře, Uživatel má vytvořený alespoň jeden kalendář. 98

104 A. Popisy diagramů užití Základní tok: 1. Uživatel provede use case Zobrazení kalendáře. 2. Uživatel vybere kalendář kliknutím na křížek u kalendáře v seznamu kalendářů 3. Uživatel tlačítkem Sdílet zobrazí okno, kde vybere Uživatele, kterým chce události sdílet. Pokud už s někým kalendář sdílel, může ho odebrat kliknutím na křížek u jeho jména. 4. Uživatel po ukončení výběru potvrdí výběr tlačítkem OK. 5. Systém nasdílí událost do kalendářů vybraných Uživatelů. 6. Systém rozešle Uživatelům informační o nasdílení události. Alternativní tok: Podmínky dokončení: Nasdílení kalendáře vybraným Uživatelům. Tabulka A.43: Smazání kalendáře Krátký popis: Use case umožňující Uživateli smazat kalendář. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má spuštěný Systém (portlet), Uživatel je vlastníkem kalendáře, Uživatel má vytvořený alespoň jeden kalendář. Základní tok: 1. Uživatel provede use case Zobrazení kalendáře. 2. Uživatel vybere kalendář kliknutím na křížek u kalendáře v seznamu kalendářů 3. Uživatel klikne na tlačítko Smazat. 4. Systém odstraní vybraný kalendář Uživateli a všem dalším Uživatelům, kterým byl nasdílen. Alternativní tok: Podmínky dokončení: Nasdílení kalendáře vybraným Uživatelům. 99

105 A. Popisy diagramů užití A.7 Úřední deska - popis Tabulka A.44: Vytvoření a zveřejnění příspěvku Krátký popis: Use case zobrazující příspěvek na Úřední desce. Aktéři: - Uživatel - Systém - Archiv - Veřejná část Úřední desky Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu). Uživatel má spuštěný Systém. Základní tok: 1. Uživatel otevře rozhraní Systému. Klikne na Vytvořit příspěvek. 2. Uživatel vloží nový příspěvek a může připojit přílohy (dokumenty nebo obrázky z DMS/ Elektronické spisové služby). Uživatel nastaví datum a čas zveřejnění příspěvku a datum a čas exspirace. 3. Uživatel klikne na Uložit. 4. Systém příspěvek uloží. 5. Jakmile nadejde datum a čas zveřejnění příspěvku, Systém příspěvek zveřejní ve Veřejné části Úřední desky. 6. Systém po uběhnutí doby exspirace příspěvek stáhne z Veřejné části Úřední desky a archivuje. Alternativní tok: Podmínky dokončení: Zobrazení příspěvku na Úřední desce a jeho exspirace po uplynutí dané lhůty. Tabulka A.45: Přehled příspěvků na Úřední desce Krátký popis: Use case zobrazující příspěvky na Úřední desce. Aktéři: - Občan - Uživatel - Systém 100

106 A. Popisy diagramů užití Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel si zobrazí základní obrazovku systému. 2. Systém v ní zobrazí aktuální příspěvky. 3. Uživatel kliknutím na příspěvky uvidí detail příspěvku. Alternativní tok 1: Zobrazení Úřední desky občanem 1. Občan si zobrazí veřejně dostupnou část Úřední desky, kde může procházet jednotlivé zveřejněné příspěvky. Kliknutím na příspěvek, Systém zobrazí detail příspěvku a odkaz na připojené přílohy. Podmínky dokončení: Zobrazení příspěvků na Úřední desce. Tabulka A.46: Editace příspěvku Krátký popis: Use case umožňující editaci příspěvku na Úřední desce Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel si zobrazí detail příspěvku podle use case Zobrazení příspěvku 2. Uživatel klikne na Editovat příspěvek. 3. Systém zobrazí editační rozhraní. 4. Uživatel upraví text/přílohy příspěvku. 5. Uživatel úpravy uloží tlačítkem Uložit. 6. Systém uloží editaci. Alternativní tok: Podmínky dokončení: Uložení editace příspěvku. 101

107 A. Popisy diagramů užití Tabulka A.47: Odstranění příspěvku Krátký popis: Use case popisující odstranění příspěvku ještě před exspirací. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel si zobrazí hlavní stranu portletu. 2. Uživatel vybere z nabídky příspěvek a klikne na Smazat. 3. Systém zobrazí dialogové okno a vyžádá si od Uživatele potvrzení. 4. Uživatel potvrdí odstranění příspěvku. 5. Po potvrzení odstranění, Systém odstraní příspěvek. Alternativní tok: Podmínky dokončení: Odstranění příspěvku. A.8 Systém pro definování workflow Tabulka A.48: Tvorba workflow Krátký popis: Use case popisující tvorbu workflow. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen do portálu, Administrátor má spuštěný Systém (portlet). Základní tok: 1. Administrátor spustí Systém. 2. Administrátor klikne na tlačítko Přidat workflow. 3. Administrátor v nabídnutém grafickém rozhraní nakliká požadované workflow a uloží ho. 4. Systém workflow uloží. 102

108 A. Popisy diagramů užití Alternativní tok: Podmínky dokončení: Vytvoření nového workflow. Tabulka A.49: Editace workflow Krátký popis: Use case popisující editace vytvořeného workflow. Aktéři: - Administrátor - Systém Podmínky pro spuštění: Administrátor je přihlášen do portálu, Administrátor má spuštěný Systém (portlet). V Systému je zavedeno alespoň jedno workflow. Základní tok: 1. Administrátor klikne na Editovat workflow na hlavní obrazovce systému. 2. Systém mu zobrazí seznam vytvořených workflow. Úředník vybere ze seznamu vytvořených workflow to, které chce editovat. 3. Systém zobrazí workflow v editačním WYSIWYG rozhraní. 4. Administrátor provede editace a klikne na Uložit. 5. Systém workflow uloží. Změny ve workflow se promítnou do všech portletů, kde je workflow přiřazeno. Alternativní tok: Podmínky dokončení: Uložení editací ve workflow. Tabulka A.50: Odstranění workflow Krátký popis: Use case popisující odstranění vytvořeného workflow. Aktéři: - Administrátor - Systém 103

109 A. Popisy diagramů užití Podmínky pro spuštění: Administrátor je přihlášen do portálu, Administrátor má spuštěný Systém (portlet). V Systému je zavedeno alespoň jedno workflow. Základní tok: 1. Administrátor klikne na tlačítko Odstranit workflow. 1. Systém mu zobrazí seznam workflow v systému. Administrátor vybere ze seznamu vytvořených workflow to, které chce odstranit. 2. Administrátor klikne na tlačítko Odstranit. 3. Systém workflow odstraní. Pokud je workflow přiřazeno k portletu, je zobrazeno chybové hlášení a operace neproběhne. Administrátor musí nejprve odebrat workflow ze všech portletů. Alternativní tok: Podmínky dokončení: Odstranění workflow. Tabulka A.51: Přiřazení workflow Krátký popis: Use case popisující přiřazení existujícího workflow k portletu Aktéři: - Systém - Administrátor Podmínky pro spuštění: Administrátor je přihlášen do portálu, Administrátor má spuštěný portlet. Existuje alespoň jeden portlet, kterému může být přiřazeno defaultní workflow. Existuje alespoň jedno workflow, které může být přiřazeno k portletu. Základní tok: 1. Administrátor na hlavní straně vybere odbor úřadu, k jehož portletům bude přiřazovat workflow. Z roletkového menu u portletu vybere workflow, které chce k portletu přiřadit. Pokud chce přiřadit další workflow, kromě již existujícího, klikne na tlačítko + u portletu. 2. Administrátor svoji volbu uloží pomocí tlačítka Uložit. 3. Systém workflow přiřadí k portletu. Alternativní tok: Podmínky dokončení: Přiřazení workflow k portletu. 104

110 A. Popisy diagramů užití A.9 DMS Tabulka A.52: Vytvoření dokumentu Krátký popis: Use case popisující vytvoření dokumentu Uživatelem. Aktéři: - Uživatel - Systém - Microsoft office Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel klikne na tlačítko Vytvořit dokument na hlavní obrazovce Systému 2. Systém zobrazí menu, kde Uživatel vybere typ dokumentu. 3. Systém zobrazí prázdný dokument otevřený v programu z kancelářského balíků Microsoft Office 4. Uživatel vyplní dokument podle svého uvážení. 5. Uživatel klikne na Uložit dokument. 6. Uživatel vyplní název a z nabídky vybere umístění dokumentu. 7. Systém dokument uloží na vybranou pozici. Alternativní tok1: V složce existuje dokument se stejným názvem Systém zobrazí Uživateli oznámení o již existujícím dokumentu se stejným názvem. Na výběr je buď přepsat starý dokument nebo změnit jméno nového dokumentu Uživatel vybere akci a případně vloží nové jméno Systém v závislosti na vybrané akci buď dokument přejmenuje nebo dokument uloží na vybranou pozici a starý přepíše. Podmínky dokončení: Vytvoření nového dokumentu. Tabulka A.53: Zobrazení dokumentu Krátký popis: Use case popisující zobrazení dokumentů 105

111 A. Popisy diagramů užití Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel má zobrazené jím vytvořené nebo jemu nasdílené dokumenty na hlavní straně Systému. 2. Uživatel kliknutím na název dokumentu otevře dokument. 3. Systém Uživateli zobrazí dokument v programu odpovídající typu dokumentu. Alternativní tok1: Dokument je v jiné složce 1. Uživatel vybere složku v seznamu dostupných složek a kliknutím na ni si zobrazí její obsah. Pokračování bodem 1 základního toku. Podmínky dokončení: Zobrazení dokumentu. Tabulka A.54: Editace dokumentů Krátký popis: Use case popisující editaci dokumentů v DMS. Aktéři: - Uživatel - Systém - MS Office Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel zobrazí dokument podle use case Zobrazení dokumentu. 2. Uživatelovi se zobrazí dokument a editační rozhraní v programu z kancelářského balíku MS Office. 3. Uživatel provede editaci. 4. Uživatel změny uloží tlačítkem Uložit. 5. Systém dokument uloží. Alternativní tok: 106

112 A. Popisy diagramů užití Podmínky dokončení: Uložení editací provedených Uživatelem. Tabulka A.55: Odstranění dokumentu Krátký popis: Use case popisující odstranění dokumentu ze Systému. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Uživatel je vlastníkem dokumentu. Základní tok: 1. Uživatel má zobrazené jím vytvořené nebo jemu nasdílené dokumenty na hlavní straně Systému. 2. Uživatel označí ten, který chce smazat a klikne na tlačítko Smazat. 3. Systém zobrazí žádost o potvrzení odstranění dokumentu. Uživatel klikne na OK a dokument se odstraní. Alternativní tok: Podmínky dokončení: Odstranění dokumentu Tabulka A.56: Připojení workflow k dokumentu Krátký popis: Use case popisující připojení workflow k již existujícímu dokumentu Aktéři: - Uživatel - Systém - Systém pro definici workflow Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Systém pro definici workflow obsahuje alespoň jedno workflow připojitelné k dokumentu. 107

113 A. Popisy diagramů užití Základní tok: 1. Uživatel má zobrazené jím vytvořené nebo jemu nasdílené dokumenty na hlavní straně Systému. 2. Uživatel označí ten, ke kterému chce připojit workflow a klikne na tlačítko Připojit workflow. 3. Systém zobrazí seznam workflow, které Uživatel může připojit k dokumentu a výběr potvrdí tlačítkem OK. 4. Systém přiřadí k dokumentu workflow a dále s ním pracuje podle něj. Alternativní tok: Podmínky dokončení: Odstranění dokumentu Tabulka A.57: Nahrání dokumentu Krátký popis: Use case umožňující nahrání externího dokumentu do Systému. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Základní tok: 1. Uživatel klikne na tlačítko Nahrát dokument na hlavní obrazovce Systému. 2. Systém zobrazí menu, kde Uživatel vybere dokument ze zdroje dokumentů (např.: externí disk) 3. Uživatel vybere složku, kam se dokument nahraje. 4. Systém dokument uloží na vybranou pozici. Alternativní tok: Podmínky dokončení: Nahrání externího dokumentu. 108

114 A. Popisy diagramů užití Tabulka A.58: Sdílení dokumentů Krátký popis: Use case umožňující sdílení dokumentů ostatním Uživatelům. Aktéři: - Uživatel - Systém Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Uživatel je tvůrce dokumentu nebo mu byl dokument nasdílen. Základní tok: 1. Uživatel má zobrazené jím vytvořené nebo jemu nasdílené dokumenty na hlavní straně Systému. 2. Uživatel označí ten, který chce sdílet a klikne na tlačítko Sdílet. 3. Systém mu zobrazí seznam Uživatelů, se kterými dokument už sdílí. 4. Uživatel klikne na tlačítko Přidat další. 5. Systém zobrazí Uživatelovi ostatní Uživatele, se kterými může dokument sdílet. 6. Uživatel vybere kliknutím na jejích jména Uživatele, se kterými chce sdílet a potvrdí výběr tlačítkem OK. 7. Systém rozešle upozornění o nasdílení dokumentu vybraným Uživatelům na . Alternativní tok1: Odstranění sdílení. 3. Uživatel může zrušit sdílení dokumentu kliknutím na křížek u jména Uživatele. Podmínky dokončení: Nasdílení dokumentu vybraným Uživatelům. Tabulka A.59: Zobrazení dokumentu na portletu Úřední deska Krátký popis: Use case zobrazující dokument na Úřední desce. Aktéři: - Uživatel - Archiv - Systém - Úřední deska 109

115 A. Popisy diagramů užití Podmínky pro spuštění: Uživatel je přihlášen do portálu, Uživatel má autentizovaný přístup do Systému (portletu), Uživatel má spuštěný Systém. Uživatel je tvůrce dokumentu nebo mu byl dokument nasdílen. Základní tok: 1. Uživatel má zobrazené jím vytvořené nebo jemu nasdílené dokumenty na hlavní straně Systému. 2. Uživatel zaškrtne dokument na hlavní straně portletu. 3. Uživatel klikne na tlačítko Publikovat na ÚD. 4. Systém mu zobrazí rozhraní, kde Uživatel může vložit popis k dokumentu a nastavení data exspirace. 5. Uživatel nastaví popis a datum exspirace. 6. Zpráva se i s přílohou zobrazí na Úřední desce. Alternativní tok: Podmínky dokončení: Zobrazení zprávy na portletu Úřední deska a její expirace po uplynutí dané lhůty. 110

116 B Návrhy obrazovek portletů Obrázek B.1: SERVICE DESK Hlavní strana portletu Service Desk. Obrázek B.2: SERVICE DESK Návrh obrazovky pro Tabulku A.5 (příloha A) Zobrazení požadavku v případě, že si ho zobrazí uživatel. 111

117 B. Návrhy obrazovek portletů Obrázek B.3: SERVICE DESK Návrh obrazovky pro Tabulku A.5 (příloha A) Zobrazení požadavku v případě, že ho zobrazí administrátor. Obrázek B.4: SERVICE DESK Návrh obrazovky detailu požadavku pro Tabulku A6 (příloha A) Vrátit vyřešení požadavek zpět k řešení. 112

118 B. Návrhy obrazovek portletů Obrázek B.5: SERVICE DESK Návrh obrazovky pro Tabulku A.1 (příloha A) Vložení nového požadavku. Jedná se o veřejně dostupné rozhraní umístěné na webové stránce úřadu. Obrázek B.6: SERVICE DESK Návrh obrazovky pro Tabulku A.1 (příloha A) Vložení nového požadavku. Rozhraní je dostupné pro uživatele portálu. 113

119 B. Návrhy obrazovek portletů Obrázek B.7: SERVICE DESK Návrh obrazovky pro Tabulku A.2 (příloha A) Vyhledání požadavku podle ID nebo klíčových slov. Obrázek B.8: ÚKOLNÍK Návrh hlavní strany portletu Úkolník. 114

120 B. Návrhy obrazovek portletů Obrázek B.9: ÚKOLNÍK Návrh zobrazení detailu úkolu podle Tabulky A.12 (příloha A) Zobrazení úkolu. Obrázek B.10: ÚKOLNÍK Návrh nastavení Úkolníku podle tabulky A.17 (příloha A) Nastavení 115

121 B. Návrhy obrazovek portletů Obrázek B.11: MANAŽERSKÝ IS Návrh hlavní strany portletu Manažerský IS. Obrázek B.12: MANAŽERSKÝ IS Návrh obrazovky pro Tabulku A.20 (příloha A) Zobrazení statistik. 116

122 B. Návrhy obrazovek portletů Obrázek B.13: MANAŽERSKÝ IS Návrh obrazovky pro Tabulku A.22 (příloha A) Správa statistik. Obrázek B.14: DOHLED NAD PŘÍSPĚVKOVÝMI ORGANIZACEMI Návrh hlavní strany portletu Dohled na příspěvkovými organizacemi. 117

123 B. Návrhy obrazovek portletů Obrázek B.15: DOHLED NAD PŘÍSPĚVKOVÝMI ORGANIZACEMI Návrh obrazovky pro zobrazení stránky Zápisy a závěrečné zprávy organizace Obrázek B.16: DOHLED NAD PŘÍSPĚVKOVÝMI ORGANIZACEMI Návrh obrazovky pro zobrazení stránky Rozpočet organizace. 118

124 B. Návrhy obrazovek portletů Obrázek B.17: DOHLED NAD PŘÍSPĚVKOVÝMI ORGANIZACEMI Návrh obrazovky pro zobrazení stranky Správa majetku organizace Obrázek B.18: DOHLED NAD PŘÍSPĚVKOVÝMI ORGANIZACEMI Zápisy a závěrečné zprávy organizace 119

125 B. Návrhy obrazovek portletů Obrázek B.19: DOCHÁZKA Návrh hlavní strany portletu Docházka, zobrazené pro uživatele podle tabulky A.28 (příloha A) Obrázek B.20: DOCHÁZKA Návrh hlavní strany portletu Docházka, zobrazené pro Administrátora podle Tabulky A.28 (příloha A) 120

126 B. Návrhy obrazovek portletů Obrázek B.21: DOCHÁZKA Návrh naplánované docházky uživatele podle Tabulky A.29 (příloha A) Moje naplánovaná docházka. Obrázek B.22: DOCHÁZKA Návrh plánování docházky administrátorem podle Tabulky A.30 (příloha A) Moje naplánovaná docházka. a A.31 Vytvoření a editace naplánované docházky. 121

127 B. Návrhy obrazovek portletů Obrázek B.23: DOCHÁZKA Návrh přehledu docházky uživatelů pro administrátora podle Tabulky A.32 (příloha A) Zobrazení docházky Uživatele. Obrázek B.24: KALENDÁŘ Návrh hlavní strany portletu Kalendář. 122

128 B. Návrhy obrazovek portletů Obrázek B.25: KALENDÁŘ Návrh zobrazení detailu události podle Tabulky A.36 (příloha A) Zobrazení události. Obrázek B.26: KALENDÁŘ Návrh vytvoření události podle Tabulky A.34 (příloha A) Vytvoření události 123

129 B. Návrhy obrazovek portletů Obrázek B.27: DMS Návrh hlavní strany portletu DMS. Obrázek B.28: ÚŘEDNÍ DESKA Návrh hlavní strany portletu Úřední deska. 124

130 B. Návrhy obrazovek portletů Obrázek B.29: ÚŘEDNÍ DESKA Návrh rozhraní pro vytvoření příspěvku podle tabulky Vytvoření příspěvku A.44 (příloha A) Obrázek B.30: ÚŘEDNÍ DESKA Návrh rozhraní portletu Úřední deska na webové stránce úřadu. 125