}w !"#$%&'()+,-./012345
M a s a ry kova u n i v e r z i ta Fa k u lta i n f o r m at i k y
Portál úředníka D i p l o m ová p r ác e
Bc. Vlasta Žáková
Brno, jaro 2014
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
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
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
Klíčová slova Portál úředníka, Liferay, IS veřejné správy, Portlety, UML, Návrh IS
v
Obsah Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Veřejná správa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Územní samospráva . . . . . . . . . . . . . . . . . . . . . . . 5 3 Strategie Smart Administration . . . . . . . . . . . . . . . . . 9 3.1 Implementace strategie Smart Administration . . . . . . . . . 10 3.2 Vnitřní integrace úřadu . . . . . . . . . . . . . . . . . . . . . 14 4 Portálové řešení Portálu úředníka . . . . . . . . . . . . . . . . 17 4.1 Podnikové portály . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.1 Porovnání jednotlivých portálových řešení . . . . . . . 21 4.1.2 Porovnání portálu z hlediska zastoupení na úřadech ČR 23 4.2 Portlety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5 Funkční požadavky na Portál úředníka . . . . . . . . . . . . 28 5.1 Portlety a integrované funkce portálu Liferay vyžadované v Portálu úředníka . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Nefunkční požadavky na Portál úředníka . . . . . . . . . . . . 36 6 Návrh portálu úředníka . . . . . . . . . . . . . . . . . . . . . . 37 6.1 Návrh Portálu úředníka v Liferay . . . . . . . . . . . . . . . . 38 6.2 Návrh portletů do Portálu úředníka . . . . . . . . . . . . . . 39 6.2.1 DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.2.2 Docházka . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.2.3 Dohled nad příspěvkovými organizacemi . . . . . . . . 47 6.2.4 Kalendář . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.5 Úřední deska . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.6 Service desk . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.7 Úkolník . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.2.8 Manažerský IS . . . . . . . . . . . . . . . . . . . . . . 59 6.2.9 Systém pro definování workflow . . . . . . . . . . . . . 61 7 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 A Popisy diagramů užití . . . . . . . . . . . . . . . . . . . . . . . 70 A.1 Service desk - popis . . . . . . . . . . . . . . . . . . . . . . . 70 A.2 Úkolník - popis . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.3 Manažerský IS - popis . . . . . . . . . . . . . . . . . . . . . . 83 A.4 Dohled nad příspevkovými organizacemi - popis . . . . . . . . 85 A.5 Docházka - popis . . . . . . . . . . . . . . . . . . . . . . . . . 89 A.6 Kalendář - popis . . . . . . . . . . . . . . . . . . . . . . . . . 93 A.7 Úřední deska - popis . . . . . . . . . . . . . . . . . . . . . . . 100 A.8 Systém pro definování workflow . . . . . . . . . . . . . . . . . 102 1 2
1
A.9 DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 B Návrhy obrazovek portletů . . . . . . . . . . . . . . . . . . . . 111
2
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 2015. 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
1 . Ú vo d 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
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
2 . V e ř e j n á s p r á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
2 . V e ř e j n á s p r áva Tabulka 2.1: Tabulka pravomocí ORP a kraje [56]
Oblast pravomocí
ORP
Kraje
Hasiči
Zřizování sboru dobrovolných hasičů obce 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í Mohou zřizovat jesle, obecní nemocnice a lékarny.
HZS kraje
Sociální služby
Zdravotnictví
Školství
Voda
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í a rušení ma- Zřizování nebo rušení teřských škol. Obec je středních škol, vyšších povinna zajistit pod- odborných škol, speciálmínky pro plnění po- ních škol, dětských dovinné školní docházky movů. dětí s místem trvalého pobytu na jejím území, z toho důvodu může založit základní školu. Řešení dodávek pitné Zřizování koupališť, řevody, kanalizace, čiš- šení povodňových plánů. tění odpadních vod a ochrany vod před znečištěním (např. čističkou vody).
7
2 . V e ř e j n á s p r áva Lesnictví
MHD
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. Zavedení není povinné.
Veřejná doprava
Na bázi dobrovolnosti.
Policie
Obecní (městská) policie. Nepovinné zřizování Zřizování příspěvkových příspěvkových organi- organizací, přidělování zací (knihovna, divadlo, dotací. kino).
Rybářsví
Odpady
Kultura
Tvoření koncepce systému a rozvíjení potřebné infrastruktury k nakládání s komunálními odpady. Řešení integrovaného dopravního systému kraje. Zajišťují veřejnou dopravu v kraji.
8
3 Strategie Smart Administration Struktura ICT veřejné správy je významně ovlivněna dokumentem Strategie Smart administration, který si na roky 2007- 2015 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n 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 2020. U těchto podání budou navíc údaje, které jsou už obsaženy v základních registrech nebo AIS1 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n 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žby2 , ∙ Identity management3 , ∙ DNS4 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
Negarantované úložiště nevyřízených a ne- povinné uzavřených spisů Garantované úložiště (eSpisovna) povinné Elektronická spisová služba povinné Vnitřní integrace úřadu povinné
ORP povinné nepovinné 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n
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 CzechPOINT, 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n 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ář, email, 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
3 . S t r at e g i e S m a rt A d m i n i s t r at i o n ∙ Centrální systémy eGovernmentu (základní registry, CzechPOINT, PVS atd.) ∙ Agendové informační systémy úřadu
16
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 email, 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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a 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í LDAP1 nebo Active directory2 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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a
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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a 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 DMS3 . Další výhodou je mnoho aplikací zaměřených na BPM4 . V této oblasti byla IBM označena společností Gartner jako lídr pro rok 2014. [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 LGPL5 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í WYSIWYG6 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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a 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 1996. [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] 4.1.1 Porovnání jednotlivých portálových řešení Tabulka 4.1: Porovnání portálových řešení
Liferay
IBM Web- Microsoft Sphere Sharepoint
Oracle Web- SAP Center Portal
Aktuální verze
Liferay 6.2
WebSphere 8.0.0.1
SharePoint 2013
Standard JSR-168 Standard JSR-268 WSRP 2.0
ok
ok
ok
ok
ok
ok
Založeno na .NET Založeno na .NET ok
Oracle Web- SAP Net Center Por- Weaver 7.4 tal 11g R1 ok ok ok ok
ok (od verze 7.2) ok 21
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a Funkcionalita Sociální v kostce API, portlety pro spolupráci a sdílení práce, podniková sociální síť. Velká, neustále se vyvíjející nabídka portletů. Tvorba apli- Otevřený kací a port- kód, tvorba letů uživa- portletů teli vyžaduje znalosti programování, ale je dobře zdokumentovaná. Cena Komerční Enterprise edice, Open Source Community edition.
Aplikační servery
Podpora pro správu workflow, automatizaci procesů v organizaci, spolupráce uživatelů, podpora IM
Portlety pro spolupráci, sociální sítě, business inteligence, business aplikace.
správa webových stránek, sociální aplikace, správa obsahu
Kolaborativní nástroje, správa workflow, správa informací z dalších SAP systémů.
WebSphere Portlet Factory (WYSIWYG tvorba portletů), IBM Portlet API
Kompozice portletů i bez znalosti programování.
WebCenter Framework pro vytváření vlastních portletů.
Bez znalosti technologií nejsou úpravy možné.
Processor Platba za value units uživatele (PVUs) pro + poplatek každé jádro za server. a každou Standardní kompoa Enterprise nentu řešení licence. zvlášť. Široce kom- WebSphere Windows patibilní Application server, Server Microsoft SQL server
Licence vá- Součástí zaná na pro- platformy cesor. SAP NetWeaver, není možné pořídit samostatně. Databázový server společnosti Oracle (Oracle WebLogic Server).
Součástí komplexní integrující platformy Netweaver.
22
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a Podporované Linux, Unix, Linux, Win- Windows platformy Window dows
Windows, Linux
Linux
4.1.2 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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a Nevyhraněné úřady 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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a 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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a
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 2008.
JSR 168 První ze dvou standardů přináší základní programovací model. Zabývá se architekturou portletu – podporuje architekturu MVC (ModelView-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
4 . P o rtá l ov é ř e š e n í P o rtá l u ú ř e d n í k a 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
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
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a
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 port- Nahraditelné letu v Liferay externí aplikací
Email Kalendář
ok ok
ok ok
Manažerský IS
ok
ok
Úřední deska
ok
ok
ok Calendar CE/Social Office Portal Statistics, Activity tracking Portlet chybí.
DMS
ok
ok
DMS portlet
Service desk
ok
ok
Portlet chybí.
Úkolník
ok
ok
Docházkový systém
ok
ok
Částečně My Workflow Tasks. Portlet chybí.
Dohled nad zřizovanými příspěvkovými organizacemi.
ok
ok
Portlet chybí.
Existují externí aplikace. Existují externí aplikace. Existují externí aplikace. Existují externí aplikace.
Existují externí aplikace.
29
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a 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
Součást Li- Nahraditelné feray (název externí portletu) aplikací
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
ok
ok
ok
ok
ok
ok
Social office, Contact center Web Form Existují externí aplikace. DMS/Wiki
ok
ok
BonitaBPM
ok
ok
Calendar
ok
ok
ok
ok
Kaleo Work- Existují flow externí aplikace. Portlet chybí.
ok
ok
PDF Viewer
Existují externí aplikace.
Existují externí aplikace.
30
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a Integrované portlety 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. Email Díky podpoře protokolu IMAP1 může emailová schránka agregovat poštu ze všech mailboxů uživatele. Podporuje integraci s Gmailem2 . 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 – email provozovaný společností Google
31
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a 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í BPM3 . 3. Bussiness process management
32
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a Formulářový systém 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 emailovou 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
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a 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 emailová 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
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a 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 (emailovou adresu), kam může občan poslat 35
5 . F u n kč n í p o ž a dav k y n a P o rtá l ú ř e d n í k a 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á)
Maximální čas telefonické odpovědi Pohotovostní čas odpovědi
4 hodiny nespecifikovaný
24 x 7 (365 dní v roce) 2 hodiny 1 hodina
36
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
6 . N áv r h p o rtá l u ú ř e d n í k a Organizace úřadu v portálu Liferay 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 email. 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. 6.2 6.4 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
6 . N áv r h p o rtá l u ú ř e d n í k a 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 UML1 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
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a 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] 6.2.1 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 6.10. 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
6 . N áv r h p o rtá l u ú ř e d n í k a 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. 6.2.2 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í. 6.11 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
6 . N áv r h p o rtá l u ú ř e d n í k a jsou rozepsány v příloze A a B diplomové práce.
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
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a 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
6.2.3 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
6 . N áv r h p o rtá l u ú ř e d n í k a
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. 6.16
Obrázek 6.16: Návrh hlavní obrazovky portletu Dohled nad příspěvkovými organizacemi
48
6 . N áv r h p o rtá l u ú ř e d n í k a 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. 6.18 6.2.4 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
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a
Obrázek 6.20: Návrh hlavní obrazovky portletu Kalendář
6.2.5 Úř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
6 . N áv r h p o rtá l u ú ř e d n í k a Návrh hlavní obrazovky portletu Úřední deska 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
6 . N áv r h p o rtá l u ú ř e d n í k a
Obrázek 6.23: Diagram tříd pro portlet Úřední deska
Obrázek 6.24: Sekvenční diagram pro portlet Úřední deska
6.2.6 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
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a
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. 6.2.7 Ú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. Klik55
6 . N áv r h p o rtá l u ú ř e d n í k a
Obrázek 6.27: Diagram tříd pro portlet Service desk
Obrázek 6.28: Sekvenční diagram pro portlet Service desk
56
6 . N áv r h p o rtá l u ú ř e d n í k a
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
6 . N áv r h p o rtá l u ú ř e d n í k a Diagram tříd pro portlet Úkolník 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
6 . N áv r h p o rtá l u ú ř e d n í k a
Obrázek 6.32: Sekvenční diagram pro portlet Úkolník
6.2.8 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
6 . N áv r h p o rtá l u ú ř e d n í k a Návrh hlavní obrazovky pro Manažerský IS 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
6 . N áv r h p o rtá l u ú ř e d n í k a
Obrázek 6.35: Diagram tříd pro portlet Manažerský IS
Obrázek 6.36: Sekvenční diagram pro portlet Manažerský IS
6.2.9 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
6 . N áv r h p o rtá l u ú ř e d n í k a Aktuálně je požadavek na workflow explicitně zmíněn pouze při oběhu dokumentů v DMS. 6.37
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
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
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
Literatura [1] Zákon č. 2/1969 Sb., o zřizení ministerstev a jiných ústř. orgánů státní správy ČR. 1969. [2] Zákon č. 347/1997 Sb., o vytvoření vyšších územních samosprávných celků. 1997. [3] Vyhláška č. 496/2004 Sb., o elektronických podatelnách. 2000. [4] Zákon č. 128/2000 Sb., o obcích. 2000. [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ů. 2000. [6] Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů. 2004. [7] Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů. 2008. [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ů. 2009. [9] Zákon č. 111/2009 Sb., o základních registrech. 2009. [10] Předpis č. 259/2012 Sb.,Vyhláška o podrobnostech výkonu spisové služby. 2012. [11] ABDELNUR, A. a S. HEPPER: JSR 168: Java Portlet Specification, version 1.0. online, 2003, [cit. 30. 4. 2014]. URL https://www.jcp.org/en/jsr/detail?id=168 [12] AREVOLO, W.: The Future of Portals. Gartner, 2007. [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, 2010. [14] DigitSmith Embroidery and Screen Printing: Ecommerce definition and types of ecommerce. online, [cit. 30. 4. 2014]. URL http://www.digitsmith.com/ecommerce-definition.html 65
L i t e r at u r a [15] DVOŘÁK, V.: Teoretické principy sociální správy - Správa, veřejná správa a samospráva. online, [cit. 30. 4. 2014]. URL http://eamos.pf.jcu.cz/amos/ksb/externi/ksb_7434/1.htm [16] EUNICE CONSULTING a.s: Studie proveditelnosti pro projekt ’Rozvoj služeb eGovernmentu v krajích’ Zlínský kraj. Praha, 2010. [17] EUNICE CONSULTING a.s: Studie proveditelnosti pro projekt „Vnitřní integrace úřadu a integrace s ISVS Olomouckého kraje. Praha, 2010. [18] FOWLER, M.: UML Distilled: A Brief Guide to the Standard Object Modeling Language. 3. edition. Addison-Wesley Professional, 2003. [19] Gartner: Magický kvadrant horizontálních portálu. online, 2013, [cit. 30. 4. 2014]. URL http://www.gartner.com/technology/reprints.do?id= 1-1KH0XVB&ct=130917&st=sg&submissionGuid=3f51a4b3-729d4b30-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á, 2010. [21] HEPPER, S.: JSR 286: Java Portlet Specification, version 2.0. online, 2008, [cit. 30. 4. 2014]. URL http://www.ibm.com/developerworks/websphere/library/ 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. 30. 4. 2014]. URL http://www.ibm.com/developerworks/websphere/library/ techarticles/0803_hepper/0803 [23] International Business Machines Corporation (IBM): WebSphere Portal family. online, [cit. 30. 4. 2014]. URL http://www-03.ibm.com/software/products/en/websphereportal-family [24] International Business Machines Corporation (IBM): WebSphere Portal Version 8.0.0.1 Reviewer’s Guide. United States of America: IBM Corporation, 2013. [25] Jihomoravský kraj: Studie proveditelnosti pro projekt „Vnitřní integrace úřadu a integrace s ISVS Jihomoravského kraje. Brno, 2010. 66
L i t e r at u r a [26] KROTKÝ, J.: Vnitřní integrace úřadu Kraje Vysočina dokončena. online, 2013, [cit. 30. 4. 2014]. URL http://www.kr-vysocina.cz/vnitrni-integrace-uradukraje-vysocina-dokoncena/d-4048890/p1=1013 [27] Královéhradecký kraj: Komplexní integrace Krajského úřadu Královéhradeckého kraje. Hradec Králové, 2013. [28] Liferay Inc.: Liferay Portal Enterprise Subscription, Service Levels Liferay. online, [cit. 30. 4. 2014]. URL http://www.liferay.com/products/liferay-portal/ee/ service-levels [29] Liferay Inc.: Liferay Portal Overview. online, [cit. 30. 4. 2014]. URL http://www.liferay.com/products/liferay-portal [30] LÁTAL, J.: Studie proveditelnosti v rámci projektu „Technologické centrum ORP Děčín – Vnitřní integrace úřadu. Česká Lípa, 2010. [31] Magistrát statutárního města Chomutov: Implementace rozvoje služeb eGovernmentu – statutární město Chomutov. Chomutov, 2011. [32] Marbes Consulting: Uživatelská příručka ePusa. Praha, 2011. [33] Microsoft: Co je SharePoint? online, [cit. 30. 4. 2014]. URL http://office.microsoft.com/cs-cz/sharepointfoundation-help/co-je-sharepoint-HA010378184.aspx [34] Microsoft: SharePoint Software Requirements. online, [cit. 30. 4. 2014]. URL http://technet.microsoft.com/en-us/library/cc262485(v= office.15).aspx [35] Ministerstvo vnitra ČR: czechPOINT. [cit. 30. 4. 2014]. URL http://www.czechpoint.cz/ [36] Ministerstvo vnitra ČR: Implementace Strategie Smart Administration. online, [cit. 30. 4. 2014]. URL http://www.smartadministration.cz/clanek/implementacestrategie-smart-administration-implementace-strategiesmart-administration.aspx [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, 2003. 67
L i t e r at u r a [38] Ministerstvo vnitra ČR: EFEKTIVNÍ VEŘEJNÁ SPRÁVA A PŘÁTELSKÉ VEŘEJNÉ SLUŽBY: Strategie realizace Smart Administration v období 2007–2015. 2006. [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, 2008. [40] Ministerstvo vnitra ČR: Informační systém datových schránek, základní informace. Praha, 2009. [41] Ministerstvo vnitra ČR: Vnitřní integrace úřadu, Typizovaný projekt. Praha, 2009. [42] Ministerstvo vnitra ČR: Aktuální stav projektu DMVS Ministerstvo vnitra, Sekce veřejné správy a eGovernmentu. Praha, 2012. [43] Ministerstvo vnitra ČR: Strategický rámec rozvoje eGovernmentu 2014+. Praha, 2012. [44] Moravskoslezský kraj, Krajský úřad, odbor informatiky: Návrh technické specifikace ’Vnitřní integrace úřadu’ Moravskoslezský kraj. Ostrava, 2010. [45] Moravskoslezský kraj, Krajský úřad, odbor informatiky: STRATEGIE E-GOVERNMENT SLUŽEB V MORAVSKOSLEZSKÉM KRAJI. Ostrava, 2010. [46] Moravskoslezský kraj, Krajský úřad, odbor informatiky: Datové sklady SW Technologie a metadatový systém, Datová tržiště ekonomiky, Školství, statistiky, zdravotnictví. Ostrava, 2013. [47] Pardubický kraj: Vnitřní integrace úřadu a integrace s ISVS. 2013. [48] PATIL, S.: What Is a Portlet? online, 2005, [cit. 30. 4. 2014]. URL http://oreilly.com/pub/a/java/archive/what-is-aportlet.html?page=1 [49] ROGERS, Y., H. SHARP, a J. PREECE: Interaction design: Beyond human-computer interaction (3rd edition). Chichester, 2011. [50] RPSC ideas s.r.o.: Studie proveditelnosti. Přerov, 2010. [51] RÁKOSOVÁ, S. a P. ROUS: Statutární město Kladno a strategie implementace eGovernmentu. Kladno, 2009. 68
L i t e r at u r a [52] SEZOV, R.: Liferay in Action: The Official Guide to Liferay Portal Development. Shelter Island: Manning Publications, 2011. [53] Software 602: Elektronizace životních situací a interních procesů magistrátu okresního města. online, 2012, [cit. 30. 4. 2014]. URL http://www.bezpapiru.cz/elektronizace-mesta-decin [54] Správa základních registrů: Příručka pro obce. Praha, 2013. [55] Svaz měst a obcí České republiky: Chytřejší města v České Republice. Praha, 2011. [56] Svaz měst a obcí České republiky: Příručka pro člena zastupitelstva obce, Aktualizované znění 2012. Praha, 2012. [57] TATNALL, A.: The new gateways to internet information and services. Idea Group Publishing, 2005. [58] THOMPSON, R.: Web Services for Remote Portlets Specification v2.0. online, 2008, [cit. 30. 4. 2014]. URL http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html [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, 2010.
69
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 emailem 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
A . P o p i s y d i ag r a m ů u ž i t í 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í, email). 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
A . P o p i s y d i ag r a m ů u ž i t í
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 email 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 emailové 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
A . P o p i s y d i ag r a m ů u ž i t í 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 emailovou 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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 emailová 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 emailovou 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 emailovou 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
A . P o p i s y d i ag r a m ů u ž i t í
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 email 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
A . P o p i s y d i ag r a m ů u ž i t í 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 emailové upozornění o sdílení úkolu. Alternativní tok 1: Odstranění Uživatelů z výběru. 3.1. Uživatel klikne na křížek u jména vybraného Uživatele. 3.2. Uživatel klikne na tlačítko OK. 3.3. Systém vybraným Uživatelům odebere úkol z Úkolníku. 3.4. Systém odešle Uživatelům oznámení o odebrání úkolu. Podmínky dokončení: Změna ve sdílení úkolu. 82
A . P o p i s y d i ag r a m ů u ž i t í
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 Tabulka A.20: Zobrazení statistik
Krátký popis: Uživatel si zobrazí vybrané statistiky. Aktéři: - Uživatel - Systém - Databáze požadavků
83
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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 emailem 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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. 4.2. Úř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
A . P o p i s y d i ag r a m ů u ž i t í
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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í
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. 3.1. 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ů. 3.2. 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
A . P o p i s y d i ag r a m ů u ž i t í 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. 1.2. 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
A . P o p i s y d i ag r a m ů u ž i t í
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
A . P o p i s y d i ag r a m ů u ž i t í 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. 2.1. 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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í email o nasdílení události. Alternativní tok: Podmínky dokončení: Nasdílení události Uživatelům.
97
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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í email 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
A . P o p i s y d i ag r a m ů u ž i t í
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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í
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. 6.1. 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. 6.2. Uživatel vybere akci a případně vloží nové jméno. 6.3. 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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
A . P o p i s y d i ag r a m ů u ž i t í 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 email. 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
A . P o p i s y d i ag r a m ů u ž i t í 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
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
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
B . N áv r h y o b r a z ov e k p o rt l e t ů
Obrázek B.31: ÚŘEDNÍ DESKA – Návrh zobrazení detailu příspěvku podle Tabulky A.46 (příloha A) Editace příspěvku
Obrázek B.32: WORKFLOW – Návrh hlavní strany portletu pro definici workflow.
126
