Na tomto místě bude oficiální zadání vaší práce

Na tomto místě bude oficiální zadání vaší práce • Toto zadání je podepsané děkanem a vedoucím katedry, • musíte si ho vyzvednout na studijním oddělení Katedry počítačů na Karlově náměstí, • v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), • ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě).

i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Návrh a implementace automatizovaného service desku Bc. Miroslav Janošík

Vedoucí práce: Ing. Martin Molhanec, CSc.

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 10. května 2012

iv

v

Poděkování Za cenné nápady, podněty a připomínky k problematice této práce patří mé poděkování Petru Novákovi.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 11. 5. 2012

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

viii

Abstract For the successful provision of IT services to their users through the organization’s suppliers is crucial to manage these services. Methodological framework of ITIL supports this topic. This thesis is intended to design, implement and test software solution to support the work of people in the Service Desk department. This solution is composed of multiple components and provide automatic routing of user requests to the relevant parties.

Abstrakt Pro úspěšné poskytování IT služeb uživateli prostřednictvím organizace dodavatele je potřeba tyto služby řídit. Problematika řízení IT služeb je řešena metodickým rámcem ITIL. Tato práce si klade za účel navrhnout, implementovat a otestovat softwarové řešení pro podporu práce lidí v oddělení service desk. Toto řešení složené z více komponent umožní automatické směrování požadavků na službu mezi kompetentními osobami.

ix

x

Obsah 1 Úvod

1

2 Teorie 2.1 Řízení IT služeb . . . . . . . 2.2 Metodický rámec ITIL v3 . . 2.3 Terminologie . . . . . . . . . 2.4 Funkce . . . . . . . . . . . . . 2.4.1 Service Desk . . . . . 2.5 Procesy . . . . . . . . . . . . 2.5.1 Request Fulfillment . . 2.5.2 Incident Management 2.5.3 Change Management . 2.5.4 Problem Management

. . . . . . . . . .

3 3 4 5 6 6 6 8 8 8 8

. . . . . .

9 9 9 10 10 11 11

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

13 13 14 15 17 20 22 22 24 24 26 26 26

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3 Použité technologie a metodiky 3.1 UML . . . . . . . . . . . . . . . . . 3.2 Unifikovaný proces vývoje aplikací 3.3 ITIL v3 . . . . . . . . . . . . . . . 3.4 Mantis Bug Tracker . . . . . . . . 3.5 PHP . . . . . . . . . . . . . . . . . 3.6 MySQL . . . . . . . . . . . . . . . 4 Úvodní studie 4.1 Deklarace záměru . . . . . . . . . . 4.1.1 Jednoduchý service desk . . 4.1.2 Závislé service desky . . . . 4.1.3 Hierarchie service desků . . 4.2 Požadavky na systém . . . . . . . . 4.3 Návrh architektury řešení . . . . . 4.3.1 Model komunikace . . . . . 4.3.2 Integrace . . . . . . . . . . 4.3.2.1 Komunikační kanál 4.3.2.2 Forma komunikace 4.3.3 Vstupní a výstupní šablony 4.3.4 Automatizace komunikace .

. . . . . . . . . .

. . . . . .

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

xi

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

. . . . . . . . . .

. . . . . .

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

xii

OBSAH

4.4

4.3.5 Stavový prostor požadavků . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.6 Hlavní prvky řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Rizika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Analytická dokumentace 5.1 Obchodní proces . . . . . . 5.2 Komponenty řešení . . . . . 5.3 Případy užití . . . . . . . . 5.3.1 Balíky případů užití 5.3.2 Aktéři . . . . . . . . 5.3.3 ASD klient . . . . . 5.3.4 ASD automat . . . . 5.3.5 Mantis . . . . . . . . 5.3.6 IMAP mailbox . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

6 Implementace 6.1 Druhy zpráv . . . . . . . . . . . . 6.2 Uživatelské prostředí ADS klienta 6.3 Stavy požadavků . . . . . . . . . 6.4 Složky poštovní schránky . . . . 6.5 Datový model . . . . . . . . . . . 6.6 Nasazení komponent . . . . . . . 6.7 Nastavení komponenty Mantis . . 6.7.1 Konfigurační položky . . . 6.7.2 Uživatelé . . . . . . . . . 6.7.3 Kategorie . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

31 31 32 35 36 36 37 37 39 40

. . . . . . . . . .

43 43 43 45 46 48 49 49 49 52 52

7 Testování 53 7.1 Testy při programování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.2 Integrační testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.3 Akceptační testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8 Závěr

57

A Protokoly z testování

61

B Uživatelská příručka

69

C Administrátorská příručka

71

D Seznam použitých zkratek

73

E Obsah přiloženého DVD

75

Seznam obrázků 2.1 2.2

Trojúhelník lidé - nástroje - procesy . . . . . . . . . . . . . . . . . . . . . . . Životní cyklus služby dle ITIL v3 . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5

Logo Logo Logo Logo Logo

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9 10 10 11 11

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

Schéma jednoduchého SD . . . . . . . . . . . Třístupňový model podpory . . . . . . . . . . Schéma dvou závislých SD . . . . . . . . . . . Schéma hierarchie SD . . . . . . . . . . . . . Model manuální a asistované komuikace . . . E-mail jako komunikační kanál . . . . . . . . Stavový prostor požadavku . . . . . . . . . . Zjednodušený diagram komponent ASD řešení

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

14 16 16 18 23 25 27 28

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

Obchodní proces zpracování požadavku Diagram komponent ASD řešení . . . . Balíky případů užití ASD řešení . . . . . Aktéři ASD řešení . . . . . . . . . . . . Případy užití ASD klienta . . . . . . . . Případy užití ASD automatu . . . . . . Případy užití Mantisu . . . . . . . . . . Případy užití IMAP mailboxu . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

33 34 36 37 38 39 41 42

6.1 6.2 6.3 6.4 6.5 6.6

Oblasti šíření zpráv . . . . . . . . . . . . . . . Návrh grafického rozhraní ASD klienta . . . . ASD automat - stavy pžadavků . . . . . . . . Stromová struktura složek poštovní schránky Fyzický model upravené databáze Mantisu . . Diagram nasazení . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

44 45 47 48 50 51

UML . . ITIL . . Mantis . PHP . . MySQL

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

4 5

E.1 Obsah DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

xiii

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1

Důležité termíny ITSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 4.2 4.3

Funkční požadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Nefunkční požadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Rizika ASD řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1 6.2

Oblasti šíření zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Typy zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.1 7.2

Přehled testovacích scénářů 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Přehled testovacích scénářů 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . 56

A.1 Test A.2 Test A.3 Test A.4 Test A.5 Test A.6 Test A.7 Test A.8 Test A.9 Test A.10 Test A.11 Test A.12 Test A.13 Test A.14 Test A.15 Test A.16 Test A.17 Test A.18 Test A.19 Test

T1 - Práce s ASD klientem . . . . . . . . . . . T2 - Registrace požadavku . . . . . . . . . . . T3 - Kategorizace požadavku . . . . . . . . . T4 - Předání požadavku . . . . . . . . . . . . T5 - Vypsání seznamu SP (report přiřazení) . T6 - Zadávání ID ze zákaznického SD . . . . . T7 - Vyřešení požadavku . . . . . . . . . . . . T8 - Prohlížení, filtrování, vyhledávání SP . . T9 - Report požadavků ke KP . . . . . . . . . T10 - Export libovolného reportu . . . . . . . T11 - Výpis statistik . . . . . . . . . . . . . . T12 - Komunikace v zónách Public, Protected, T13 - Notifikace s celou historií SP . . . . . . T14 - Notifikace s přírůstkovou historií SP . . T15 - Autentifikace pomocí e-mailů . . . . . . T16 - Zobrazení požadavku . . . . . . . . . . T17 - Manipulace se schránkou . . . . . . . . T18 - Manipulace se stavem požadavků . . . . T19 - Archivace zpráv podle typu do složek .

xv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Private . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

7

61 61 62 62 62 63 63 63 64 64 64 65 65 65 66 66 66 67 67

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Prostředky informační technologie pro úspěšné plnění svého účelu potřebují lidskou činnost. Tiskárna s prázdným tonerem, chybný program aplikace nebo server bez správného nastavení administrátorem by neposkytovaly uživatelům žádanou funkcionalitu. V podnikovém prostředí jsou tyto činnosti poskytované prostřednictvím služeb. Podnikové procesy, lidé a nástroje tvoří tři základní prvky pro řízení IT služeb v organizaci. Problematice poskytování IT služeb se věnuje celosvětově uznávaný metodický rámec ITIL. IT služby mohou být organizaci poskytovány prostřednictvím externího dodavatele. V případě komplexních služeb je dokonce možné tyto poskytovat prostřednictvím více subdodavatelů. Této implementační diplomové práci je kladeno za úkol vytvořit softwarové řešení pro podporu práce lidí v oddělení service desk na straně dodavatele služby. Při dodržení některých předpokladů je možné lidskou práci operátorů oddělení service desk automatizovat. Výsledné řešení má umožnit jednodušší komunikaci mezi uživatelem, dodavatelem a subdodavateli služby prostřednictvím automatizovaného evidování a směrování požadavků na službu. Motivací je ušetření lidské práce a snížení faktoru lidské chyby. Práce si však neklade za úkol implementovat řešení do prostředí konkrétní organizace. Řešení složené z více komponent je třeba navrhnout, implementovat, otestovat a zdokumentovat dle zvyklostí softwarového inženýrství.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Teorie Tato kapitola si klade za cíl popsat teoretický základ pro pochopení problematiky řízení služeb v oboru informačních a komunikačních technologií, uvést obecně uznávaný přístup k této problematice, zmínit terminologii, uvést typické příklady takových služeb a některé procesy pomáhající zajištění fungování těchto služeb.

2.1

Řízení IT služeb

Řízení služeb informačních technologií - anglicky IT Service Management (ITSM) je disciplínou zabývající se zajištěním poskytování IT služeb jejich uživatelům tak, aby byly splněny požadavky na služby kladené. Příkladem IT služby může být zajištění fungování tiskáren v organizaci, zajištění provozu účetní aplikace nebo v oblasti telekomunikací poskytování služby připojení k síti Internet. Všechny tyto služby mají za účel poskytovat jejich uživateli přidanou hodnotu. IT služba může být definována jako explicitně definovaná a popsaná funkcionalita, poskytovaná informačními technologiemi, která podporuje, či přímo umožňuje chod nějakého podnikového procesu, resp. podnikové činnosti[5]. Služby vznikají v organizacích buďto samovolně, nebo za stanoveným účelem. Druhému případu se věnuje právě ITSM. Bez ohledu na to, zda je služba poskytována zdroji uvnitř organizace, nebo je pro její poskytnutí potřeba externí subjekt, je vhodné takovouto službu naplánovat, určit její vstupy, výstupy, zdroje a parametry, tak aby poskytovala žádanou hodnotu. Manažerská disciplína řízení IT služeb zahrnuje tři relativně samostatné, ale přesto navzájem propojené a na sobě závislé oblasti [5]. Jejich vzájemný vztah vystihuje trojúhelník na obrázku 2.1. • Lidé - všichni, kteří přicházejí do styku s danou službou - především uživatelé, IT pracovníci nebo vedoucí pracovníci. • Nástroje - nástroje mají za účel účel usnadnit zúčastněným lidem práci. Jedná se například o monitoring IT infrastruktury, nástroj pro správu incidentů, změn a servisních požadavků nebo komunikační prosředky.

3

4

KAPITOLA 2. TEORIE

• Procesy - organizačně-procesní prvky systému řízení služeb IT. Mezi tyto patří zejména vymezení pojmů, aktivit, rolí, pravomocí a odpovědností pracovníků. Účel procesů je určit aktivity pracovníků a nástrojů k zajištění požadované služby.

Procesy

Lidé

Nástroje

Obrázek 2.1: Trojúhelník lidé - nástroje - procesy

2.2

Metodický rámec ITIL v3

ITIL je zkratkou pro Information Technology Infrastructure Library - souboru knižně vydaných nejlepších zkušeností (ang. best practices) z oboru ITSM. ITIL je celosvětově uznávaným rámcem pro naplnění potřeb ITSM, který byl zaveden britským vládním úřadem Cabinet Office (dříve známým také jako OGC - Office of Government Commerce). Ačkoliv ITIL původně vznikl pro veřejnou správu, rychle se rozšířil i do komerčních a nekomerčních organizací. Tento metodický rámec nevychází z akademických přístupů, ale je prakticky orientován a staví na základech získaných dlouhodobou praxí. ITIL vznikl v první polovině devadesátých let minulého století a v současné době na jeho základech staví většina organizací. Zavedení ITILu do IT organizace je podmínkou pro úspěšné udělení certifikace ISO/IEC 20000 - řízení IT služeb v organizaci. ITIL však není normou, která musí být beze zbytku naplněna, ale lze vybrat pouze potřebné oblasti a tyto lze upravit podle potřeb každé organizace. Metodika ITIL v současné verzi 3 pohlíží na IT služby z pohledu jejich životního cyklu [2]:

2.3. TERMINOLOGIE

5

1. Service Strategy (Strategie služeb) - plánování služby pro zajištění business požadavků, 2. Service Design (Návrh služeb) - návrh, vývoj procesů a jejich řízení, 3. Service Transition (Přechod služeb) - zavádění služeby a implementace procesů, 4. Service Operation (Provoz služeb) - procesy zajišťující provoz služby, 5. Continual Service Improvement (Neustálé zlepšování služeb) - stálé vylepšování služby. Výše uvedené oblasti ITILu jsou zároveň samostatnými příručkami tohoto metodického rámce a jejich vztah nejlépe vystihuje cyklus na obrázku 2.2 [4].

Obrázek 2.2: Životní cyklus služby dle ITIL v3

2.3

Terminologie

Oblast řízení IT služeb je mezinárodním polem a pro potřebu dorozumění byl, tak jak je v informačních technologiích obvyklé, použit anglický jazyk. Výše zmíněný metodický rámec ITIL vznikl ve Velké Británii a používá anglické názvosloví. V praktickém životě se často používá právě originální anglické názvosloví a názvy se do češtiny nepřekládají, případně jejich obraz v češtině chybí nebo není výstižný.

6

KAPITOLA 2. TEORIE

V tabulce 2.1 jsou uvedeny pojmy [3] ITILu v3, které jsou potřebné pro pochopení dalšího textu práce.

2.4

Funkce

Význam slova funkce podle ITILu je tým nebo skupina lidí a nástroje, které tito lidé používají k provádění jednoho nebo více procesů nebo činností.

2.4.1

Service Desk

Service Desk (dále též SD) poskytuje jediné kontaktní místo mezi poskytovatelem služeb a uživateli. Typický Service Desk spravuje incidenty a požadavky na službu a obstarává komunikaci s uživateli. Termín Help Desk bývá často brán za synonymum pro Service Desk. Pracovníci Service Desku, kteří přijímají volání od uživatelů bývají označováni za operátory/dispečery. Hlavní náplní práce operátora je: • poskytnutí kontaktu uživateli služby, • první (základní) úroveň podpory uživateli, • zaznamenání požadavku uživatele do Service Deskového nástroje (dále též SD nástroj) a jejich kategorizování, • eskalování, tedy předání požadavku uživatele na další (odbornější) úroveň podpory, • zodpovědnost za stavy požadavků. Vzhledem k tomu, že Service Desk poskytuje jediné kontaktní místo pro uživatele, je tedy přímo zodpovědný za spokojenost uživatelů s řešením jejich požadavků.

2.5

Procesy

Podnikový proces je strukturovaná množina činností navržená pro dosažení určitého specifického cíle. Proces má jeden či více vstupů a přetváří je do definovaných výstupů. Výše uvedená definice je podobná definici algoritmu s tím rozdílem, že do procesu vstupuje lidský faktor, a pro dosažení žádaných výsledků je potřeba lidskou práci řídit. Dále jsou uvedeny nejčastěji používané procesy ITILu, které mají význam pro tuto práci. Za zmínku jistě stojí, že všechny uvedené procesy mají mnoho společného: • Iniciace - požadavek je většinou zadán uživatelem služby, • Evidence - zanesení požadavku do SD nástroje, • Stav požadavku - každý požadavek má svůj životní cyklus vyjádřený stavem - např. nový, přiřazený, vyřešený, uzavřený, atd.

2.5. PROCESY

7

Anglický termín IT Service

Český termín Služba IT

Process

Proces

Function

Funkce

Tool

Nástroj

Configuration Item (CI)

Konfigurační položka (KP)

Call

Volání

Service Request

Požadavek na službu

Incident

Incident

Change

Změna

Problem1

Problém

Výklad Služba poskytovaná jednomu nebo více zákazníkům poskytovatelem služeb IT. Služba IT je založena na využití infornační technologie a podporuje podnikové procesy zákazníka. Služba IT je vytvářena za pomoci personálu, procesů a techniky. Strukturovaná množina činností navržená pro dosažení určitého specifického cíle. Proces má jeden či více vstupů a přetváří je do definovaných výstupů. Příkladem procesu může být Správa incidentů (Incident Management) 2.5.2. Tým/skupina lidí a nástroje, které tito lidé používají k provádění jednoho nebo více procesů nebo činností. Příkladem funkce může být Service Desk 2.4.1. Technický prostředek používaný pro dosažení specifického cíle. Příkladem může být nástroj pro monitoring provozu IT, v dalším textu bude termín nástroj použit především pro aplikaci podporující práci funkce Service Desk - konkrétně aplikaci Mantis 5.3.5. Jakákoliv komponenta, která by měla být spravována za účelem dodávky IT služby. Konfigurační položky typicky zahrnují hardware, software, stavby, lidi a formální dokumentaci. Telefonické volání uživatele na Service Desk, které může vyústit v registraci incidentu nebo požadavku na službu. V praxi je též obvyklé použití termínů case, issue, ticket, bug nebo český termín požadavek, který bude dále v textu použit ve významu obecného požadavku uživatele na službu. V některých případech bude v tomto významu použit termín servisní požadavek (zkratka SP ). Požadavek uživatele na informaci, radu, standardní změnu nebo na zpřístupnění služby. Např. opětovné nastavení hesla nebo poskytnutí standardní služby IT novému uživateli. Požadavky na službu jsou zpravidla vyřizovány Service Deskem a nevyžadují překlasifikování na změnový požadavek. Neplánované přerušení služby IT nebo omezení kvality služby IT. Incident je rovněž porucha konfigurační položky, která dosud neovlivnila službu. Příkladem incidentu je výpadek síťového připojení, porucha pevného disku, zaseknutý papír v tiskárně nebo chybná funkčnost aplikace. Přidání, modifikace nebo odstranění čehokoliv, co by mohlo mít vliv na služby IT. Druh požadavku, který vytváří změnu v IT prostředí. Změny jsou zpravidla schvalovány Požadavkem na změnu - Request for Change (RFC). Příkladem změny je přidání serveru, instalace upgradu aplikace nebo změna konfigurace směrovače. Příčina jednoho nebo více incidentů. Příčina obvykle není známa v čase vytvoření záznamu o problému a proces Správy problémů 2.5.4 je zodpovědný za jeho další zkoumání. Příkladem problému může být chybné chování aplikace.

Tabulka 2.1: Důležité termíny ITSM

8

KAPITOLA 2. TEORIE

• Předání požadavku - požadavek může být přiřazen řešiteli k vyřešení, • Komunikace - zainteresované strany jsou informovány o stavu požadavku. Výše uvedené společné znaky poukazují na možnost užití jednoho nástroje, který bude požadavky spravovat a usnadňovat práci lidí.

2.5.1

Request Fulfillment

Proces Request Fulfillment (česky plnění požadavků) je odpovědný za správu všech požadavků na službu v rámci jejich životního cyklu. Požadavky na službu jsou požadavky uživatele na informaci, radu, standardní změnu nebo na zpřístupnění služby. Např. opětovné nastavení hesla nebo poskytnutí standardní služby IT novému uživateli. Požadavky na službu jsou zpravidla vyřizovány Service Deskem a nevyžadují překlasifikování na změnový požadavek.

2.5.2

Incident Management

Proces Incident Management (česky správa incidentů) odpovídá za správu životního cyklu všech incidentů. Hlavním cílem správy incidentů je co nejrychleji obnovit službu pro uživatele. Incident je neplánované přerušení služby. Příkladem incidentu může být nedostupná síťová tiskárna. Správa incidentů má umožnit co nejrychlejší zprovoznění tisku uživatelům - třeba přesměrováním na jinou tiskárnu. To, že je opět vytažený síťový kabel, protože chybí přechodová lišta, není pro tento proces to nejdůležitější. Příčinu opakujících se incidentů řeší správa problémů.

2.5.3

Change Management

Proces Change Management (česky správa změn) odpovídá za správu životního cyklu všech změnových požadavků. Změna je přidání, modifikace nebo odstranění čehokoliv, co by mohlo mít dopad na IT službu. Cílem procesu je pak umožnit realizaci prospěšných změn při minimálním narušení služby.

2.5.4

Problem Management

Proces Problem Management (česky správa problémů) je odpovědný za správu všech problémů během jejich životního cyklu. Primárním účelem je odhalovat příčiny vzniku incidentů a předcházet jim. Příkladem může být, že uživatelé hlásí hromadně incidenty na nefunkční ukládání souboru na server. Správa problémů pak má odhalit problém v zaplněném disku serveru kvůli jiné aplikaci.

Kapitola 3

Použité technologie a metodiky 3.1

UML

Jazyk Unified Modeling Language (česky unifikovaný modelovací jazyk) - UML je univerzální jazyk pro vizuální modelování systémů. Nejčastěji je využíván pro modelování objektově orientovaných softwarových systémů. Široké využití si zasloužil pro svou schopnost poskytnout dorozumění lidem zainteresovaným do vývoje softwarových systémů. První verze jazyka UML byla přijata v roce 1997 a defacto se stala průmyslovým standardem [1]. Jazyk UML je spravován sdružením Object Management Group (OMG). V této práci je jazyk UML použit pro vytvoření diagramů pro popis modelu navrhovaného softwarového řešení. Pro tvorbu diagramů byl použit především nástroj Enterprise Architect 8 od společnosti Sparx Systems.

Obrázek 3.1: Logo UML

3.2

Unifikovaný proces vývoje aplikací

Anglický název Unified Process (zkratkou UP ) je používán pro metodiku zabývající se procesem návrhu a realizace softwarových aplikací. UP vychází z dlouhodobých zkušeností s vývojem aplikací a snaží se poskytnout návod k pochopení potřeb uživatele na softwarový systém, převedení těchto potřeb do požadavků na systém, návrh a tvorbu systému, jeho testování a zavádění do produktivního života. Tato metodika je vhodná zejména pro konstrukci středních nebo větších systémů, na které spolupracuje více lidí. Osvědčí se v odběratelsko-dodavatelských vztazích, kdy je vhodné se

9

10

KAPITOLA 3. POUŽITÉ TECHNOLOGIE A METODIKY

zákazníkem specifikovat zadání projektu na dodávku SW řešení. Pro potřeby této práce je použita pouze část z této metodiky - především specifikace požadavků na systém.

3.3

ITIL v3

Metodický rámec ITIL v3 je podrobně popsán v oblasti 2.2. ITIL byl zaveden britským vládním úřadem Cabinet Office (dříve známým také jako OGC - Office of Government Commerce) v polovině devadesátých let dvacátého století. Poskytuje sadu praxí ověřených nejlepších postupů pro disciplínu řízení IT služeb a v tomto oboru je brán za standard. Implementace ITILu však nemusí být striktní a je možné jej upravit pro potřeby konkrétní organizace a jejích služeb. Pro potřeby této práce jsou vybrány čtyři procesy ITILu (blíže v oblasti 2.5), pro jejichž provoz může mít nástroj navržený v této práci velký vliv na lidskou práci. Pro tvorbu diagramů byl použit především nástroj Visio 2010 od společnosti Microsoft.

Obrázek 3.2: Logo ITIL

3.4

Mantis Bug Tracker

Mantis Bug Tracker (zkráceně též pouze Mantis) je populární webový nástroj pro správu chyb software. Je napsaný v jazyce PHP a jako databáze může být použito MySQL, MS SQL nebo PostgreSQL a téměř libovolný webový server. Mantis je široce užívaný nástroj v open source komunitě - poskytuje důležité funkčnosti, není náročný na hardwarové prostředky, je rozšiřitelný pomocí zásuvných modulů a tyto mohou být dále vyvíjeny díky veřejnému API. V neposlední řadě je Mantis oblíben pro použití licence GNU General Public License (GPL) - jeho použití je tedy zdarma a na rozdíl od komerčních aplikací není potřeba platit licence za produkt a/nebo uživatelské licence. Pro potřeby této práce byt nástroj Mantis vybrán z důvodu nákladů na pořízení, nenáročný provoz a kvůli API poskytujícímu možnost upravení.

Obrázek 3.3: Logo Mantis

3.5. PHP

3.5

11

PHP

PHP (rekurzivní zkratka PHP: Hypertext Preprocessor, česky PHP: Hypertextový preprocesor, původně Personal Home Page) je skriptovací programovací jazyk. PHP poskytuje prostředky jak pro procedurální, tak pro objektovou tvorbu programů. Pro svou příbuznost s jazyky C a Perl se stal hojně používaným. Jazyk PHP je pro tuto práci použit z důvodu poskytnutí dostatečné funkčnosti, obsáhlosti knihoven, nenáročné implementace a pro navázání na procedurální API poskytované aplikací Mantis, které je rovněž napsané v jazyce PHP. Kód v PHP bývá často pouze interpretován místo přeložení do strojového kódu. To přináší výhodu v jednodušší práci programátora, ale často bývá tato vlastnost kritizována pro pomalejší běh programu. Tento nedostatek však není pro navrhované řešení důležitý.

Obrázek 3.4: Logo PHP

3.6

MySQL

MySQL je databázový systém, vytvořený švédskou firmou MySQL AB, nyní vlastněný společností Sun Microsystems, dceřinou společností Oracle Corporation [6]. MySQL je licencování pod dvěma druhy licencí - jak pod bezplatnou licencí GPL, tak pod komerční placenou licencí. MySQL je oblíbený databázový systém v open source komunitě a s PHP tvoří často prostředí pro běh webových aplikací - tak, jak je tomu právě v případě Mantisu. Databázový server MySQL byl pro tuto práci vybrán z důvodu nenáročnosti na hardwarové prostředky a zkušeností autora práce s administrací této databáze.

Obrázek 3.5: Logo MySQL

12

KAPITOLA 3. POUŽITÉ TECHNOLOGIE A METODIKY

Kapitola 4

Úvodní studie Účelem úvodní studie je rozebrat problematiku, analyzovat možné přístupy, výhody a nevýhody jednotlivých řešení.

4.1

Deklarace záměru

Hlavním úkolem práce je navrhnout a implementovat softwarové řešení Automatizovaného Service Desku (zkráceně ASD), tedy sytém, který bude evidovat požadavky uživatelů, bude umožňovat jejich prohlížení a manipulaci s nimi. Dalším úkolem je automatizovat práci operátorů, tedy především zadávání a předávání požadavků. Tato automatizace přináší možnost minimalizace lidské chyby a snižuje náklady na lidskou práci. Výsledná aplikace má umožnit prohlížení požadavků, jejich filtrování a tvorbu přehledů (reportů, statistik). Řešení tohoto problému je odvislé od komplexnosti poskytované služby klientovi. V nejjednodušším případě se dá úkol vyřešit nainstalováním a patřičným nakonfigurování SD aplikace jak je popsáno v oblasti 4.1.1. Tento přístup nevyžaduje velké náklady na práci a aplikací poskytujících tuto funkčnost lze na Internetu najít dostatek ať již placených nebo pod nějakou Open source licencí. Služba může být dodávána zákaznické organizaci externí organizací. V takových případech bývá obvyklé, že obě tyto organizace mají svá oddělení Service desk a své Service deskové nástroje/aplikace. Takovýto model je popsán v oblasti 4.1.2 a je používán v případech, kdy některá řešitelská skupina je takzvaně outsorcována externí organizací. Pokud je poskytovaná služba zákazníkovi ještě komplexnější, pak může být model závislých service desků rozšířen pro další externí subdodavatelské organizace. V takovém případě dochází ke komunikaci ne dvou, ale obecně mnoha service desků, které jsou seřazeny do hierarchické struktury. V takovém případě se pro ulehčení lidské práce nabízí možnost vzájemné integrace SD aplikací těchto organizací. Blíže tuto situaci popisuje oblast 4.1.3. Právě takovéto uspořádání je předmětem této práce.

13

14

KAPITOLA 4. ÚVODNÍ STUDIE

4.1.1

Jednoduchý service desk

Toto uspořádání je vhodné především pro malé organizace a open sourceové projekty. Využívá jednu funkci service desk a jednu SD aplikaci. Schématicky je zachyceno na obrázku 4.1.

Dodavatel služby

Telefon, E-mail, Web, atd.

SD nástroj

Service Desk

Uživatel služby

Řešitel

Obrázek 4.1: Schéma jednoduchého SD Hlavní vlastnosti řešení: • Služba - příklad: oprava chyb open sourceového projektu. • Organizace - malá organizace, internetový projekt nebo nezisková organizace. • Obsluha - většinou nevyžaduje přidělené operátory SD, samoobslužné webové aplikace. • SW řešení - placené, případně open source aplikace např. BugZilla nebo Mantis Bug Tracker 5.3.5. • Průběh práce 1. Nahlášení - pro nahlášení požadavku na service desk použije uživatel služby patřičný komunikační kanál (telefon, e-mail, web, apod.). 2. Evidence - operátor přijme požadavek a zaeviduje, doplní o klasifikaci - např. závažnost, priorita, konfigurační položka. 3. Předání - operátor požadavek pomocí SD aplikace předá řešiteli a ten je patřičně notifikován dohodnutým způsobem - obvykle e-mailem, sms nebo telefonátem. 4. Vyřešení - řešitel vyřeší požadavek uživatele a zapíše o tom zprávu do SD nástroje. 5. Uzavření - po ověření správné funkčnosti operátor uzavře požadavek a informuje uživatele. • Výhody - jednoduchá a nenákladná implementace softwarového řešení, pokud je pro nahlášení požadavku možné využít samoobslužné řešení, pak není bezpodmínečně nutná role operátora SD.

4.1. DEKLARACE ZÁMĚRU

15

• Nevýhody - poskytuje řešení pouze pro malé organizace, nevýhodné pro složité dodavatelské modely, často pokrývají pouze malou oblast ITSM.

4.1.2

Závislé service desky

Hlavním rozdílem oproti modelu jednoduchého SD je přítomnost dvou service desků. Tento model je vhodný v odběratelsko-dodavatelských vztazích, kdy se organizace uživatele služby rozhodne část služby pokrýt externí organizací - tzv. outsorcing. Schématicky je tento model uveden na obrázku 4.3. Závislé service desky bývají využity pro vícestupňový model podpory. Příkladem může být poskytování podpory pro chod podnikových aplikací. Pokud je problém triviální, vyřeší ho první úroveň podpory (většinou operátor SD). Pokud první úroveň podpory (anglicky Level 1 Support - zkráceně L1 ) nedokáže vyřešit požadavek uživatele, předá jej na druhou úroveň podpory (analogicky L2 ) - v organizaci zákazníka ji většinou zajišťují zkušení uživatelé aplikací, administrátoři aplikací, databází apod. Pokud ani tito řešitelé nedokáží požadavek uživatele vyřešit, předávají ho na další úroveň podpory - zde třetí - L3, která může být například dodavatel aplikace. Obecně ITIL nedefinuje počet úrovní podpory, ale v praxi bývají často využity právě tři úrovně - viz. obrázek 4.2. Obvykle u takové služby bývá její přesný předmět, parametry, odpovědnosti a odměna za poskytnutí specifikována smluvně. Obsah dat v aplikaci dodavatele je závislý na datech poskytnutých od aplikace zákazníka. Hlavní vlastnosti řešení: • Služba - příklad: zajištění chodu hardwaru v IT organizaci, poskytování síťové konektivity telekomunikačním operátorům. • Organizace - střední a velké organizace využívající dodavatele služby k zajištění svého IT pro podporu svého podnikání. • Obsluha - vyžaduje operátory na straně SD zákazníka i dodavatele. • SW řešení - podle požadavků na nástroj lze zvolit nástroj s vhodnou fuknčností. Většina velkých dodavatelů IT je schopna dadat takovýto software jako řešení, příkladem může být CA Service Desk Manager, HP Service Manager, IBM Tivoli Service Request Manager. Taková řešení bývají často certifikována na shodu s metodickým rámcem ITIL. Nevýhodou mohou být náklady na zřízení a potřeba licencování. • Průběh práce 1. Nahlášení - pro nahlášení požadavku na service desk uživatele služby použije uživatel patřičný komunikační kanál (telefon, e-mail, web, apod.). 2. Evidence a L1 - operátor přijme požadavek a zaeviduje, doplní o klasifikaci např. závažnost, priorita, konfigurační položka. 3. Předání na L2 - operátor požadavek pomocí SD aplikace předá patřičnému řešiteli na druhou úroveň podpory, řešitel je patřičně notifikován dohodnutým způsobem - obvykle e-mailem, sms nebo telefonátem.

16


Uživatel služby Operátoři service desku

Odbornost

L1 První úroveň podpory Odborní pracovníci

L2 Druhá úroveň podpory Dodavatel IT techologie

L3 Třetí úroveň podpory

Obrázek 4.2: Třístupňový model podpory

Dodavatel služby

Uživatel služby

L3

L1, L2 Telefon, E-mail, Web, atd.

Uživatel služby

Manuálně nebo integrace aplikací

Service Desk uživatele

SD nástroj

Service Desk dodavatele

Obrázek 4.3: Schéma dvou závislých SD

Řešitel


17

4. Předání na L3, evidence u dodavatele - pokud L2 podpora nevyřeší požadavek, pak dochází k předání na L3 podporu - poskytovatele služby. Komunikační kanál a forma předání je předem dohodnuta. V tento okamžik dochází k evidenci požadavku na straně dodavatele (manuálně nebo automaticky) a předání na příslušného řešitele. 5. Vyřešení - řešitel vyřeší požadavek uživatele a zapíše o tom zprávu do SD nástroje. Tato zpráva je dohodnutým způsobem propagována na SD uživatele a dále k uživateli. 6. Uzavření - po ověření správné funkčnosti operátor uzavře požadavek a informuje uživatele. • Výhody - komplexní nástroje usnadňující práci v mnoha oblastech řízení IT služeb podporujících ITIL. • Nevýhody - náklady na implementaci řešení a licence. V některých případech může být takovéto řešení až zbytečně komplikované pro pokrytí požadavků na službu. Nutnost dvou funkcí service desk a SD nástrojů.

4.1.3

Hierarchie service desků

Hierarchie service desků je rozvinutím modelu Závislé service desky. Hlavním rozdílem je přítomnost dalších externích (sub)dodavatelských organizací s vlastními funkcemi service desk a SD aplikacemi. Příkladem může být komplexní podpora IT organizace, kde jednotlivé oblasti IT dodávají různí dodavatelé nebo autonomní týmy - příkladem podpora hardware, podpora síťových prvků, podpora aplikací. Model je zachycen na obrázku 4.4. Hlavní vlastnosti řešení: • Služba - příklad: outsorcing IT, podpora IT s užitím subdodavatelů. • Organizace - velké organizace využívající dodavatele služby k zajištění svého IT pro podporu svého podnikání. • Obsluha - vyžaduje operátory na straně SD zákazníka, dodavatele i subdodavatelů. • SW řešení - podle požadavků na nástroj lze zvolit nástroj s vhodnou fuknčností. Většina velkých dodavatelů IT je schopna dadat takovýto software jako řešení, příkladem může být CA Service Desk Manager, HP Service Manager, IBM Tivoli Service Request Manager. Taková řešení bývají často certifikována na shodu s metodickým rámcem ITIL. Tyto nástroje umožňují předávání požadavků na externí (sub)dodavatelské skupiny. Nevýhodou mohou být náklady na zřízení a potřeba licencování. • Průběh práce 1. Nahlášení - pro nahlášení požadavku na service desk uživatele služby použije uživatel patřičný komunikační kanál (telefon, e-mail, web, apod.). 2. Evidence a L1 - operátor přijme požadavek a zaeviduje, doplní o klasifikaci např. závažnost, priorita, konfigurační položka.

18


Uživatel služby

L1, L2 Telefon, E-mail, Web, atd.

Service Desk uživatele

Uživatel Manuálně nebo Integrace aplikací

Dodavatel služby

L3 Service Desk dodavatele

SD nástroj

Řešitel



Service Desk subdodavatele

L3-b


Subdodavatel služby C

L3-a

Subdodavatel služby B

Subdodavatel služby A


L3-c


SD nástroj

SD nástroj

SD nástroj

Řešitel

Řešitel

Řešitel

Např. podpora HW

Např. podpora OS

Např. podpora aplikací

Obrázek 4.4: Schéma hierarchie SD


19

3. Předání na L2 - operátor požadavek pomocí SD aplikace předá patřičnému řešiteli na druhou úroveň podpory, řešitel je patřičně notifikován dohodnutým způsobem - obvykle e-mailem, sms nebo telefonátem. 4. Předání na L3, evidence u dodavatele - pokud L2 podpora nevyřeší požadavek, pak dochází k předání na L3 podporu - poskytovatele služby. Komunikační kanál a forma předání je předem dohodnuta. V tento okamžik dochází k evidenci požadavku na straně dodavatele (manuálně nebo automaticky) a předání na příslušného řešitele. 5. Předání na subdodavatele L3, evidence - operátor SD předá požadavek na subdodavatelskou skupinu poskytující L3 podporu. Komunikační kanál a forma předání je předem dohodnuta. V tento okamžik dochází k evidenci požadavku na straně subdodavatele (manuálně nebo automaticky) a předání na příslušného řešitele. 6. Vyřešení - řešitel vyřeší požadavek uživatele a zapíše o tom zprávu do SD nástroje subdodavatele. Tato zpráva je dohodnutým způsobem propagována na SD dodavatele, SD uživatele a dále k uživateli. 7. Uzavření - po ověření správné funkčnosti operátor uzavře požadavek a informuje uživatele. • Výhody - komplexní nástroje usnadňující práci v mnoha oblastech řízení IT služeb podporujících ITIL. Kvalitu služeb subdodavatelských skupin lze smluvně garantovat. • Nevýhody - náklady na implementaci řešení a licence. V některých případech může být takovéto řešení až zbytečně komplikované pro pokrytí požadavků na službu. Nutnost mnoha funkcí service desk a SD nástrojů, duplikace práce obsluhy. Služby mívají obvykle definované časové pokrytí - tedy dobu kdy je služba poskytována - například pouze v pracovní dobu (model 5x8) nebo nepřetržitou službu (model 7x24). V případě nepřetržité služby a manuálního zpracování požadavků je potřeba zajistit nepřetržitou obsluhu SD na všech úrovních podpory. Náklady na tyto zdroje mohou být velké, přitom vytížení nízké. Z výše uvedeného průběhu práce a schématu 4.4 zle vyvodit, že funkce service desk dodavatele (úroveň L3) je centrálním bodem komunikace mezi všemi zainteresovanými stranami. Selhání lidského faktoru nebo technologie může mít vliv na kvalitu poskytované služby a tím pádem i spokojenost zákazníka. Pokud vezmeme v úvahu následující předpoklady: • zadání a klasifikace požadavků je poskytnuta ze strany uživatele služby ve strukturované formě, • poskytnutá klasifikace (vč. druhu služby a příslušného ITSM procesu) je dostačující pro předání požadavku na řešitele nebo subdodavatelskou skupinu, • komunikace mezi jednotlivými SD jsou pevně definovány,

20


• práce operátorů je pouze evidovat a předávat požadavky1 , pak lze práci operátorů funkce service desk automatizovat pomocí softwarového vybavení. V takovém případě se minimalizuje čas na přijetí a předání požadavku, snižuje se riziko lidské chyby a dále se snižují náklady na lidskou práci. A právě takovéto softwarové vybavení si tato práce klade za úkol navrhnout a implementovat. Řešení umožní směrování požadavků mezi jednotlivými řešitelskými skupinami, tuto komunikaci bude zaznamenávat do SD nástroje a minimalizuje nároky na obsluhu.

4.2

Požadavky na systém

Tato oblast pojednává o požadavcích (angl. requirements) na budoucí softwarové řešení. Význam slova požadavek zde není chápán jako instance procesu ITSM (jak bylo používáno výše), ale z pohledu softwarového inženýrství (SI). Metodika Unified Process (zkráceně UP ) definuje požadavky na systém jako „specifikaci toho, co by mělo být implementováno“ [1]. Stanovení požadavků na systém je nutnou činností pro úspěšnou analýzu potřeb budoucího uživatele systému a následný návrh SW systému. UP definuje dvě základní kategorie požadavků[1]: • Funkční požadavky (angl. Functional Requirements), jež určují, jaké chování bude systém nabízet, • Nefunkční požadavky (angl. Non-Functional Requirements), které specifikují vlastnosti nebo omezující podmínky daného systému. Požadavky na systém by měly být jediným vyjádřením toho, co by měl systém dělat, nikoliv toho, jak by to měl dělat. Lze totiž určit, co by měl systém dělat a jaké chování by měl poskytovat, aniž bychom cokoliv říkali o způsobu, jak bude dané funkce dosaženo[1]. Funkční požadavky jsou uvedeny v tabulce 4.1. Nefunkční požadavky jsou uvedeny v tabulce 4.2.

1 Práce operátora obvykle zahrnuje více činností, než jen evidenci a předávání požadavků (např. L1 podporu, eskalace závažných požadavků, apod.). Tyto činnosti je v případě automatického příjmu a předávání požadavků potřeba pokrýt metodicky.

4.2. POŽADAVKY NA SYSTÉM

ID F1

Kategorie Evidence

F2

Evidence

F3

Evidence

F4

Evidence

F5

Evidence

F6

Evidence

F7

Evidence

F8

Evidence

F9

Evidence

F10 F11

Evidence Evidence

F12

Komunikace

F13

Komunikace

F14

Komunikace

F15

Komunikace

F16

Komunikace

Požadavek na systém Systém bude umožňovat zadávání požadavků na službu (registrace požadavku) Systém bude umožňovat kategorizaci požadavků - především: priorita, tarif služby, dopad, typ požadavku Systém bude umožňovat předávání požadavků na řešitele/řešitelskou skupinu (subdodavatele služby) Systém bude umožňovat vypsání seznamu požadavků přidělených řešiteli nebo řešitelské skupině (report přiřazení) Systém bude umožňovat přikládat k požadavku ID v zákaznickém systému Systém bude umožňovat vyřešení požadavků řešitelem/řešitelskou skupinu (subdodavatelem služby) Systém bude umožňovat prohlížení požadavků, filtrování podle kategorizace, fulltextové vyhledávání Systém bude umožňovat vypsání seznamu požadavků k dané konfigurační položce (report ovlivněné KP) Systém bude umožňovat export výpisu požadavků pro další zpracování tabulkovým procesorem (Excel export) Systém bude umožňovat vypsání statistik Systém bude umožňovat vypsání seznamu požadavků přidělených řešiteli nebo řešitelské skupině s dobou přidělení (report SLA) Systém bude umožňovat komunikaci mezi uživatelem služby, dodavatelem služby a subdodavatelskými skupinami v hierarchické struktuře Systém bude poskytovat notifikace s celou historií požadavku Systém bude notifikovat zainteresované uživatele o změně stavu požadavku Systém bude poskytovat notifikace s přírůstkovou historií požadavku (změna od minulého předání na konkrétního uživatele) Systém bude umožňovat zasílání tří druhů zpráv podle hierarchie: všichni zainteresovaní (vč. zákazníka), pouze zainteresovaní řešitelé a dodavatelské skupiny (bez zákazníka), pouze jeden řešitel/dodavatelská skupina Tabulka 4.1: Funkční požadavky na systém

21

Typ F

Priorita 1 - Nezbytný

F

1 - Nezbytný

F

1 - Nezbytný

F

1 - Nezbytný

F

1 - Nezbytný

F

1 - Nezbytný

F

2 - Možný

F

2 - Možný

F

2 - Možný

F F

3 - Eventuální 4 - Chtěný

F

1 - Nezbytný

F

1 - Nezbytný

F

2 - Možný

F

4 - Chtěný

F

4 - Chtěný

22


ID N17

Kategorie Dostupnost

N18

Dostupnost

N19

Dostupnost

N20

Kapacita

N21

Výkon

N22

Výkon

N23

Zabezpečení

Požadavek na systém Interaktivní rozhraní systému pro prohlížení a filtrování požadavků bude dostupné z intranetu dodavatele služby Systém bude umožňovat zpracovávání zpráv z různých podnikových sítí (rozdílné intranety zákazníka, dodavatele i subdodavatelských skupin) Systém bude možné provozovat na HW, který je alespoň základně zabezpečen proti výpadkům Systém bude umožňovat zpracování 300 požadavků za měsíc s průměrným počtem 4 zpráv k jednomu požadavku - tzn. 1200 příchozích zpráv měsíčně Interaktivní rozhraní systému bude poskytovat odezvu v řádu jednotek sekund Systém bude umožňovat zpracování zprávy v řádu jednotek minut Systém bude poskytovat svou funkčnost pouze autentifikovaným uživatelům

Typ N

Priorita 1 - Nezbytný

N

1 - Nezbytný

N

2 - Možný

N

2 - Možný

N

2 - Možný

N

3 - Eventuální

N

1 - Nezbytný

Tabulka 4.2: Nefunkční požadavky na systém

4.3

Návrh architektury řešení

V této oblasti jsou popsány hlavní rysy architektury navrženého řešení, základní předpoklady a modely práce. Detailnější rozbor je v následujících kapitolách. Výsledné řešení zobecňuje požadavky zaslané uživatelem služby a tak pokrývá všechny procesy ITSM uvedené v oblasti 2.5.

4.3.1

Model komunikace

Náplní práce operátora service desku je přijímat a evidovat požadavky od uživatele služby a dále je předávat na správné řešitele (alespoň pro potřeby dalšího textu). Pro plnění svých úkolů potřebuje operátor komunikovat s řešiteli/subdodavateli. Komunikace může probíhat dvěma způsoby: • Manuálně - operátor využívá standardní prostředky lidské komunikace. Komunikační kanál je například telefon, e-mail nebo IM komunikátor. V takovémto případě je nutné aby přijímající porozuměl zprávě. Výhodou tohoto modelu je znalost operátorů, kteří dokáží odhalit závažný incident a eskalovat jej, případně rozpoznají a odfiltruj nepřesnosti z informací od zákazníka. • Asistovaně - operátor využije ke komunikaci svou aplikaci, která je integrovaná na aplikaci uživatele se kterým chce operátor komunikovat. Komunikační kanál je například

4.3. NÁVRH ARCHITEKTURY ŘEŠENÍ

23

webová služba nebo strukturovaný e-mail. V takovémto případě je nutné aby byla komunikace pevně definována. Výhodou je výrazné ulehčení manuální práce s přijímáním a předávání požadavků.

Uživatel služby

Uživatel služby

Oba tyto způsoby ukazuje obrázek 4.5. Diagram je odvozen z obrázku 4.4. Pro zjednodušení jsou vypuštěny role řešitelů (uživatelů jednotlivých aplikací), dále je zobrazen pouze jeden subdodavatel služby, ale obecně jich může být mnoho. Zelenou barvou je znázorněn operátor dodavatelského service desku a aplikace kterou používá. O návrh systému pro podporu práce na této úrovni jde především.

L1, L2

Operátor SD uživatele

SD aplikace uživatele

Manuálně: e-mail, telefon, atd.

Integrace: webové služby, e-mail

Dodavatel služby

Dodavatel služby


L3

Operátor SD uživatele

L3

Operátor SD dodavatele

SD aplikace dodavatele

Manuálně: e-mail, telefon, atd.

Integrace: webové služby, e-mail

Subdodavatel služby

SD aplikace dodavatele Subdodavatel služby

L1, L2

L3-a

SD aplikace subdodavatele

Operátor SD subdodavatele

Manuální model komunikace

Operátor SD dodavatele

L3-a


Operátor SD subdodavatele

Asistovaný model komunikace

Obrázek 4.5: Model manuální a asistované komuikace Pro automatizaci práce operátorů SD je výhodnější asistovaný model komunikace. Ovšem v případě technického problému při asistované komunikaci ve vhodné mít možnost přejít na

24


manuální model a zajistit tak fungování služby pomocí dočasného náhradního řešení (tzv. workaround). Navržené řešení v této práci vyhovuje oběma výše uvedeným přístupům.

4.3.2

Integrace

Pro použití asistované komunikace pomocí informační technologie je vhodné použít standardizovaná rozhraní. Bohužel se mi nepodařilo dohledat, že by takový standard pro komunikaci SD aplikací existoval. Některé aplikace se s tímto vyrovnávají pomocí zásuvných modulů, které poskytují rozhraní v podobě webových služeb, případně umožňují konfiguraci modulů pro příjem zpráv ze strukturovaných e-mailů (např. aplikace HP Service Manager ). Vždy je však potřeba připravené prostředky implementovat pro konkrétní službu. Domnívám se, že jednou z příčin lze najít v nejednotných stavových prostorech požadavků v rozdílných organizacích. Vždy je nutné analyzovat stavový prostor požadavků v každých dvou vzájemně komunikujících organizacích a vytvořit příslušná mapování - více v oblasti 4.3.5. 4.3.2.1

Komunikační kanál

Při návrhu asistované komunikace mezi SD nástroji je potřeba zvolit komunikační kanál, kterým se budou informace přenášet. Zprávy mezi SD nástroji mohou přenášet krátké textové informace, případně přiložené dokumenty, otisky obrazovek. Běžná zpráva bude mít velikost stovek kilobytů. V případě přiložených souborů je možné počítat s jednotkami megabytů. Zprávy této velikosti je obvyklé zasílat pomocí webových služeb. Organizace mívají své SD nástroje umístěné ve svých intranetových sítích. Každou intranetovou síť odděluje od sítě Internet brána firewall. Graficky je tato situace znázorněna na obrázku 4.6. V některých případech může být složité změnit pravidla pro nastavení brány firewall v organizaci pro síťový prostup na webovou službu aplikace, případně to ani z bezpečnostních důvodů není vhodné. Nabízí se však možnost použít e-mail jako nositele informace. Textová informace je emailu vlastní a práce s přiloženými soubory rovněž. E-mail je možné odeslat i přijmout jak uživatelem, tak strojem. Připojení uživatele i stroje k e-mailové schránce uvnitř intranetu je možné v takřka každé organizaci. Některé e-mailové klienty a poštovní servery (např. Microsoft Outlook a Microsoft Exchange) umožňují takzvané tunelování spojení pomocí HTTP protokolu, je tedy možné se na svou e-mailovou schránku připojit i z intranetu jiné organizace (výhodné při práci uživatelů dodavatele v síti zákazníka). Výhodou použití e-mailů pro komunikaci je, že zprávy lze archivovat, vyhledávat v nich, případně znovu zaslat ke zpracování. E-mailové zprávy jsou rovněž vhodné pro čtení člověkem (pokud nejsou šifrované). Lze tedy v případě výpadku technologie asistované komunikace přejít na záložní manuální zpracování. Nevýhodou e-mailů je, že různé poštovní servery mají nastavenou různou maximální velikost přenášené zprávy. Dále e-mailová komunikace není synchronní, a není zaručeno, že adresát zprávu vždy obdrží.


25

Dodavatel služby

Poštovní server uživatele


e-mail

e-mail

e-mail

Brána firewall

Poštovní server dodavatele

Subdodavatel služby

Uživatel služby

e-mail

Brána firewall

Poštovní server subdodavatele

SD aplikace dodavatele

Obrázek 4.6: E-mail jako komunikační kanál


26


E-mailovou komunikaci lze zabezpečit šifrováním. Tyto možnost zabezpečení jsou blíže uvedeny v oblasti 5.2, která rozebírá blíže komponenty řešení a jejich komunikační rozhraní.

4.3.2.2

Forma komunikace

Většina SD aplikací umožňuje notifikování uživatelů o změnách stavu požadavku pomocí e-mailů. Obsah takové zprávy sebou většinou nese informace o • odesilateli zprávy, • identifikátoru požadavku, • přiřazeném řešiteli, • stavu požadavku, • textové informaci od původce změny stavu, • případně historii požadavku. Ačkoliv obsah zprávy obvykle obsahuje výše uvedené informace, forma kterou jsou do e-mailu zapsány je u každého nástroje jiná. Nabízí se tedy implementovat adaptéry, které budou tyto informace převádět do formy které rozumí ostatní SD aplikace zúčastněné v poskytované službě.

4.3.3

Vstupní a výstupní šablony

Každá dodavatelská skupina (dokonce každý uživatel) může používat vlastní formu zpráv. Pokud je formát zprávy pevně definován, pak lze tuto zprávu strojově přečíst a převést do zobecněné podoby pomocí vstupní šablony. Následně lze zobecněnou zprávu zaslat do zpracování automatu, který rozhodne o dalším zpracování zprávy a tuto činnost vykoná. O provedené činnosti předá zprávu zainteresovaným řešitelům/skupinám formou, která může být opět pro každého různá. Tuto transformaci zajišťují výstupní šablony.

4.3.4

Automatizace komunikace

Předně je potřeba stanovit předpoklady kdy komunikaci lze automatizovat. Pokud jsou mají požadavky předávané do systému pokaždé jinou formu a nemají pevně danou strukturu, pak je vhodné použit manuální zpracování operátorem SD. Pokud však požadavky vykazují definovanou strukturu, může automatizace zakládání požadavků a následné komunikace ušetřit hodně lidské práce a omezit chyby lidského faktoru.


4.3.5

27

Stavový prostor požadavků

Stavové prostory požadavků v jednotlivých nástrojích se často různí. Dokonce každý z výše uvedených procesů ITIL má jiné stavy, ve kterých může požadavek nacházet. Například aplikace Mantis nabízí šest stavů požadavku - nový, reakce, potvrzený, schválený, přiřazený, vyřešený, uzavřený. Pro obecnost použití jsem vybral minimum v podobě stavů - nový, přiřazený, vyřešený, uzavřený. Tyto stavy jsou nepostradatelné pro základní použití. Přechody mezi stavy jsou na diagramu 4.7. Diagram souží pro úvodní představu, a proto v něm nejsou zaznamenány podmínky pro přechod mezi stavy. Detailní stavový diagram je dále v textu práce - obrázek 6.3.

Obrázek 4.7: Stavový prostor požadavku To, že dva vzájemně komunikující SD nástroje používají jiné stavové prostory, vede k potřebě zavést mapování z jednoho stavového prostoru na druhý a opačně. Takováto možnost je dána pomocí vstupních a výstupních šablon, kde je možné stanovit, která příchozí zpráva vyvolá kterou událost, a na základě události bude vygenerována odchozí zpráva.

4.3.6

Hlavní prvky řešení

Pro implementaci výše uvedených vlastností systému jsem navrhl řešení skládající se z: • E-mailové komunikace - e-mailové zprávy jsou vhodnou formou komunikace jak pro uživatele, tak pro strojové zpracování. • ASD automat - automat napsaný v jazyce PHP, který periodicky kontroluje e-mailovou schránku2 a příchozí zprávy převádí pomocí vstupních šablon do zobecněné podoby, rozhodne a vykoná další zpracování, poskytne o tomto zainteresovaným řešitelům zprávu formátovanou pomocí výstupních šablon. ASD automat je pomocí PHP API napojen na komponentu Mantis, kterou využívá pro ukládání požadavků a práci s nimi. 2

IMAP protokol bohužel nepodporuje notifikaci o příchozí zprávě. Proto je potřeba pomocí plánovače úloh operačního systému nastavit periodické spouštění skriptu pro běh ASD automatu.

28


• ASD klient - multiplatformní desktopová aplikace napsaná v jazyce Java pro tvorbu zpráv pro ASD automat od řešitelů, kteří nemají svůj SD nástroj integrovaný na ASD automat. Poskytuje tvorbu zpráv v dohodnutém formátu, které jsou pak odeslány pomocí implicitního e-mailového klienta uživatele. • Mantis - webová aplikace s databází požadavků. Mantis poskytuje prezentační vrstvu pro požadavky na službu včetně fulltextového vyhledávání, tvorby reportů, exportů a statistik, správy uživatelů a konfiguračních položek. Vzájemný vztah komponent jak zapadají do ASD řešení je na obrázku 4.8.

Obrázek 4.8: Zjednodušený diagram komponent ASD řešení

4.4

Rizika

Navržené řešení asistované komunikace pomocí automatického zpracování je závislé na funkčnosti použitých technologií. Pokud nebudou tyto prostředky funkční, pak je provoz dodávané služby ohrožen. V některých případech je za nefunkční službu možno vyměřit uživatelem služby penále dodavateli. Z důvodu zachování funkčnosti služby je vhodná e-mailová forma zprávy. Pokud nebude z jakéhokoliv důvodu funkční automat pro zpracování zpráv, může jeho funkci převzít operátor

4.4. RIZIKA

29

SD. Tento přechod z asistované na manuální formu komunikace je vhodné zavést metodickým pokynem a definovat jej do provozní příručky služby. Další rizika řešení z oblasti komunikace, automatického zpracování, uživatelského prostředí a technických prostředků jsou uvedeny v tabulce 4.3. Rizika projektová pro tuto práci nejsou řešena.

KAPITOLA 4. ÚVODNÍ STUDIE 30

Komunikace

Nedoručení e-mailové zprávy

3 - Malý

1 - Velký

3 - Malý

2 - Střední

Dopad 3 - Malý 2 - Střední

10%

30%

20%

5%

30%

Výskyt 5% 30%

1 - Odvrácení

5 - Není

4 - Přijmutí

1 - Odvrácení

3 - Omezení

3 - Omezení

Strategie 2 - Přenesení 3 - Omezení

Monitoring zaplnění schránky, metodický pokyn pro administrátora pro odklad přebytečných zpráv Periodická kontrola stavu požadavků (týden, měsíc) v databázích jednotlivých SD nástrojů (report přiřazení) Důkladné integrační a uživatelské testy

Opatření Detekovat a upozornit odesilatele Monitoring počtu zpráv v INBOX složce poštovní schránky

Kategorie Automat Automat

R4

Komunikace

Chybné mapování stavů požadavků mezi jednotlivými SD nástroji Zpoždění zpracování zpráv automatem oproti synchronní komunikaci

3 - Malý

10%

4 - Přijmutí

ID R1 R2

R5 Komunikace

Nevhodný návrh rozhraní ASD klienta a prezentační komponenty Mantis

1 - Velký

5%

Komunikace

R6

Uživatelské rozhraní

Nedostupnost řešení ASD - technické potíže, odstávka

1 - Velký

R3

R7

Technické prostředky

Nedostupnost DB serveru, web serveru, e-mail serveru

Riziko Chybný formát příchozí zprávy Přeplnění poštovní schránky (vstupní fronta zpráv) - značí nefunkčnost ASD automatu Přeplnění poštovní schránky (historie zpracovaných zpráv)

R8

Technické prostředky

Zpoždění zpracování zpráv v řádu jednotek minut dané asynchronní komunikací je akceptovatelné. Uživatelský komfort komponenty Mantis není řešen z důvodu převzetí standardního balíku. GUI komponenty ASD klient není pro svůj malý rozsah řešeno. Přepnutí na manuální model komunikace operátorů SD do zprovoznění ASD řešení (workaroud) Monitoring dostupnosti jednotlivých serverů

R9

Tabulka 4.3: Rizika ASD řešení

Kapitola 5

Analytická dokumentace Tato kapitola navazuje na oblast návrhu architektury řešení 4.3 a základní rysy řešení rozvádí podrobněji. Účelem je analyzovat hlavní vlastnosti systému jak z pohledu funkčního, tak technologického. Podklady získané v této kapitole mají poskytnout dostatečné informace pro implementování programového vybavení řešení. Nejprve proběhla analýza obchodního procesu. Dále bylo potřeba specifikovat blíže komponenty řešení a jejich integraci. Pro přiřazení funkčních požadavků na systém a jeho komponenty jsem použil případy užití. Tato kapitola neobsahuje konceptuální datový model. To je dáno povahou tohoto projektu, kdy datový model pochází z převzaté komponenty Mantis. Fyzický datový model je v kapitole Implementace v oblasti 6.5.

5.1

Obchodní proces

Na základě funkčních požadavků je vytvořen základní obchodní proces. Diagram odpovídající notaci BPMN 1.0 je na obrázku 5.1 a specifikuje základní práci s požadavky. Navržené schéma práce odpovídá modelu práce hierarchie service desků z oblasti 4.1.3. Hlavní vlastnosti procesu jsou následující. • Uživatel služby zasílá požadavek na službu pomocí své funkce service desk. • Service desk dodavatele je ústředním bodem přes který musí probíhat veškerá komunikace, jinak by docházelo k nekonzistenci informací. • Každý subdodavatel si vede evidenci požadavků, řešitelé dodavatele nemusí, protože ji již mají v nástroji Mantis. • Řešitel/subdodavatel1 má pouze dvě možnosti manipulace s požadavkem: – vyřešení - pokud to jde, řešitel požadavek vyřeší a předá o tom informaci, 1

Z pohledu navrženého řešení je jedno, zda systém komunikuje přímo s řešitelem dodavatele nebo se subdodavatelskou skupinou.

31

32

KAPITOLA 5. ANALYTICKÁ DOKUMENTACE

– předání - pokud řešitel není kompetentní pro řešení, předává požadavek na kompetentního řešitele2 . • Informace o vyřešení požadavku je zaslána na SD dodavatele a ten ji patřičným způsobem komunikuje se zákazníkem. • Uživatel služby posoudí, zda je řešení vyhovující. Pokud není, je požadavek znovu zaslán na dodavatele k dořešení.

5.2

Komponenty řešení

Systém se skládá z několika základních stavebních prvků, které je potřeba spojit. Bližší pohled na komponenty, jejich vztahy a navázání je v diagramu komponent na obrázku 5.2 tento vychází ze Zjednodušeného diagramu komponent ASD řešení 4.8. Úvodní popis komponent ASD klient, ASD automat a Mantis a jejich činností je zmíněn v textu oblasti Hlavní prvky řešení 4.3.6. Požadované funkce na tyto komponenty z pohledu uživatele jsou v analyzovány v oblasti Případy užití 5.3. Účely komponent jsou: • ASD klient umožňuje uživateli správné formování e-mailu podle druhu zasílané zprávy. Pro samotné odeslání zprávy je využit implicitní e-mailový klient pro operační systém počítače uživatele. • Jiný SD nástroj je obecné označení pro SD aplikaci, která zasílá emailové zprávy v dohodnutém formátu. Může se jednat o SD nástroj uživatele služby (zákazníka) nebo SD nástroj libovolného subdodavatele služby. • IMAP mailbox označuje e-mailovou schránku, do níž jsou zasílány všechny zprávy z ASD klienta a jiného SD nástroje. Tato schránka slouží k uchovávání zpráv a umožňuje jejich třídění do složek. Přístup do ní má ASD automat, který zpracovává zprávy v režimu práce asistovaná komunikace. V případě přepnutí do režimu práce manuální komunikace do ní přistupuje i operátor SD pomocí e-mailového klienta. • ASD automat zpracovává e-mailové zprávy od uživatelů a na základě stavu požadavků (blíže v oblasti 6.3) rozhodne o další komunikaci zprávy, kterou pak vykoná. ASD automat používá pro evidenci požadavků komponentu Mantis. • Mantis Bug Tracker (též Mantis) je webová aplikace, která poskytne prezentační vrstvu nad svou databází. pro běžné uživatele slouží pouze ke čtení informací. Zápis do komponenty provádí pouze ASD automat, případně může úpravu udělat administrátor. Nejdůležitější standardy pro integraci komponent: • SMTP protokol - odesílání e-mailových zpráv pomocí SMTP protokolu do poštovní schránky (na obrázku 5.2 jako IMAP mailbox). 2

V případě, že by si řešitelé stále pouze předávali požadavek a nebyli schopni určit kompetentního řešitele, je vhodné požadavek eskalovat - tedy předat na řešitele řešící eskalace

5.2. KOMPONENTY ŘEŠENÍ

Obrázek 5.1: Obchodní proces zpracování požadavku

33

34


Obrázek 5.2: Diagram komponent ASD řešení

5.3. PŘÍPADY UŽITÍ

35

• IMAP protokol - ASD automat používá pro práci s poštovní schránkou IMAP4 protokol. Ten umožňuje pohodlnější manipulaci se zprávami než starší POP3 protokol3 . ASD automat používá IMAP protokol především pro čtení e-mailových zpráv a přesouvání zpráv v rámci složek poštovní schránky. • Mantis PHP API - ASD automat používá pro práci s požadavky programové rozhraní komponenty Mantis. Mantis PHP API je sice původně určené pro přidávání zásuvných modulů do aplikace, ale jeho široké spektrum funkcí umožňuje použit mantis jako úložiště pro požadavky a komunikaci přenechat ASD automatu. Vzhledem k rozšíření datového modelu Mantisu bylo potřeba doplnit možnost používání těchto polí a tabulek nad rámec Mantis PHP API pomocí SQL. K použití protokolu IMAP a SMTP se hodí poznamenat, že umožňují šifrovanou komunikaci. Zpráva by tak při použití šifrování neměla být odposlechnuta. Další možností zabezpečení e-mailů je šifrování zprávy pomocí standardu S/MIME Encryption a/nebo digitální podepisování. To by umožnilo zabezpečit zprávu pomocí asymetrického šifrování a pouze vlastník privátního klíče by dokázal zprávu přečíst. Bylo by ale potřeba zajistit více sad certifikátů a mohlo by se stát, že při používání manuálního modelu komunikace nebude mít operátor SD potřebné certifikáty a nebude moci zprávu přečíst. Šifrování zpráv není zahrnuto v rozsahu této práce.

5.3

Případy užití

Pro stanovení požadované funkčnosti softwarového systému jsou často používány diagramy případů užití (angl. Use Case). Jako vstup pro tvorbu těchto popisů modelovaného systému slouží především: • funkční požadavky z oblasti 4.1, • omezení daná návrhem architektury řešení z oblasti 4.3, • technologická omezení použitými komponentami z oblasti 5.2. Celý systém je určen ke komunikaci s požadavky dle významu ITSM. Pro jednoduchost a odlišení od požadavku na systém dle významu softwarového inženýrství jsem pro servisní požadavky použil zkratku SP. Tato zkratka bude použita i dále v práci. Prvkem pro stavbu diagramu jsou aktéři (angl. Actors), kteří jsou odpovědí na otázku „kdo bude systém používat?“. Zahrnují jak lidské uživatele, tak okolní systémy. V diagramu zobrazeno symbolem člověka. Dalším prvkem je samotný případ užití - tedy funkčnost, kterou má systém poskytovat. V diagramu zobrazeno symbolem oválu. Posledním stavebním prvkem diagramu je hranice systému značená obdélníkem. Ta určuje co je předmětem funkce daného (sub)systému. Případů užití je v celé systému mnoho. Pro přehlednost jsem případy použití rozčlenil do balíků podle komponent. 3

IMAP protokol je dostupný na většině serverů, proto zajištění kompatibility řešení s POP protokolem není předmětem této práce.

36


Obrázek 5.3: Balíky případů užití ASD řešení

5.3.1

Balíky případů užití

Balíky odpovídají komponentám řešení až na jednu výjimku. Tou je balík ASD aktéři, který obsahuje aktéry společné pro celé řešení a jednotlivé balíky si pak tyto aktéry propůjčují. Diagram balíků případů užití je na obrázku 5.3.

5.3.2

Aktéři

Aktér systému je role, kterou může konkrétní uživatel nebo okolní systém mít. Při analýze požadavků na systém jsem objevil mnoho aktérů, kteří kteří jsou napojeni na stejné případy užití. Proto jsem se se rozhodl generalizovat role řešitel, operátor, subdodavatel, zákazník a admin Mantisu na obecnější roli uživatel. Přehled aktérů je na diagramu 5.4.


37

Obrázek 5.4: Aktéři ASD řešení

5.3.3

ASD klient

Komponenta ASD klient představuje nástroj pro tvorbu správné formy zpráv (e-mailů). Uživatel její pomocí vytváří zprávy pro: • registraci SP, • informaci o průběžném stavu SP (bez předání), • předání SP na jiného řešitele, • zaslání informace o vyřešení SP, • vyžádání zaslání přepisu detailu SP, • vyžádání zaslání seznamu SP přiřazených na daného řešitele případně na řešitelskou skupinu do které patří. Případy užití jsou zachyceny na obrázku 5.5. V diagramu je užit vztah informační tok, značeno popisem flow, který znázorňuje, že případ užití vyvolává tok informací do jiné komponenty.

5.3.4

ASD automat

Komponenta ASD automat je z pohledu případů užití poměrně jednoduchá. Aktéry jsou pouze plánovač úloh operačního systému a administrátor ASD automatu. • Administrátor ASD automatu má za úkol pouze nastavování plánovače a může vynutit jednorázové zpracování příchozích zpráv pomocí skriptu pro běh ASD automatu.

38


Obrázek 5.5: Případy užití ASD klienta


39

Obrázek 5.6: Případy užití ASD automatu • Plánovač má za úkol spouštět zpracování ASD automatu podle specifikace dané administrátorem. Pro co největší interaktivitu je vhodné nastavit malé intervaly mezi spuštěními - např. jedna minuta od dokončení minulého spuštění. Hlavní funkcí ASD automatu je zpracování přišlých požadavků, zapsání patřičných informací do komponenty Mantis a komunikace změn na zainteresované uživatele. Diagram případů užití ASD automatu je na obrázku 5.6.

5.3.5

Mantis

Komponenta Mantis je webová aplikace. Její účel je pro běžného uživatele omezen pouze pro čtení. Pokud je Mantis umístěn v intranetu dodavatele, pak není ze síťového pohledu dostupný pro vnější uživatele (zde zákazník a subdodavatel). Základní funkce (seznam SP a detail SP) pro prohlížení SP však umožňuje ASD klient. Zápis do komponenty běžným uživatelem probíhá výhradně pomocí e-mailových zpráv zaslaných na IMAP mailbox, které následně zpracovává ASD automat. Případy užití komponenty Mantis jsou spjaty se dvěma aktéry. Uživatel může Mantis použít pro práci s požadavky: • vyhledání SP (pomocí řetězce, identifikátoru zákazníka, atd.),

40


• zobrazení detailu SP, • zobrazení seznamu SP, • filtrování seznamů SP podle parametrů (konfigurační položka, priorita, tarif služby, řešitel, atd.), • vytvoření exportu pro tabulkový procesor ze zobrazeného seznamu, Administrátor Mantisu může Mantis použít pro práci s požadavky stejně jako uživatel, ale má k dispozici ještě další tři funkce: • změna SP - vhodné pro manuální opravy chyb v parametrech požadavků, • přidání, úprava a odebrání konfigurační položky (KP) - vhodné pro konfiguraci Mantisu podle konkrétní služby, • přidání, úprava a odebrání uživatele - vhodné pro správu uživatelů, kterým bude řešení ASD poskytovat svou funkčnost. Diagram případů užití pro komponentu Mantis je na obrázku 5.7.

5.3.6

IMAP mailbox

Specifikace případů užití komponenty IMAP mailbox je intuitivní a vychází z obecných vlastností IMAP protokolu. Všichni aktéři používají IMAP mailbox k práci se zprávami. Hlavním případem užití je přečtení seznamu zpráv, následuje přečtení jedné zprávy a po zpracování zprávy je tato přesunuta do archivní složky. Složky používané v poštovní schránce jsou popsány v oblasti 6.4. Aktéři jsou následující. • ASD klient vkládá zprávy. • Subdodavatel vkládá zprávy (v tomto případě nevyužívá ASD klienta). • ASD automat zpracovává příchozí zprávy. • Administrátor ASD zpracování v případě potřeby může znovu zaslat chybně zpracovanou zprávu ke zpracování, případně smazat nevhodnou zprávu. • Operátor SD využije emailovou schránku v případě výpadku systému a přechodu na manuální model komunikace. Diagram případů užití pro komponentu IMAP mailbox je na obrázku 5.8.


41

Obrázek 5.7: Případy užití Mantisu

42


Obrázek 5.8: Případy užití IMAP mailboxu

Kapitola 6

Implementace Analytický rozbor problému umožnil stanovit hlavní rysy řešení. Tím se snížila implementační rizika. Tato kapitola popisuje hlavní prvky implementovaného systému a rozvádí tak do většího detailu předchozí kapitoly.

6.1

Druhy zpráv

Případy užití ASD klienta ukazují na více druhů zpráv. Tyto zprávy se liší podle informace kterou nesou a také komu je určena. Nejprve je potřeba specifikovat oblast šíření zprávy. Je zřejmé, že funkce vyžádání zaslání přepisu detailu SP má poskytnout informace zpátky odesilateli zprávy. Oproti tomu zaslání informace o vyřešení SP je zpráva, kterou by měl obdržet každý zainteresovaný uživatel a především zákazník. Oblasti šíření zpráv definuje tabulka 6.1. Názornější je pak obrázek 6.1, na kterém je uživatel odesílající zprávu oranžovou barvou a ASD automat zeleně. Nyní je možné na základě případů užití ASD klienta určit typy zasílaných zpráv. Blíže je definuje tabulka 6.2. Zpráva Uzavření SP sice není definována v případech užití ASD klienta, ale je vhodné připravit automat i pro tuto zprávu.

6.2

Uživatelské prostředí ADS klienta

Komponenta ASD klient má za úkol poskytnout uživateli grafické prostředí pro vytvoření správně formátované zprávy. Název zóny Veřejná Chráněná

ID PUBLIC PROTECTED

Privátní

PRIVATE

Rozsah všichni zainteresovaní uživatelé včetně zákazníka všichni zainteresovaní uživatelé dodavatele, nikoliv zákazník pouze odesilatel zprávy

Tabulka 6.1: Oblasti šíření zpráv

43

44

KAPITOLA 6. IMPLEMENTACE

Uživatel služby

Dodavatel služby e-mail e-mail e-mail


ASD automat

Uživatel odesílající zprávu

Zainteresovaný uživatel

Privátní zpráva Chráněná zpráva

Veřejná zpráva

Obrázek 6.1: Oblasti šíření zpráv ID M1 M2

Případ užití / typ zprávy Registrace SP Informace o stavu SP

M3

Předání SP

M4 M5

Vyřešení SP Detail SP

M6

Seznam SP

M7

Uzavření SP

Zóna

Význam zprávy

PRIVATE Založení nového požadavku v ASD. PUBLIC, Zaslání průběžné informace o stavu řešení. PoPROTECTED dle kontextu může být v zóně dodavatele nebo i se zákazníkem. PUBLIC, Předání požadavku na kompetentního řešitele. PROTECTED Podle kontextu může být v zóně dodavatele nebo i se zákazníkem. PUBLIC Zaslání vyjádření o vyřešení požadavku. PRIVATE Zaslání přepisu detailu požadavku odesilatele zprávy. PRIVATE Zaslání seznamu požadavků přiřazených skupině nebo řešiteli, do které patří odesilatel zprávy. PUBLIC Vyřešení požadavku je potvrzeno. Požadavek již nemůže být otevřen. Tabulka 6.2: Typy zpráv

6.3. STAVY POŽADAVKŮ

45

Grafické prostředí má umožnit vytvoření zpráv M1 až M6, které definuje tabulka 6.2. Pro rozvržení ovládacích prvků je použit návrh vystižený obrázkem 6.2. Tento návrh specifikuje použití ASD klienta, základní atributy jednotlivých zpráv, druh jejich zadávání a příklad dat.

ASD klient Registrace

ASD klient Manipulace

Detail

Seznam

Registrace

Manipulace

Detail

Seznam

Registrace nového požadavku

Manipulace s existujícím požadavkem

Typ požadavku:

incident

ID zákazníka:

INC000123

ID zákazníka:

INC000123

ID dodavatele:

000057

Typ zprávy:

vyřešení

Zóna komunikace:

veřejná (zákazník a dodavatel)

Konfigurační položka:

serverDELL1

Priorita:

2-střední

Předmět:

Chyba disku na serveru dell1.firma-abc.cz

Vyjádření: Řešení požadavku: Vadný disk v serveru dell1.firma-abc.cz byl vyměněn za nový bez nutnosti vypnutí serveru.

Popis:

Server dell1.firma-abc.cz hlásí chybu SCSI disku. Žádám o kontrolu a případnou výměnu.

Alexandr Velký HW Support Specialist DELL ČR podpora

Antonín Malý ICT administrátor Firma ABC

Smazat vše

Smazat vše

Vytvořit zprávu

ASD klient Registrace

Vytvořit zprávu

ASD klient Manipulace

Detail

Seznam

Registrace

Vyžádání zaslání detailu požadavku ID zákazníka:

INC000123

ID dodavatele:

000057

Manipulace

Detail

Seznam

Vyžádání zaslání seznamu požadavků přiřazených řešiteli nebo jeho skupině Vytvořit zprávu

Vytvořit zprávu

Obrázek 6.2: Návrh grafického rozhraní ASD klienta

6.3

Stavy požadavků

Výše uvedené zprávy vytvořené ASD klientem jsou zpracovávány ASD automatem. Každý typ zprávy vyvolá různou reakci systému v kontextu stavu požadavku kterého se týká. Takovéto chování je vhodné vystihnout stavovým diagramem. Události pro spuštění přechodu mezi stavy jsou zprávy z tabulky zpráv 6.2, případně jsou implicitně zřejmé. V případě tohoto diagramu jsem se rozhodl pro použití anglických názvů pro reakce na události. Obdobě jsou uvedeny i překlady stavů požadavků. Subjektivně hodnotím anglické

46


názvy jako výstižnější, ale především jak původní, tak mnou přidaný zdrojový kód programů je v angličtině. Reakce na události (např. updateSP, assignSP, atd.) jsou velmi blízké názvům funkcí programu, které manipulují s objektem. Tento diagram tedy odkazuje na funkce ve zdrojovém kódu. Požadavky se mohou nacházet v následujících stavech. • Nový požadavek vznikne pouze pomocí zprávy M1 s podmínku, že ID požadavku zákazníka již není v databázi vedeno. V ostatních případech dojde k zaslání chybového hlášení. • Přiřazený požadavek má u sebe vždy uvedeného odpovědného řešitele. Toto je základní předpoklad pro odpovědnou práci řešitelů. Ze stavu nový vzniká přiřazený funkcí předání na implicitního řešitele assignImplicitSolver. Předpokladem je, že při registraci je zadána konfigurační položka a že každá konfigurační položka má nastaveného implicitního řešitele. • Vyřešený je požadavek ve chvíli zaslání zprávy o vyřešení. Z tohoto stavu je možné se vrátit do stavu přiřazený. • Uzavřený je požadavek ve chvíli potvrzení vyřešení zákazníkem. Užívání ASD klienta je předpokládáno v organizaci dodavatele, a proto zaslání zprávy pro uzavření nepodporuje. Uzavírat požadavky může administrátor Mantisu nebo ASD automat při namapování zprávy M7 ve vstupní šabloně zákazníka. Diagram zachycující podrobně stavy požadavků, iniciátory změn stavů a vyvolané akce je na obrázku 6.3.

6.4

Složky poštovní schránky

ASD automat přistupuje do jedné poštovní schránky a čte příchozí zprávy. Po přečtení a zpracování zprávy přesouvá tuto do složky podle výsledku zpracování. Význam složek pro příchozí e-maily je následující: • INBOX - implicitní složka pro příchozí zprávy, odtud ASD automat čte zprávy. • Archive - zprávy úspěšně zpracované ASD automatem jsou v následujících podsložkách: – M1-Register - zprávy pro registraci požadavků, – M2-Info - zprávy pro informaci o průběžném stavu řešení, – M3-Assign - zprávy pro předání požadavku, – M4-Resolve - zprávy pro vyřešení požadavku, – M5-Detail - zprávy pro vyžádání zaslání přepisu požadavku, – M6-List - zprávy pro vyžádání zaslání seznamu uživateli/skupině přiřazení požadavku,

6.4. SLOŽKY POŠTOVNÍ SCHRÁNKY

Obrázek 6.3: ASD automat - stavy pžadavků

47

48


– M7-Close - zprávy pro uzavření požadavku, • Error - zprávy při kterých nastala chyba při zpracování ASD automatem, • ManuallyProcessed - složka, kam mají operátoři přesouvat zprávy manuálně zpracované při dočasném výpadu ASD automatu, • Unrecognized - nerozpoznané zprávy ASD automatem. Stromová struktura složek je na obrázku 6.4.

<Mailbox_root_folder>

INBOX

M1-Register

Archive

Error

M2-Info

M3-Assign

ManuallyProcessed

M4-Resolve

M5-Detail

Unrecognized

M6-List

M7-Close

Obrázek 6.4: Stromová struktura složek poštovní schránky Velikost e-mailových schránek je většinou limitována dle nastavení poštovního serveru. Při dlouhodobém běhu ASD automatu se budou e-maily ve schránce hromadit. Úkolem administrátora ASD zpracování je aby hlídal velikost schránky. Je vhodné nastavit automatický odklad zpráv podle vhodného pravidla. Například zprávy starší tří měsíců mají být odloženy. Vhodnější pravidlo může být například pokud je schránka zaplněna z více než 90%, pak udlož 20% zpráv.

6.5

Datový model

Mantis API bohužel neposkytuje dostatečnou funkcionalitu pro ukládání dat navrženého řešení. Proto bylo potřeba patřičně rozšířit databázové schéma komponenty Mantis. Pro manipulaci s přidanými položkami modelu je potřeba použít příkazy SQL. Fyzický datový model MySQL databáze je na obrázku 6.5. Původní schéma databáze Mantisu verze 1.2.8 obsahuje 31 tabulek. Z toho 5 jsem jich upravil (znázorněno žlutou barvou). Dále jsou přidané 3 nové tabulky (znázorněno oranžovou barvou). Mezi tabulkami je přidáno 7 vztahů. Nezměněné tabulky a původní vztahy nejsou vyobrazeny. Přidání nových vztahů si vynutilo založení nových cizích klíčů v původních tabulkách. Tyto cizí klíče jsou však vždy nepovinné. Úprava se tak nedotkne původní funkcionality Mantisu. Všechny přidané sloupce tabulek mají předponu asd_.

6.6. NASAZENÍ KOMPONENT

49

Mimo cizí klíče byly doplněny sloupce asd_customer_id pro identifikátor požadavku z SD nástroje zákazníka a asd_message_type pro záznam o typu zprávy. Nově přidané tabulky jsou tři: • asd_service_level - specifikace služby která je poskytována pro konkrétní požadavek, • asd_automat_run_log - záznam z běhu ASD automatu, • asd_message_log - záznam ze zpracování jedné příchozí zprávy.

6.6

Nasazení komponent

Pro funkčnost systému je potřeba jednotlivé komponenty ASD řešení rozmístit na fyzické výpočetní prostředky. Rozmístění komponent proběhne až při implementaci ASD řešení do organizace. Pro účely této práce je příkladné rozvržení komponent zachyceno na diagramu nasazení (angl. Deployment diagram) v obrázku 6.6. Hardwarové požadavky jsou dány použitým běhovým prostředkem jednotlivých komponent. Především se jedná o: • operační systémy klientských stanic, • prostředí JavaRE, • operační systémy serverů, • databázový server MySQL, • webový server Apache s podporou prostředí PHP. Běh ASD automatu je vhodné spouštět plánovačem úloh operačního systému. Doporučená prodleva mezi spuštěním běhů je v rozmezí 1 až 15 minut.

6.7

Nastavení komponenty Mantis

Pro správné fungování komponenty Mantis v ASD řešení je potřeba splnit následující předpoklady.

6.7.1

Konfigurační položky

Mantis v základní instalaci nepočítá s konfiguračními položkami. Umí ovšem požadavky seskupovat do projektů. V tomto kontextu lze využít projekty pro reprezentaci konfiguračních položek. Projekty se také dají řadit do hierarchické struktury. ASD automat počítá s tím, že v prvním stupni struktury je projekt reprezentující celého zákazníka. Jako podprojekty v druhé úrovni jsou pak přiřazeny jednotlivé konfigurační položky. ASD automat zařazuje požadavky do projektů podle konfiguračních položek. Výše popsanou konfigurací je umožněno vytvářet reporty a statistiky jak pro konkrétní konfigurační položky, tak pro všechny požadavky zákazníka.

50


Obrázek 6.5: Fyzický model upravené databáze Mantisu

6.7. NASTAVENÍ KOMPONENTY MANTIS

Obrázek 6.6: Diagram nasazení

51

52

6.7.2


Uživatelé

ASD automat počítá s tím, že uživatelská jména odpovídají e-mailovým adresám, ze kterých přicházejí zprávy. Autentifikace uživatele je založena na existenci odesílající adresy v poli uživatelského jména. Administrátor Mantisu má implicitně veškerá práva. Běžného uživatele je vhodné založit v roli recenzent a odebrat této roli veškerá práva pro manipulaci s požadavkem. Především se jedná o úpravu zadání požadavku, stavů a přidávání komentářů.

6.7.3

Kategorie

Mantis podporuje kategorizaci požadavků. Kategorie jsou použity pro typ služby vztahující se k požadavku. V globálních kategoriích je potřeba zadat všechny typy požadavků - například: incident, change, servis nebo problem.

Kapitola 7

Testování Pro zajištění správné funkčnosti softwarového vybavení je vhodné provádět testování během celého procesu implementace. Tato kapitola obsahuje přístup testování, který byl zvolen při vývoji ASD řešení.

7.1

Testy při programování

Během vývoje jednotlivých komponent, především ASD klienta a ASD automatu, probíhalo kontinuální testování jednotlivých funkčností kódu. Toto testování je zaměřeno na funkčnosti jednotlivých tříd s využitím znalostí o jejich struktuře (anglicky nazýváno White Box testing). Každý soubor s třídou má ve stejném adresáři kde se nachází i soubor pro otestování nazvaný podle konvence: test. Po spuštění tohoto souboru dojde k otestování základních funkcí třídy ze souboru .

7.2

Integrační testy

Integrační vazby mezi jednotlivými komponentami (blíže popsané v oblasti 5.2) jsou velmi silné a ověřené častým používáním. PHP funkce pro IMAP protokol, SQL dotazy do MySQL databáze a Mantis PHP API jsou prověřovány použitím v mnoha aplikacích po celém světě. Při vývoji ASD automatu byla tato funkčnost potvrzena. Integrační testy ASD automatu s jiným SD nástrojem nejsou předmětem této práce, protože implementace ASD řešení do konkrétní organizace rovněž není součástí práce.

7.3

Akceptační testy

Předmětem akceptačních testů je provést ověření chování aplikace vzhledem k funkční specifikaci. Pro tento účel jsem využil požadavky na systém z oblasti 4.2 a případy užití z oblasti 5.3 ke stanovení testovacích scénářů. Každý testovací scénář obsahoval alespoň jeden testovací případ.

53

54

KAPITOLA 7. TESTOVÁNÍ

Podrobné protokoly z testování jsou v příloze A. Přehled výsledků testování obsahují tabulky 7.1 a 7.2. Sloupce tabulky označené písmeny B, Z a D znamenají počty Blokujících, Zásadních a Drobných chyb nalezených v testovacím scénáři. Součet nalezených chyb jednotlivých závažností (B =1, Z =6 a D=4) je nízký. To je však dáno tím, že během vývoje bylo provedeno mnoho testů a celý vývoj řešení prováděl jeden člověk.

ASD klient

ASD automat ASD automat, ASD Klient Mantis, ASD klient Mantis, ASD automat

ASD automat Mantis, ASD klient Mantis Mantis Mantis

T2

T3 T4

T7 T8

T9 T10 T11

T6

T5

Komponenta ASD klient

ID T1

F8 F9 F10

F6 F7

F5

F4

F2 F3

F1

Odkaz -

0 0 0

0 0

0

0

0 0

1

B 0

0 0 0

0 0

1

1

0 0

0

Z 0

0 0 0

0 1

2

0

0 0

0

D 1

-

OK

OK

OK

-

OK

Oprava OK

Tabulka 7.1: Přehled testovacích scénářů 1/2

Vyřešení požadavku Prohlížení, filtrování, vyhledávání SP Report požadavků ke KP Export libovolného reportu Výpis statistik

Vypsání seznamu SP (report přiřazení) Zadávání ID ze zákaznického SD

Kategorizace požadavku Předání požadavku

Registrace požadavku

Název testovacího scénáře Práce s ASD klientem

Z - ASD klient nevypisoval požadavky skupiny do které uživatel patří. Z - Mantis nezobrazuje ID, přiřazeno do pole OS. D - ve dvou výstupních šablonách nebylo ID zákazníka zobrazeno. D - vyhledávání zpřehledněno přidání ID zákazníka do pole OS (viz. T5). -

Nalezené chyby D - někdy odesílá mezery za ID SP, vyřešeno oříznutím. B - pád ASD automatu při zpracování neznámé KP. -

7.3. AKCEPTAČNÍ TESTY 55

KAPITOLA 7. TESTOVÁNÍ 56

T17

T15 T16

T13 T14

ID T12

ASD automat Mantis

ASD automat ASD automat

Komponenta ASD automat

Manipulace se schránkou

Název testovacího scénáře Komunikace v zónách Public, Protected, Private Notifikace s celou historií SP Notifikace s přírůstkovou historií SP Autentifikace pomocí e-mailů Zobrazení požadavku -

N23 -

F13, F14 F14, F15

Odkaz F12, F16

0

0

0 0

0 0

B 0

1

0

0 1

0 1

Z 1

0

0

0 0

0 0

D 0

OK

-

OK

OK

Oprava OK

-

-

0

Manipulace se stavem požadavků

0

ASD automat, IMAP mailbox ASD automat

0

4

T18

-

6

ASD automat

1

T19

Archivace zpráv podle typu do složek Celkem

Tabulka 7.2: Přehled testovacích scénářů 2/2

Nalezené chyby Z - systém neinformoval zákazníka při zprávě M2 Info. Z - systém neinformoval zákazníka při zprávě M2 Info. Z - Mantis nezobrazuje ID, přiřazeno do pole OS. (viz. T5). -

Z - chybné přiřazení na řešitele při zprávě M3 Assign (z Resolved na Assigned), měl být přiřazen poslední a nikoliv implicitní. -

Kapitola 8

Závěr Začátek práce pojednává o řízení dodávání IT služeb. Teoretické podklady a názvosloví jsou čerpány z metodického rámce ITIL. V práci se podařilo podrobně rozebrat různé obchodní modely z oblasti řízení IT služeb. Důraz byl kladen na model hierarchie service desků, který zahrnuje jak organizaci uživatele, tak organizaci dodavatele a případných subdodavatelů služby. Bylo navrženo komponentní softwarové řešení pomocí principů metodiky unifikovaného vývoje aplikací, které poskytuje uživatelům nástroj pro komunikaci a ulehčení práce. Toto řešení zahrnuje především použití strukturovaných e-mailových zpráv pro komunikační kanál, klientskou aplikaci ASD klient pro tvorbu těchto zpráv, automat zpracování příchozích zpráv ASD automat a převzaté databázové úložiště s prezentační vrstvou Mantis. Celé řešení je multiplatformní. Dopad rizika technologického výpadku je omezen pomocí možnosti přechodu na manuální zpracování zpráv. Celé řešení bylo otestováno a shledáno funkčním. Všechny určující parametry řešení jsou příslušným způsobem zdokumentovány. K dispozici jsou příručky pro uživatele a administrátora systému. Pokračováním práce může být vylepšení uživatelského rozhraní převzaté komponenty Mantis, přidání BI1 komponenty pro reportování stavu poskytované služby, případně rozšíření stavového prostoru servisních požadavků.

1

Zkratka BI značí Business Intelligence - aplikaci pro získávání informací pro podporu obchodních rozhodnutí.

57

58

KAPITOLA 8. ZÁVĚR

Literatura [1] Jim Arlow, Ila Neustadt. UML 2 a unifikovaný proces vývoje aplikací. 2. Holandská 8, 639 00 Brno, Česká republika : Computer Press, 2. edicce edition, 2008. [2] Kolektiv autorů. ITIL: Service Strategy Book. 1. St Crispins House, Duke Street, Norwich, UK : The Stationery Office, 1st edition, 2007. [3] Kolektiv autorů. ITIL v3 Slovníček termínů, definic a zkratek. 1. Vyskočilova 3/741, Praha 4, Česká republika : itSMF Czech Republic, o.s., v2.0 edition, 2008. [4] Lucid IT. Lucid IT, 2012. http://www.lucidit.com.my, stav ze 27. 2. 2012. [5] OMNICOM, s.r.o. ITSM Portál, 2012. http://www.itsmportal.cz/, stav ze 23. 2. 2012. [6] Wikipedia. MySQL, 2012. http://cs.wikipedia.org/wiki/MySQL, stav ze 14. 3. 2012.

59

60

LITERATURA

Příloha A

Protokoly z testování Protokoly z testování jsou uvedeny ve složce testy/protokoly na DVD. Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y) Blokující chyby Závažné chyby Drobné chyby Výsledek přetestování

Data T1 ASD klient Práce s ASD klientem Registrace, manipulace (průběžná informace, předání, vyřešení), detail a seznam SP. D - někdy odesílá mezery za ID SP, vyřešeno oříznutím. OK

Tabulka A.1: Test T1 - Práce s ASD klientem Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y) Blokující chyby

Závažné chyby Drobné chyby Výsledek přetestování

Data T2 ASD klient Registrace požadavku F1 Registrace požadavku z role dodavatele i zákazníka. Vyplňování chybných hodnot do formuláře. B - pád ASD automatu při zpracování neznámé KP. Opraveno, při nenalezení KP se požadavek zařadí do projektu se jménem zákazníka. OK

Tabulka A.2: Test T2 - Registrace požadavku

61

62

PŘÍLOHA A. PROTOKOLY Z TESTOVÁNÍ

Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y) Blokující chyby Závažné chyby Drobné chyby Výsledek přetestování

Data T3 ASD automat Kategorizace požadavku F2 Zaslání požadavků ve všech kategoriích (incident, change, problem, servis) a následná kontrola zobrazením v Mantisu. -

Tabulka A.3: Test T3 - Kategorizace požadavku


Data T4 ASD automat, ASD Klient Předání požadavku F3 Předání existrujícího požadavku mezi dvěma řešiteli/skupinami. Tabulka A.4: Test T4 - Předání požadavku


Data T5 Mantis, ASD klient Vypsání seznamu SP (report přiřazení) F4 Vypsání seznamu SP v Mantisu. Zažádání ASD klientem o zaslání výpisu přiřazený SP k uživateli a jeho skupině. Z - ASD klient nevypisoval požadavky skupiny do které uživatel patří. OK

Tabulka A.5: Test T5 - Vypsání seznamu SP (report přiřazení)

63


Data T6 Mantis, ASD automat Zadávání ID ze zákaznického SD F5 Zobrazení ID zákazníka v Mantisu - seznamu i detailu. Přítomnost zákaznického ID u všech zpráv ASD klienta. Z - Mantis nezobrazuje ID zákazníka, přiřazeno do pole OS. 2x D - ve dvou výstupních šablonách nebylo ID zákazníka zobrazeno. OK

Tabulka A.6: Test T6 - Zadávání ID ze zákaznického SD Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y) Blokující chyby Závažné chyby Drobné chyby Výsledek přetestování

Data T7 ASD automat Vyřešení požadavku F6 Vyřešení požadavku pomocí ASD klienta. Ověření zapsání do Mantisu. Tabulka A.7: Test T7 - Vyřešení požadavku


Data T8 Mantis, ASD klient Prohlížení, filtrování, vyhledávání SP F7 Zobrazení ID zákazníka v Mantisu - seznamu i detailu. Přítomnost zákaznického ID uz všech zpráv ASD klienta. D - vyhledávání zpřehledněno přidání ID zákazníka do pole OS (viz. T5). OK

Tabulka A.8: Test T8 - Prohlížení, filtrování, vyhledávání SP

64



Data T9 Mantis Report požadavků ke KP F8 Výpis seznamu požadavků k jednomu projektu (KP) -

Tabulka A.9: Test T9 - Report požadavků ke KP


Data T10 Mantis Export libovolného reportu F9 Export seznamů požadavků pro projekt zákazníka a podprojekt konfigurační položky -

Tabulka A.10: Test T10 - Export libovolného reportu


Data T11 Mantis Výpis statistik F10 Zobrazení statistik pro projekt zákazníka a podprojekt konfigurační položky Tabulka A.11: Test T11 - Výpis statistik

65

Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y)

Blokující chyby Závažné chyby Drobné chyby Výsledek přetestování

Data T12 ASD automat Komunikace v zónách Public, Protected, Private F12, F16 ASD klientem zaslat zprávy: registrace, manipulace (průběžná informace, předání, vyřešení), detail a seznam SP. Kontrola předání informace podle zón. Z - systém neinformoval zákazníka při zprávě M2 Info. OK

Tabulka A.12: Test T12 - Komunikace v zónách Public, Protected, Private Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y)


Data T13 ASD automat Notifikace s celou historií SP F13, F14 Kontrola, zda pro zprávy: manipulace (průběžná informace, předání, vyřešení) a detail SP, je odeslána výstupní komunikace ASD automatem s celým přepisem historie SP. -

Tabulka A.13: Test T13 - Notifikace s celou historií SP Položka ID scénáře Komponenty Název scénáře Funkcionalita (odkaz) Testovací případ(y)


Data T14 ASD automat Notifikace s přírůstkovou historií SP F14, F15 Kontrola, zda pro zprávy: manipulace (průběžná informace, předání, vyřešení) a detail SP, je odeslána výstupní komunikace ASD automatem s přírůstkovým přepisem historie SP. Z - systém neinformoval zákazníka při zprávě M2 Info. OK

Tabulka A.14: Test T14 - Notifikace s přírůstkovou historií SP

66



Data T15 ASD automat Autentifikace pomocí e-mailů N23 Zaslání zprávy z registrované e-mailové schránky. Zaslání zprávy z neznámé e-mailové schránky. -

Tabulka A.15: Test T15 - Autentifikace pomocí e-mailů


Data T16 Mantis Zobrazení požadavku Zobrazení detailu požadavku v Mantisu, kontrola všech důležitých položek Z - Mantis nezobrazuje ID zákazníka, přiřazeno do pole OS. (viz. T5). OK

Tabulka A.16: Test T16 - Zobrazení požadavku


Data T17 ASD automat, IMAP mailbox Manipulace se schránkou Test čtení e-mailů ASD automatem. Test přístupu do IMAP mailboxu uživatelem pomocí Microsoft Office Outlooku. -

Tabulka A.17: Test T17 - Manipulace se schránkou

67


Data T18 ASD automat Manipulace se stavem požadavků Kontrola manipulace ASD automatu s požadavkem. Předpisem je stavový diagram. Z - chybné přiřazení na řešitele při zprávě M3 Assign (z Resolved na Assigned), měl být přiřazen poslední a nikoliv implicitní. OK

Tabulka A.18: Test T18 - Manipulace se stavem požadavků


Data T19 ASD automat Archivace zpráv podle typu do složek Kontrola rozřazování e-mailů zpracovaných ASD automatem do složek v IMAP mailboxu pro zprávy M1, M2, M3, M4, M5 a M6. -

Tabulka A.19: Test T19 - Archivace zpráv podle typu do složek

68


Příloha B

Uživatelská příručka Uživatelská příručka poskytuje podporu uživateli pro instalaci a spuštění komponent ASD klient a Mantis. Dále obsahuje popis základních práci s těmito komponentami z pohledu uživatele. Vzhledem k tomu, že se jedná o samostatný dokument ve formátu Microsoft Word, je přiložen pouze v elektronické podobě na DVD. Uživatelská příručka je ve složce prirucka_uzivatele.

69

70

PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA

Příloha C

Administrátorská příručka Administrátorská příručka poskytuje podporu administrátorovi pro instalaci a spuštění komponent ASD automat a Mantis. Dále obsahuje popis základních práci s těmito komponentami z pohledu administrátora. Vzhledem k tomu, že se jedná o samostatný dokument ve formátu Microsoft Word, je přiložen pouze v elektronické podobě na DVD. Administrátorská příručka je ve složce prirucka_administratora.

71

72

PŘÍLOHA C. ADMINISTRÁTORSKÁ PŘÍRUČKA

Příloha D

Seznam použitých zkratek API Application Programming Interface ASD Automatizovaný Service Desk BI Business Intelligence BPMN Business Process Model and Notation DVD Digital Versatile Disc nebo Digital Video Disc GUI Graphical User Interface (grafické uživatelské rozhraní) HTTP Hypertext Transfer Protocol HW Hardware IMAP Internet Message Access Protocol IT Informační Technologie ITIL Information Technology Infrastructure Library ITSM IT Service Management KP Konfigurační Položka L1 Level 1 Support (první úroveň podpory) L2 Level 2 Support (druhá úroveň podpory) L3 Level 3 Support (třetí úroveň podpory) MySQL MySQL databázový stroj OGC Office of Government Commerce OMG Object Management Group OS Operační Systém

73

74

PŘÍLOHA D. SEZNAM POUŽITÝCH ZKRATEK

PHP rekurzivní zkratka PHP: Hypertextový Preprocessor POP Post Office Protocol RFC Request For Change (požadavek na změnu) SD Service Desk SI Softwareové Inženýrství SLA Service Level Agreement (dohoda o parametrech služby) SMTP Simple Mail Transfer Protocol SP Servisní Požadavek SQL Structured Query Language SW Software UML Unified Modeling Language UP Unified Process (Unifikovaný Proces vývoje aplikací)

Příloha E

Obsah přiloženého DVD Struktura přiloženého DVD je na obrázku E.1. Návod na práci s daty na disku je v souboru README.TXT.

Obrázek E.1: Obsah DVD

75

Na tomto místě bude oficiální zadání vaší práce

Recommend Documents