Systém pro využívání metodiky Management of Business Informatics

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Diplomová práce

Systém pro využívání metodiky Management of Business Informatics Bc. Michal Dobiáš

Vedoucí práce: prof.Ing. Jiří Voříšek, CSc.

7. května 2013

Poděkování Chtěl bych poděkovat profesoru Ing. Jiřímu Voříškovi, CSc. za to, že nám umožnil pracovat na tomto projektu, za to, že vedl naši práci a spolu s ním bych chtěl poděkovat i docentu Ing. Janu Pourovi, CSc. za spolupráci při konzultacích a podporu při realizaci diplomové práce. V neposlední řadě bych chtěl poděkovat kolegovi Bc. Ondřeji Kofroňovi za spolupráci na tomto projektu a koordinaci výsledného díla, které je výstupem našich prací.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 7. května 2013

.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Michal Dobiáš. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Dobiáš, Michal. Systém pro využívání metodiky Management of Business Informatics. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract The goal of this work is to familiarize with widespread IT management methodologies like ITIL and COBIT and with the newly created methodology MBI, which has been developed at University of Economics in Prague. Another goal of this work is to examine the reasons that hinder companies from implementing enterprise IT management methodologies. Second part of the work is to create a system that will be used by companies that want to user MBI. The system will allow them to customize the model so it fits their needs. Keywords Enterprise IT management, IT mangement methodologies, ITIL, COBIT, MBI

ix

Abstrakt Cílem práce je seznámit se s rozšířenými metodikami řízení IT jako jsou ITIL a COBIT a s nově vytvořenou metodikou MBI, která byla vyvinuta na VŠE. Spolu s metodikami je obsahem práce prozkoumání důvodů, které brání firmám tyto metodiky zavést do řízení IT. Druhou částí práce je vytvoření systému pro využívání metodiky MBI konkrétními firmami. Systém umožní uživatelům kopírovat přizpůsobovat si obsah metodiky tak, aby vyhovoval potřebám společnosti. Klíčová slova Řízení IT, metodiky řízení IT, ITIL, COBIT, MBI

x

Obsah Úvod

1

1 Metodiky řízení IT 1.1 Metodika ITIL . . . . . . . . 1.2 Norma ISO 20000 . . . . . . . 1.3 Metodika COBIT . . . . . . . 1.4 Podniková informatika v praxi 2 Metodika MBI 2.1 Faktory ovlivňující vývoj MBI 2.2 Cíl metodiky . . . . . . . . . 2.3 Struktura MBI . . . . . . . . 2.4 Srovnání s metodikami ITIL a 2.5 Způsob využití metodiky . . . 2.6 Verze MBI a budoucí vývoj .

. . . v

. . . . . . . . . . . . . . . . . . . . . . . . . . . České republice

. . . . . . . . . . . . . . . COBIT . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

3 4 7 8 10

. . . . . .

13 13 14 15 21 21 23

3 Implementace systému pro využívání metodiky 25 3.1 Analýza a návrh . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Volba platformy . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3 Životní cyklus požadavku v aplikaci . . . . . . . . . . . . . . 37 4 Realizace 4.1 Platform specific model . . . . 4.2 Vygenerování základu aplikace 4.3 Návrh uživatelského rozhraní . 4.4 Průběh realizace . . . . . . . 4.5 Zabezpečení . . . . . . . . . . xi

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

41 41 46 46 47 54

5 Testování

59

6 Zátěžové testování

61

Závěr

63

Literatura

65

A Seznam použitých zkratek

67

B Obsah přiloženého CD

69

xii

Seznam obrázků 1.1 1.2

Statistika využití metodiky ITIL . . . . . . . . . . . . . . . . . Míra definování procesů v závislosti na velikosti podniku . . . .

11 12

2.1

Metamodel MBI . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.1 3.2 3.3 3.4 3.5

Use case diagram pro vlastníka modelu Use case diagram pro uživatele . . . . Doménový model . . . . . . . . . . . . Diagram nasazení . . . . . . . . . . . . Životní cyklus požadavku v CakePHP

. . . . .

. . . . .

28 28 30 37 38

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12

Databázové schéma - část 1 . . . . . . . . . . . . . . . . . . . Databázové schéma - část 2 . . . . . . . . . . . . . . . . . . . Databázové schéma - část 3 . . . . . . . . . . . . . . . . . . . Databázové schéma - část 4 . . . . . . . . . . . . . . . . . . . Uživatelské rozhraní - hlavní stránka . . . . . . . . . . . . . . Uživatelské rozhraní - rozdělení rozhraní . . . . . . . . . . . . Ad hoc procházení generického modelu - výběr filtru . . . . . Ad hoc procházení generického modelu - výsledek vyhledávání Vytváření podnikového modelu . . . . . . . . . . . . . . . . . Proces vytváření podnikového modelu . . . . . . . . . . . . . Stránka s výpisem úloh v podnikové modelu . . . . . . . . . . Editace objektu z podnikového modelu . . . . . . . . . . . . .

. . . . . . . . . . . .

42 43 44 45 47 47 48 49 50 51 53 54

xiii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Seznam tabulek 6.1 6.2

Benchmark - vytváření podnikového modelu . . . . . . . . . . . Benchmark - listování úloh . . . . . . . . . . . . . . . . . . . . .

xv

62 62

Úvod Metodiky řízení IT poskytují firmám prostředek, jak se vyhnout chybám, které už za ně udělali ostatní a nejen to, nabízí i nejlepší známá řešení daných problémů. Na trhu existuje mnoho metodik řízení, avšak stále si nedokázaly i přes svůj prokazatelný přínos najít cestu ke značné části společností. Katedra informačních technologií VŠE provedla v minulosti sadu průzkumů s cílem zjistit, proč tomu tak je. Jak bylo zjištěno - častou překážkou bývají zdroje, konkrétně jejich nedostatek, a to ať už finančních či personálních, a to platí hlavně pro malé a střední firmy. Metodika MBI, která byla vyvinuta na VŠE, se snaží být řešením tohoto problému a působit jako dostupná metodika řízení IT, která je navíc dostatečně flexibilní, aby po přizpůsobení přesně vyhovovala prakticky každému podniku. Metodika ve své první verzi vyvolala již zájem některých společností, avšak stále je ve fázi vývoje a jedním z plánovaných rozšíření je systém, který umožní vývoj a využití metodiky MBI v praxi. Vytvoření tohoto systému je předmětem této práce. Systém slouží dvěma hlavním účelům, konkrétně usnadní autorům rozvoj metodiky. Druhá část systému je určena pro koncové uživatele a poslouží jako nástroj pro pohodlné používání a přizpůsobování tohoto metodologického rámce. Práce je koordinována s prací Bc. Ondřeje Kofroně, a to takovým způsobem, že analýza a návrh systému probíhá v součinnosti, zatímco implementaci svých částí realizujeme samostatně. Má část práce se týká rozhraní pro koncové uživatele, díky němuž bude možné s metodikou pracovat na uživatelské úrovni.

1

Kapitola

Metodiky řízení IT Společným cílem metodik pro řízení IT je nastínit best-practice řešení problémů, které se často objevují v oblasti řízení IT. Metodiky staví na praktických poznatcích kumulovaných napříč různými firmami Z rozličných odvětví a hledají nejlepší řešení problémů, před které jsou manažeři často stavěni. Některé metodiky se zaměřují pouze na některé sektory řízení IT, některé se snaží obsáhnout všechny oblasti. Dalším rozdílem mezi metodikami je například zaměření metodiky podle velikosti podniku, který se metodikou má řídit. Existují například metodiky, jejichž využitelnost pro malé podniky je prakticky nulová, ale existují i metodiky, které jsou vhodné pro libovolně velký podnik. Mezi nejčastěji zmiňované metodiky patří ITIL, COBIT. U těchto metodik je patrný výše zmiňovaný rozdíl v zaměření, kde ITIL se zaměřuje zejména na IT služby a je vhodný pro libovolně velký podnik, kdežto COBIT se snaží postihnout všechny aspekty řízení informatiky. Jednotlivé metodiky budou rozebrány podrobněji v kapitolách jim přímo věnovaných. Při vyhledávání informací o řízení IT je možné také často narazit na další rozšířené metodiky a standardy, jejichž obsah není předmětem této práce, pro úplnost je však vhodné některé z nich vyjmenovat. Mimo ITIL a COBIT do této skupiny patří: • Normy pro IT service management – ISO 20000-1 – ISO 20000-2 • CMMI - Capability Maturity Model Integration • Standardy vymezujíc procesy v IT governance - ISO/IEC 38500 3

1

1. Metodiky řízení IT • TOGAF • Zachman Framework • Procesy životního cyklu software - ISO/IEC 12207 • Metodiky pro řízení projektů jako PRINCE2, PRiSM, PMBOK, apod. • Standardy týkající se informační bezpečnosti – ISO/IEC 27001 – ISO/IEC 27002 – ISO/IEC 27003 – ISO/IEC 27004 • Standardy pro řízení kvality – ISO 9000 – ISO 9001 – ISO 9004

1.1

Metodika ITIL

Metodika ITIL1 je produktem britského úřadu OGC2 (v té době původně CCTA3 ), který byl vládou pověřen k vytvoření frameworku pro návrh a užívání IT služeb, a to z důvodu, že kvalita vládě dodávaných služeb nebyla dostatečná. První verze frameworku byla vydána v 80. letech minulého století a tato verze se postupem času rozrostla až na 30 knih zabývajících se různými částmi životního cyklu IT služeb. Mnoho firem ITIL přijalo a tato metodika se rychle rozšiřovala i mimo vládní sektor. V roce 2001 došlo k revizi a restrukturalizaci obsahu, což vedlo k vydání ITIL verze 2, který členil informace do 8 kategorizovaných knih. Vydání nové verze vedlo k další popularizaci metodiky. Zatím nejnovější verze nese pořadové číslo 3 - byla vydána v roce 2007 a aktualizována o 4 roky později, v roce 2011. Nyní ITIL čítá 5 knih, a to konkrétně: 1

IT Infrastructure Library Office of Government Commerce 3 The Central Computer and Telecommunications Agency 2

4

1.1. Metodika ITIL • Service Strategy • Service Design • Service Transition • Service Operation • Continual Service Improvement Knihy popisují celý životní cyklus IT služby a každá z nich se zaobírá jednou oblastí tohoto cyklu.

1.1.1

Service Strategy

První knihou ITIL v3 je Service Strategy [12], která radí, jak správně zvolit strategii. Mezi základní kroky zmiňované v této knize patří zjištění zákazníkových potřeb a zmapování trhu. Výstupem je ve stručnosti znalost toho, jaké služby bude organizace poskytovat a jaké schopnosti musí vyvinout či zlepšit. Hlavním cílem je přimět organizaci myslet a jednat strategicky a na základě toho stavět portfolio poskytovaných služeb.

1.1.2

Service Design

Kniha Service Design [10] shrnuje doporučení pro fázi návrhu služeb, a to se týká jak služeb nových, tak úprav stávajících, tak, aby plnily potřeby zákazníků a zároveň byly říditelné a přínosné. Mezi hlavní cíle popisované v této knize je správa portfolia služeb, které zákazníkovi přinesou hodnotu, řešení dostupnosti IT služeb, řízení kapacity IT služeb, řizení nepřetržité dodávky služeb, řízení úrovně služeb prostřednictvím SLA4 , zajištění bezpečnosti služeb a řízení dodavatelů poskytujících službu.

1.1.3

Service Transition

Třetím krokem životního cyklu IT služby je její přenesení do ostrého provozu [13]. V rámci této knihy je popsáno, co je třeba zajistit před zveřejněním služby, jak nakládat se změnami, ověřovat správnou funkci služeb a jak spravovat informace společnosti. Dále kniha doporučuje připravit se na různé situace, které mohou nastat při provozování služby a nastavit správu nasazování služeb do ostrého provozu. 4

Service Level Agreement - smlouva, která zajišťuje, že služba bude provozována za předem daných podmínek ve sjednané kvalitě a dostupnosti

5

1. Metodiky řízení IT

1.1.4

Service Operation

Svazek číslo 4 [11] se zaměřuje na období, kdy je již služba v provozu a hlavním cílem doporučení v této knize je provozovat službu správně a udržet ji v provozu. Organizace řídící se těmito doporučeními by měla zajistit stabilitu služby, optimalizovat služby jak z pohledu nákladů, tak kvality a dokáže se připravit na neočekávané situace. Součástí těchto doporučení je například funkce service desk, podle které by měli klienti mít možnost kontaktovat provozovatele služby s připomínkami a požadavky týkajícími se dané služby. Provozovatel by měl míst nastaveny procesy, které popisují, jak s touto zpětnou vazbou naloží.

1.1.5

Continual Service Improvement

Poslední kniha aktuální verze knihovny ITIL [9] obsahuje sadu doporučení, jejichž hlavním cílem je pokračovat ve vylepšování služby i po tom, co je plně v provozu. Doporučení jsou rozdělena na 4 hlavní procesy: • Service review - cílem tohoto procesu je pravidelně zkoumat službu a hledat oblasti, ve kterých by se dala zlepšit, • Process evaluation - formální ohodnocení procesů souvisejících s poskytováním služeb, kdy se vyhodnocuje splněný metrik, benchmarky a v případě nutnosti se provádí audity, • Definition of CSI5 - definování činností, které vedou ke zlepšení služeb a procesů založené na výsledcích předchozích 2 procesů service review a process evaluation, • Monitoring of CSI initiatives - cílem tohoto procesu je ověřit, zda jdou vylepšení podle původního plánu a pokud tomu tak není, tak podniknout příslušné kroky k nápravě. V případě implementace ITILu se společnost může rozhodnout, že využije pouze některé části z rozsáhlé sady doporučení pro zlepšení svých procesů, jelikož ostatní části nemusí být pro daný typ podniku vhodné. Kvůli tomuto faktu se neprovádí certifikace společností na soulad s knihovnou ITIL. V případě nutnosti získat certifikaci blízkou souladu s ITILem je možnost využít normy ISO 20000. 5

6

Continual Service Improvement

1.2. Norma ISO 20000

1.2

Norma ISO 20000

Normy ISO/IEC 20000 jsou standardem pro řízení IT služeb, které jsou silně spjaty s ITILem a řeší absenci možnosti certifikace na řízení IT služeb. Norma specifikuje provozovateli požadavky na plánování, vytváření, implementaci, provoz, monitorování, přezkoumání, udržení a vylepšování IT služeb. Jak je vidět, i zde je velká podobnost s ITILem, a to je jen podtrženo faktem, že sledování praktik definovaných v ITILu je nejlepší cestou k získání certifikace ISO 20000. Norma je cílena jak na společnosti, které poptávají IT služby, jelikož jim zajišťuje, že certifikovaná společnost bude poskytovat služby na dostatečné úrovni kvality, tak na dodavatele služeb, kteří pomocí této certifikace mohou prokázat, že jejich služby jsou opravdu dostatečně kvalitní a jejich monitorování a rozvoji je věnováno dostatečné úsilí. Celkem se norma skládá z 5 částí a 3 další jsou v současnosti připravovány: • ISO/IEC 20000-1:2011 Information technology – Service management - Part 1: Service management system requirements - definuje požadavky na systém řízení IT služeb. Na základě shody s požadavky je možné provádět certifikaci. • ISO/IEC 20000-2:2012 Information technology – Service management - Part 2: Guidance on the application of service management systems - obsahuje pokyny a doporučení pro použití systému řízení IT služeb. • ISO/IEC 20000-3:2009 Information technology – Service management – Part 3:Guidance on scope definition and applicability of ISO/IEC 20000-1 - tato norma poskytuje návod, jak aplikovat normu ISO 20000:1 a ukazuje příklady shody s normou. Tato část doplňuje druhou část normy a obsahuje spíše konkrétní příklady. • ISO/IEC 20000-4:2010 Information technology – Service management – Part 4:Process reference model - specifikace referenčního modelu. • ISO/IEC 20000-5:2010 Information technology – Service management – Part 5:Exemplar implementation plan for ISO/IEC 20000-1 - Ukázková implementace systému pro správu IT služeb, která vyhovuje ISO 20000-1. • ISO/IEC 20000-7: Application of ISO/IEC 20000-1 to the cloud Tento standard podává návod, jak aplikovat ISO 20000-1 v prostředí cloudu. V současnosti připravováno. 7

1. Metodiky řízení IT • ISO/IEC 20000-10: Concepts and terminology for ISO/IEC 20000-1 - Detailní popis konceptu a terminologie ISO 20000-1. V současnosti připravováno. • ISO/IEC 20000-11: Guidance on the relationship between ISO/IEC 20000-1 and related frameworks - Tato technická zpráva definuje vztah mezi ISO 20000-1 a ITILem, případně dalšími obdobnými metodikami. V současnosti připravováno.

1.3

Metodika COBIT

Metodika COBIT6 byla vytvořena organizací ISACA7 a dnes je distribuována ve verzi s označením COBIT 5 [3]. Tato metodika se zaměřuje na popis sady procesů, návodů, cílů, hodnocení, nejlepších praktik a ukazatelů s cílem maximalizovat využití informačních technologií při dosahování podnikových cílů.

1.3.1

Historie

První verze vydaná v roce 1996 obsahovala pouze framework pro řízení podnikové informatiky. Při tvorbě COBITu vycházela ISACA z mezinárodních standardů a rozsáhlých zkušeností s řízením IT a auditorskou činností. Druhé vydání, které vyšlo o 2 roky později bylo obohaceno o auditorské postupy (audit guidelines), implementační nástroje (implementation toolset) a kontrolní cíle (control objectives). Dvouletý interval byl dodržen i mezi druhým a třetím vydáním, které bylo vydáno roku 2000. Novinkou ve třetím vydání byla část zabávající se manažerskými postupy (management guidelines) a přepracování se dočkala část týkající se řízení podnikové informatiky. Čekání na čtvrté vydání zkrátilo v roce 2003 zpřístupnění online verze, na samotnou čtvrtou verzi se však muselo čekat až do roku 2005. Následující dva roky práce přinesly revizi čtvrtého vydání na verzi s označením 4.1. V této verzi se procesy v COBITu dělily do 4 domén: • Plan and Organize, • Acquire and Implement, • Deliver and Support, 6

Control Objectives for Information and Related Technology dříve známá Information Systems Audit and Control Association, dnes vystupuje pouze pod zkratkou ISACA 7

8

1.3. Metodika COBIT • Monitor and Evaluate. Tato verze byl nejčastěji využívána pro audit systémů podnikové informatiky.

1.3.2

Současná verze

Nejaktuálnější verze z roku 2012, COBIT 5, byla rozšířena a restrukturalizována tak, že nyní obsahuje 37 procesů rozdělených do 5 následujících domén (zdroj [5]): • doména EDM (Evaluate, Direct and Monitor) zahrnuje procesy zaměřené na nastavení rámce pro IT governance a procesy zaměřené na dosažení efektů, optimalizaci rizik, zdrojů a řízení zúčastněných stran, • doména APO (Align, Plan and Organise) obsahuje procesy zaměřené na plánování a řízení nákupů, obchodních vztahů a dodavatelů, řízení rizik, řízení IT strategie, řízení podnikové architektury, plánování programů, portfolií a projektů, řízení kvality, řízení bezpečnosti, • doména BAI (Build, Acquire and Implement) se zaměřuje na budování a implementaci IT řešení, jedná se zejména o procesy pro správu uživatelských požadavků, návrh a realizaci IT řešení, řízení programů a projektů, řízení změn, správu aktiv a správu konfigurací, • doména DSS (Deliver, Service and Support) obsahuje popis procesů zaměřených na dodávku IT řešení a následnou podporu jejich provozu, včetně řízení kontinuity, řízení bezpečnosti v oblasti provozu IT řešení, • doména MEA (Monitor, Evaluate and Assess) se zaměřuje na monitorování, měření a posuzování souladu s externími požadavky, sledování a posuzování systému interních kontrol. Největšími posuny kupředu z pohledu verze 5 bylo zahrnutí IT governance, integrace dílčích standardů jako Val IT a Risk IT a stejně, jako tomu bylo u předcházející liché verze, přepracování pohledu na řízení IT, díky čemuž bylo možné využít metodiku pro výchozí nastavení procesů v oblasti řízení podnikové informatiky. 9

1. Metodiky řízení IT

1.4

Podniková informatika v praxi v České republice

Cílem této kapitoly je identifikovat stav, v jakém se nachází řízení informatiky v ČR a zjistit, proč nejsou v množství případů využívány metodiky ITIL a COBIT.

1.4.1

Hlavní problémy v řízení informatiky

Dodržování prověřených metodik je určitě správnou cestou, po které jít, avšak ne vždy se o společnosti snaží nebo k tomu pro ně existuje řada překážek, které jim v tom brání. Jak ukazuje výzkum provedený Katedrou informačních technologií Vysoké školy ekonomické v Praze v únoru roku 2012 na semináři ČSSI8 [15], mezi nejzásadnější problémy v oblasti řízení informatiky z pohledu pracovníků konkrétních společností patří: • Chybějící strategie informatiky, • nedostatečné řízení nákladů na informatiku, • chybějící katalog informatických služeb, • orientace na strategické aplikace9 , • sledování návratnosti investic, • řízení personálních zdrojů pro rozvoj informatiky. Mezi další problémy v řízení podnikové informatiky, které byly v rámci daného výzkumu zjištěny, patří zejména nízká míra dokumentace procesů, či dokumentace bez dalšího využití (do těchto dvou kategorií spadá až 60 % podniků).

1.4.2

Využívání metodik ITIL a COBIT pro řízení podnikové informatiky v ČR

Z obrázku 1.1 je patrné, že téměř polovina respondentů odpovídala záporně na otázku, zda využívají metodiku ITIL. Část respondentů využívala ně8

Česká společnost pro systémovou integraci Strategickými aplikacemi jsou označovány ty aplikace, které rozhodujícím způsobem přispívají ke zvyšování konkurenceschopnosti podniku. Příkladem jsou ERP, Business intelligence či CRM systémy 9

10

1.4. Podniková informatika v praxi v České republice

Obrázek 1.1: Využití metodiky ITIL v řízení informatiky [%], zdroj: [15]

které její části, avšak komplexního využití se metodika dočkala pouze v 6 % případů. Co se týče metodiky COBIT, tak je situace ještě horší, konkrétně 53 % dotazovaných přiznalo, že metodiku nevyužívá vůbec a 12 % ji využívá pouze v oblasti strategického řízení, ostatní na tuto otázku neodpověděli, což je možné vysvětlit tak, že metodiku také nevyužívají. Mezi nejpravděpodobnější příčiny této situace patří relativně velká složitost metodik, velké nároky na čas a finance potřebné pro jejich implementaci, nutnost nastudovat rozsáhlou dokumentaci a v neposlední řadě jsou kladeny vysoké nároky na znalosti pracovníků. Vzhledem k těmto faktorům je pravděpodobnější, že spíše velké firmy budou tyto metodiky využívat, zatímco malé firmy budou mít větší problémy vyhradit potřebné zdroje na implementaci. Rozdíl ve využívání je možné vidět například na obrázku 1.2, který srovnává míru definování procesů podle velikosti podniku. Průzkum z roku 2006 [2] ukázal významnou závislost relativního počtu certifikovaných firem na velikosti podniku, kdy se mezi nejmenšími podniky mohlo pyšnit certifikací v oblasti řízení IT ani ne 18 % z nich, oproti tomu mezi firmami nad 25 zaměstnanců již byla více než polovina certifikována. Součástí průzkumu byla i snaha zjistit, proč je mezi malými podniky tak málo certifikovaných subjektů. Výsledky se neliší od předpokladů zmíněných 11

1. Metodiky řízení IT

Obrázek 1.2: Míra definování procesů v závislosti na velikosti podniku [%], zdroj: [4]

výše, kdy největší překážkou pro malé firmy jsou zdroje a složitost norem, pro než neexistuje dostatečně "jednoduchý"návod na jejich implementaci. Většina z těchto podniků však zájem o certifikaci má, avšak zmíněné bariéry jim k tomu blokují cestu.

12

Kapitola

Metodika MBI Nově vznikající metodika MBI10 má být odpovědí na problémy zmiňované v předchozí kapitole. Hlavním cílem, který si autoři kladli při vytváření metodiky bylo zvýšit využití metodik řízení IT v praxi, přičemž se metodika zaměřuje hlavně na malé a střední firmy, které se s těmito problémy potýkají nejvíce a které mají, ač často nechtěně, k metodikám a certifikacím cestu uzavřenou, a to nejvíce svými časovými a finančními omezeními. Metodika MBI je součástí metodiky MMDIS11 vyvinuté KIT VŠE12 v Praze.

2.1

Faktory ovlivňující vývoj MBI

Návrh metodiky vychází z rozsáhlých analýz a průzkumů. Jednou z hlavních otázek, které vyvstaly před samotnou tvorbou modelu, bylo, zda by se měla metodika ubírat směrem k univerzálně platnému modelu či zda respektovat fakt, že se podniky z různých odvětví různých velikostí mohou lišit i co do požadavků na řízení IT. Na základě výzkumů KIT VŠE, jak vlastních, tak cizích, bylo zjištěno, že by podoba modelu řízení měla být závislá na podniku samotném a že i například dva podniky ze stejného odvětví, které jsou stejně velké, mohou mít naprosto odlišné požadavky na model řízení IT. O nalezení či vytvoření řešení pro daný podnik by se měl starat CIO13 spolu se svým týmem, jelikož je z pohledu řízení IT nejkompetentnější osobou, respektive skupinou lidí ve společnosti. 10

Management of Business Informatics Multidimensional Management and Design of Information Systems 12 Katedra informačních technologií Vysoké školy ekonomické 13 Chief Information Officer 11

13

2

2. Metodika MBI Mezi faktory, které byly brány v potaz při vývoji metodiky patří například: • Faktory společné všem podnikům: – stav hospodářského prostředí, – stav legislativy, – situace na IT trhu, – aktuální úroveň znalostí IT komunity. • Faktory specifické pro jednotlivé podniky: – význam IT pro daný sektor, – význam IT pro realizaci cílů podniku, – velikost podniku, – rozdělení kompetencí a pravomocí v řízení informatiky, – zvolený typ IT strategie, – zaměření IT služeb, – náležitost podniku do soukromého či veřejného sektoru, – počet zaměstnanců a uživatelů IS a úroveň jejich znalostí, – rozsah a úroveň outsourcingu, – podniková kultura.

2.2

Cíl metodiky

Hlavním cílem metodiky bylo poskytnout řídícím pracovníkům IT metodický rámec, který by mohli jednoduše využívat pro řízení podnikové informatiky. Tento rámec si zakládá na tzv. best practices14 . Důležitým faktem, který je třeba zmínit je ten, že metodika se nezaměřuje na podniky, jejichž hlavním předmětem podnikání je IT jako takové, a to hlavně z důvodu, že řízení IT v těchto společnostech funguje na jiné, jednodušší, bázi, kdy je jejich cílem udržovat pouze takové služby, které přinášejí zisk. Pro ostatní společnosti může být nutné udržovat služby, které jsou nutné pro dosažení vlastních business cílů. Hlavní přínos modelu vidí autoři v následujících oblastech, které usnadňují nebo pomáhají řízení podnikové informatiky: 14

14

Nejlepší známá řešení, která byla ověřena v praxi

2.3. Struktura MBI • zaznamenávání a dokumentace v podniku implementovaného systému řízení podnikové informatiky, • návrh a implementace nového systému řízení IT, • mapování jednotlivých částí systému řízení na mezinárodně uznávané metodiky, standardy a nejlepší praktiky • využití best practice řešení konkrétních problémů Vzhledem k výše zmíněnému množství faktorů, které mohou být různé napříč jednotlivými podniky je nespornou výhodou možnost přizpůsobit model vlastním potřebám a využívat z něj jenom ty části, které zrovna ta která firma potřebuje, či si nejlepší praktiky definované v modelu upravit tak, jak to dané firmě bude vyhovovat nejvíce a vytvořit si tím pádem vlastní model řízení podnikové informatiky, který je založen na best practices, avšak zároveň je postaven přesně na míru danému podniku. Druhotným cílem metodiky je poskytnout budoucím manažerům přehled o tom, jak by mělo fungovat řízení informatiky a na jakých principech je založeno.

2.3 2.3.1

Struktura MBI Úlohy

Hlavním stavebním kamenem metodiky MBI jsou úlohy, jak je vidět na obrázku 2.1, které se pak vážou na řadu dalších entit a tvoří hlavní jednotku řízení podnikové informatiky. Úloha obsahuje popis, jak řešit nějakou konkrétní situaci, jako příklady mohou posloužit následující úlohy: • U0001A - Plán řešení informační strategie, • U011A - Vymezení subjektu, pro který se strategie zpracovává, a jeho významného okolí, • U101A - Vytvoření a rozvoj katalogu služeb • U221A - Analýzy stavu personálních zdrojů a jejich kvalifikace Každá entita v MBI má svůj unikátní identifikátor, u úloh je to v seznamu vypsaný identifikátor ve tvaru UxxxY, kde U označuje úlohu, xxx je číslo úlohy a Y zastupuje variantu úlohy. Varianty úlohy jsou v modelu 15

2. Metodika MBI

Obrázek 2.1: Metamodel MBI

16

2.3. Struktura MBI obsaženy proto, že některé druhy společností se na stejnou úlohu mohou dívat jinak, případně se na ně vztahují například jiné legislativní požadavky a řešení pro ně může být odlišné. Je však zbytečné, aby do svého modelu přidávali úlohu, která je vhodným řešením daného problému pro jiný typ společnosti, když už ve svém modelu řešení daného problému mají a navíc takové, které jim vyhovuje nejvíce. Vzhledem ke značnému počtu úloh v modelu jsou pro lepší orientaci úlohy tříděny do dvouúrovňové hierarchické struktury. První úrovní dělení jsou domény řízení, které rozdělují úlohy podle toho, jaké části řízení IT se týkají. Mezi domény řízení patří: • Strategické řízení, • řízení informatických služeb, • řízení informatických zdrojů, • řízení ekonomiky podnikové informatiky, • řízení rozvoje podnikové informatiky, • řízení provozu podnikové informatiky. Domény řízení se dále dělí na skupiny úloh, které seskupují úlohy do společných kategorií. Jako příklad skupin úloh mohou posloužit následující skupiny spadající do domény řízení informatických zdrojů: • Řízení datových zdrojů, • řízení technologických zdrojů, • řízení personálních zdrojů.

2.3.2

Další významné entity v MBI

2.3.2.1

Schéma úlohy a klíčové činnosti

Pro každou úlohu platí, že může mít přiřazeno schéma, které znázorňuje postup, jak při plnění úlohy správně postupovat. Pokud je potřeba k jednotlivým krokům přidat detailnější popisy, je nutné vyplnit klíčové činnosti, což jsou kroky, jak již z jejich názvu vyplývá, které je třeba pro splnění úlohy učinit. 17

2. Metodika MBI 2.3.2.2

Role

Role v MBI slouží ke znázornění zodpovědností týkajících se dané úlohy, konkrétně je využíváno RACI matice, která definuje různé druhy zodpovědností a míry účasti na splnění dané úlohy. 2.3.2.3

Dokumenty

Častým vstupem či výstupem úloh bývají dokumenty. Například pro úlohu U105A Příprava a uzavírání SLA je vstupním dokumentem katalog služeb a výstupem je smlouva s konkrétním zákazníkem o poskytování některé ze služeb. 2.3.2.4

Metody

Pod označením metoda se skrývá způsob, jakým můžeme dosáhnout kýženého cíle. Jedná se o osvědčené a formalizované postupy. 2.3.2.5

Referenční metodika a referenční proces

Vazba úlohy na referenční metodiku a referenční proces umožňuje namapovat úlohy MBI na procesy ostatních metodik a standardů, jako například ITIL, COBIT, PRINCE2, ISO 20000. Každá z úloh MBI může obsahovat více vazeb na referenční procesy a metodiky a stejně tak je tomu i naopak, že jeden referenční proces (resp. metodika) může být vázán na více úloh MBI. Tato vazba je využitelná například při ověřování shody modelu MBI a referenční metodiky. 2.3.2.6

Critical Success Factors

Klíčové faktory úspěchu, anglicky Critical Success Factors (CSF), definují, co je potřeba zajistit, aby bylo možné úlohu splnit. Mezi CSF může patřit: • Podpora vrcholového vedení, • zkušený vedoucí projektu, • seznámení týmu s metodikou. 2.3.2.7

Praktiky

Praktika definuje doporučení, které usnadní realizaci úlohy. V rámci každé úlohy může být navrženo více praktik, ale jejich dodržení není mandatorní. 18

2.3. Struktura MBI 2.3.2.8

Životní situace

Vztah úlohy k nějaké životní situaci umožňuje na základě právě této životní situace získat seznam úloh, které nám pomohou danou situaci vyřešit. Konkrétně se může jednat například o životní situaci Je třeba snížit rozpočet na IT při zachování dosavadní úrovně služeb. 2.3.2.9

Vlastnosti informačního systému

Na obdobném principu jako spojení úloh a životních situací funguje i napojení úloh na vlastnosti informačního systému. V případě, že je třeba ověřit nějakou vlastnost informačního systému, je možné si v modelu vyhledat jenom úlohy týkající se dané vlastnosti a zajistit jejich splnění. Mezi vlastnosti informačního systému popsané ve výchozím nastavení MBI jsou: • Pokrytí požadované funkcionality • dostupnost, včasnost, správnost a důvěryhodnost potřebných funkcí a informací • soulad s legislativou • uživatelská přívětivost • bezpečnost, • flexibilita, • otevřenost, • integrita, • standardizace, • výkonnost, • efektivita. 2.3.2.10

Objekty řízení

Další kritérium k vyhledávání úloh zastupují objekty řízení, což jsou objekty podnikové informatiky či objekty podniku. Mezi objekty podnikové informatiky patří: • ICT služby, 19

2. Metodika MBI • ICT procesy, • ICT zdroje: – aplikace (ASW), – technologické zdroje (ZSW, HW, komunikační infrastruktura), – datové zdroje, – finanční zdroje, – personální zdroje ICT útvaru a znalosti, • organizace ICT útvaru, • pravidla řízení podnikové informatiky, • ICT projekty. Mezi objekty podniku můžeme zahrnout: • podnikové procesy, • podnikovou organizaci, • podnikové směrnice a pravidla, • externí partnery, můžeme také hovořit o marketingovém mikroprostředí, • rozvojové projekty podniku. 2.3.2.11

Metriky a dimenze

Aby bylo možné nějakým formálním způsobem měřit míru dosažení cíle úlohy, byly do modelu zapojeny i metriky. Každá metrika může v rámci úlohy vystupovat jako KGI15 či KPI16 , případně nemusí být ani KGI ani KPI. Metriky označené jako KGI vyjadřují míru dosažení cíle úlohy, zatímco KPI metriky měří kvalitativní a kvantitativní parametry úlohy. V případě metrik je možné definovat i IT podpůrné aplikace, které slouží k měření dané metriky. Těsně k metrikám se váží dimenze, které reprezentují analytická hlediska pro identifikaci a hodnocení sledovaných ukazatelů. 15 16

20

Key goal indicator Key performance indicator

2.4. Srovnání s metodikami ITIL a COBIT 2.3.2.12

IT podpůrné aplikace

Mimo použití podpůrných aplikací pro měření metrik je možné pro úlohu definovat aplikace, které úloha používá pro splnění svého cíle. 2.3.2.13

Charakteristika podniku a profil

Velmi důležitou součástí modelu je i charakteristika podniku a jeho profil, na jejichž základě je pro podnik vytvořen prvotní model, který je potom dále přizpůsobován. Toto však platí pouze pro použití modelu popsané v sekci 2.5.2.

2.4

Srovnání s metodikami ITIL a COBIT

Nemělo by smysl vyvíjet metodiku, která by se z velké části podobala zavedeným metodikám jako ITIL a COBIT. I když z těchto metodik MBI čerpá podklady a často mapuje své prvky právě na tyto metodiky, existují zásadní odlišnosti, které by měly v konečném důsledku znamenat větší adaptabilitu MBI ve srovnání s ITIL a COBIT, a to zejména v oblasti SMB17 . Tyto podniky s menším počtem zaměstnanců charakterizuje hlavně jejich rozmanitost, kterou MBI respektuje a bere v potaz, že každý podnik má jiné požadavky a tím pádem neexistuje jeden obecně platný model. S tímto souvisí i to, že MBI respektuje oproti velkým podnikům širší pravomoce a zodpovědnosti jednotlivých zaměstnanců v SMB, takže zodpovědnosti za vykonávání úloh z modelu řízení si může každá organizace nastavit sama. Mezi hlavními znaky, kterými se MBI odlišuje, jsou: • Zaměření na SMB, • součástí užívání modelu je přizpůsobení specifickým podmínkám daného podniku, • základ modelu vychází z přesně definovaného metamodelu2.1, • jednotlivé prvky jsou mapovány na vybrané metodiky a standardy.

2.5

Způsob využití metodiky

Pokud se organizace rozhodne využívat metodiku MBI má k tomu připraveny dva způsoby použití. První možností je využití modelu tzv. Ad hoc, 17

Small and medium–sized businesses neboli malé a střední firmy

21

2. Metodika MBI tato možnost je cílena spíše na menší podniky a druhá varianta zahrnuje vytvoření modelu na míru danému podniku.

2.5.1

Ad hoc využití

Často se stává, že podnik potřebuje vyřešit jeden konkrétní problém, vylepšit jeden aspekt podnikové informatiky a nemá zájem či prostředky na to procházet komplexní metodiky a hledat nejlepší řešení jeho konkrétní situace. Pro tento případ umožňuje metodika ad hoc využití, díky kterému si uživatel může vyfiltrovat úlohy z generického, které jsou pro něj v tu chvíli důležité. Filtrování je možné na základě následujících 4 faktorů: • Životní situace, • objekt řízení, • vlastnost informačního systému, • typ podniku. Zvolením příslušných filtrů je možné ihned získat seznam úloh, které řeší situaci, kdy v podniku náklady na informatiku přesahují povolený rozpočet. Pokud uživatel navíc zvolí objekt řízení aplikace ASW, Efektivitu jako vlastnost IS a svůj obor podnikání, například Bankovnictví, dostane seznam úloh, které radí, jak snížit náklady na informatiku pomocí úprav aplikačního software a které budou vést ke zvýšení efektivity využívání tohoto software. Vše bude mít navíc seřazeno podle vhodnosti pro společnosti podnikající v bankovnictví. Tento unikátní nástroj dodává metodice nesrovnatelnou výhodu v jednoduchosti používání oproti ostatním metodikám, a to hlavně proto, že nároky na znalosti uživatele metodiky jsou prakticky nulové. Uživateli stačí k užívání metodiky vědět jen jedinou věc, a tou je problém, který chce aktuálně vyřešit.

2.5.2

Vytvoření podnikového modelu

Pro větší podniky, či podniky, které mají zájem o striktnější definici podnikových procesů je zde možnost vytvořit si vlastní podnikový model. Proces funguje tak, že si uživatel - vlastník modelu (detailní popis role je k nalezení v sekci 3.1.4.2) - při vytváření účtu zadá údaje o podniku, konkrétně obor podnikání a počet zaměstnanců. 22

2.6. Verze MBI a budoucí vývoj Následuje krok, kdy je třeba vytvořit podnikový model. Při vytváření modelu je nejdříve uživateli předvybrána sada úloh, které jsou vhodné pro jeho typ podniku. Tato sada úloh, společně s přidruženými objekty, je nazývána specifickým modelem18 . Dalším krokem je přizpůsobení modelu, kdy uživatel ze specifického modelu odebere ty úlohy, které nepovažuje za důležité a může si naopak přidat ty úlohy z generického modelu, které by ve svém modelu chtěl mít a nebyly zařazeny do specifického modelu. Po přizpůsobení je model již připraven k používání. Uživatel si může procházet úlohy rozdělené do skupin a domén a hlavním rozdílem mezi tímto a ad hoc přístupem je ten, že v případě podnikového modelu má uživatel možnost si editovat veškeré objekty svého modelu, mazat je, či vytvářet úplně nové, čímž vznikne unikátní model, který je vytvořen přímo na míru podniku, který však vychází z nejlepších praktik.

2.6

Verze MBI a budoucí vývoj

Možnost vytváření podnikových modelů ve webové aplikaci je součástí až druhé verze metodiky. První verze metodiky vyšla knižně pod názvem Management podnikové informatiky [5]. V této verzi je zahrnut popis struktury modelu a seznam objektů, se kterými metodika pracuje spolu s obsahem klíčových objektů modelu. Druhá verze, jejích součástí je i výstup této práce, je plánována na první kvartál roku 2014. Mimo systému pro správu objektů MBI, který je výstupem práce Bc. Ondřeje Kofroně [6] a systému pro využívání metodiky pro koncové uživatele bude součástí další verze i doplnění objektů tak, aby model pokrýval všechny úlohy, které jsou aplikovatelné v SMB. Dále je v plánu aktualizace úloh ve skupině Řízení rozvoje služeb podnikové informatiky, a to hlavně s cílem držet si aktuální úlohy i pro nové trendy v IT jako jsou mobilní aplikace, cloud computing, BI či sociální sítě. O rok později, čili v prvním čtvrtletí roku 2015 by měla být podle plánu uvolněna třetí verze MBI, která bude obsahovat nově metodiku použití MBI jako nástroje pro audit systému řízení informatiky v podniku. Při vývoji této verze budou brány v potaz připomínky a návrhy uživatelů, které se objeví v průběhu provozu metodiky v první a druhé verzi. Předpokládá se, že v rámci třetí verze bude vytvořena sociální síť uživatelů MBI, která bude sloužit k dalšímu rozvoji metodiky. Uživatelé by si v ideálním případě měli vyměňovat zkušenosti s používáním metodiky a 18

Specifický model označuje model, který v sobě zahrnuje úlohy, které jsou pro dané odvětví nejvhodnější

23

2. Metodika MBI sdílet své modely, díky čemuž by docházelo ke zdokonalování modelu generického. Zároveň by takto bylo možné získat zpětnou vazbu od uživatelů k nejmodernějším trendům a vyvíjet model, který bude schopen podat nejlepší řešení aktuálních problémů.

24

Kapitola

Implementace systému pro využívání metodiky 3.1

Analýza a návrh

Cílem této části je prozkoumat požadovanou funkcionalitu a identifikovat potencionální rizika, která by mohla mít negativní dopad na aplikaci v době implementace. Základem analýzy byla identifikace aktérů, kteří budou se systémem interagovat, identifikace veškerých datových struktur, se kterými se pracuje a hlavních interakcí mezi nimi.

3.1.1

Problémy tištěné verze metodik

V případě tištěných verzí metodik mohou vznikat nesrovnalosti při úpravách objektů, a to zejména asociací. Když by například došlo ke změně názvu uživatelské role, bylo by třeba tuto změnu propagovat do všech úloh, ve kterých se vyskytuje, což může vést k opomenutí některých výskytů a tím pádem nepřesnosti modelu. Další nevýhodou, která se týká také aktualizace je to, že v případě vydání nové verze si uživatelé musí sehnat nový výtisk, chtějí-li mít vše aktuální. Mezi nejzávažnější nevýhody tištěných verzí však patří za prvé nízká možnost přizpůsobení metodiky a hlavně vyhledávání relevantních objektů. Všechny tyto problémy by měly být odstraněny se zavedením aplikace pro správu a užívání modelu, která je cílem této práce a práce kolegy Kofroně. 25

3

3. Implementace systému pro využívání metodiky

3.1.2

Funkční požadavky

Požadavky na funkčnost aplikace vychází hlavně ze specifikace metodiky a dají se shrnout následujícími body: • Vytváření uživatelských účtů: – registrace nového uživatele, – vytvoření uživatele s přístupem k podnikovému modelu, který ho může pouze procházet. • Ad hoc procházení generického modelu s filtrací podle: – životních situací, – objektů řízení, – vlastností informačního systému. • Ad hoc procházení generického modelu s možností řadit podle vhodnosti pro daný typ podniku • Vytvoření podnikového modelu, které se skládá z: – navržení specifického modelu, – výběru výskytů úloh, které chce uživatel zařadit do svého modelu, – kopírování generického modelu do modelu podnikového, – úprava podnikového modelu s možností dodatečně přidat či odebrat úlohy. • Úprava objektů v podnikovém modelu - vytváření, editace, mazání: – úlohy (včetně entit na ně přímo navázaných jako CSF, Klíčové činnosti apod.), – dokument, – metriky, – metody, – životní situace, – referenční procesy, – role, 26

3.1. Analýza a návrh ∗ možnost sloučit role tak, že se v nové roli spojí přiřazení jejich zodpovědností – objekty řízení, – it aplikace, – vlastnosti informačního systému. • Procházení podnikového modelu, úlohy budou tříděny do domén a skupin úloh

3.1.3

Nefunkční požadavky

• systém a databáze musejí být navrženy tak, aby umožňovaly napojení administrační části aplikace, která je vyvíjena paralelně s touto prací, • aplikaci bude možné provozovat na některém ze serverů zadavatele, • krátká doba odezvy, • pravidelné zálohování databáze a uložených souborů.

3.1.4

Role v systému

3.1.4.1

Nepřihlášený uživatel

Uživatel, který není přihlášen v systému, má jenom velmi omezené možnosti - může si buď vytvořit nový účet a nebo se přihlásit k již existujícímu účtu. Veškerá ostatní funkcionalita aplikace je přístupná až po přihlášení. 3.1.4.2

Vlastník modelu

Po úspěšné registraci vznikne nový účet, kde uživatel bude v roli vlastníka modelu. Nejdůležitější funkcionalitou je pro vlastníka modelu vytvoření podnikového modelu, který si poté může libovolně upravovat a přidávat další uživatele, kteří už mohou model pouze procházet. Dále má tento uživatel možnost spravovat veškeré objekty, se kterými se v podnikovém modelu pracuje, čili může vytvářet kompletně nové úlohy se vším potřebným. Další důležitou funkcí přístupnou vlastníkovi modelu je ad hoc procházení generického modelu. Veškeré možnosti uživatele znázorňuje use case diagram na obrázku 3.1. 27

3. Implementace systému pro využívání metodiky

Obrázek 3.1: Use case diagram pro vlastníka modelu

Obrázek 3.2: Use case diagram pro uživatele

3.1.4.3

Uživatel

Poslední rolí, která se v uživatelské části vyskytuje je uživatel, kterého má vlastník modelu možnost vytvořit. Tento uživatel má velice omezené možnosti, a to konkrétně na procházení generického a podnikového modelu. Souhrn jeho povolených akcí vyobrazuje use case diagram na obrázku 3.2. 28

3.1. Analýza a návrh

3.1.5

Domény v systému

Systém pracuje z velké části na základě metamodelu, který je součástí první verze MBI. Některé entity však musely být přizpůsobeny potřebám aplikace a některé entity byly z modelu odstraněny, jiné zase přidány. Současný doménový model je zobrazen na obrázku 3.3. Oproti původnímu modelu zde došlo k následujícím změnám: • Odstraněné / nevyužité domény: – Profil, – Charakteristika, – Hodnota charakteristiky, – Hodnota vhodnosti profilu. • Přidané domény: – Company, – User, – Person, – Document Group, – Role Group, – Technical Term, – Model. Domény Profil, Charakteristika, Hodnota charakteristiky a Hodnota vhodnosti podniku byly odstraněny z toho důvodu, že v současném použití nemá takto složitá datová struktura smysl. Ze schůzek vyplynulo, že informace, které jsou potřebné pro využívání metodiky jsou pouze obor podnikání a počet zaměstnanců, což tedy jasně směřovalo k odstranění této struktury. Mezi přidanými entitami figuruje na prvním místě entita Company, která zastupuje výše zmíněné 4 objekty a slouží k uchování nutných informací o společnosti. V aplikaci je nutné rozlišovat, kdo je autorem úloh, kdo je vlastníkem modelu apod. a také který uživatel má přístup ke kterému modelu. Z tohoto důvodu bylo nutné zavést entitu která reprezentuje osobu, a tou byla entita User společně s doplňujícími informacemi, které zastupuje entita Person. Ze schůzek, na kterých se řešil obsah diplomové práce byl vznesen požadavek na zavedení skupin dokumentů a skupin rolí, a to hlavně z důvodu 29

3. Implementace systému pro využívání metodiky

Obrázek 3.3: Doménový model 30

3.1. Analýza a návrh lepší orientace v těchto objektech. Na základě toho byly do modelu zařazeny entity Document Group a Role Group. Mezi další požadavky, které vyplynuly ze schůzek patří zavedení terminologického slovníku, jehož cílem je zajistit, aby nedocházelo k nesouladu mezi pochopením pojmu a jeho pravým významem. Následují dvě položky, které se týkají modelů - Model a Model Type. Vzhledem ke značné podobnosti podnikového a generického modelu je rozumné pracovat s nimi jako s totožnými entitami, avšak je nutné mít způsob, jak je odlišit. Entita Model tedy reprezentuje celý model, který obsahuje úlohy, dokumenty, metriky, atd. a Model Type udává, zda se jedná o model podnikový či generický.

3.1.6

Kopírování modelu

Velmi důležitou operací je pro uživatele kopírování úloh z generického modelu do modelu podnikového a z toho důvodu bylo nutné tuto operaci dobře promyslet a vybrat nejvhodnější řešení. Varianty, které se nabízí pro vytváření podnikového modelu: • Podnikový model budou tvořit pouze vazby odkazující na objekty generického modelu, • podnikový model bude vytvořen jako kopie objektů generického modelu, a to pouze pro objekty, které si uživatel vybral, ostatní objekty budou přebírány z generického modelu, • podnikový model bude vytvořen jako kopie objektů generického modelu a pouze u vybraných bude nastaven příznak, že je uživatel uvidí. 3.1.6.1

Podnikový model budou tvořit pouze vazby odkazující na objekty generického modelu

Realizace kopírování generického modelu způsobem, kdy jsou pouze vytvořeny vazby mezi nově vytvořeným podnikovým modelem a existujícími úlohami a dalšími objekty z generického modelu, by byla vhodná v případě, že by bylo cílem vytvořit podnikový model jen pro čtení. U takového modelu by nebylo možné přizpůsobovat si úlohy podle svého, model by působil vlastně jen jako vyfiltrovaná verze generického modelu. Výhodou by však na druhé straně byl fakt, že se úlohy aktualizují všem uživatelů poté, co budou upraveny administrátorem. Na konzultacích k projektu bylo dosaženo závěru, že je nutné, aby si uživatelé mohli přizpůsobovat svůj podnikový model, což samo o sobě tuto 31

3. Implementace systému pro využívání metodiky variantu znemožňuje a jako druhý argument proti zvolení této varianty byla dříve zmíněná výhoda, a to automatická aktualizace podnikového modelu při změně generického modelu. Ukázalo se, že změny v podnikovém modelu, které uživatel nemá pod kontrolou nejsou žádoucí, čili tato varianta je zcela jistě nepoužitelná. 3.1.6.2

Podnikový model bude vytvořen jako kopie objektů generického modelu, a to pouze pro objekty, které si uživatel vybral, ostatní objekty budou přebírány z generického modelu

Další variantou řešení způsobu kopírování modelu je kopírování pouze vybrané části objektů a zbytek objektů by byl řešen vazbou na generický model. Výhodou této varianty je možnost editovat si objekty, které chceme a zároveň nechat aktualizovat objekty, které si vybereme. Na druhou stranu by se v modelu objevovaly i nově přidané objekty, což nemusí být žádoucí, chce-li mít nějaká společnost opravdu jednoduchý model, ve kterém by nemátly nepoužívané objekty. Navíc u existujících objektů by docházelo k aktualizaci, což může být výhoda, ale když uživatel bude očekávat nějaký objekt, se kterým ve svém podnikovém modelu pracoval delší dobu a poté se mu zničehonic tento objekt změnil. Je však otázkou, zda v tomto případě převažují výhody nad nevýhodami, ale to bude možné zjistit až za provozu na základě četnosti a rozsahu prováděných změn v objektech. Mezi nevýhody patří složitější implementace, kdy je třeba u každého objektu sledovat, ke kterému objektu se váže a na základě toho vybírat, zda budou prvky generického modelu, nebo v případě, že má uživatel tyto prvky zkopírované, tak místo nich ty uživatelovy. Stejně jako v předchozím případě se automatická aktualizace ukázala jako problémový faktor a bez automatické aktualizace se tato varianta z funkční stránky jeví stejně jako varianta následující, což vzhledem ke složitější implementaci znamená zamítnutí i této možnosti. 3.1.6.3

Podnikový model bude vytvořen jako kopie objektů generického modelu a pouze u vybraných bude nastaven příznak, že je uživatel uvidí

Třetí varianta je tou, která byla nakonec zvolena - jedná se o variantu, kdy je při vytváření podnikového modelu vybrána sada úloh, které uživatel chce využívat. Po výběru úloh jsou zkopírovány jak všechny úlohy, tak všechny asociované objekty z generického modelu a u vybraných je nastaveno, že budou použity v podnikovém modelu. 32

3.2. Volba platformy Pokud bude mít uživatel později zájem o přidání dosud nepřidaných objektů, je možné jenom změnit nastavení u daných objektů, že jsou uživatelem vybrány a může s nimi pracovat. V případě, že by se objevil v budoucnu požadavek na možnost volitelné aktualizace - například přidání nových úloh, které v době vytváření nebyly součástí generického modelu - je možné jednoduše získat seznam úloh z generického modelu a zařadit nově vybrané do podnikového.

3.2 3.2.1

Volba platformy Architektura aplikace

Volba architektury vychází z požadavků na aplikaci, které by nebylo možné splnit, pokud by bylo použito architektury standalone desktopové aplikace19 , a to hlavně proto, že je třeba vždy pracovat s aktuálními daty. Jasnou volbou byla architektura klient-server, která se vyznačuje tím, že na straně uživatele je klientská část aplikace, která získává a posílá data jednomu či více serverům. V případě takto řešených aplikací je třeba vyřešit otázku, zda bude vhodným řešením tlustý nebo tenký klient. Tlustý klient je takový, který zná a vykonává veškerou logiku aplikace a komunikuje se serverem pouze s požadavky na data, která zpracuje a zase odešle zpět serveru. Hlavní nevýhodou tohoto řešení je nutnost instalovat aplikace na všechna zařízení, která mají systém využívat, což může být ve větších firmách velmi nákladné. Na druhou stranu bývá práce s tlustým klientem rychlejší, jelikož není třeba kvůli každé operaci komunikovat se serverem. Kromě nutnosti instalace aplikace na všechny stanice má obecně tlustý klient řadu dalších nevýhod, kterými jsou například: • Vyšší HW nároky na straně klienta, • vyšší nároky na přenosový kanál, • složité aktualizace a opravy, • nutnost vyvíjet klientskou aplikaci pro různé verze operačních systému a různý HW. Z pohledu aplikace pro využívání MBI není první bod moc relevantní, jelikož aplikace není nijak výpočetně ani paměťově náročná. Nároky na přenos 19

Aplikace, která nevyžaduje internetové připojení pro svůj provoz

33

3. Implementace systému pro využívání metodiky dat nejsou vysoké, čili tato položka také problémová není. Velkým problémem je však třetí bod v seznamu - aktualizace a opravy. Hlavním důvodem je to, že metodika je stále ve vývoji a tím pádem se očekává, že se řada aspektů jejího používání bude měnit, což bude znamenat častou nutnost měnit logiku aplikace a časté rozšiřování funkcionality. To ovšem vzhledem k nákladům na aktualizace software na všech stanicích není žádoucí. Tlustý klient má kromě nevýhod samozřejmě i řadu výhod, mezi nimiž je například možnost pracovat s aplikací bez připojení k internetu, či nižší HW nároky na server, avšak žádné z těchto kladných stránek nejsou v našem případě přínosné a tím pádem byla jasně zvolena alternativní možnost tenkého klienta. V případě tenkého klienta má uživatel na své straně prezentační vrstvu a veškeré logické operace s daty zajišťuje server, který uživateli dodá pouze výsledek operace. Nespornou výhodou této architektury je fakt, že k využívání aplikace stačí internetový prohlížeč, který je přítomný na každém počítači či tabletu a také na řadě mobilních telefonů, což znamená nulové náklady na instalaci aplikace, stejně tak je tomu i v případě aktualizací, které se projeví ihned všem klientům. Jedinou nevýhodou tenkého klienta je absence možnosti pracovat se systémem bez připojení k internetu. To ale v dnešní době poměrně irelevantní, jelikož je možné se připojit k internetu prakticky na každém rohu, a velké množství lidí je připojeno pomocí mobilního telefonu neustále. Výsledkem je, že systém poběží jako webová aplikace v prohlížeči.

3.2.2

Volba programovacího jazyka

Pro realizaci systému byl zvolen programovací jazyk PHP, jedná se o jeden z nejrozšířenějších, ne-li nejrozšířenější, jazyk volený pro tvorbu webových aplikací. S vývojem aplikací v jazyce PHP mám již několikaleté zkušenosti, což byl také jeden z důvodů pro výběr tohoto jazyka. Spolu s programovacím jazykem jsme vybírali i framework, který pro vývoj aplikace zvolíme. Volba padla na framework CakePHP, se kterým mám jen kladné zkušenosti. Framework z různých testů ([1],[8],[7]) vychází jako jeden z pomalejších, avšak s přihlédnutím k očekávanému využití aplikace zpočátku řádově desítkami, maximálně stovkami uživatelů je tento fakt zanedbatelný a převládají výhody plynoucí z použití známého frameworku. Z vlastní zkušenosti však vím, že s frameworkem nebyl problém ani v aplikaci se stovkami tisíc unikátních uživatelů měsíčně - jednalo se o aplikaci pro server www.uschovna.cz, která sloužila uživatelům ke správě vlastních zásilek a administrátorům ke správě obsahu a nastavování serverů. 34

3.2. Volba platformy 3.2.2.1

CakePHP

CakePHP je open-source MVC framework, který si klade za cíl co nejvíce urychlit vývoj webových aplikací. Vývoj tohoto frameworku je mimo jiné sponzorován i firmou Microsoft, což vypovídá o jeho potenciálu. V následujících odstavcích budou shrnuty vybrané vlastnosti frameworku, díky kterým se stal oblíbeným a často využívaným frameworkem. Každá webová aplikace musí nějakým způsobem řešit zabezpečení proti případnému útoku. CakePHP poskytuje komponentu, která chrání před různými druhy útoků či škodlivé činnosti. Více o bezpečnostních opatřeních poskytovaných frameworkem a využívaných v aplikaci je možné se dočíst v kapitole 4.5. Při tvorbě vizuální stránky aplikace je využit šablonovací systém, který je integrální součástí CakePHP a umožňuje mimo jiné například ukládat do mezipaměti kód jednotlivých view souborů, aby bylo dosaženo rychlejšího načítání stránek. Navíc je možné ukládat do cache například jen vybrané části stránky, díky čemuž je možné kombinovat cacheování s dynamickým obsahem. CakePHP disponuje vlastní implementací ORM20 , díky čemuž je kterákoliv aplikace nezávislá na tom, zda funguje na MySQL (verze 4 a vyšší), PostgreSQL, Microsoft SQL server či SQLite. V nové verzi CakePHP, ve verzi 3, je navíc v plánu přidání podpory pro další databázové stroje. Programátor nepíše SQL dorazy, které by byly specifické pro danou databázi, nýbrž každý model je vybaven sadou CRUD21 operací u kterých framework sám rozhodne, jak je přeložit do jazyka vybrané databáze. Mocným nástrojem pro aplikace vyžadující velmi specifickou definici přístupových práv, který však při implementaci systému pro využívání MBI nebyl využit, je tzv. ACL22 . ACL umožňuje přidělovat oprávnění provádět akce na úrovni uživatelů či uživatelských skupin. Je tak možné definovat, kdo bude mít k jaké akci přístup a naopak kdo bude od dané akce zcela odstíněn. Validace formulářů byla vždy činností, která se napříč webovými aplikacemi opakovala stále dokola. CakePHP nabízí možnost, jak tuto činnost automatizovat a pomocí jednoduchých definic vytvořit komplexní validace. Za jednu z největších výhod frameworku považuji jeho preferenci konvencí před konfigurací, čímž je míněno to, že je pro aplikace doporučováno používat jistou sadu konvencí pro pojmenovávání tříd, souborů a databázových polí a tabulek. Dodržování těchto konvencí má hned dvě obrovské vý20

Objektově relační mapování Create, Read, Update, Delete - základní sada operací pro správu objektů 22 Access Control List 21

35

3. Implementace systému pro využívání metodiky hody - první je to, že pokud se někdo cizí, kdo však již s CakePHP pracoval, dostane k aplikaci, kterou předtím neviděl, dokáže se rychle zorientovat a pochopit jak aplikace funguje a začít na ní rychleji pracovat. Druhou, častěji oceňovanou výhodou je možnost vygenerovat si kostru aplikace na základě návrhu databáze. Při dodržení konvencí si dokáže framework automaticky zjistit, jaké jsou vazby mezi různými objekty a podle toho připravit základ aplikace. V rámci zadání této práce se objevuje i požadavek na otestování aplikace. CakePHP využívá testovacího frameworku PHPUnit, který se, jak z názvu vyplývá, zaměřuje na provádění unit testů. Aplikace bude k ověření správné funkcionality využívat testů napsaných v tomto frameworku. Další neoddiskutovatelnou výhodou je rozsáhlá komunita vývojářů pracujících s CakePHP, díky čemuž je framework rychle rozvíjen a často je otázkou jen několika minut najít řešení nějakého problému, který se při implementaci vyskytne.

3.2.3

Volba databáze

Pro uchovávání dat byla zvolena databáze MySQL, a to hlavně díky rozšíření a dostupnosti této databáze. S ohledem na předpokládanou nutnost vytvářet či editovat velké množství záznamů během jedné operace byl zvolen engine InnoDB, který podporuje transakce. Oproti netransakčnímu engine MyISAM vyžaduje InnoDB více diskového prostoru a ve výchozím nastavení trvají read operace na tomto engine déle, avšak InnoDB poskytuje spoustu výhod, které s přehledem vyváží zápory tohoto řešení. Mezi další nevýhody oproti MyISAM patří omezení limitu velikosti databáze na 64 TB v porovnání s 256 TB pro MyISAM, což však nejsou hodnoty, které by valnou většinu aplikací používajících libovolný z výše zmíněných engine používal jakkoliv omezovaly. Ve výčtu výhod InnoDB v porovnání s MyISAM nesmí chybět (zdroj [14]): • podpora ACID23 transakcí, • ochrana proti ztrátě dat při pádu aplikace, 23

ACID - zkratka slov Atomicity, Consistency, Isolation a Durability. Toto označení pod sebou skrývá transakce, které jsou atomické - provedou se buďto kompletně nebo vůbec, zachovávají konzistenci dat - výsledkem každé transakce je databáze v konzistentním stavu, izolované - dokud není transakce odeslána příkazem commit, nikdo se k datům změněným v transakci nedostane. Poslední vlastnost udává, že data jsou po skončení transakce uložena a ani výpadek proudu nezpůsobí jejich ztrátu

36

3.3. Životní cyklus požadavku v aplikaci

Obrázek 3.4: Diagram nasazení

• podpora cizích klíčů, • při editaci záznamů je přidán zámek pouze na daný záznam (u MyISAM je zámek na celé tabulce), • mnohem lepší škálovatelnost. Aplikace bude tedy postavena jako klient-server aplikace s tenkým klientem. Programována bude v PHP na frameworku CakePHP a pro uchování dat poslouží databáze MySQL. Na serveru bude běžet operační systém Linux a jako aplikační server poslouží Apache. Diagram nasazení v tomto případě vypadá velmi jednoduše a je znázorněn na obrázku 3.4.

3.3

Životní cyklus požadavku v aplikaci

Aplikace bude využívat architekturu MVC, která rozděluje aplikaci do vrstev - model, view a controller, kde každá z těchto vrstev se stará pouze o záležitosti, které jí přísluší. Vrstva modelu zajišťuje správu dat, což v základním pojetí znamená čtení, ukládání a mazání. Controller se stará o byznys logiku aplikace a View definuje, jak bude aplikace vypadat. Jednotlivé vrstvy pracují nezávisle na sobě, což dovoluje v aplikaci vyměnit i celou vrstvu, aniž by byly ovlivněny zbývající dvě. Životní cyklus zpracování požadavku je k vidění na obrázku 3.5. V prvním kroku klient vyšle na server požadavek, adresa může být například www.example.com/tasks/list/1. Dispatcher požadavek přijme a nasměruje 37

3. Implementace systému pro využívání metodiky

Obrázek 3.5: Životní cyklus požadavku v CakePHP

na správný controller. Mezi controllerem a dispatcherem je možné si všimnout bloku s názvem Router, který definuje mapování vlastních url na jednotlivé akce. Výchozí nastavení CakePHP je takové, že adresa se skládá z následujících částí: • doména spolu s adresářem, ve kterém aplikace běží - www.example.com, • jméno controlleru - tasks, • akce controlleru - list, • volitelný libovolný počet parametrů - 1. V tomto případě by došlo k zavolání metody: TasksController::list(1); Router dovoluje definovat v adresách tzv. prefixy, které umožňují seskupovat akce a na základě prefixů je poté možné omezit používání akcí jenom pro administrátory, či jinou uživatelskou skupinu. Alternativní URL s admin prefixem pro akci z předchozího příkladu by bylo sestaveno takto: 38

3.3. Životní cyklus požadavku v aplikaci www.example.com/admin/tasks/list/1. V tomto případě však není volána akce list, nýbrž admin_list. Pomocí routeru je možné namapovat libovolnou URL adresu na akci, kterou si zvolíme. Router tyto URL rozluští a dalším krokem zpracování požadavku je zavolání příslušné metody controlleru. Metody controllerů, neboli akce, vykonávají byznys logiku aplikace. Šedý čtvereček v diagramu 3.5 reprezentuje tzv. callback metody, které se volají v různých okamžicích životního cyklu. Před voláním jakékoliv akce je volán callback beforeFilter, což je nejčastěji využíváno pro kontrolu, zda je uživatel přihlášen. Pokud ne, je přesměrován na přihlašovací stránku a v ostatních případech se pokračuje na volání metody controlleru. Ve valné většině případů jsou z controlleru volány metody modelu, a to aby buď data uložily nebo načetly. Zde jsou opět připraveny callback funkce, první z nich, beforeFind, umožňuje centralizovaně upravovat požadavky na získání dat z databáze. Druhá callback funkce, afterFind, je volána po získání dat z databáze a slouží k úpravě dat před tím, než se s nimi bude dále pracovat v controlleru. Dále jsou k dispozici ještě funkce beforeSave, afterSave, beforeDelete, afterDelete a další. Dalším krokem je poslání dat pro zobrazení do view. U čísla 7 je vidět obdélník znázorňující volání další callback funkce, tentokráte s název beforeRender, která slouží k úpravě dat těsně před jejich vykreslením. Prezentační vrstva aplikace se skládá z různých komponent. Nejvyšší úrovní je Layout, což je část view, která definuje základní šablonu stránky, jako například rozložení elementů a obsahuje prvky, které jsou společné všem stránkám. Uvnitř jsou potom vykreslovány views, což jsou šablony, které jsou zpravidla přiřazeny nějaké akci a nesou stejné pojmenování jako daná akce. Poslední součástí view jsou tzv. elementy, které slouží jako způsob k vložení obsahu, který je používán na více místech, aby nebylo nutné psát stále dokola stejný kód. Příkladem může být například výpis posledních článků na blogu. Po připravení šablony následují dva callbacky, které umožňují volat akce buď v okamžiku po vyrenderování view souboru včetně vložených elementů a nebo po vyrenderování view i s layoutem a všemi elementy. Výsledek je nakonec odeslán zpět klientovi.

39

Kapitola

Realizace 4.1

Platform specific model

Prvním krokem při vytváření aplikací v CakePHP bývá zpravidla vytvoření databázového schématu, a to podle konvencí, které jsou pro framework definovány. Pro pojmenovávání tabulek platí doporučení používat množná čísla s malými písmeny, čili tabulka pro uchování úloh je pojmenována tasks. U víceslovných názvů je k oddělení slov použito podtržítko, takže tabulka obsahující seznam procesů z referenčních metodik se jmenuje reference_processes. Pro vazební tabulky konvence praví používat jména obou modelů, mezi kterými je vazba, a to v abecedním pořadí a oddělené podtržítkem - příkladem je zde vazební tabulka mezi úlohami a referenčními procesy reference_processes_tasks. Další dvě doporučení se týkají sloupců v tabulce, konkrétně klíčů. Primární klíč by měl nést jméno id a všechny cizí klíče by měly být pojmenovávány názvem asociované tabulky ve tvaru podstatného jména v jednotném čísle s příponou _id. Opět konkrétní příklad, pro který poslouží cizí klíč s názvem task_group_id z tabulky tasks, který udává, do které skupiny úloh daná úloha patří. Výsledné schéma databáze je možné vidět na obrázcích 4.1, 4.2, 4.3 a 4.4. Schéma databáze bylo lehce zjednodušeno a rozděleno na 4 části, aby bylo možné se v něm orientovat. Zjednodušení se týká toho, že všechny tabulky, které mají sloupec state_id nemají v diagramech vazbu na tabulku state a stejně tak tomu je i pro tabulku mbimodel s výjimkou posledního diagramu, ve kterém tyto tabulky jsou i s příslušnými vazbami. Stav u objektů indikuje, v jaké fázi vytváření se objekt nachází, tyto stavy jsou využívány jen v administrační části, v uživatelské jsou všechny nově vytvořené a zkopírované objekty ve stavu OK, který udává, že s objektem je možné pracovat. Vazba na mbimodel říká, do kterého modelu daný objekt patří. V tabulce 41

4

4. Realizace

Obrázek 4.1: Databázové schéma - část 1

mbimodels je implicitně vytvořen jeden model, který reprezentuje generický model. Schéma databáze bylo vytvářeno v programu MySQL Workbench, který umožňuje připojit se k databázi a vytvářený diagram reprezentující schéma databáze převést na změny v dané databázi. Jelikož CakePHP v současné verzi nepodporuje namespaces, bylo nutné přejmenovat tabulku models na mbimodels, a to z důvodu, že odpovídající třída by se jmenovala Model a došlo by ke konfliktu se třídou Model, která 42

4.1. Platform specific model

Obrázek 4.2: Databázové schéma - část 2

43

4. Realizace

Obrázek 4.3: Databázové schéma - část 3 je předkem všech tříd reprezentujících model v CakePHP. Tento problém řeší CakePHP v nové verzi, avšak u této verze ještě není známo, kdy bude uvolněna. Dalším rozšířením oproti doménovému modelu je zavedení uživatelských skupin, které umožňují rozlišovat uživatele a podle skupiny, do které patří uživateli povolit či zakázat vybrané akce. V systému figurují 4 uživatelské skupiny: • Administrátor, • Editor, • Vlastník modelu, • Uživatel. 44

4.1. Platform specific model

Obrázek 4.4: Databázové schéma - část 4

45

4. Realizace První dvě z těchto skupin opravňují uživatele k přístupu do administračního rozhraní, ve kterém se edituje generický model. Zbývající dvě role byly popsány v sekci 3.1.4.

4.2

Vygenerování základu aplikace

Spolu s CakePHP je dodáván CLI24 skript, který umožňuje vygenerovat soubory Modelu, View a Controllerů, které podporují základní operace jako vytváření, čtení, úpravy a mazání záznamů. Vygenerovaný kód je opravdu jen základem a pro drtivou většinu aplikací, stejně jako tomu bylo u aplikace pro využívání MBI, je třeba tento kód značně rozšířit, aby bylo dosaženo požadované funkcionality. Hlavním přínosem generování kódu je však generování souborů s definicí modelu, v nich jsou definovány vazby na ostatní třídy. Tato část aplikace byla poté editována jen minimálně, a to v případě, kdy bylo třeba přidat nějakou novou asociaci. Z akcí v controlleru nezůstala v původní podobě prakticky žádná, jelikož ve výchozím stavu neprobíhají například žádné kontroly přístupových práv a ve výchozím nastavení dotazy hledají i asociace, které nejsou potřeba a tím pádem je prováděno velké množství dotazů, což může vést ke zbytečnému zpomalení aplikace.

4.3

Návrh uživatelského rozhraní

Uživatelské rozhraní je rozděleno na 2 hlavní části - horní menu, které slouží pro navigaci v rámci celé aplikace a hlavní část, která slouží k zobrazování informací relevantních k dané stránce. Hlavní stránka, kterou uživatel uvidí po vytvoření podnikového modelu či po kliknutí na logo MBI nebo odkaz Úvod v hlavním menu je k vidění na obrázku 4.5. Hlavní část se může dále dělit na dvě podoblasti, a to v případě editace objektů z podnikového modelu. V levé části se nachází navigace, která souvisí s daným modelem a v pravé už buďto výpis objektů či editační formulář. Rozdělení hlavní části je vidět na obrázku 4.6. 24

46

Command Line Interface - rozhraní příkazové řádky

4.4. Průběh realizace

Obrázek 4.5: Uživatelské rozhraní - hlavní stránka

Obrázek 4.6: Uživatelské rozhraní - rozdělení rozhraní

4.4 4.4.1

Průběh realizace Vytváření uživatelských účtů

Prvním požadavkem, který byl v aplikaci implementován, byla možnost vytvářet uživatelské účty, a to hlavně z toho důvodu, že by veškerá funkcionalita aplikace měla být přístupna pouze pro přihlášené uživatele. Pro zaregistrování je potřeba zadat jméno, příjmení, emailovou adresu, heslo a základní údaje o firmě jako název, obor podnikání a počet zaměstnanců. Po registraci je automaticky uživateli nastavena role vlastníka modelu, i když zatím žádný model vytvořen nemá. 47

4. Realizace

Obrázek 4.7: Ad hoc procházení generického modelu - výběr filtru

4.4.2

Ad hoc prohledávání modelu

Po možnosti vytvářet uživatelské účty byla do systému přidána funkcionalita umožňující prohledávat generický model. Prohledávání generického modelu ad hoc má sloužit uživatelům k vyhledávání konkrétních úloh podle několika kritérií. Formulář pro výběr kritérií obsahuje pouze základní výběr možností, podle kterých filtrovat a nic, co by dále uživatele mátlo, což je v souladu s cílem poskytnout co nejjednodušší možnost procházet model. Formulář pro výběr filtru je zobrazen na obrázku 4.7. Po odeslání formuláře je uživateli zobrazen seznam úloh, které vyhovují jeho dotazu a v případě, že byl zadán typ podniku, jsou tyto úlohy řazeny podle vhodnosti pro daný podnik.

4.4.3

Vytváření podnikového modelu

Jako další přišlo na řadu vytváření podnikového modelu. Hlavním cílem podnikového modelu je dát společnosti možnost upravit si objekty generického modelu tak, aby přesně vyhovovaly potřebám jejich podniku. V případě, že uživatel ještě nemá vytvořen podnikový model, bude mít na hlavní stránce, která je mu zobrazena hned po přihlášení pouze 2 možné akce, a to buď procházení generického modelu ad hoc nebo vytvoření pod48

4.4. Průběh realizace

Obrázek 4.8: Ad hoc procházení generického modelu - výsledek vyhledávání

nikového modelu. Vybere-li si uživatel možnost vytváření podnikového modelu, dostane se na obrazovku obsahující seznam úloh roztříděných do domén a skupin úloh, viz obrázek 4.9. V horní části se nachází posuvník, který umožňuje nastavit rozsah úloh, které budou do podnikového modelu předvybrány. Předvýběr úloh funguje na základě definice vhodnosti úlohy pro typ a velikost podniku, kterou zadal uživatel během registrace. Při posunu posuvníku doleva bude předvybráno pouze menší množství úloh, avšak bude se jednat o klíčové úlohy, které by měl daný podnik řešit. Přesunutí posuvníku do zcela pravé pozice naopak označí úplně všechny úlohy modelu MBI. Po fázi automatického výběru úloh na základě vhodnosti a preference uživatele ohledně rozsahu modelu je poté možné dodatečně přidat či odebrat úlohy, u kterých si uživatel myslí, že jsou pro jeho podnik důležité, nebo naopak, mají pouze mizivý přínos. Výběr úloh je prováděn pomocí zaškrtávacího pole, které je přítomno vedle každé úlohy. Implementace se zde odlišuje od procesu popsaném v textu verze 1 [5], kde stojí, že se při vytváření podnikového modelu pracuje nejdříve s ge49

4. Realizace

Obrázek 4.9: Vytváření podnikového modelu

nerickým a pak se specifickým modelem, v aplikaci se však pracuje pouze s generickým. Důvod je prostý - v průběhu realizace bylo zjištěno, že předvýběr úloh plně zastupuje funkci specifického modelu. V průběhu testování systému bylo zjištěno, že kopírování modelu pomocí funkcí pro vyhledávání a ukládání, které poskytuje CakePHP bylo velmi časově náročné. Hlavním důvodem je to, že funkce pro interakci s modelem byly postaveny tak, aby byly co nejuniverzálnější, což si vybírá daň ve formě množství dotazů, které jsou vytvářeny. V běžném provozu aplikace na tom moc nezáleží, avšak kopírování celého generického modelu je datově náročná činnost a při kopírování modelu obsahujícího 8 úloh a řádově 60 dalších asociovaných objektů bylo vykonáno téměř 600 SQL dotazů. Při představě naplnění modelu všemi úlohami a objekty, které jsou zmíněné v první verzi textu MBI bylo jasné, že skript provádějící kopii modelu 50

4.4. Průběh realizace

Obrázek 4.10: Proces vytváření podnikového modelu

51

4. Realizace by probíhal až moc dlouho, což potvrdil test se stovkou úloh. Skript automaticky zastaven po 30 sekundách běhu a zkopírována nebyla ani pětina modelu. Podrobné informace o výkonovém testování jsou shrnuty v kapitole 5. S ohledem na to, že dotazů by bylo i při nejskromnějším nastavení pro předpokládaný rozsah generického modelu řádově několik stovek, jsem se rozhodl, pro využití čistého SQL místo ORM přístupu, který poskytuje framework. Po této úpravě je prováděn konstantní počet dotazů, a to konkrétně podle počtu tabulek, ze kterých jsou data kopírována. Jedná se samozřejmě o složitější dotazy, avšak oproti původnímu řešení je jejich množství pevně dané a množství pod-dotazů či joinů se nezvyšuje s přibývajícími objekty. Při testování nově naprogramované funkcionality byla naměřena průměrná doba okolo 7 sekund na zkopírování kompletního modelu i se všemi objekty, vazbami a fyzicky uloženými soubory, které mohou být přiřazeny úlohám či dokumentům. Budeme-li tedy předpokládat, že původnímu skriptu by trvalo kopírování nejméně 150 sekund, je možné tvrdit, že napsání čistých SQL dotazů pro kopírování velkého množství dat je alespoň v tomto případě přinejmenším 20krát hospodárnější než využívání předpřipravených funkcí frameworku. Doba běhu 7 sekund se z pohledu webové aplikace může zdát příliš dlouhá, avšak vzhledem k vysoké náročnosti na množství upravovaných dat a s přihlédnutím k faktu, že tuto operaci uživatel provede jednou v průběhu existence svého uživatelského účtu, je možné tuto prodlevu považovat za přijatelnou.

4.4.4

Vytváření podnikových účtů

Po vytvoření modelu se uživateli zpřístupní řada dalších akcí, které mu možní spravovat svůj model. Jednou z těchto akcí je i možnost vytvářet uživatele, kteří mají právo procházet podnikový model, avšak již nemají právo v něm cokoliv měnit. U takového uživatele je třeba vyplnit jméno, příjmení a údaje, pomocí kterých bude možné se přihlásit - email a heslo. Tento nově vytvořený uživatel bude v databázi označen typem uživatel a jedinými dvěma akcemi, které má povoleno vykonávat je procházení generického modelu a procházení podnikového modelu.

4.4.5

Procházení podnikového modelu

Procházení podnikovým modelem je velmi podobné ad hoc využití generického modelu, vyhledává se však pouze v podnikových úlohách a není nutné 52

4.4. Průběh realizace

Obrázek 4.11: Stránka s výpisem úloh v podnikové modelu

nastavovat si řazení podle typu podniku, jelikož typ podniku byl již vybrán při registraci.

4.4.6

Správa objektů podnikového modelu

Klíčovým požadavkem na aplikaci byla možnost editovat si objekty podnikového modelu. Úvodní stránka s výpisem úloh je vyobrazena na obrázku 4.11, úprava konkrétní úlohy je k vidění na obrázku 4.12. Úlohy, a potažmo všechny ostatní objekty, je možné si na výpisu řadit podle zobrazených sloupců, což usnadňuje orientaci, podobně jako stránkování. Objekty, které jsou v tomto rozhraní editovatelné, se z velké části chovají stejně, a proto mají všechny jejich modely a controllery společné předky, což dovoluje pracovat s různými objekty stejným způsobem. Výhodou je samozřejmě menší opakování kódu a menší náchylnost k chybám. 4.4.6.1

Spojování podnikových rolí

Podnikové role disponují oproti ostatním objektům rozšířenou funkcionalitou o možnost sloučit více rolí do jedné. Tato funkčnost je zejména užitečná vzhledem k tomu, že v různých společnostech bývají často zodpovědnosti definovány odlišně. Sloučení provádí uživatel tak, že si v seznamu rolí zaškrtne ty, které chce sloučit a tlačítkem u role zvolí, že chce role sloučit a 53

4. Realizace

Obrázek 4.12: Editace objektu z podnikového modelu

zároveň tím určí cílovou roli, která po sloučených rolích zůstane. Ve sloučené roli se potom kombinují všechny zodpovědnosti z RACI matic úloh, ve kterých role figuruje.

4.5

Zabezpečení

Aplikace je chráněna proti různým druhům útoků. Komponenta nesoucí název Security umožňuje jednoduše do aplikace přidat například ochranu proti útokům typu CSRF. Útoky tohoto typu využívají zranitelnosti webových aplikací, které proti tomu nejsou řádně vyzbrojeny.

4.5.1

Cross-site Request Forgery (CSRF)

Cílem útočníka je v tomto případě vykonat nějakou akci jménem poškozeného uživatele, aniž by on o tom věděl. Pro ilustraci: nebyla-li by hypotetická aplikace běžící na doméně www.example.com ošetřena proti CSRF 54

4.5. Zabezpečení a na nějaké stránce by se nalézal HTML tag pro obrázek s nastaveným zdrojem na adresu www.example.com/admin/products/delete/1 (existující URL, která slouží ke smazání produktu v hypotetickém eshopu), odeslal by se GET požadavek, jenž by v takovém případě smazal produkt a akce by proběhla bez vědomí administrátora, avšak ze strany systému by akce vypadala jako vyžádaná právě jím, takže by byly splněny kontroly oprávnění. Obrana proti CSRF se skládá ze 2 kroků, u nichž platí, že aby byla zajištěna ochrana, je třeba provést oba kroky. První krokem zavádění ochrany proti je vyžadovat HTTP metodu POST pro požadavky na smazání. Požadavky touto metodou je možné odeslat jen formulářem nebo odesláním AJAX požadavku. Druhým krokem je přidání speciálních skrytých polí do formulářů, které jsou generovány s každým načtením stránky nově. V CakePHP jsou používána 3 pole: • key, • fields, • unlocked_fields. Položka key obsahuje jednorázový klíč, který byl vygenerován pro daný požadavek. Jeho platnost je časově omezená (ve výchozím nastavení 30 minut). Tento klíč slouží k identifikaci požadavku. S jedním klíčem není možné odeslat více než jeden požadavek, což navíc zabraňuje poměrně častému problému s dvojím odesláním formuláře při obnovení stránky. Další hodnota přidaná do formuláře nese jméno fields, kde je uložena hashovaná informace o tom, která pole jsou ve formuláři vytvořena při jeho renderování na straně serveru. Pokud se hash vytvořený z příchozích dat z formuláře bude odlišovat od toho, který byl vygenerován před odesláním, požadavek nebude přijat, jelikož rozdíl v hodnotě hashe znamená, že byly změněny položky formuláře, a to buď tak, že byla přidána formulářová pole, která tam původně nebyla nebo že byla změněna hodnota skrytých polí. Tato ochrana slouží k tomu, aby nebyl formulář upraven nějakým škodlivým javascriptovým kódem bez vědomí uživatele nebo na druhé straně proti pokusu uživatele o uložení dat, ke kterým nemá přístup například změnou id ve skrytém poli formuláře pro editaci. Posledním polem jsou unlocked_fields, které umožňují vybrat pole, na kterých nebude prováděna kontrola, což je užitečné v případě, že je ve formuláři uživateli umožněno přidávat a odebírat javascriptem formulářová pole. 55

4. Realizace

4.5.2

Cross-site scripting (XSS)

Ochrana pomocí výše zmíněným faktorům by však nebyla dostačující, kdyby aplikace nebyla chráněna proti XSS útokům. Tento útok umožňuje škodícímu uživateli vložit na stránku vlastní html či javascriptový kód, který bude vykonán. Takto by bylo možné například odeslat formuláře s požadavky na smazání vyvoláním kliknutí pomocí javascriptu. Proti XSS poskytuje PHP funkci htmlspeciachars, která nahradí všechny speciální znaky neškodnými entitami, které se vypíší, avšak žádný kód není vykonáván. Veškeré vstupy od uživatele byly ošetřeny pomocí této funkce, čili není do aplikace možno vložit vlastní kód, který by se vykonával.

4.5.3

SQL injection

Velmi častým typem útoku je tzv. SQL injection, u něhož útočník odhadne strukturu skriptu zpracovávajícího požadavky a vytvářejícího dotazy do databáze a snaží se spustit vlastní dotaz, kterým může získat přístup k datům, ke kterým by neměl, případně může smazat data z databáze. Běžný neošetřený PHP kód pro přihlašovací stránku, se kterým je možné se v obměnách překvapivě často setkat může ve zjednodušené verzi vypadat následovně: // predpokladame vytvorene pripojeni k~databazi // pomoci funkce mysql_connect() $username = $_POST[’username’]; $password = $_POST[’password’]; mysql_query(" SELECT * FROM users WHERE username = ’$username’ AND password=’$password’ "); Když útočník zadá jako uživatelské jméno řetězec: ’ OR 1 = 1 LIMIT 1; -změní vykonávaný dotaz takto: SELECT * FROM users WHERE username = ’’ OR 1 = 1 LIMIT 1; -- ’ AND password=’heslo’

56

4.5. Zabezpečení Vzhledem k tomu, že sekvence -- slouží k označení začátku komentáře, vše po podmínce ověřující, že 1 = 1, by bylo dále ignorováno a výsledkem dotazu by byl první uživatel podle výchozího řazení, po čemž by v tomto naivním skriptu následovalo přihlášení tohoto uživatele i bez znalosti jeho hesla. Často se stává, že prvním uživatelem navíc bývá administrátor. Alternativní možností pro útočníka je spuštění vlastních příkazů, a to zadáním místo uživatelského jména například řetězce ve tvaru: ’ OR 1 = 1; DROP TABLE users; -Tímto by se provedl SELECT dotaz a po jeho provedení by došlo ke smazání tabulky users jako následek zadaného dotazu DROP TABLE. Aplikace je proti SQL injection chráněna tak, že pro všechny dotazy jsou používány tzv. prepared statements, u nichž je tomuto útoku zabráněno tak, že při definici dotazu se určují proměnné, které budou před jeho voláním nastaveny na konkrétní hodnotu. Pokud je v hodnotě nějaký znak, který má v SQL dotazu speciální význam, jako třeba uvozovky a pomlčky, nebude tento znak ovlivňovat stavbu původního dotazu, čili uvozovky neukončí zadávání hodnoty a dvě pomlčky neoznačují komentář.

57

Kapitola

Testování K testování byla využita metoda white-box testování, která označuje testování zdrojového kódu se znalostí toho, jak jsou napsány jednotlivé metody. Výhodou tohoto testování je, že je možné otestovat poměrně jednoduše všechny možné cesty, kterými může daná metoda procházet při svém vykonávání. K testování byly použity kromě manuálních testů hlavně unit testy. Pro spouštění unit testů byl vybrán testovací framework PHPUnit, se kterým velmi dobře spolupracuje CakePHP, jelikož umožňuje pro jednotlivé třídy vygenerovat kostru testovacích tříd, která obsahuje prázdné testovací metody, avšak toto generování ušetří spoustu práce s vytvářením souborů. Cílem testování bylo odhalit případné chyby při různých nastaveních testovacích dat, které můžou běžnému manuálnímu testování uniknout. Snahou bylo získat co největší pokrytí, zejména u zásadních tříd, které se starají o kopírování modelu a editaci objektů v podnikovém modelu. Testování probíhalo ve třech krocích, a to konkrétně: • Vytvoření testovacích dat, • psaní testů, • spouštění testů a kontrola výsledků. Výsledkem testů bylo odhalení některých chyb v procesu kopírování modelu, které se nepodařilo odhalit manuálními testy, čili unit testování bylo beze sporu přínosné. Jednou z chyb, které se podařilo odhalit byla například chyba v kopírování metrik využívaných IT aplikacemi spojenými s vybranou úlohou. Pro tyto metriky zároveň platilo, že nebyly přímo asociovány s danou úlohou. Tyto metriky nebyly označeny jako používány v generickém modelu, i když měly být. Navíc je teď možné kdykoliv v případě úprav 59

5

5. Testování aplikaci otestovat automaticky, což ušetří spoustu času a bude odhaleno více chyb ve fázi vývoje.

60

Kapitola

Zátěžové testování Po skončení první fáze implementace následovala fáze zátěžového testování systému, jejímž cílem bylo zjistit, zda systém zvládne fungovat bez dlouhé odezvy při obsluhování předpokládaného počtu uživatelů. Benchmarking byl hlavně zaměřen na funkcionalitu vytváření podnikového modelu, jelikož je nesrovnatelně výpočetně složitější než veškeré ostatní operace. Některé závěry byly shrnuty již v kapitole o realizaci systému. K testování byl využit nástroj jMeter z dílny Apache, testováno bylo na notebooku s následující konfigurací: • Intel Pentium [email protected], • 8 GB RAM DD3, • Apache 2.2.22, • PHP 5.3.13, • MySQL 5.5.24 Simulováno bylo současné vytváření modelu s postupně se zvyšujícím počtem uživatelů až do hodnoty 50. Pro zavedení trochu reálnějších podmínek byly požadavky rozvrženy do intervalu jedné minuty. Stále se však jedná o poměrně nereálný počet požadavků za tak krátkou dobu, bereme-li v potaz, že se jedná o akci, kterou každý uživatel provede maximálně jedenkrát. Na druhou stranu potvrdí, že systém je na předpokládané použití připraven. Naměřené výsledky pro měření vytváření modelu více uživateli najednou jsou vyobrazeny v tabulce 6.1. 61

6

6. Zátěžové testování Tabulka 6.1: Benchmark - vytváření podnikového modelu Počet simulovaných uživatelů Doba odezvy (ms)

1 6958

5 7102

10 8795

25 11554

50 17887

Tabulka 6.2: Benchmark - listování úloh Počet simulovaných uživatelů Doba odezvy (ms)

1 234

5 256

10 279

25 864

50 2153

Pro listování úloh již byly všechny procesy spuštěny v jeden okamžik a proto je zde závislost doby odezvy odlišná od kopírování modelu. Odezva u této jednoduché úlohy však byla velmi dobrá a i v případě 50 uživatelů dotazujících se na to samé naráz nedošlo k přílišné prodlevě. Vzhledem k tomu, že reálné provozní prostředí nebylo v době psaní textu k dispozici, jsou testy prováděny pouze v lokálním prostředí a na stroji, který není na takovou činnost určen. Jedná se o notebook z nižší výkonnostní třídy, a proto se očekává, že odezvy na servery budou dosahovat výrazně nižších hodnot.

62

Závěr Z pohledu přínosů práce musím zmínit zejména bližší seznámení s metodikami pro řízení podnikové informatiky jako jsou ITIL a COBIT. Cennou zkušeností je spolupráce na více ekonomicko-manažersky zaměřeném projektu, oproti spíše čistě technickým projektům, jaké bývají na ČVUT. Dalším přínosem může do budoucna být i získání představy o tom, jak probíhá vytváření metodiky jako je MBI. Co se týče technických poznatků, prohloubil jsem si znalosti používání frameworku CakePHP a více jsem si zažil používání unit testů a mezi kladné stránky projektu bych zařadil i práci v týmu, kterou bylo nutné koordinovat, což se nám podařilo. Všechny funkční a nefunkční požadavky byly splněny a nic snad nebude bránit hladkému přechodu MBI do verze 2 na počátku roku 2014. Existují však jisté úpravy, které by do té doby mohly systém ještě vylepšit a zvýšit tím užitek budoucích uživatelů metodiky. Jednou z užitečných změn, resp. rozšíření současné aplikace by byla možnost přidávat si do podnikového modelu úlohy nově přidané do modelu generického. Při návrhu aplikace bylo totiž dohodnuto, že při vytváření podnikového modelu bude překopírován celý generický model v daném okamžiku a že budoucí změny se uživateli neprojeví. Zmiňovaná změna by umožnila promítnout jak nové objekty, tak objekty, které byly upraveny tak, aby bylo možné si vlastní objekty podnikového modelu aktualizovat na novou verzi. Dalším možným rozšířením aplikace by mohla být možnost své modely mezi uživateli sdílet a každý uživatel by poté měl možnost si z nějakého konkrétního, jemu nasdíleného, modelu zkopírovat objekty do modelu svého. Tato funkcionalita by mohla přinést větší spolupráci mezi jednotlivými podniky s cílem vylepšovat metodiku a udržovat si procesy řízení podnikové 63

Závěr informatiky co nejaktuálnější a za použití nejlepších možných praktik. Osobně si myslím, že metodika MBI má potenciál a může vyplnit mezeru, která momentálně existuje v oblasti metodik řízení IT v malých a středních firmách. Pevně doufám, že výstup naší práce pomůže autorům k rozvoji metodiky a umožní malým a středním firmám zajistit si dostupný standard pro řízení informatiky.

64

Literatura [1] Bley, T.: PHP Framework Comparison. 10 2012, [cit. 2013-04-14]. Dostupné z: http://we-love-php.blogspot.cz/2012/10/php-frameworkcomparison.html. [2] Claude Y. Laporte, A. R., Alain April: Applying ISO/IEC Software Engineering Standards in Small Settings: Historical Perspectives and Initial Achievements. 2006. [3] Isaca: COBIT 5. Isaca, první vydání, 2012, ISBN 978-1604202373. [4] Jan Pour, J. V.: K výsledkům průzkumu české informatiky. Technická zpráva, katedra informačních technologií VŠE, 2011. [5] Jiří Voříšek, J. P. a. k.: Management Podnikové Informatiky. PBtisk Příbram, první vydání, 2012, ISBN 978-80-7431-102-4. [6] Kofroň, O.: Systém pro správu metodiky Management of Business Informatics. Diplomová práce, České vysoké učení technické, 2013. [7] Kujawa, L.: Performance benchmark of popular PHP frameworks. 4 2013, [cit. 2013-04-25]. Dostupné z: http://systemsarchitect.net/performance-benchmark-of-popularphp-frameworks. [8] Lisa Lancor, S. K.: Analyzing PHP Frameworks for Use in a ProjectBased Software Engineering Course. Proceeding of the 44th ACM technical symposium on Computer science education, 2013. [9] Office, C.: ITIL Continual Service Improvement 2011 Edition. The Stationery Office, první vydání, 2011, ISBN 978-0113313082. 65

Literatura [10] Office, C.: ITIL Service Design 2011 Edition. The Stationery Office, první vydání, 2011, ISBN 978-0113313051. [11] Office, C.: ITIL Service Operation 2011 Edition. The Stationery Office, první vydání, 2011, ISBN 978-0113313075. [12] Office, C.: ITIL Service Strategy 2011 Edition. The Stationery Office, první vydání, 2011, ISBN 978-0113313044. [13] Office, C.: ITIL Service Transition 2011 Edition. The Stationery Office, první vydání, 2011, ISBN 978-0113313068. [14] Oracle: MySQL 5.5: Storage Engine Performance Benchmark for MyISAM and InnoDB. Technická zpráva, Oracle, 2011. [15] Pour, J.: Výsledky průzkumu řízení podnikové informatiky. Technická zpráva, Česká společnost pro systémovou integraci, 2012.

66

Příloha

Seznam použitých zkratek ITIL - IT Infrastructure library, COBIT - Control Objectives for Information and related Technology, MBI - Management of Business Informatics, MMDIS - Multidimensional Management and Design of Information Systems, SLA - Service level agreement, CIO - Chief information offices, KGI - Key goal indicator, KPI - Key performance indicator, SMB - Small and medium businesses, OGC - Office of Government Commerce, CCTA - The Central Computer and Telecommunications Agency, ORM - Objektově relační mapování, CRUD - Create, read, udpate, delete, ACL - Access control list, ACID - Atomic, Consistent, Isolation, Durability, CLI - Command-line interface, 67

A

A. Seznam použitých zkratek SQL - Structured query language, URL - Uniform resource locator.

68

Příloha

Obsah přiloženého CD

readme.txt ................................ stručný popis obsahu CD install.txt.....................................instalační příručka src impl.................................zdrojové kódy implementace thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce thesis.pdf...........................text práce ve formátu PDF manual.pdf ................. uživatelská příručka ve formátu PDF 69

B