Návrh optimalizace informačního systému

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Návrh optimalizace informačního systému Diplomová práce Autor: Bc. Tomáš Hájek Informační technologie a management Vedoucí práce: RNDr. Helena Palovská, Ph.D. Praha Červenec, 2015 0

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze dne 13.7.2015 Bc. Tomáš Hájek

Poděkování: Rád bych poděkoval vedoucí práce RNDr. Heleně Palovské, Ph.D., za pomoc při odborném vedení práce.

Anotace Diplomová práce je zaměřena na analýzu stávajícího informačního systému vyuţívaného ve státní správě. Práce dále obsahuje návrh optimalizace analyzovaného systému. Vedlejším cílem práce je poskytnout dokumentaci k analyzovanému systému a dodat vhodné podklady pro další rozvoj informačního systému v podniku. Přílohy práce tvoří podnikové metodiky analýzy a vývoje. Metodiky slouţí pro sjednocení pravidel analýzy a vývoje. Klíčová slova: Analýza, optimalizace, inovace, architektura, UML, IT analytik/architekt Annotiation The presented work focuses on an analysis of an existing information system used by the state administration. The main goal of the thesis is to propose an optimised design for the analysed system. The secondary objective is to provide documentation of the current system and specific inputs for further development of the company's information system. The annexes describe enterprise analysis and software development methodologies used to align the rules for analysis and development of enterprise systems. Key words: Analysis, opmtimization, innovation, architecture, UML, IT analyst/architect

Obsah Úvod... 7 1 Zvolené metody zpracování... 9 1.1 Specifika dokumentu... 9 1.2 Systémová analýza... 10 1.3 Meta modelování... 10 2 Trendy v analýze a návrhu IS... 12 2.1 Cloudové řešení... 12 2.2 Agilní přístup... 14 2.3 Podnikové IT role... 16 2.4 Síťová architektura... 16 2.4.1 Tlustý a tenký klient... 16 2.4.2 Mobilní klient... 18 3 Podnikové metodiky... 20 3.1 Podniková metodika analýzy... 20 3.2 Podniková metodika vývoje... 22 4 Analýza Systému Podniku... 24 4.1 Účel Systému... 24 4.2 Specifika analýzy... 24 4.3 Kontext Systému... 25 4.3.1 Aplikace... 25 4.4 Aktéři systému... 26 4.5 Přehled funkcí Systému... 26 5 Analýza Systému Podniku architektura... 28 5.1 Aplikace... 28 5.1.1 Aplikační prostředí... 29 5.2 Programátorská část systému... 29 5.3 Dekompozice Systému... 30 5.3.1 Metasystém... 30 4

5.3.2 Popis formulářové platformy... 32 5.3.3 Databázová část Aplikace... 34 5.3.4 Generování výstupů pro veřejnost... 35 5.4 Datová architektura... 41 5.4.1 Datový model... 42 5.5 Technologická architektura... 42 5.5.1 Zálohování... 44 5.5.2 Pouţívané vývojové a administrační prostředí... 44 6 Analýza Systému rozhraní a parametry... 46 6.1 Uţivatelské rozhraní formuláře... 46 6.2 Uţivatelské rozhraní pro programátory... 47 6.3 Klávesové zkratky formuláře... 47 6.4 Integrační rozhraní... 48 6.5 Autorizace, Autentizace, Role... 49 6.6 Počet uţivatelů Aplikace... 50 6.7 Práce se soubory... 50 6.8 Zatíţení serverů, odezva komponent... 50 6.9 Vysoká dostupnost... 52 6.10 Tempo růstu dat... 52 6.11 Provozní parametry / údrţba systému / kvalita... 53 6.12 Zálohování... 53 6.13 Změnové řízení... 53 7 Návrh optimalizace systému... 55 7.1 SWOT analýza... 56 7.2 Taktické optimalizace... 57 7.2.1 Integrace s agendovým informačním systémem... 57 7.2.2 Integrace s BI a datovým skladem... 57 7.2.3 Integrace s DMS... 58 7.2.4 Integrace s BPM... 58 7.2.5 Generování výstupů pro veřejnost... 59 7.2.6 Návrh nového IS pro agendu léčiv... 59 7.3 Provozní optimalizace... 60 7.3.1 Šablony... 60 5

7.3.2 Odmazání nepotřebných objektů... 60 7.3.3 Nová verze platformy... 60 7.3.4 Úprava komponent formuláře... 61 7.3.5 Hlavní menu Aplikace... 63 7.3.6 Správa verzí... 64 7.3.7 Databáze... 64 7.3.8 Bezpečnost... 64 7.3.9 Aplikační logika formulářů... 65 7.3.10 Agenda č. 1... 65 8 Návrh a doporučení pro další rozvoj Systému... 67 8.1 Varianta č. 1 doporučená... 67 8.2 Varianta č. 2... 67 8.3 Varianta č. 3 nulová varianta... 67 9 Výsledky... 69 9.1 Analýza... 69 9.2 Návrh optimalizace... 69 9.3 Metodiky... 70 9.4 Vyjádření zaměstnanců... 71 9.5 Co mi práce přinesla... 71 9.6 Bilancování... 71 Závěr... 73 Pouţitá literatura... 74 Internetové zdroje... 75 Pouţité SW nástroje... 78 Seznam obrázků a tabulek... 79 Zkratky... 81 Seznam elektronických příloh... 82 6

Úvod Budovat nový informační systém na zelené louce, bez jakýchkoliv vazeb a pravidel, je vţdy snadná úloha. Sloţitější varianta realizace informačního systému přichází v případě, kdy má podnik pevně nastavená pravidla, poţadavky a omezení. Bez těchto pravidel se nedá větší podnikové IT udrţovat a rozvíjet. Informační systém představuje v takovém podniku pouze jeden díl IT skládanky, který musí perfektně a bezproblémově zapadnout do soukolí podniku. Budování IT na zelené louce se u většiny zavedených podniků jiţ neuplatňuje. Aplikace jsou zde historicky pořízené a zavedené. Přichází na řadu nutnost inovace a s tím spojená problematika zastaralých informačních systémů. Tyto systémy nevyhovují potřebám dnešní doby a mohou představovat pro podnik velké omezení. Často generují značné provozní náklady. Předkládaná práce se zabývá problematikou zastaralého a nezdokumentovaného informačního systému, provozovaného v organizaci státní správy (dále Podnik ). Autor práce také zohledňuje konkrétní IT architekturu Podniku tak, aby mohl popisovaný systém do nastaveného IT prostředí v budoucnu lépe zapadnout. Cílem práce je vytvoření analýzy informačního systému Databáze léčivých přípravků (dále Systém ). Další úkol spočívá ve vytvoření návrhu optimalizace Systému na základě zpracované rozdílové analýzy a doporučení pro další rozvoj Systému v Podniku. Vedlejším cílem práce je zpracování dokumentace k Systému. Přílohou práce jsou také metodiky Podnikové analýzy a vývoje. Metodika Podnikové analýzy specifikuje poţadavky na analytickou činnost konkrétní podnikové role IT analytik. Analýza Systému z této metodiky vychází. Metodika vývoje slouţí pro sjednocení programátorských pravidel dle Podnikové SW architektury. Teoretická část práce se zabývá trendy v analýze a návrhu informačních systémů. Práce má následující strukturu. První kapitola seznamuje čtenáře se zvolenými metodami zpracování. Pokračuje teoretickou částí zabývající se trendy v analýze a návrhu informačního systému. Následuje krátká kapitola popisující vytvořené metodiky. Další tři kapitoly obsahují analýzu Systému (dále Analýza ). Jednotlivé názvy kapitol a podkapitol Analýzy reflektují struktury analytické šablony, podle které byly vytvořeny. Poslední dvě kapitoly těla práce obsahují návrh optimalizace Systému a doporučení pro další rozvoj Systému. Práce je 7

ukončena hodnocením výsledků samotné práce, strukturovanou dle jednotlivých artefaktů práce. Závěr práce obsahuje zamyšlení nad moţnostmi inovací informačního systému. Přílohy jsou uloţeny v elektronické podobě na CD. První dvě přílohy obsahují kompletní znění vytvořených metodik. Třetí příloha obsahuje krátké vyjádření zaměstnanců Podniku k artefaktům práce. 8

1 Zvolené metody zpracování Autor práce vyuţívá níţe popsané části uvedených metodik. Rozdělení architektury je převzato z architekturního rámce TOGAF. Analýza samotná vyuţívá jako předlohu kombinace šablon analytických dokumentů konsorcia IEEE pro zachycení ţivotního cyklu software. Jedná se konkrétně o standardy: Software Requirements Specification IEEE 830 a SDD Software Design Description IEEE 1016. Jednotlivé modely komponent systému jsou popsané mj. pomocí grafického jazyka UML. Jedná se o nejpouţívanější jazyk pro vizualizaci chování a struktury systému. Analýza vyuţívá pro vizualizaci programového kódu diagram tříd a sekvenční diagram. Pro popis komponent Systému je pouţit diagram komponent. Vyuţití jednotlivých UML diagramů v dokumentu je částečně atypické. Autor dokumentu klade vyšší důraz na porozumění diagramům, neţ nutnosti dodrţovat pravidla pro práci s konkrétními diagramy. Dále je pouţit obecný diagram uţití a obecný diagram tříd (datový model). Zobrazení architektury v Podnikové metodice vývoje je zajištěno pomocí modelovacího jazyka Archimate. Procesy v Podnikové metodice analýzy vyuţívají grafický jazyk BPMN. Všechny zmíněné vizualizační jazyky jsou technickými standardy. UML a BPMN grafické jazyky jsou standardy vytvořené konsorciem Object Management Group (OMG). Výjimku tvoří architektonický vizualizační jazyk Archimate, který je zastřešen konsorciem The Open Group. Návrh optimalizace vychází z výstupů Analýzy. Pro lepší představu o výhodách a nevýhodách Systému byla vytvořena SWOT 1 analýza. 1.1 Specifika dokumentu Dokument pouţívá notaci velkých úvodních písmen uprostřed věty v případě, ţe se jedná o konkrétní popisovaný objekt, který je ústředním tématem této práce. Jedná se konkrétně o 1 SWOT analýza je analytická technika, jejíţ pomocí je moţno identifikovat silné (Strengths) a slabé (Weaknesses) stránky, příleţitosti (Opportunities) a hrozby (Threats), spojené s určitým projektem nebo záměrem. 9

klíčová slova: Systém, Aplikace, Podnik, Metasystém, Metodika, Analýza. Autor dokumentu se tímto pravidlem snaţí zmenšit délku psaného textu. Dalším specifikem je vyuţití slova Aplikace. Tím je myšlena část Systému, ke kterému přistupují Podnikoví zaměstnanci pomocí grafického rozhraní. Na druhou stranu slovo Systém zahrnuje veškeré komponenty Systému, např. způsob zálohování. 1.2 Systémová analýza Jakákoliv analýza informačního systému, i kdyţ je vázána na moderní metodiky, stále vychází z obecných pravidel pro systémové myšlení a analýzu. Systémové myšlení, nebo také systémový přístup, je novějším typem vědeckého a technického myšlení, na rozdíl od původního myšlení mechanistického. Starší mechanistické myšlení lze souhrnně popsat jako snahu o vyřešení problému pomocí rozloţení systému na prvky, zkoumáním jednotlivých částí nezávisle na sobě a popsáním celku jako součtu chování jeho částí. Systémové myšlení se na rozdíl od mechanistického přístupu zabývá komplexním přístupem k problematice. Snaţí se o nalezení vzájemných vazeb mezi prvky systému a hledá propojení s okolím systému. Zabývá se také dynamičností systémů. Vycházíme z předpokladu, ţe komplexní systém nelze pochopit studiem jednotlivých částí v izolaci, ale musí být analyzován jako celek [1]. Systémová analýza na základě systémového přístupu dekomponuje systém na jednotlivé prvky. Následně se provádí analýza jednotlivých prvků a vzájemného působení prvků systému, včetně vazeb na okolí systému. Konkrétní zjištění chování a funkce systému následně pomohou popsat systém jako celek nebo vyřešit hledanou problematiku. 1.3 Meta modelování Část Systému je analyzována pomocí metadat a různých modelů. Na místě je proto krátké seznámení s meta pojmy. Předpona "meta" obecně znamená pohled shora, na vyšší úrovni, výskok (vymanění se) ze systému, "za", "přes" (čili přesahující), to, co určuje atp. V oblasti modelování zpravidla vyjadřuje skutečnost, že nějaký systém nebo model popisuje (na vyšší úrovni) jiné systémy, jiné modely [INT1]. Meta-modelování se rozděluje dle dnes všeobecně přijímaného standardu MOF konsorcia OMG do čtyř vrstev, viz obr. č. 1. 10

Obrázek č. 1 - metamodel dle MOF, zdroj: autor [SW1] 11

2 Trendy v analýze a návrhu IS Teoretická část obsahuje aktuální trendy v analýze a návrhu IS. 2.1 Cloudové řešení S nástupem cloudových řešení je nutné brát v potaz širší moţnosti realizace informačních potřeb podniku. Především tlak na sníţení ceny celého podnikového IT bude čím dál tím více směřovat k podrobné analýze a nasazení cloudových sluţeb. Nejdříve ale k definici cloudových sluţeb. Abychom pochopili princip cloudových sluţeb, je nutno zajít do blízké historie. Cloud vychází z virtualizace. Wikipedia píše o virtualizaci: Virtualizace je v informatice označení postupů a technik, které umožňují v počítači přistupovat k dostupným zdrojům jiným způsobem, než jakým fyzicky existují, jsou propojeny atd. [INT2]. Pro naše potřeby lze tuto definici transformovat do podoby: Virtualizace je řízené sdílení HW prostředků více uţivatelům. Zjednodušeně řečeno, jedná se o jakousi iluzi, ve které si kaţdý uţivatel myslí, ţe vlastní prostředky a zdroje pouze sám. Dle typu uţivatele se rozděluje virtualizace na [2]: serverovou virtualizaci desktopovou virtualizaci virtuální sítě virtuální diskové úloţiště Podrobný popis si ukáţeme na serverové virtualizaci OS. V tomto případě se jedná o sdílení HW prostředků. Realizaci sdílení má na starosti virtualizační platforma nainstalovaná přímo na HW, bez přítomnosti běţného OS. Virtualizační platforma poskytuje HW prostředky jednotlivým virtuálním OS (uţivatel). Mezi výhody virtualizace patří [INT3]: sdílené prostředky (úspora financí za HW) snadná administrace snazší vývoj centralizace 12

vysoká dostupnost snadná škálovatelnost V tomto bodě jsme uţ velice blízko k definici cloudu. Opět budeme poţadovat ve virtuálním prostředí (serverová virtualizace OS) vytvářet virtuální servery bez nutnosti starat se o HW. Navíc přidáme ještě poţadavek na vytváření virtuálních serverů samoobsluţně. Pomocí výše zmíněných poţadavků se dostáváme k termínu privátní cloud [INT4]. Druhá, známější varianta cloudu je veřejný cloud. Pokud se budeme drţet dále našeho příkladu, tak se jedná o sluţby velkého datového centra, kde si zákazník pouze pronajímá konkrétní počet HW prostředků. Zákazník se nestará o HW, pouze platí dodavateli sluţeb pravidelný finanční obnos za poskytované sluţby HW. Cloudové sluţby je moţné rozdělit dle umístění [2]: Veřejný cloud (Public) - umístění v datovém centru dodavatele sluţeb Soukromý cloud (Private) - sluţby jsou poskytovány v prostorech zákazníka Hybridní cloud (Hybrid) - cloud vyuţívá obě předchozí varianty Komunitní cloud (Community) - sdílená cloudová infrastruktura mezi organizacemi nebo lidmi Cloudové sluţby nezahrnují pouze poskytovaní HW. Poskytované sluţby se mohou týkat všech úrovní dílčí architektury informačního systému. Cloudové sluţby je moţné rozdělit dle úrovně architektury [2]: IaaS (Infrastructure as a Service) - Inftrastruktura jako sluţba PaaS (Platform as a Service) - Platforma jako sluţba SaaS (Software as a Service) - Software jako sluţba IaaS se zaměřuje na poskytování vybraného HW, na který si zákazník instaluje své platformy. Platforma jako sluţba slouţí pro poskytování sluţeb střední vrstvy IS a níţe. Zákazník spravuje pouze aplikace a o niţší úrovně systému se nemusí starat. PaaS nabízí především poskytování databázových sluţeb, middleware a sluţeb aplikačních serverů. SaaS je nejvyšší míra poskytovaných cloudových sluţeb. Zákazník vyuţívá zakoupené cloudové aplikace a nemusí se starat o správu dílčích částí architektury systému. 13

Výhody cloudových sluţeb vychází primárně z výhod virtualizace, navíc přináší velký benefit v podobě úspory finančních prostředků. Zákazník platí dodavateli pouze pravidelné paušály, není nucen investovat jednorázově velké částky. Kupuje si vţdy pouze to, co potřebuje [3]. Výhody cloudu jsou dnes prezentovány v mediích i na odborných konferencích. Firmy přicházejí stále s dalšími novinkami na trh, např. ipaas [INT5]. Pojďme se raději krátce seznámit s moţnými problémy při implementaci cloudových sluţeb. Dle konsorcia Open Group se jedná u níţe uvedené oblasti [INT6]: Bezpečnost, vlastnictví dat Nedostatek funkcionalit SaaS aplikací Závislost na internetovém připojení Závislost na dodavateli Správa dodavatelů, ze SLA se stává kritický prvek Změnové poţadavky ve sdílené infrastruktuře Integrace s interními systémy Nedostatek zkušeností s financováním a licenční politikou Z uvedeného seznamu je zřejmé, ţe cloudové sluţby jsou stále částečně neprobádané teritorium, kde se podnik můţe dostat velice rychle na tenký led. Rozsah moţných problémů je obrovský. Od problému s financováním, správou poţadavků, aţ po problémy se ztrátou citlivých dat a moţnosti informační špionáţe. 2.2 Agilní přístup Podporovat organizaci v dnešním rychle se měnícím prostředí je pro IT sloţky organizace značně sloţitý úkol. Podnik častěji mění svoje hlavní procesy. Procesy jsou pomocí IT prostředků staticky podchyceny, bez moţnosti provedení rychlé adaptace na nové poţadavky. [4]. Tento trend je jednou z příčin, vedle nízké úspěšnosti standardních IT projektů [INT7], který vede v posledních letech k alternativě ve způsobu realizace IT projektů. Jedná se o agilní přístup v analýze, v návrhu, při řízení a provozu informačních systému. Přístup je zaloţen na níţe uvedených základních myšlenkách [INT8], pravidla na levé straně mají větší význam: 14

individuality a komunikace před procesy a nástroji fungující software před sloţitou dokumentací spolupráce se zákazníkem před sjednáváním smlouvy změnové požadavky před dodrţením plánu Agilní přístup vyhází z 12 pravidel agilního manifestu [5]: interaktivní přístup k dodání SW, musí přinášet hodnotu zákazníkovi Změnové poţadavky je moţné dodávat v pozdějších fázích vývoje Vysoká míra spolupráce mezi vývojářem a uţivatelem Motivace jedinců je klíčem k úspěchu Osobní komunikace je nejefektivnějším nástrojem přenosu informace Primárním měřítkem úspěšnosti je fungující software Stálé pracovní tempo Kvalitní design Jednoduché postupy Samo-organizující se týmy Jednotlivá pravidla a myšlenky se postupně transformovali do různých metodik a rámců dotýkajících se práce s informačním systémem. Mezi agilní rámce lze řadit např. Extrémní programování, SCRUM, Agile Extension to BABOK a Agilní modelování. 15

2.3 Podnikové IT role Během ekonomické krize se podniky snaţily šetřit. Úsporná opatření byla zavedena také v oblasti lidských zdrojů IT části podniku. Krize jiţ minula a na výsluní se opět dostanou důleţité IT podnikové role, během krize částečně přehlíţené. Větší tlak na specifikaci přesných poţadavků a lepší propojení IT s podnikem vytvoří širší uplatnění pro podnikové business analytiky [INT9]. Podobný trend bude převládat u důleţité role podnikového architekta. Rozsah a sloţitost informačních systému dosáhla takové úrovně, ţe tato role začíná být v podniku klíčová. Další uplatnění lze nalézt ve velkých firmách, kde dochází k fúzím [INTX]. Tým architektů musí zajistit sjednocení podpory podnikových procesů a eliminovat duplicitní systémy. V nejbliţší době bude muset také architekt posunout podnik do éry Big Data a cloudových řešení. Po přesunu klíčových IS podniku do cloudu se nabízí otázka, zda role IT architekta bude nadále nutná. Při bliţším zkoumání problematiky vychází najevo, ţe IT bude muset nadále zkoumat široké spektrum nabídek cloudových sluţeb a sledovat evoluci cloudových sluţeb. Propojení cloudových řešení a interních sytémů bude také nelehký úkol [INT11]. Realizaci těchto náročných úkolů bude nadále mít na starosti IT architekt. 2.4 Síťová architektura Kapitola popisuje síťovou architekturu z pohledu klienta, se zaměřením na mobilní technologie. 2.4.1 Tlustý a tenký klient Firmy dnes nejčastěji vyuţívají klient-server síťovou architekturu. Server u klient-server architektury vytvoří centrální uzel poskytující sdílené sluţby nebo data pro jednotlivé klienty [INT12]. Klienti během síťové komunikace ţádají server o tyto sdílené sluţby nebo data, která server podle svých pravidel přiděluje, aby byl schopen obslouţit předem nastavený určený počet klientů. Klienty u klient-server architektury lze rozdělit na tenké, tlusté a hybridní. Tenký klient, dnes nejpouţívanější varianta klienta, funguje na principu vizualizace výsledků činnosti serveru. 16

Server provádí veškerou business logiku a na klientské stanici je umístěna pouze vizualizace výsledků. Typickým nositelem tenkého klienta je webový prohlíţeč [INT13]. Tlustý klient na rozdíl od klienta tenkého obsahuje i business logiku. Často vyuţívá server pouze jako úloţiště dat a také vyţaduje instalaci softwarového vybavení na klientské stanici. Díky tomu nabízí moţnost poskytnutí širší palety uţivatelských funkcionalit aplikace, které řešení na bázi tenkého klienta v prohlíţeči není schopno nabídnout [INT13]. Hybridní klient, někdy také nazývaný chytrý, je kombinací toho nejlepšího, co můţou oba předchozí typy klienta nabídnout, aplikace nese název RIA (obr. č. 2). Přináší přístup přes webový prohlíţeč, nevyţaduje tedy instalaci. Klient je schopen automatického updatu bez nutnosti instalace klientského softwaru. Data můţou být rozdělena souměrně mezi klienta a server, díky tomu dokáţe klient pracovat také v offline reţimu [INT14]. Hlavní přínos klienta spočívá v nabídce širokých moţností uţivatelského rozhraní (GUI). Tyto moţnosti tenký klient do příchodu HTML5 nebyl schopen nabídnout. Nedostatky jsou tyto: Aplikační logika na straně klienta přináší větší poţadavky na HW poţadavky na straně klienta. Nelze také opomenout nutnost aktualizace runtime knihoven 2. 2 Runtime knihovna je software pro provádění specifických operací během běhu programu. Většina operací je realizována pomocí přístupu k operačnímu systému. 17

Obrázek č. 2 - hybridní klient, zdroj: web [INT15] Mezi pouţívané technologie pro vývoj RIA aplikací patří: Adobe Flex, Java FX, Microsoft Silverlight. Příklad vyuţití RIA jsou cloudové kancelářské balíky předních softwarových výrobců, např. Google Spreadsheet. 2.4.2 Mobilní klient Mobilní zařízení dnes představují nejrychleji rostoucí segment technologického trhu a to jak softwarového, tak hardwarového. Vývoj v této technologické oblasti je tak rychlý, ţe některé inovace běţný uţivatel není schopen zachytit. Mobilní verze klienta, stejně jako standartní desktop klient, nabízí tři varianty. Klienta na mobilních zařízeních rozlišujeme z pohledu implementace na tenkého, nativního a hybridního klienta (obr č. 3). 18

První typ klienta je pouze speciálně graficky upravená webová verze HTML5 stránek pro zařízení s menším rozlišením obrazovky (telefon, tablet). Odborně se tento SW návrhový přístup nazývá responzivní design. Aplikace je dostupná z webového prohlíţeče mobilních zařízení. Klient je díky webovému prohlíţeči dostupný na všech mobilních OS platformách, ale není schopen vyuţívat sluţby mobilního zařízení, např. kameru, či bluetooth. Druhým typem klienta je nativní klient. Tento druh klienta vyuţívá moţnosti konkrétní mobilní OS platformy. Aplikace je vyvíjená v konkrétním SDK 3 pro danou mobilní platformu. Nativní klient vyţaduje instalaci na mobilním zařízení. Poslední novinkou v oblasti mobilních klientů je hybridní klient. Jedná se o kombinaci tenkého klienta a nativního klienta. Obsahuje kontejner nativního klienta, v kterém je umístěn webový prohlíţeč. Nativní kontejner zprostředkovává přístup HTML5 stránek k nízkoúrovňovým sluţbám mobilního zařízení [INT16]. Obrázek č. 3 - typy mobilních klientů, zdroj: web [INT17] Podle poradenské firmy Garnter [INT18] bude hybridní klient v blízké budoucnosti nejrychleji rostoucím typem klienta pro mobilní zařízení. 3 SDK je systémový vývojový nástroj. Jedná se o vývojový prostředek pro určitý operační systém. 19

3 Podnikové metodiky Kapitola obsahuje souhrn přiloţených Podnikových metodik vývoje a analýzy. 3.1 Podniková metodika analýzy V Podniku lze identifikovat tři druhy analýzy informačních systémů, viz obr. č. 4. První a nejdůleţitější typ analýzy je určen pro velké projekty. Jedná se o předprojektovou analýzu pro zadávací dokumentaci výběrového řízení. Druhý typ analýzy je spojen s interním vývojem. Tento přístup je vhodný pro malé projekty a typ analýzy je spojen částečně s agilním přístupem. Poslední typ analýzy slouţí pro tvorbu aktuální dokumentace k informačním systémům. Rozdělení jednotlivých analytických směrů určuje dle typu Podnikových poţadavků vedení IT spolu s IT architektem. Obecně lze konstatovat, ţe většina poţadavků, které nemají dopady na okolí podniku s pracností do 30 dnů (analýza a vývoj) je realizována formou malého projektu. Analýza stávajících systému se provádí při provozním problémech, případně při volné pracovní kapacitě IT analytika. Zbývá velký projekt, který je oficiálně schvalovaný na základě IT doporučení vyšším vedením Podniku. Provedená analýza v rámci práce se řadí do třetí části podnikové metodiky. 20

Obrázek č. 4 - typy Podnikové metodiky analýzy, zdroj: autor [SW1] Proces tvorby dokumentace by měl být zaloţen na spolupráci business analytika a IT analytika (obr. č. 5). Business analytik se dotazuje podnikového uţivatele a analyzuje procesy. IT analytik se zaměřuje na systém jako takový. Důleţitý faktor hraje koordinace a spolupráce obou rolí, bez které by analýza nebyla kompletní. Společným výstupem práce obou rolí je dokument nazvaný systémová specifikace. Dokument je vytvořen podle standardů IEEE konsorcia Software Requirements Specification IEEE 830 a SDD Software Design Description IEEE 1016. Obrázek č. 5 analýza stávajícího systému, zdroj: autor [SW1] Metodika je psána jako pracovní podklad pro roli podnikového IT analytika. Analytik by měl přispět do výsledného výstupu minimálně v těchto oblastech: Obecný popis systému o Kontext systému o Přehled funkcí systému Architektura systému o Aplikační architektura systému o Dekompozice systému o Datová architektura systému o Technologická architektura systému 21

Popis rozhraní systému Nefunkční specifikace Provozní parametry systému IT analytik můţe spolupracovat s business analytikem na identifikaci aktérů, jejich odpovědnosti a rolí. Spolupráci lze také navázat při popisu funkční specifikace nebo popisu podnikových procesů. Pokud během kompletace dokumentace vzniknou nové uţivatelské nebo technické poţadavky na systém, tak vzniká dokument Návrh optimalizace. IT analytik předkládá technické poţadavky a spolupracuje na návrhu řešení krátkodobých optimalizací. Poţadavky směřující do kategorie střednědobého plánování jsou v gesci IT architekta, případně vedení IT. 3.2 Podniková metodika vývoje Podniková metodika vývoje si klade za cíl sjednotit postupy pro návrh a vývoj informačního systému. Pravidla jsou nastavená tak, aby jednotlivé systémy bylo moţno jednoduše provozovat, integrovat, přebírat pod správu a dále rozvíjet. Aplikace metodiky vyţaduje spolupráci s analytiky a IT architektem. Bez organizačního provázání se zmíněnými rolemi Podniku nelze tuto metodiku v praxi aplikovat. Důleţité je provázání Metodiky s architekturními principy podniku. Vedle specifického vyuţití velké míry virtualizace se Podnik z velké části zaměřuje na Servisně Orientovanou Architekturu (Service Oriented Architecture, SOA). Realizaci komunikace zajišťuje integrační platforma (Enterprise Service Bus, ESB). Metodika zmiňuje obecně známá SOA pravidla [INT19], ale především klade důraz na: vícenásobnou pouţitelnost sluţeb skládání sluţeb bezpečnost sluţeb monitoring sluţeb Příklad vyuţití SOA pro sloţení jednotlivých sluţeb je zobrazen níţe (obr. č. 6). 22

Obrázek č. 6 -příklad využití integrační platformy, zdroj: Autor [SW3] Základem SOA jsou především webové sluţby. Dokument popsuje minimální poţadavky na webové sluţby [INT20] [INT21] v následující podobě: musí být volány asynchronně musí být dostupná WSDL definice pro všechny klienty sluţeb musí podporovat UDDI musí mít návratovou hodnotu v případě chyby musí vracet jasný popis chyby musí být dostupný číselník chyb veškeré chyby a varování musí být logovány musí být autorizovány musí být vyuţita XSD specifikace XML webové sluţby musí být bezstavové, mezi jednotlivými voláními neudrţují stav jednotlivé operace musí vţdy definovat strukturu poţadavků request/response Metodika dále zmiňuje konkrétní moţné přístupy k vývoji, včetně pravidel [4]. OOP přistup RAD database vývoj Transakční přístup Vývoj řízený testováním Fundamenty SOA Dokument dále obsahuje poţadavky na bezpečnost, dokumentaci, logování, monitoring apod. 23

4 Analýza Systému Podniku Následující kapitola obecným způsobem popisuje analyzovaný Systém. 4.1 Účel Systému Systém slouţí jako datová podpora části podnikových Procesů. Dále eviduje informace o léčivech a jejich komponentách. Jednou z hlavních funkcí Systému je generování pravidelných seznamů povolených léčiv pro veřejnost. 4.2 Specifika analýzy Pro potřeby dokumentování byla formulářová část Systému (Aplikace) logicky rozdělena na jednotlivé agendy, bloky a moduly (obr. č. 7). Moduly se snaţí spojit společné bloky aplikace do ucelených částí tak, aby aplikace byla lépe popsatelná. Logický prvek agenda popisuje obsah jednotlivých formulářů. Obrázek č. 7 logické rozdělení Aplikace, zdroj: autor [SW2] 24

4.3 Kontext Systému V organizačním kontextu Podniku slouţí Systém jako hlavní pracovní nástroj odborných sekcí při evidování informací o léčivech a registračních řízení léčiv. Informace o léčivech vyuţívá jako zdroj dat celý Podnik, včetně navázaných IT systémů. Systém také eviduje informace o přijatých hlášeních na webových stránkách. Generování výstupů pro veřejnost je realizováno pomocí specializovaných komponent systému, které mají přístupné interní programátoři a analytici. Zaměstnanci přistupují k datům pomocí formulářů vytvořených pomocí formulářové platformy. 4.3.1 Aplikace Aplikaci pro Podnikové uţivatele je moţné rozdělit na dva hlavní moduly. Modul č. 1 slouţí pro evidenci agendy léčiv, např. knihovna léků. Jednotlivé agendy jsou dále rozděleny do bloků, podle společných atributů. Modul č. 2 se zaměřuje na podporu registračních procesů. První blok modulu č. 1 slouţí primárně pro evidenci léčiv a léčivých látek. Blok adresář obsahuje různé číselníky, adresy a pomocné informace. Archiv zahrnuje informace o registračních řízeních umístěných v archívech. Poslední blok seskupuje pomocnou agendu spojenou s určováním cenových a úhradových řízení léčivých přípravků a léčivých látek. Tato agenda je primárně umístěna mimo Aplikaci v jiném systému. Modul č. 2 zabezpečuje datovou podporu registračních řízení. Procedury lze rozdělit dle ţivotního cyklu léčivého přípravku na nové registrace, změny registrace, prodlouţení registrace a ukončení registrace. Ostatní procedury mají podpůrný charakter. Aplikace neobsahuje automatizované procesy, pouze eviduje podpůrné informace k registračním řízením. Jedná se především o různé datumové poloţky, evidence přidělených osob k řízení, přidělené číslo jednací k řízení apod. Aplikace podporuje celkově 20 registračních procesů, viz obr. č. 8. Procesy jsou blíţe popsané v Podnikových směrnicích. Názvy procesů jsou anonymizovány. 25

Obrázek č. 8 Podnikové procesy přímo podporované Aplikací, zdroj: autor [SW1] 4.4 Aktéři systému Aplikace vyuţívají všichni zaměstnanci Podniku. Zaměstnanci s oprávněním zápisu jsou rozmístěni v 7 odděleních Podniku. Aplikaci vyuţívají pro práci také zaměstnanci IT. Vedle tvorby nových funkcionalit mají na starosti generování výstupů pro odbornou veřejnost, které musí být přesné a bez chyb. Mezi poslední aktéry systému patří informační systémy Podniku. Celkový počet přistupujících systémů k agendě léčiv je 8. Uţivatelé podnikového webu zapisují do Systému pomocí integrační platformy. Oprávnění jednotlivých aktérů jsou evidována v interní RACI 4 autentizace aktérů je blíţe popsána v kapitole 6.5. matici. Autorizace a 4.5 Přehled funkcí Systému Pro lepší pochopení funkcí Systému jako celku je dále uveden UML diagram uţití, viz obr. č. 9. Rozčlenění do funkcí je realizováno pomocí bloků aplikace. Systém sám o sobě nelze funkčně více dekomponovat bez provedení analýzy Podnikových procesů. 4 RACI je metoda pro přiřazení a zobrazení odpovědností podnikových rolí nebo osob k úkolu 26

Jednotlivé formulářové moduly Aplikace jsou vyuţívané zaměstnanci odborných útvarů (Uţivatel). Agendu Knihovna léku z modulu Informace o léčivech vyuţívají pro čtení ostatní informační systémy Podniku. Do Systému jsou zapisovány automatizovaně hlášení (Informace o léčivech) vytvořené externími subjekty na Podnikovém webu. Generování výstupů pro veřejnost má na starosti IT zaměstnanec Podniku (Programátor). Obrázek č. 9 Use Case Systému, zdroj: autor [SW1] 27

5 Analýza Systému Podniku architektura Aplikace je vytvořena pomocí Oracle technologií. Mezi pouţité technologie patří Oracle Forms, Oracle Weblogic a Oracle DB. Oracle DB je technologicky vyspělá relační databáze a nabízí široké spektrum funkcí. Oracle AS je aplikační server určený pro Oracle Java aplikace. Produkt Oracle Forms je nativní komponenta pro Oracle aplikační server. Slouţí především pro rychlý vývoj interních podnikových aplikací na bázi formulářů, dále pouze jako formulářová platforma. Veškeré produkty jsou implementovány pomocí standartních postupů. Generování výstupů je realizováno pomocí programů na klientských stanicích. Programy jsou vytvořené v C#, nebo Visual Basic kódu. Programy volají PL/SQL programové balíčky databáze. PL/SQL kód v databázi sbírá poţadovaná data a poskytuje je klientské aplikaci. 5.1 Aplikace Aplikační architektura uţivatelské části Systému se skládá z dvou hlavních technologických bloků (obr. č. 10). První blok tvoří aplikační server. Zobrazení dat, načtení dat a uloţení dat zajišťuje formulářová platforma umístěná v tomto serveru. Aplikační server obsahuje vedle vyuţívaných formulářů také PL/SQL formulářové knihovny, které slouţí pro specifikou komunikaci s klientem. Druhý blok Aplikace tvoří sluţby databáze. Nativní sluţby databáze se starají o správu dat a poskytují moţnost čtení a zápisu dat aplikační logice pomocí SQL jazyka. Aplikace vyuţívá autorizační a autentizační moţnosti databáze pro ověření přistupující identity. Poslední funkcí databáze je zajištění historických dat u klíčových entit. Data jsou archivována do speciálních tabulek pomocí databázové úlohy. 28

Obrázek č. 10 architektura Aplikace, zdroj: autor [SW2] 5.1.1 Aplikační prostředí Aplikace je nasazena v produkčním prostředí na dvou dedikovaných virtuálních serverech. Jeden virtuální server slouţí pro aplikační server, druhý pro DB server. Testovací prostředí slouţí pro testování změn před nasazením do produkčního prostředí. Aktualizuje se metodou kompletního klonování produkčního prostředí. Vývojové prostředí má kaţdý programátor na osobním počítači. Jedná se o aplikaci Oracle Designer, v kterém lze jednoduchým způsobem navrhovat a upravovat formuláře Aplikace. 5.2 Programátorská část systému Zaměstnanci IT vyuţívají Systém pro naplnění poţadavku odborných sekcí na generování výstupů pro odbornou veřejnost. Výstupy jsou generované do souborů pomocí dvou klientských aplikací, viz obr. č. 11. Kompletaci dat zajišťují programové jednotky databáze. 29

Obrázek č. 11 architektura části Systému pro generování výstupů, zdroj: autor [SW2] 5.3 Dekompozice Systému Dekompozice Systému je rozdělena na dvě části. První část popisuje formulářovou část systému a navázané databázové komponenty. Je zdokumentována pomocí nově vytvořeného Podnikového Metasystému a textového popisu. Druhá část dekompozice se zabývá analýzou části Systému určenou pro generování výstupů. Analýza vyţívá pro popis komponent Systému UML grafické modely a textové popisy. 5.3.1 Metasystém Celkový počet pouţívaných formulářů je 52. Na formulářích jsou prováděny kaţdý měsíc změny. Časté úpravy jsou také prováděné na databázové úrovni. Z těchto důvodů byl pro podrobné dokumentování informačního systému zvolen Metasystém s automatizovanou aktualizací metadat. Vstupním prvkem pro Metasystém jsou jednotlivé formuláře převedené do XML formátu. Metasystém jednotlivé soubory rozebírá a vybírá z jednotlivých XML nejdůleţitější informace. Tato data jsou následně uloţena do databáze Metasystému. 30

Vzhledem k tomu, ţe Aplikace vyuţívá širších funkcionality databáze, bylo nutné začlenit do Metasystému také databázovou část. Metasystém je napojen do data dictionary 5, odkud čte vybrané informace. Aktualizace metadat databázové části Aplikace probíhá automaticky jednou denně. Aktualizace jednotlivých informací o formulářích probíhá manuálně vloţením nového či aktualizovaného formuláře v XML podobě do Metasystému. Metasystém je schopen i dávkové zpracování formulářů. Grafické rozhraní Metaystému je realizováno pomocí reportů (Oracle Apex) pro všechny důleţité sekce Systému. Základní filtr je umístěný v horní části všech sekcí a je nastaven na filtrování podle logického prvku Agenda. Pro snazší orientaci ve struktuře formulářů obsahuje uţivatelské rozhraní hierarchický strom důleţitých komponent formuláře. Jednotlivé sekce Metasystému obsahují informace o (tab. č. 1): Sekce Komponenta Druh Formuláře Strom Aplikace Navigace Formuláře Formulář Objekt Formuláře Window Objekt Formuláře Canvas Objekt Formuláře Data blok SQL Formuláře Item Objekt Formuláře Číselník SQL Formuláře Trigger PL/SQL Formuláře Procedura PL/SQL Formuláře Knihovna PL/SQL Formuláře Navigace Objekt Databáze Entita Objekt Databáze Atributy Objekt Databáze Omezení Objekt Databáze Cizí klíče Objekt 5 Data dictionary je relační úloţiště metadat v databázi 31

Databáze Procedury PL/SQL Databáze Úlohy PL/SQL Databáze Role a práva Objekt Databáze Uţivatelé Objekt Databáze Sekvence Objekt Databáze Pohledy Objekt Databáze Indexy Objekt Tabulka č. 1 seznam komponent Metasystému, zdroj: autor Poloţka tabulky druh vyjadřuje informaci o tom, zda komponenta má blíţe k definici chování sytému (program) nebo k uchovávání dat. 5.3.2 Popis formulářové platformy 5.3.2.1 Struktura formuláře Formuláře mají vţdy jedno nebo více oken zobrazujících data. Kaţdé okno obsahuje několik regionů nazvaných Canvas. Jde pouze o grafické ohraničení místa v okně. Okno obsahuje jednotlivé datové poloţky nazvané Item (dále poloţka). Data jsou získávána a ukládána do databáze pomocí datových bloků (Data block). Datové bloky obsahují SQL příkazy. Jednotlivé datové bloky jsou propojené s poloţkami a poloţky jsou také provázány s regiony. Obrázek č. 12 ukazuje datový model Metasystému formulářové části Aplikace. Z obrázku jsou patrné jednotlivé vazby mezi prvky formuláře. 32

Obrázek č. 12 struktura formulářových objektů, zdroj: autor [SW2] 5.3.2.2 Popis tvorby tabulkového formuláře a reportu Tabulkový formulář slouţí pro editaci více poloţek najednou. Pro lepší představu lze tabulkový formulář přirovnat k tabulce v MS Excel. Tabulkový formulář je ve formulářové platformě vytvářen následujícím způsobem. Pokud má poloţka nastavený patřičný parametr, dochází při vykreslování formuláře k opakovanému vykreslení poloţky pod sebou s dalšími daty z databáze. Několik takto vykreslených sloupců vedle sebe tvoří tabulkový formulář. Pokud jsou veškeré poloţky v tabulkovém formuláři omezeny pouze na čtení, stává se z tabulkového formuláře report. Z výše uvedeného je zřejmé, ţe princip tvorby reportů a tabulkových formuláře je poplatný své době. Dnešní moderní formulářové a reportingové platformy dovolují tvorbu formulářů a reportů podstatně jednodušeji. 33

5.3.2.3 Chování formuláře Jednotlivé události jsou ve formuláři zachycovány pomocí spouštěčů (Trigger). Událost můţe být např. stisk tlačítka uţivatelem, nebo vykreslení formuláře na obrazovku. Sloţitější zpracování událostí je umístěno mimo spouštěč ve formulářových procedurách. Pokročilejší aplikační logika nebo logika vyuţívaná ve více formulářích je uloţena v knihovnách. 5.3.2.4 Technologický upgrade formulářové platformy Formulářová platforma je implementována od r. 2015 v aplikačním serveru. Během migrace do aplikačního severu proběhl technologický upgrade všech formulářů z verze Oracle Forms 7 na verzi 11g. Víše popsaná struktura formulářů a popsaný způsob práce s formulářem zachycuje návrh jednotlivých formulářů v původní verzi aplikace, tedy verzi Oracle Forms 7. 5.3.3 Databázová část Aplikace Aplikace vyuţívá standardní databázové objekty a funkce. Vedle základních objektů entita a index Aplikace vyuţívá také pohledy, sekvence a různá omezení. Obrázek č. 13. zobrazuje datový model Metasystému databázové části Systému. Obrázek č. 13 metamodel databázových objektů Aplikace, zdroj: autor [SW2] Databáze také slouţí jako autorizační a autentizační komponenta Aplikace. Eviduje všechny uţivatele Aplikace a jejich oprávnění. Formulář Aplikace vyţaduje pro autorizaci uţivatele patřičné databázové role. Jednotlivé role mají oprávnění k databázovým entitám. 34

Obrázek č. 14 zobrazuje datový model autorizační části Systému v Metasystému. Objekt formulář slouţí pouze pro znázornění navázání na formulářovou část Metasystému. Obrázek č. 14 autorizace a autentizace Aplikace, zdroj: autor [SW2] 5.3.4 Generování výstupů pro veřejnost Generování výstupů o léčivech pro veřejnost patří mezi důleţité agendy Podniku. Výstupů se generuje pět typů. Dva výstupy nejsou uvedené, jelikoţ mají téměř totoţnou strukturu jako níţe popsané výstupy. 5.3.4.1 Výstup č. 1 Výstup č. 1 slouţí jako zdroj dat pro vyhledání v léčivech a léčivých látkách na webových stránkách Podniku. Generování výstupů probíhá kaţdé pondělí a poslední den v měsíci. Vedle načítání základních informací o léčivech a léčivých látkách se také přidávají do výstupů nestrukturované data s vazbou na léčivé přípravky, např. příbalový leták. Zdrojové texty se evidují v PDF i DOC formátu, ve kterých se také exportují. Další částí nestrukturovaných výstupů jsou rozhodnutí o nových registracích léčiv. Vstupem procesu zpracování jsou rozhodnutí v PDF podobě, umístěné na souborovém serveru. Vybrané soubory jsou načítány do databáze a dále zpracovávány stejně jako texty. 35

Aplikační logika generování výstupů je umístěna v databázi a na klientských počítačích. Programátoři vyuţívají jako uţivatelské rozhraní Excel šablonu. Šablona obsahuje aplikační logiku jazyka Visual Basic. V šabloně jsou umístěné dva aplikační moduly. První modul Excel šablony načítá parametry šablony a řídí celý proces generování. Samotné načítání dat zajišťuje databázová PL/SQL programová jednotka. Seznam vyuţívaných programových jednotek je zobrazen níţe (obr. č. 15): Obrázek č. 15 seznam programových balíků výstupu č. 1, zdroj: autor [SW2] Průběh volání jednotlivých metod je následující: vstupním bodem pro generování výstupů je tlačítko šablony. Řízení toku programu a načítání parametrů Excel souboru zajišťuje první modul, viz obr. č. 16. Ten v klíčových pasáţích předává řízení druhému modulu. A ten dále volá PL/SQL proceduru pro získání dat. PL/SQL modul vytvoří datovou strukturu pro další zpracování nebo vrátí zpět kurzor. Obsah kurzoru je vloţen do pole. Průběh volání končí vygenerováním souborů z pole nebo datových struktur. 36

Obrázek č. 16 sekvence volání jednotlivých modulů výstupu č. 1, zdroj: autor[sw2] Výstupy jsou dále ručně nahrávány do adresářových sloţek souborového serveru. Seznam vyuţívaných entit při generování jednotlivých výstupů lze dohledat v Metasystému. Sloţka je napojena na FTP server a přenášena kaţdou půlnoc do informačního systému webu. Informační systém webu pravidelně zpracovává data a prezentuje je veřejnosti jako parametrizovatelný report. 5.3.4.2 Výstup č. 2 Výstup č. 2 slouţí pro potřeby odborných SW třetích stran mimo Podnik. Výstupem generování jsou soubory sobory DBF (dbase). Formát výstupů se nikdy nemodifikuje, jelikoţ je navázán na automatické zpracování na straně výrobců SW. Z těchto důvodů také výstup obsahuje omezené mnoţství informací. Aplikační logika generování výstupu č. 2 je podobná výstupu č. 1. První dva moduly mají stejnou funkci. Navíc je přidán modul pro komunikaci s MS Access. Seznam veškerých vyuţívaných programových jednotek je uveden níţe (obr. č. 17): 37

Obrázek č. 17 - seznam programových balíků výstupu č. 2, zdroj: autor [SW2] Průběh volání jednotlivých metod je následující: vstupním bodem pro generování výstupů je tlačítko šablony. Načtení parametrů zajišťuje první modul, viz obr. č. 18. Po jejich načtení tento modul spouští generování datových struktur v MS Access. Access databáze je vyuţívána pro generování výstupních DBF souborů z důvodu, ţe novější verze MS Excel jiţ nepodporují exportování do dbase formátu. Následuje postupné volání jednotlivých get metod a PL/SQL procedur. Návratové hodnoty jsou následující. Databázové procedury vrací kurzor. Modul č. 2 data transformuje do pole. Následuje generování textových souborů z jednotlivých polí do souborů. Tyto soubory jsou importovány do MS Access databáze a následně exportovány v DBF formátu. Po vygenerování jsou soubory ručně vloţeny do článku pomocí redakčního systému webu. Článek se upravuje kaţdý měsíc podle aktuálních potřeb. 38

Obrázek č. 18 - sekvence volání jednotlivých modulů výstupu č. 2, zdroj: autor [SW2] 5.3.4.3 Výstup č. 3 Generování výstupu č. 3 obsahuje cenové a úhradové rozhodnutí regulovaných léčiv. Výstup se generuje několikrát do měsíce. Výstupy jsou publikovány ručně formou souborů na webových stránkách podniku. Pro generování výstupu č. 3 je pouţita aplikační logika vytvořená v C# a PL/SQL. C# aplikace vyuţívá paralelní zpracování pro jednotlivé souborové výstupy. Díky tomu je moţné zrychlit generování několikanásobně oproti sériovému zpracování dat. Během paralelního zpracování se vyuţívají vícejádrové procesory klienta a více sezení databázového serveru. Vztah jednotlivých tříd zobrazuje UML Class digaram (obr. č. 19). 39

Obrázek č. 19 - seznam tříd výstupu č. 3, zdroj: autor [SW2] Průběh volání jednotlivých tříd a programových balíčků je zobrazen na níţe uvedeném obrázku (obr. č. 20). C# aplikace má podstatně sloţitější strukturu volání jednotlivých tříd, na rozdíl od volání procedur v předchozích výstupech. UML diagram se omezuje pouze na popis činnosti spojenou s voláním jiné komponenty C# aplikace. Obrázek č. 20 - sekvence volání jednotlivých modulů výstupu č. 3, zdroj: autor [SW2] 40

C# aplikace načítá do číselníků formuláře nejdříve informace z databáze o minulých výstupech. Starší verze výstupů se pouţívají při opravě nových. Po stisknutí tlačítka generování výstupu klientská aplikace pomocí třídy ScauReportParamItem načte a vyhodnotí atributy formuláře. Následuje příprava dat a samotné generování souborů. Celý proces zastřešuje třída ExcelReports. Třída je volána paralelně pro kaţdý soubor dat. Při kaţdém volání je spouštěna PL/SQL balíček pro sběr dat. Druhý PL/SQL balíček slouţí pro načtení dat do kurzoru. Data jsou následně nahrána dole a exportována do jednotlivých TXT a XLS souborů. XLS sešity, včetně jednotlivých listů, jsou před generováním naformátovány dle konkrétního typu výstupu. Na datové úrovni jsou vyuţívány tabulky AC_* jako dočasné úloţiště při generování výstupu. Po ukončení generování výstupu jsou data uloţena do auditních tabulek AD_*. Evidována jsou data všech generování, včetně návrhu výstupu. Seznam vyuţívaných entit při generování jednotlivých výstupů lze dohledat v Metasystému. 5.4 Datová architektura Systém vyuţívá jako datové uloţiště relační databázi firmy Oracle. Databáze je pravidelně aktualizována, momentálně v11.2.0.4. Aplikace vyuţívá pro uloţení dat dvě hlavní databázová schémata, viz tab. č. 2. První schéma slouţí pro uloţení veškerý entit a druhé pro uloţení entit se soubory. Název Datová soubor Velikost (M) Free (M) % Used AISLP_DOC aislp_doc01.dbf 30720 3968 59 AISLP_DOC aislp_doc02.dbf 6244 1150 80 USERS users02.dbf 30592 1230 96 USERS users01.dbf 17286 60 100 Tabulka č. 2 rozložení databáze Systému na úrovní souborového systému, zdroj: autor Celkový počet databázových objektů typu index a tabulka je uveden níţe (tab č. 3). Název Vlastník Objekty USERS AGENDA 71 tables USERS AGENDA 78 indexes AISLP_DOC AISLP 3 indexes AISLP_DOC AISLP 7 tables 41

USERS AISLP 795 tables USERS AISLP 326 indexes Tabulka č. 3 počet entit a indexů Systému, zdroj: autor 5.4.1 Datový model Datový model Aplikace lze strukturovaně dohledat v metadatech pomocí Metasystému. Metasystém je schopen zobrazit veškerá důleţitá metadata všech typů objektů databáze. Samostatnou sekci Metasystému tvoří vazby mezi entitami (cizí klíče), které byly odděleny od ostatních omezení, jelikoţ tvoří základ pro datový model. Význam entit a atributů je popsán v Metasystému. Popis entit a atributů je rovněţ automaticky načítán ze Systému do Metasystému. Obrázek č. 21 zobrazuje základní informace o databázových metadatech Systému evidovaných v Metasystému. Obrázek č. 21 Metamodel vybraných databázových objektů Systému, zdroj: autor[sw2] 5.5 Technologická architektura Aplikace je implementována na dvou serverech. První server je určen pro aplikační server (tab. č. 4), druhý pro databázi (tab. č. 5). Servery jsou umístěné ve virtualizovaném prostředí, kde sdílejí prostředky s ostatními systémy. Virtualizované prostředí řídí přístup k diskovému poli, CPU i paměťovým prostředkům dle vlastních pravidel a dále tyto sluţby poskytuje 42

virtualizovanému OS. OS virtuálních strojů tyto sluţby pouze vyuţívá a dále poskytuje standardní cestou platformám. Parametry jednotlivých virtuálních serverů: Aplikační server Parametr Hostname OS Paměť CPU Diskové místo SW Databázový server Parametr Hostname OS Paměť CPU Diskové místo SW Velikost Hostname1 RHEL6.6 16GB 4 jádra 70GB Oracle Weblogic 11g(10.3.6) Oracle Forms 11gR2(11.1.2.2) Tabulka č. 4 parametry aplikačního serveru, zdroj: autor Velikost Hosntame2 RHEL6.6 8GB 2jádra 450GB Oracle Database 11gR2(11.2.0.4) Tabulka č. 5 parametry databázového serveru, zdroj: autor Obrázek č. 22 názorně ukazuje seznam vyuţívaných SW platforem a HW. Systém je připojen pouze na jedno diskové pole, neumí se tedy vyrovnat s výpadkem datového úloţiště. Výpadek fyzického serveru díky architektuře virtualizačního clusteru neomezuje Systém v činnosti. Virtualizace sama zabezpečí přechod na jiný HW server. 43

Obrázek č. 22 Technická architektura Systému, zdroj: autor[sw2] 5.5.1 Zálohování Systém je zálohován čtyřmi způsoby: Zálohování virtuálních serverů na diskové pole Zálohování virtuálních serverů na pásky Zálohování pomocí datové pumpy Zálohování pomocí utility RMAN (Hot Backup) Zálohy celých virtuálních serverů jsou vhodné pro rychlé obnovy, pokud dojde k destrukci SW nebo dat na virtuálním serveru. Soubory datové pumpy jsou vhodné při obnově konkrétní dat, např. při smazání dat uţivatelem. Zálohy provedené pomocí utility Oracle RMAN jsou důleţité, pokud je nutnost dostat server do poslední, nebo vybrané transakce v jakémkoliv čase. 5.5.2 Používané vývojové a administrační prostředí Programátoři a administrátoři vyuţívají následující nástroje (tab. č. 6). Vývoj formulářů je prováděn pomocí Oracle Forms Developer. Programátorské rozhraní formulářů má nainstalovaný kaţdý programátor na vlastním počítači. Úprava databáze je prováděna pomocí produktů PL/SQL Developer a SQL Developer. První uvedený se pouţívá z historických důvodů a kvůli schopnosti přímého exportu z databáze na klienta. Výstupy pro veřejnost jsou 44

naprogramovaný v MS C# a MS Excel. Sluţby monitoringu zajišťuje Oracle Cloud Control. Monitoring je společný pro všechny databáze. Sběr dat monitoringu se provádí pomocí agenta v databázovém serveru. Analytici vyuţívají grafy monitoringu z důvodu sledování zátěţe SQL serveru a při běţných databázových problémech. Produkt Účel Oracle Forms Developer Tvorba a úprava formulářů Allround PL/SQL Developer Tvorba a úprava PL/SQL Visual Studio 2013 Generování výstupů pro veřejnost XLSB šablona MS Excel Generování výstupů pro veřejnost Oracle SQL Developer Tvorba a úprava PL/SQL, administrace Oracle Cloud Control 12c Monitoring, administrace Tabulka č. 6 seznam využívaných vývojových a administračních prostředí, zdroj: autor 45

6 Analýza Systému rozhraní a parametry Kapitola obsahuje popis rozhraní, provozní metriky, informace o bezpečnostních komponentech Systému ad. 6.1 Uživatelské rozhraní formuláře Následující dva obrázky ukazují menu Aplikace (obr. č. 23) a jeden náhodně vybraný formulář aplikace (obr. č. 24). Menu aplikace a všechny formuláře jsou provedeny v standardním barevném provedení formulářové platformy, tedy hlavně pomocí šedé palety barev. Obrázek č. 23 část GUI Menu Aplikace, zdroj: autor Obrázek č. 24 Ukázka formuláře, zdroj: autor 46

6.2 Uživatelské rozhraní pro programátory Rozhraní pro programátory slouţí k efektivnějšímu a samoobsluţnému generování výstupů pro veřejnost. Programátor vyuţívá dvě rozhraní pro generování výstupních souborů (Excel šablonu a C# GUI). Excel sešit (obr. č. 25) zajišťuje uţivatelské rozhraní pro generování výstupů č. 1 a č. 2. C# GUI (obr. č. 26) poskytuje přístup ke generování výstupu č. 3. Jednotlivá rozhraní mají mnoho vstupních parametrů. Jejich popis je obsahově nad rámec této sekce. Obrázek č. 25 GUI generování výstupu č. 1 a 2, zdroj: autor Obrázek č. 26 GUI generování výstupu č. 3, zdroj: autor 6.3 Klávesové zkratky formuláře 47

Nejpouţívanější klávesové zkratky Aplikace jsou: F8 dotaz do DB naplní formulář daty, nebo výstup dle poţadovaných filtrů F7 filtr pro vyhledávání, postup práce: o Nejdřív zmáčknout klávesu F7 o Vytvořit filtr o Zmačknout klávesu F8 F1 - technické informace o formuláři F3 kopírován poloţky F4 - kopírování celé řádky F6 vloţení prázdného řádku F9 zobrazení číselníku Shift + F6 zrušení poloţky Down /Up další/předchozí záznam TAB přechod mezi políčky v menu 6.4 Integrační rozhraní Mezi vyuţívané integrační rozhraní patří (tab. č. 7): Název rozhraní Technologie přenosu Čtení/Zápis (R/W) Systém 1-4 Dblink R Systém 5 Datová pumpa R Systém 6 Dblink RW Systém 7-9 ESB W Tabulka č. 7 seznam integračních rozhraní, zdroj: autor Integrační rozhraní se liší dobou svého vzniku. Nejstarší přenos dat je realizován pomocí souborů (datová pumpa). Následuje období růstů robustních relačních databází v Podniku. Rozhraní z této doby jsou realizované pomocí databázových linků. Poslední období je spojené 48

s érou integrační platformy. Jednotlivé rozhraní jsou realizovány pomocí ESB. Podrobnosti o parametrech jednotlivých rozhraní jsou uvedené v Metasystému. 6.5 Autorizace, Autentizace, Role Postup při ţádosti o přidělení přístupových oprávnění je následující. Uţivatel získá oprávnění do patřičné části aplikace pomocí ţádosti svého nadřízeného. Ţádost je evidována v helpdeskovém systému. Administrátor aplikace následně přidělí patřičné role identitě uţivatele. Pokud identita není zavedena v systému, tak jí administrátor zavede. Iniciační heslo je vytvořeno pro všechny uţivatele stejné. Administrátor zašle iniciační heslo uţivateli emailem. Uţivatel si po přihlášení můţe heslo podle potřeb změnit. Identity nejsou v aplikaci nijak řízeny. Při odchodu zaměstnance z Podniku nedochází k deaktivaci, či odmazání identity. Seznam uţivatelů systému, seznam rolí a obsah rolí je evidován v Metasystému. Podrobné informace správě uţivatelů a jejich oprávnění jsou uvedena v následujících bodech. Veškeré identity jsou vytvářeny v DB. Veškeré role jsou vytvářeny v DB. Ověření identity probíhá pomocí autorizačních a autentizačních mechanizmů DB. Zobrazení sloţky hlavního menu uţivateli je definováno na základě konkrétní role. Zobrazení formuláře danému uţivateli je definováno na základě konkrétní role. Přístup do formulářů je vyspecifikován na základě autorizační databázové role. Samotná autorizace pro přístup do jednotlivých formulářů je nastavována ve speciálním menu souboru formuláře. Ten obsahuje menu a oprávnění k formulářům. Počet uţivatelských rolí je 69 Název identity tvoří příjmení uţivatele Název identity má vţdy maximálně šest písmen. Pokud má uţivatel dlouhé příjmení, tak administrátor vytvoří zkratku dle svého uváţení. 49

Veškeré role mají objektové oprávnění, resp. udílí se pouze oprávnění na databázový objekt. Administrátor nepřiděluje systémová oprávnění, tzn. nemá právo a změnu struktury databázového schématu. Udělené oprávnění není moţné předat dalšímu uţivateli. 6.6 Počet uživatelů Aplikace Aplikaci vyuţívá aktivně dvě odborné sekce Podniku, tedy cca 50 aktivních uţivatelů. Ostatní pracovníci Podniku pouţívají Aplikaci pouze pro čtení, tzn. cca 300 uţivatelů. Databáze obsahuje skoro 700 identit, jelikoţ nedochází k deaktivaci identity. 6.7 Práce se soubory Aplikace ukládá všechny soubory do tabulek. Jedná se o příchozí XML webové hlášení a příbalové letáky léčiv v PFD a DOC formátu. Odezva na uloţení a otevření souboru nebyla strojově měřena. Uloţení 2MB souboru z Aplikace do databáze trvá do 2s. Průměrná velikost ukládaných souborů je 2MB. Počet souborů v systému je 150 000. Aplikace umoţňuje přistupovat k souborům pomocí nativních funkcí formulářové platformy. 6.8 Zatížení serverů, odezva komponent Výstup AWR 6 reportu během pracovní doby ukazuje, ţe databáze nemá ţádné výkonnostní problémy. Databázi lze řadit dle výstupu mezi nízkotransakční (obr. č. 27). 6 AWR je uloţiště snímků Oracle databáze. Snímky se provádějí v pravidelných intervalech a zachycují všechny důleţité statistiky databáze. 50

Obrázek č. 27 Měření počtu transakcí databáze, zdroj: autor Paměť databázového serveru je plně dostačující. Server má načtené veškeré potřebné informace v paměti (obr. č. 28). Obrázek č. 28 Měření využití paměti databáze, zdroj: autor Výkonností aspekty aplikačního serveru byly měřeny zátěţovým testem. Odezva HTTP serveru při zátěţovém testu nedoznala ţádných změn. Veškeré poţadavky měly reakční čas do 30ms. Z grafu (obr. č. 29) je vidět, ţe odezva při zátěţi dokonce klesala. 51

6.9 Vysoká dostupnost Obrázek č. 29 Měření zatížení HTTP serveru, zdroj: autor Systém nemá vlastním způsobem řešené zajištěné vysoké dostupnosti. Spoléhá se na řešení vysoké dostupnosti pomocí virtualizačního Clusteru. Virtualizace zabezpečuje dostupnost při scénáři výpadku jednoho HW serveru. Při výpadku dojde k přenesení virtuálních serverů na jiný HW. Proti výpadku diskového pole není systém nijak chráněn. Veškeré disky serveru jsou umístěné na jediném diskovém poli. Systém není schopen funkčnosti při výpadku celé lokality. 6.10 Tempo růstu dat Z historických snímků databáze lze dohledat tempo růstu databázových objektů měsíc zpět. Z přiloţené tabulky č. 7 je vidět tempo růstu databáze přibliţně 2GB za měsíc. Většina nových dat je zaznamenána do systémových tabulkových prostor. Název Velikost (MB) růst za den (MB) SYSTEM 7853,63 73,16 SYSAUX 2069,69 10,4 USERS 46587,63 5,93 Tabulka č. 7 Tempo růstu DB za měsíc 52

6.11 Provozní parametry / údržba systému / kvalita Systém je spravován a udrţován interně. Podnik je tedy plným vlastníkem majetkových autorských práv a má moţnost s těmito právy nakládat dle vlastního přání. Veškeré úpravy aplikace zajišťují pracovníci oddělení datové podpory IT, kteří jsou autoři veškerého duševního vlastnictví k vytvořenému kódu. Databáze a aplikační server jsou spravovány smluvně pomocí externího dodavatele sluţeb Oracle. Zálohování je prováděno dodavatelem sluţeb zálohování a dodatelem sluţeb Oracle. 6.12 Zálohování Systém je zálohován několik způsoby. První způsob je realizován pomocí pravidelných zálohování celých virtuálních serverů. Databáze i aplikační server jsou zálohovány na zálohovací pole a pásky. Záloha na pole probíhá kaţdé pondělí a pátek od 21:30 a trvá cca. 4 hodiny. Zálohy mají retenci tři týdny. Export na pásky probíhá kaţdý pátek 20:30 a trvá 28 hodin, jelikoţ je záloha umístěna v balíčku s dalšími servery. Druhý způsob zálohování je realizován pomocí Oracle technologií. Pouţívá se datová pumpa a utilita RMAN. Datovou pumpu je kaţdý den exportována celá databáze a přesunuta na speciální vyhrazený souborový server určený pro zálohy. Stejným způsobem je zajištěno zálohování RMAN. Soubory datové pumpy mají nastavenou retenci sedm dní, RMAN zálohy pouze jeden den. Plán Oracle zálohování je následující: Plná záloha RMAN se spouští v neděli v 00:11 a běţí 2 hodiny. Záloha archivních logů v ostatních dnech v 00:11 a běţí půl hodiny. Export datové pumpy se spouští vţdy v neděli po dokončení RMAN zálohy a trvá hodinu. 6.13 Změnové řízení Proces schválení změnových poţadavků je navrţen tak, aby byla zajištěna informovanost klíčových pracovníku a celého řešícího týmu Aplikace. Postup při schylovaní procesu je následující: Na základě potřeb uţivatele (po schválení vedoucího) vzniká poţadavek. S tímto poţadavkem je osloven business analytik. Ten má pak za úkol zpracovat poţadavek, vytvořit zadání a vést uţivatele procesem. 53

V zadání kaţdého poţadavku jsou evidovány minimálně následující informace: o jak velkou změnu se jedná a její dopady do jaké skupiny priorit poţadavek řadí jestli se poţadavek dotýká práce ostatních pracovníků odhady pracností na implementaci poţadavku Zadání odesílá vedoucí sekce jako podklad na vedoucího oddělení datové podpory IT. Po evidenci zadání (poţadavku) bude následně předán řešitelskému týmu Aplikace, který rozhodne o jeho konečné kategorizaci a prioritizaci. Po implementaci poţadavku budou uţivatelé informování o provedení. Po následném otestování funkcionalit uţivatelem (oproti zadání) a uţivatelským akceptováním bude poţadavek uzavřen a dále veden pro evidenční a statistické účely. 54

7 Návrh optimalizace systému Návrh optimalizace je rozčleněn do dvou sekcí podle typu plánování [INT22]. Provozní optimalizace jsou zaměřeny na zlepšení klíčových parametrů systému, zvýšení komfortu uţivatelů, včetně administrátorů. Velký důraz je kladen na zvýšení transparentnosti systému, tak aby byl Systém mohl být jednoduše spravován a rozvíjen. Jako poslední jsou uvedeny návrhy na zlepšení bezpečnosti systému tak, aby odpovídaly Podnikovým poţadavkům. Návrhy optimalizace střednědobého plánování (taktické optimalizace) odráţí pevně danou budoucí roli Systému v Podniku. Aplikace bude nadále plnit klíčovou roli pro evidenci agendy léčiv a v podpoře registračních procesů. Tento trend se nebude v příštích dvou letech výrazně měnit. Postupně bude docházet k migraci podpory jednotlivých Podnikových procesů. Tyto procesy budou přesunuty do nástroje pro podporu procesů (BPM). Přechod bude pozvolného charakteru a je potřeba domyslet do důsledků migraci jednotlivých procesů. Aplikace během období migrace musí dále poskytovat komplexní informace o agendě léčiv a všech prováděních registračních řízeních. Důleţitou poloţku návrhu optimalizace tvoří návrh nového moderního systému pro evidenci agendy léčiv a poţadavky na provázání s běţícími IT projekty. Z výstupu SWOT analýzy vyplývá, ţe by měl být systém dále rozvíjen interně. Systém bude po migraci podpory jednotlivých registračních procesů plnit funkci evidence agendy léčiv. Transformace agendy léčiv do moderního objektového návrhu je programátorský a analytický tým schopen. Vývojový tým je vysoce flexibilní a má se Systémem dlouholeté zkušenosti. Rizika spočívají v moţném nedostatku informací vedení Podniku o moţnostech rozvoje datové podpory této agendy. Dále v moţném tlaku veřejnosti na kvalitu poskytovaných dat, které mohou vyústit v nevhodné řešení této Podnikové agendy. 55

7.1 SWOT analýza Vypracovaná SWOT analýza (obr. č. 30) dává jasnou představu o nutnosti inovace veškerých komponent Systému. Obrázek č. 30 SWOT analýza Systému, zdroj: autor[sw2] Mezi hlavní pozitiva Systému lze řadit rychlost a kvalitu zapracování změnových poţadavků. Další výhoda spočívá ve velice schopném analytickém a vývojovém týmu. Hlavní nevýhoda Systému spočívá v charakteru datové podpory procesů. V Aplikaci nelze evidovat ţádné úkoly a Aplikace neobsahuje ani jeden pracovní tok. Veškerá procesní podpora je zajištěna pouze vyplňováním datumových poloţek a pomocí evidence přidělené osoby k úkolu. Druhá hlavní nevýhoda spočívá v nedostatečné integraci s ostatními systémy. Tento problém je z velké části o koncepci celého IT, ale je nutné jej zde zmínit. Poslední problém se dotýká poskytovaných výstupů veřejnosti. Výstupy mají zastaralou formu, neobsahují kompletní informace o léčivech a prezentují se veřejnosti nevhodným způsobem. 56