Návrh a prototypová implementace systému pro správu poţadavků

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Návrh a prototypová implementace systému pro správu poţadavků Diplomová práce Autor: Tomáš Růţička Informační technologie a management Vedoucí práce: Ing. Michal Valenta, Ph.D. Praha Duben, 2010

2 Prohlášení: Prohlašuji, ţe jsem svou diplomovou práci zpracoval samostatně, s pouţitím uvedené literatury. V Jinočanech, dne Tomáš Růţička ii

3 Annotation: The main goal of this thesis is to develop a system for request management. It summarizes domain recommendations defined by ITIL framework and delimitates fundamental premises of effective request management in small to mid-sized companies. Based on the results of this analysis a new request management system was designed and implemented using ASP.NET 3.5 and Microsoft SQL Server. The system was developed according to principles of event management defined by ITIL together with respect to ease of implementation and operation. The implementation part of the thesis marks the techniques used to overcome some of the ASP.NET technology limitations. System was thoroughly tested in production environments, which was a basis for future development process outlining. Anotace: Cílem práce je vývoj systému pro správu poţadavků. Práce shrnuje doporučení definovaná v této oblasti frameworkem ITIL a vymezuje nezbytné předpoklady efektivní správy poţadavků v menší či středně velké společnosti. Na základě této analýzy je navrţen a pomocí technologií ASP.NET 3.5 a Microsoft SQL Server implementován vlastní systém pro správu poţadavků. Systém je vyvíjen v souladu se základními principy správy událostí definovanými v ITIL, zároveň je však respektován poţadavek, aby jeho nasazení neznamenalo pro menší či střední firmu zásadní zvýšení administrativních a technologických nároků. V implementační části jsou naznačeny techniky vedoucí k překonání některých nedostatků technologie ASP.NET a webových aplikací obecně, mezi něţ patří odezva uţivatelského rozhraní, neefektivní HTML kód či problematická správa stavu relací. Ověření ţivotaschopnosti předkládaného konceptu bylo provedeno nasazením v produkčních prostředích vybraných společností, zkušenosti z nasazení slouţí jako podklad pro nástin dalších moţných směrů vývoje aplikace. iii

4 Obsah 1 Úvod Správa poţadavků Správa poţadavků z pohledu ITIL Service Desk Event Management Incident Management Request Fulfilment Problem Management Change Management Release Management Configuration Management Knowledge Management Systémy pro správu a řízení poţadavků Analýza poţadavků a návrh systému Analýza poţadavků Vymezení základních poţadavků Rozbor poţadavků Volba technologie a implementačního prostředí Analýza a návrh systému Volba architektury, vrstvy a moduly Významné třídy Implementace Problémové oblasti ASP.NET a způsoby jejich řešení iv

5 4.1.1 Odezva uţivatelského rozhraní Ověřování Neefektivní HTML/XHTML kód View State Datová vrstva Procedura pro načtení seznamu poţadavků Archivace změn Konkurenční přístup k datům Mezivrstva pro přístup k datům Archivace změn z pohledu DAL PersonManager Business vrstva Request Section Person POP3Sync RequestorScheduler a RequestorTask RequestorConfig UserConfig RequestSearchParameters Ovladače HTTP Prezentační vrstva Stránka rqviewlist.aspx Stránka rqeditrequest.aspx rqglobalprefs.aspx rqsectionprefs.aspx a rquserprefs.aspx rqtitlebar.ascx v

6 4.5.6 Soubory rqjsfce.js, rqjsfiles.js, rqjsviewlist.js RequestReport.rpt Nasazení systému Závěr Literatura Seznam obrázků Seznam výpisů vi

7 Lit. srovnání dle abecedy, nesahat [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] vii

8 viii

9 1 Úvod Většina společností, které provozují nějaký informační systém, je dříve či později nucena čelit problému správy a řízení poţadavků, které v souvislosti s provozováním systému vznikají. Cílem této práce je vyvinout pomocí technologie ASP.NET systém pro správu poţadavků, který by splňoval nároky malé či střední firmy. Systém by měl na jedné straně v co největší míře respektovat standardy předkládané znalostním rámcem ITIL, na straně druhé by jeho nasazení nemělo pro společnost znamenat podstatné zvýšení administrativních a technologických nároků, coţ, jak bude později rozebráno, není při dodrţení zásad ITIL zcela samozřejmé. Práce se kromě vlastního vývoje systému zabývá i problémy spojenými s nasazením ASP.NET při vývoji webových aplikací a moţnými postupy jejich řešení. Práce se pokouší naznačit techniky vedoucí k překonání některých nedostatků technologie ASP.NET (a webových aplikací obecně), mezi něţ patří odezva uţivatelského rozhraní, neefektivní HTML kód či problematická správa stavu relací. Práce je členěna na tři základní oddíly Správa poţadavků, Analýza a Implementace. Kapitola Správa poţadavků z pohledu ITIL definuje a vymezuje pojem správy poţadavků tak, jak bude chápán v rámci této práce. Uvádí do problematiky správy poţadavků a incidentů z pohledu znalostního rámce ITIL a shrnuje doporučení, která pro řešení této problematiky ITIL předkládá. V kapitole jsou téţ nastíněny klíčové operace prováděné při správě poţadavků a funkce, které by měl systém pro správu poţadavků poskytovat. Jsou téţ uvedeny některé výhody i nevýhody některých známých a dostupných řešení. Kapitoly Analýza poţadavků a návrh systému a Implementace jsou stěţejními částmi práce. Před vlastním popisem návrhu systému jsou v kapitole Analýza poţadavků a návrh systému nejprve definovány a rozebrány základní poţadavky na vyvíjený systém, korespondující s doporučeními ITIL, a obvyklé případy uţití. Další část kapitoly tvoří popis implementačního prostředí, návrh základní architektury systému 1

10 a rozbor, jak se výchozí poţadavky promítnou do návrhu datového modelu a některých konkrétních tříd. Kapitola Implementace rozebírá implementační detaily jednotlivých částí aplikace, popisuje konkrétní postupy pouţité pro řešení problematických oblastí návrhu, pojmenovává základní problémy, které s sebou při vývoji webových aplikací přináší nasazení technologie ASP.NET a detailně rozvádí konkrétní způsoby jejich řešení. Konečným výsledkem práce je systém pro správu poţadavků postavený na technologii ASP.NET, který lze bez dalších dodatečných nákladů nasadit jak v malé firmě provozující Windows Small Business Server s jedinou doménou, tak i ve větším podniku s několika doménami a dedikovaným SQL Serverem. Systém implementuje doporučení ITIL v nezbytně nutné míře, která je dle názoru autora dostačující pro zajištění potřebné funkcionality, aniţ by zároveň nutila uţivatele k zásadním změnám firemních procesů. 2

11 2 Správa poţadavků Správu poţadavků lze chápat jako řízené vykonávání procesů spojených s celým ţivotním cyklem poţadavků, od jejich iniciace po vyřešení a následný reporting či audit. Poţadavkem je přitom míněna ţádost o řešení libovolného problému uţivatele či zákazníka. Můţe se jednat o změnu funkcionality systému, řešení incidentu, odstranění chyby, optimalizaci stávajících postupů, přidělení prostředků výpočetní techniky novému uţivateli, apod. Poţadavky v tomto smyslu odpovídají významům request či incident, vztahují se tedy k řešení událostí plynoucích z provozu informačních systémů. Pojem poţadavek lze téţ chápat ve významu requirement, tedy jako potřebu či omezení definované při vývoji informačních systémů. Tímto druhem poţadavků se v textu zabývat nebudeme. Spolu s rozvojem informační infrastruktury nezřídka roste i objem chyb, incidentů a změnových poţadavků plynoucích z jejího uţívání. Evidovat tyto události v klasické papírové formě je od jistého objemu zpracovávaných informací značně problematické, ne-li téměř nemoţné. Údrţba dokumentů se v takových systémech komplikuje, přehlednost se ztrácí a efektivita řešení klesá často není jasné kdo, kdy a co má vlastně řešit, poţadavky jsou často opomíjeny, řešeny pozdě či vůbec. Se zvyšujícím se počtem řešených poţadavků tak vzniká potřeba automatizace činností spojených s jejich zpracováním. Ta je obvykle zajišťována nasazením specializovaného software pro správu poţadavků. V oblasti software pro řízení poţadavků existuje široká škála řešení, sahající od jednoduchých systémů pro záznam telefonických hovorů aţ po rozsáhlé service-desk aplikace. Optimální nástroj by měl umoţňovat správu poţadavků v celém ţivotním cyklu, od jejich vzniku, přes proces validace, přijetí a přidělení řešiteli, aţ po jejich konečné vyřešení. Systém by měl být zároveň zdrojem relevantních údajů pro případný audit IT procesů. Dle názoru autora lze konstatovat, ţe by systém pro správu poţadavků měl v nejvyšší moţné míře respektovat koncepty a doporučení frameworku ITIL. 3

12 2.1 Správa poţadavků z pohledu ITIL Znalostní rámec ITIL (Information Technology Infrastructure Library) je dnes mezinárodně uznávaným standardem a pravděpodobně nejrozšířenějším znalostním rámcem pro řízení a poskytování IT sluţeb. V podstatě se jedná o sadu kniţních publikací popisujících způsob řízení IT sluţeb a infrastruktury. Framework vznikal koncem 80. let ve Velké Británii, za vydatné podpory vlády. Jedním z hlavních motivů jeho vzniku byla tehdy nespokojenost s kvalitou a náklady spojenými s provozem informačních technologií ve státních organizacích. Knihovna ITIL prodělala poměrně bohatý vývoj, byla mnohokrát revidována a konsolidována. V červnu 2007 byla představena jiţ její 3. verze. ITIL, jenţ sám sebe definuje jako Best practice framework, shrnuje praktické poznatky a zkušenosti IT manaţerů s řízením a poskytováním IT sluţeb v podnikovém prostředí. Cílem frameworku je vytvoření přehledného a provázaného systému jednotlivých aktivit, který povede ke zvýšení stability a kvality poskytovaných sluţeb. K hlavním rysům ITIL patří orientace na zákazníka a řízení procesů s důrazem na jejich vzájemnou provázanost. ITIL akcentuje odklon od úzce technického či obchodního pojetí řízení IT k širšímu pohledu 1, vedoucímu k zaměření na zvyšování kvality sluţeb a budování těsného vztahu se zákazníky ( quality approach ). Spíše neţ o metodiku se tedy jedná o jakousi konzervaci reálných zkušeností z provozu, o popis a vymezení procesů a funkcí (funkcí je v pojetí ITIL myšlena organizační jednotka), které jsou nezbytné ke správnému fungování a řízení ICT sluţeb. Právě definice ucelené sady těchto procesů a funkcí, včetně detailního rozboru jejich vstupů, výstupů, vzájemných vazeb a moţných problémových oblastí je dle názoru autora hlavním přínosem knihovny. Zásadním pro zlepšování kvality řízení ICT v organizacích je i důsledná orientace na proces a jeho definici spolu s popisem metrik, způsobů měření kvality a principů reportingu. 1 [6], s. 42. The organization that focuses only on business requirements without thinking about how they are going to deliver willl end up making promises that cannot be kept. The organization that focuses only on internal systems without thinking about what services they support will end up with expensive services that deliver little value. 4

13 Framework není přehnaně rigorózní, nepředepisuje kompletní změnu myšlení či bezpodmínečný redesign stávajících procesů. ITIL, svými vlastními slovy 2, pouze poskytuje rámec, do něhoţ lze strukturovaně uspořádat existující metody a činnosti. Nutno však podotknout, ţe pokusíme-li se aplikovat uvedená doporučení a případně dodrţet auditovatelný standard ISO/IEC 20000, redesignu některých procesů se zřejmě nevyhneme, přičemţ potřeba redesignu bude tím větší, čím vyšší verzi ITIL implementujeme. Zde je vhodné poznamenat, ţe přestoţe hnutí itsmf deklaruje snahu o vytvoření komunikační platformy napříč celým odvětvím informatiky 3 je jeho přínos k propagaci a zavádění standardů ITIL do menších a středně velkých společností, dle názoru autora, přinejmenším diskutabilní. Z hlediska přístupu k problematice správy a řízení poţadavků jsou stěţejními dokumenty ITIL v. 3 knihy Service Operation a Service Transition, případně Service Support (a Service Delivery), vycházíme-li z ITIL verze 2. ITIL verze 3 mírně mění schéma procesů a funkcí známé z verze 2, klíčové koncepty však zůstávají zachovány. Při vývoji systému proto nebudeme vycházet z konkrétní verze frameworku, nýbrţ z konceptů, které jsou v metodice obsaţeny jiţ od počátku. Pro členění jednotlivých procesů v textu pouţijeme schéma verze 3 a v případech, které se bezprostředně dotýkají řešené problematiky, připomeneme rozdíly mezi oběma verzemi. Detailní rozbor frameworku ITIL přesahuje rámec této práce, proto pouze stručně nastíníme oblasti a doporučení, z nichţ budeme vycházet při vývoji vlastního řešení pro správu poţadavků Service Desk Primárním cílem funkce Service Desk je poskytnout uţivatelům IT sluţeb centralizované kontaktní místo pro zadávání a vyřizování poţadavků. Service Desk v podstatě představuje unifikovaný komunikační kanál mezi uţivatelem IT sluţby a jejím poskytovatelem. Podpora provozních a uţivatelských záleţitostí je jedním z hlavních problémů většiny IT oddělení. Jak zmiňuje [15], není-li k dispozici Service Desk, je velmi častým jevem 2 [7], s. 1: Using ITIL doesn't imply a completely new way of thinking and acting 3 5

14 ţivelná komunikace mezi IT oddělením a uţivateli jednotlivých sluţeb. Hlášení poruch, výpadků či poţadavků na změnu funkcionality se nezřídka odehrávají zcela nesystémově, přičemţ způsob nahlášení poţadavku je často zcela v rukou pracovníka ohlašujícího incident. Jak dále uvádí [15], velmi často dochází k jevu trefně nazvaném Ulov si svého IT uţivatel má obvykle přímou cestu k jednotlivým pracovníkům IT oddělení, kontaktovány jsou různé osoby, různými cestami, bez jakékoli evidence co, kdy, proč a v jaké kvalitě bylo poţadováno. Tento stav vede nejen k přetěţování pracovníků problémy, které mnohdy nespadají do jejich kompetence, ale i k neefektivnímu a často chybnému řešení (či dokonce neřešení) přijatých poţadavků. Sledovat a vykazovat reálné vytíţení pracovníků či finanční náročnost jednotlivých sluţeb je za tohoto stavu věcí značně obtíţné. Instalace centrálního kontaktního místa (Service Desk) umoţňuje efektivní řízení komunikace oddělení IT s uţivateli, včetně automatizace sběru a vyhodnocování dat pomocí specializovaných aplikací. Další funkcí Service Desk je filtrace, rozdělování, eskalace a koordinace řešení přijatých poţadavků v rámci definovaných úrovní odbornosti řešitelů. Příkladem můţe být situace, kdy první úroveň podpory řeší běţné problémy, na druhé úrovni působí specialisté a třetí úroveň reprezentují externí dodavatelé a konzultanti Event Management Proces zavedený v ITIL v. 3 se zabývá správou událostí majících nějaký vliv na chod infrastruktury či sluţeb. Je základem všech procesů operačního managementu a správy sluţeb a integrální součástí většiny procesů definovaných v publikacích Service Operation a Service Transition. Schopnost detekovat a zaznamenat výskyt události je základním předpokladem k započetí procesu jejího řešení Incident Management Zatímco Service Desk vytváří komunikační rozhraní mezi uţivatelem a IT oddělením, primárním cílem Incident Managementu je řešení nestandardních situací. Incidentem je v pojetí ITIL jakékoli neplánované přerušení sluţby, sníţení kvality sluţby či potenciální ohroţení její kvality (příkladem můţe být výpadek jednoho z disků RAID pole, kdy sluţba je stále dostupná, při výpadku dalšího z disků však jiţ hrozí její omezení). 6

15 Smyslem Incident Managementu je zajištění rychlého a efektivního řešení výpadku či obnovení dodávky sluţby a minimalizaci důsledků vyplývajících z přerušení její dodávky. Procesy Incident Managementu jsou úzce integrovány s procesy Service Desk, Problem Management a Change Management Request Fulfilment ITIL rozlišuje mezi incidentem a poţadavkem na změnu nebo novou sluţbu či funkcionalitu (Request For Change RFC). V ITIL v. 2 byly oba tyto případy z hlediska jejich dalšího zpracování zahrnuty pojmem incident a řešeny v rámci procesů Incident Managementu. ITIL v. 2 předpokládal, ţe proces řešení výpadků a jiných nestandardních situací se v podstatě shoduje s procesem řešení změnových poţadavků. Přestoţe tomu tak skutečně často je, přichází ITIL v. 3 se samostatným procesem řešícím poţadavky uţivatelů nazvaným Request Fulfilment. Dle [6] je hlavním důvodem pro zavedení sady procesů Request Fulfilment rozdíl mezi příčinou vzniku zmiňovaných událostí zatímco incident je událost neplánovaná a víceméně náhodná, poţadavky uţivatelů mohou a měly by být plánovány. V organizacích, kde lze očekávat větší mnoţství servisních poţadavků, je vhodné řešit, spravovat a evidovat incidenty odděleně od těchto poţadavků. Cílem Request Fulfilment je poskytnout uţivatelům rychlý a efektivní přístup ke standardizovaným sluţbám servisní podpory. Procesy Request Fulfilment omezují byrokratickou zátěţ spojenou s udělováním přístupů ke stávajícím či novým sluţbám, čímţ sniţují nejen náklady na jejich poskytování, ale i náklady na poskytování servisní podpory. Centralizace řešení navíc přináší větší kontrolu nad provozem sluţeb a nad postupy řešení, které mohou být u opakujících se poţadavků standardizovány v rámci předem připravených modelů. Request Fulfilment pokrývá poţadavky, které nejsou předmětem formálního změnového řízení (Change Management), přičemţ se nutně nemusí jednat pouze o poţadavky z oblasti IT stejně dobře lze postupy aplikovat na jiné typy poţadavků (např. poţadavky na odbor Facility Management). Request Fulfilment je úzce spjat s funkcí Service Desk, ITIL v. 3 v rámci Request Fulfilment explicitně doporučuje vyuţití specializovaného software, jehoţ úkolem bude automatizace procesů spojených se zadáváním a řešením poţadavků. 7

16 2.1.5 Problem Management Problém je v ITIL definován jako příčina incidentu. Posláním Problem Managementu je správa ţivotního cyklu problémů, primárním cílem pak identifikace příčin vedoucích k incidentům a návrh opatření směřujících k eliminaci rizik výskytu těchto incidentů v budoucnu. O problému lze hovořit tehdy, vyskytuje-li se určitý incident opakovaně. U opakovaných incidentů se do popředí zájmu dostávají data získaná z procesů Incident Management a Service Desk. Analýza těchto dat pak pomáhá definovat příčiny problémů a předcházet jejich výskytu. Problem Management je těsně spjat s procesy z oblasti Incident Management, Change Management a Knowledge Management, jehoţ součástí je vedení znalostní báze známých problémů (Known Error DB) obsahující postupy jejich řešení. Hlavním přínosem databáze chyb je redukce nákladů spojených s opakovanou diagnostikou a řešením problémů, které se vyskytly jiţ v minulosti. Data mohou být sdílena nejen pracovníky IT oddělení, ale mohou být přímo zprostředkována i uţivatelům jednotlivých systémů tak, aby některé z problémů mohly být odstraňovány přímo samotnými uţivateli Change Management Cílem Change Managementu je dle [11] zajištění hladkého průběhu implementace schválených změn a minimalizace počtu incidentů souvisejících se zavedením změn do infrastruktury. Dodejme, ţe v pojetí ITIL je obsahem Change Managementu celý proces řízení a dokumentace změn, jejich prioritizace, plánování, testování a identifikace rizik plynoucích z implementace 4. Posláním Change Managementu je zajistit soulad aplikace změn s firemní strategií, minimalizovat moţná rizika, výpadky sluţeb a předělávky řešení. Změny sluţeb a infrastruktury, nejsou-li v souladu s firemní strategií či není-li jejich implementace dobře řízena, mohou mít na chod společnosti značně negativní dopad. Řízení změn se tak stává nejen jedním z klíčových procesů v oblasti IT, ale zároveň i potenciálně slabým místem, jelikoţ změny samy o sobě bývají často zdrojem incidentů a omezení. 4 Jak uvádí [8], s. 43: The objective of Change Management is to ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. 8

17 2.1.7 Release Management Popis procesů zajišťujících bezproblémové nasazení schválených změn v produkčním prostředí, s úzkou vazbou na Change Management. Sleduje nasazení (implementaci) změn ICT infrastruktury z hlediska technického i organizačního. Dle [11] se jedná o nezbytný komplement Change Managementu, dle autora, ve vztahu ke správě uţivatelských poţadavků v malé a střední organizaci, spíše postradatelné rozšíření Configuration Management Pro vyhodnocování okolností vzniku jednotlivých problémů jsou nezbytné informace o konfiguraci a nastavení prostředí, ve kterých k problémům dochází. Configuration Management se zabývá popisem procesů sběru, archivace a prezentace modelu ICT infrastruktury a sluţeb. Procesy Configuration Managementu mají význam nejen při řešení problémů, ale i pro dlouhodobé plánování. Jsou velmi úzce svázány s procesy Change Managementu, který vyuţívá konfigurační informace k nalézání a trasování závislostí změnových poţadavků a dopadů změn plynoucích z jejich implementace. Hlavním cílem procesů Configuration Management je vytvoření logického modelu infrastruktury pomocí centrální databáze, obsahující konfigurační data infrastruktury a vazby a závislosti mezi jednotlivými komponentami. Jelikoţ IT infrastruktura podléhá konstantnímu vývoji a rychlým změnám, bývá hlavním úskalím Configuration Managementu zajištění aktuálnosti údajů v konfigurační databázi Knowledge Management Úkolem Knowledge Managementu je zajištění informací a relevantních údajů pro podporu rozhodování. Knowledge Management, jak název napovídá, transformuje informace a data získané v průběhu celého ţivotního cyklu sluţby do znalostí, které jsou zaznamenávány a uchovávány pro pozdější pouţití. Proces zajišťuje sdílení a transfer znalostí mezi jednotlivými úseky společnosti, stejně jako syntézu nových poznatků ze znalostí stávajících. Efektivní Knowledge Management staví na specializovaných nástrojích a dodrţování striktních postupů při dokumentaci událostí, zajišťujících relevantnost a integritu dat v jednotlivých znalostních bázích. 9

18 2.2 Systémy pro správu a řízení poţadavků Z popisu procesů a funkcí definovaných v ITIL pod hlavičkou Service Operation majících stěţejní vliv na správu poţadavků v organizaci, zejména procesů Incident Management, Request Fulfilment a Service Desk, lze vysledovat klíčové operace prováděné pracovníky servisní podpory. Těmito operacemi jsou především: příjem poţadavků od uţivatelů a hlášení o incidentech zaznamenávání a evidence incidentů a poţadavků klasifikace incidentů a poţadavků prioritizace incidentů a poţadavků eskalace poţadavků nalézání a aplikace řešení komunikace a interakce s ostatními procesy ITIL tvorba a udrţování databází znalostní, konfigurační a databáze známých chyb reporting Systém pro správu poţadavků (SSP) by měl kromě pokrytí většiny výše uvedených činností splňovat i řadu dalších kritérií, která budou detailněji rozebrána v následující části. SSP by měl umoţňovat definování rolí a eskalačních úrovní vystupujících v ţivotním cyklu poţadavku v závislosti na konkrétní organizační struktuře útvaru, který poţadavek řeší. Pro některé případy jsou naprosto dostačující role zadavatele a řešitele, pro jiné bude ţádoucí definovat sloţitější organizační strukturu (např. vedoucí týmu, řešitel, tester, release manager apod.). Stejně tak stavy, kterých můţe poţadavek během ţivotního cyklu nabývat, by měly být v ideálním případě uţivatelsky definovatelné. Někdy lze vystačit se třemi stavy poţadavku (vloţený/nahlášený, řešený, hotový), jindy bude situace vyţadovat stavů více. Systém by měl dále umoţnit a evidovat průběţnou komunikaci zúčastněných stran vztahující se k řešení poţadavků, s cílem omezit či zcela vyloučit komunikaci jinými prostředky (např. em nebo telefonem). Evidence proběhlé komunikace je důle- 10

19 ţitá nejen pro přehlednost, ale i pro dokladování průběhu řešení poţadavku, případně plnění servisních smluv (Service Level Agreement SLA). Důleţitým faktorem je i bezpečnost, uţivatelská přehlednost a ovladatelnost systému. Systém by neměl uţivatelům poskytovat data, která se jich netýkají, měl by umoţňovat efektivní vyhledávání a filtrování dat, včetně moţnosti uloţení vlastních dotazů a filtrů pro snadnější opakované zobrazení potřebných údajů. Veškeré operace provedené uţivateli v systému by měly být v ideálním případě vysledovatelné a zaznamenané, systém by měl evidovat modifikace jednotlivých údajů. SSP nesmí umoţnit uţivatelům provádět operace, k nimţ nemají oprávnění, ať uţ se jedná o prohlíţení dat či jejich úpravy. Systémů SSP existuje na trhu celá řada, v zásadě se od sebe liší jak přístupem k frameworku ITIL, tak i komplexností řešené problematiky. Většinou platí, ţe čím je daný systém komplexnější, tím více jsou jeho základy v ITIL ukotveny. Na druhé straně však není neobvyklé ani setkání se systémy, jeţ doporučení obsaţená v ITIL zcela ignorují. Uvedené často platí pro různá in-house řešení SSP v malých a středních firmách. V této práci se však budeme drţet předpokladu autora, ţe zcela ignorovat principy obsaţené v ITIL není ţádoucí. Striktní dodrţování procesů ITIL ve všech detailech a z toho vyplývající vysoká komplexnost SSP však můţe být nezřídka hlavní překáţkou úspěšného nasazení těchto systémů. Malé a střední podniky naráţejí na nedostatek zdrojů potřebných k efektivnímu zajištění těchto procesů, zejména pak jejich administrativních částí. Mezi problémové oblasti patří často procesy Configuration Management a Knowledge Management (zejména vytváření a údrţba konfiguračních a znalostních databází) a procesy řízení změn (ve vztahu k dokumentaci změn ve znalostních databázích). Zajištění těchto činností je mnohdy značně administrativně náročné a klade poměrně velké poţadavky na personální obsazení rolí i technické zabezpečení provozu podpůrných systémů. Implementace ITIL v podnikovém prostředí tak můţe na jedné straně zdroje šetřit a na druhé vyţadovat. Komplexní komerční systémy (např. Microsoft System Center, NetResults Tracker, BMC Remedy či HP OpenView) se tak mohou pro nasazení v podmínkách malých a středních firem jevit jako nepříliš vyhovující, a to nejen z pohledu ekonomického (v důsledku vysokých pořizovacích a provozních nákladů), ale i technickými a personálními poţadavky na zajištění provozu. 11

20 Systémy menších výrobců (např. TaskPool společnosti Bellman), které ve svých propagačních materiálech velmi často slibují excelentní poměr cena/výkon, nezřídka, z pohledu autora, slibovaného poměru nedosahují a to nejen v případě ceny, ale i z hlediska nabízené funkcionality. Nasazení nekomerčních (open-source/gpl) systémů (velmi zdařilým zástupcem této kategorie je například Request Tracker společnosti Best Practical Solutions LLC) naráţí na podobné obtíţnosti. Pořizovací cena open-source systémů sice bývá podstatně niţší neţ cena komerčních produktů (obvykle reflektuje náklady na implementaci systému v daném prostředí), provozní nároky jsou však velmi podobné systémům komerčním. Implementace, správa a dovývoj či přizpůsobení funkcionality často vyţadují znalost a pouţití specifických technologií, obvykle úzce spjatých s platformou linux/unix zákazník se tak často ocitá natrvalo v područí implementačního partnera těţícího z exkluzivního know-how, případně je nucen vynaloţit značné prostředky na proškolení vlastních administrátorů, případně vývojářů. Nasazení open-source systémů se také, z důvodu neznalosti platformy, často setkává se značnou rezistencí ze strany IT personálu a to nejen ze strany systémových administrátorů, ale i manaţerů. Jednou z variant, jak řešit problém správy poţadavků, můţe být vývoj vlastního SSP systému. 12

21 3 Analýza poţadavků a návrh systému V předcházející části jsme nastínili, ţe implementace systémů pokrývajících doporučení frameworku ITIL v celé šíři můţe, zejména v menších firmách, naráţet na nemalé obtíţe. I pro tyto společnosti je však správa poţadavků jedním z důleţitých témat. Řešením situace tak můţe být vývoj vlastního systému, který nebude implementovat všechny funkce komerčních produktů, ale bude pokrývat pouze ta doporučení, která lze v menší společnosti úspěšně aplikovat. Výsledný systém musí být maximálně jednoduchý na pouţívání, nesmí však zároveň rezignovat na klíčová doporučení ITIL uvedená v předchozí části. Vývoj SSP systému, určeného pro nasazení v malých a středních firmách, je i cílem této práce. Vyvíjený systém pracovně nazveme Requestor. Bude-li kdekoli v textu práce odkazováno na Requestor, bude tím míněn systém vyvíjený v rámci této práce. Funkčnost vyvíjeného systému otestujeme v produkčních prostředích společností FTV Prima, spol. s r.o. a Hey Média, s.r.o., kde bude systém nasazen, a zkušenosti z provozu budou zohledněny v jeho dalších úpravách. 3.1 Analýza poţadavků Nejprve se pokusíme definovat sadu základních poţadavků, jejichţ naplnění povede k vývoji dostatečně uţivatelsky přívětivého, přiměřeně flexibilního a průkazného SSP systému, jehoţ nasazení v prostředí malé a střední firmy s sebou nepřinese závaţnější překáţky v podobě zvýšených administrativních, technologických, ekonomických či personálních nároků Vymezení základních poţadavků Základní poţadavky na vyvíjený systém vycházejí z popisu klíčových operací prováděných servisními pracovníky a z doporučení uvedených v předchozí části. Poţadavky budeme definovat s ohledem na cílovou oblast nasazení systému, přičemţ předpokládáme, ţe systém bude navrţen pro interní pouţití tedy pro řešení interních poţadavků, nikoli pro pouţití systému ve společnosti, jejímţ předmětem činnosti je např. outsourcing sluţeb a z toho vyplývající specifické nároky na provozovaný service desk systém. 13

22 Do poţadavků proto záměrně nepromítneme všechna doporučení ITIL popsaná v části 2.1. Implementace ITIL v plné šíři by vedla ke značnému nárůstu sloţitosti systému a zvýšení administrativních nároků při jeho nasazení. Procesy Release Management, Configuration Management a Knowledge Management nebudeme v systému implementovat vůbec, procesy Problem Management a Change Management pouze v nezbytně nutné míře. Důvody pro takové rozhodnutí byly jiţ zmíněny k hlavním patří, ţe zajištění činností spojených se zavedením zmíněných procesů obvykle zvyšuje nároky na administrativu, personální obsazení a technologické zázemí. Stěţejními pro nás budou procesy a doporučení oblastí Service Desk, Event Management, Incident Management a Request Fulfilment. Některé z níţe uvedených poţadavků mohou přesto v prostředích menších firem na první pohled působit nadbytečně či budit dojem, ţe právě jejich naplnění povede ke zbytečné sloţitosti navrhovaného systému, jíţ se chceme vyvarovat. Implementace těchto poţadavků, v textu vyznačených kurzívou, je však obvykle v nějaké formě vyţadována auditory IT procesů. Autor je přesvědčen, ţe i ve firmách, kde audit informačních technologií neprobíhá, je implementace těchto vlastností na místě uţ jen pro zajištění průhlednosti jednotlivých operací. Detailní specifikace všech poţadavků překračuje rámec této práce, proto se zde omezíme pouze na výčet základních okruhů k řešení. K základním poţadavkům na systém patří: 1) Podpora řešení poţadavků v celém ţivotním cyklu, od jejich vzniku do vyřešení 2) Podpora klíčových operací uvedených v předchozí části umoţnit vkládání, evidenci, klasifikaci, prioritizaci a eskalaci poţadavků 3) Evidence základních SLA atributů (poţadované/skutečné termíny, definovatelné priority apod.) 4) Archivace provedených datových změn, sledování stavu poţadavku v čase 5) Integrace s podnikovým prostředím (v podmínkách menších firem především integrace s prostředím Windows a Active Directory) 6) Rozlišení rolí a oprávnění zadavatelů, klientů, interních správců (řešitelů) a externích správců 14

23 7) Omezení přístupu v závislosti na uţivatelských rolích 8) Podpora vytváření vzájemně nezávislých oddílů (sekcí) s nezávisle definovanými rolemi, prioritami a klasifikátory 9) Podpora vzájemné komunikace uţivatelů, moţnost vkládání zpráv a souborů 10) Vyhledávání v poţadavcích 11) Podpora předávání dat em 12) Podpora komunikace s externími systémy 13) Moţnost vyţadovat akceptaci (potvrzení) vyřešení poţadavku uţivatelem 14) Přístupnost (provozuschopnost) uţivatelského rozhraní z obvyklých operačních systémů (Windows, Linux, MacOS) pomocí obvyklých webových prohlíţečů (Internet Explorer, Firefox, Safari) Rozbor poţadavků Systém musí nabídnout jednoduché a přehledné rozhraní pro vloţení, prohlíţení a úpravy poţadavků. Rozhraní systému by mělo vycházet z faktu, ţe bude pouţíváno nejen školenými administrátory, ale i běţnými uţivateli s rozdílnou úrovní počítačové gramotnosti Oddíly Spravované poţadavky budou v systému rozděleny do samostatných oddílů (sekcí). Sekce zajistí třídění poţadavků do skupin, například podle jednotlivých oddělení, která je zpracovávají (poţadavky na oddělení IT, na oddělení správy nemovitostí atd.). Sekce by měly být navzájem nezávislé, aby bylo moţno v kaţdé z nich definovat nejen rozdílná oprávnění jednotlivých uţivatelů, ale i rozdílné typy poţadavků, jejich atributy či priority a z nich vyplývající termíny řešení. Systém tak bude moţno bez dalších úprav pouţívat napříč celou organizací pro různé druhy řešených poţadavků Atributy poţadavku Systém musí u poţadavků evidovat všechny potřebné atributy, nikoli však atributy nadbytečné. Základními budou kromě vlastního obsahu poţadavku a osob zainteresovaných na jeho řešení také poţadované a předpokládané termíny dokončení, stav ře- 15

24 šení (rozpracování), záznamy a zápisy o řešení, připojené soubory, klasifikace (typy) poţadavků, priority řešení, ale i uţivatelsky definované příznaky, které usnadní individuální třídění poţadavků. Kaţdému poţadavku bude v systému přidělen jedinečný identifikátor. Prioritu řešení budeme chápat jako klasifikátor určující závaţnost poţadavku spolu s časem vymezujícím povinný začátek (či konec) jeho řešení. Dle ITIL je při prioritizaci třeba brát v úvahu dvě hlediska prvním je naléhavost, tedy jak rychle je vyţadováno řešení, druhým pak dopad na vlastní chod organizace (business impact). Dopad je často kvantifikován počtem dotčených uţivatelů, větší počet zasaţených uţivatelů však nemusí vţdy znamenat větší dopad někdy můţe omezení konkrétní sluţby pro jediného uţivatele představovat zásadní ohroţení chodu společnosti. Způsob stanovení celkové priority dle ITIL je znázorněn v T1. Dopad na chod firmy Vysoký Střední Nízký Vysoká Naléhavost Střední Nízká Kód priority Popis Cílový čas řešení v hodinách 1 Kritická 1 2 Vysoká 8 3 Střední 24 4 Nízká 48 5 Plán Dle plánu T1: STANOVENÍ PRIORIT DLE ITIL Rozdělení poţadavků či chyb do několika kategorií (např. A-C) s odlišnou dobou povedení zásahu bývá součástí většiny smluv SLA a i v Requestoru se budeme drţet tohoto modelu. Mnoţství kategorií (priorit), jejich názvy a časová omezení budou plně uţivatelsky definovatelné. Přidrţíme se i dalšího z doporučení ITIL, které předpokládá, ţe se priorita můţe vlivem různých okolností během ţivotního cyklu poţadavku měnit. Výchozí prioritu proto určí uţivatel při zaloţení poţadavku a v dalších částech ţivotního cyklu bude jiţ nastavení priority podléhat revizi správce, který bude mít moţnost její modifikace dle aktuální situace, případně na základě podmínek dohodnutých v SLA. Typem poţadavku budeme rozumět vymezení oblasti, do níţ konkrétní poţadavek spadá. Můţe se jednat například o oblast tiskárny, počítače či CRM systém. Typy poţadavků umoţní jemnější granularitu členění záznamů v rámci jedné sekce. Typy poţadavků budou samozřejmě také uţivatelsky definovatelné. 16

25 Uţivatelské příznaky umoţní kaţdému z uţivatelů připojit k poţadavkům individuální privátní (nesdílenou) informaci. Uţivatel bude mít moţnost nadefinovat si vlastní sadu příznaků (např. k objednání, revidovat později apod.), které bude moţno přiřadit jednotlivým poţadavkům obdobně, jako lze např. v aplikaci Microsoft Outlook označit y barevnými kategoriemi. Příznaky uţivateli usnadní orientaci a vyhledávání v poţadavcích, mohou slouţit jako individuální klíč pro třídění Změny, zápisy Zápisy a komentáře vkládané do systému budou mít vazbu na oprávnění uţivatele tak, aby bylo moţno vkládat záznamy viditelné pouze určitým skupinám uţivatelů např. pouze členům řešitelského týmu, správcům apod. Při kaţdé změně poţadavku systém automaticky uloţí datum jejího provedení, identifikaci pachatele a předcházející data poţadavku tak, aby bylo moţno kdykoli v budoucnu dohledat, v jakém stavu se poţadavek nacházel v libovolném čase svého řešení Role Eskalací poţadavků rozumíme předávání řešení a notifikace na různé úrovně servisní podpory. ITIL v organizaci předpokládá existenci více skupin servisní podpory zajišťujících řešení na různých stupních odbornosti Service Level 1 zajišťuje běţnou uţivatelskou podporu, Service Level 2 vyřizuje poţadavky, které jdou nad rámec znalostí skupiny úrovně 1. Service Level 3 je obvykle tvořen externími specialisty, kteří vyřizují poţadavky eskalované z úrovně 2. V malých a středních firmách často jeden ze stupňů chybí a úrovně 1 a 2 splývají v jednu. Lze se setkat i s případy, kdy chybí obě úrovně (Level 1 i 2) a poţadavky jsou předávány přímo externím konzultantům. Pro nasazení v menších a středních firmách budeme proto uvaţovat pouze dvě úrovně servisní podpory, které promítneme do uţivatelských rolí v systému vytvoříme roli interního správce poţadavku pro úrovně 1 a 2 a externího správce (dodavatele) pro úroveň 3. Systém bude rozlišovat čtyři uţivatelské role uţivatele, správce, externího správce a supersprávce. Kaţdá z rolí bude mít v systému odlišné pravomoci, jejichţ přehled přináší T2. Jak jiţ bylo uvedeno, role správce a externího správce reprezentují dvě úrovně uţivatelské podpory, supersprávce můţe měnit globální systémová nastavení a role uţivatele je zřejmá vkládá poţadavky do systému a očekává jejich vyřešení. 17

26 uţivatel externí správce správce SU prohlíţet poţadavky pouze vlastní pouze vlastní a přidělené neomezeně v sekci N/A upravit text poţadavku pouze vlastní pouze vlastní neomezeně v sekci N/A připojit zápis nebo soubor pouze k vlastním k vlastním a přiděleným neomezeně v sekci N/A zrušit poţadavek pouze vlastní pouze vlastní neomezeně v sekci N/A odmítnout poţadavek N/A N/A Neomezeně N/A akceptovat řešení vlastních vlastních poţadavků i za uţivatele N/A vloţit/smazat sekci poţadavků ne ne Ne ano upravit nastavení sekce ne ne základní parametry neomezeně nastavit interní správce sekce ne ne Ne ano nastavit externí správce sekce ne ne Ano N/A T2: ROLE V SYSTÉMU Spolupráce s externími systémy Requestor musí umoţnit předávání dat do externích systémů stejně jako příjem z nich, minimálním poţadavkem na tuto funkcionalitu je schopnost předávat a přijímat data pomocí u. V ideálním případě by měl systém obsahovat podporu pro vytváření dalších typů předávání dat. Snad v kaţdé organizaci existují sluţby, jeţ jsou alespoň částečně zajišťovány externími dodavateli či konzultanty schopnost předávání dat mezi systémy je tak nutnou podmínkou efektivní komunikace interních správců s dodavateli řešení Vyhledávání Systém musí umoţnit vyhledávání v poţadavcích podle různých kritérií, včetně uţivatelsky definovaných atributů. Vyhledávací parametry bude moţné ukládat pro opakované pouţití Integrace s Active Directory Přihlášení do systému by mělo být v ideálním případě automatické, bez nutnosti zadávat přístupové údaje (Single Sign-On). Pouze v případě, ţe nebude moţné ověřit uţivatele automaticky, vyzve aplikace uţivatele k přihlášení. Ověření bude primárně probíhat proti Active Directory (AD), nebude-li uţivatelský účet nalezen v AD, proběhne ověření proti interní uţivatelské databázi Requestoru. Tím bude umoţněn přístup i uţivatelům, kteří nemají zaloţeny účty v AD (např. externí správci) Případy uţití Základní případy uţití systému zachycuje O1. 18

27 O1: PŘÍPADY UŢITÍ 3.2 Volba technologie a implementačního prostředí Účelný systém pro správu poţadavků musí být uţivatelům snadno přístupný z různých míst, zařízení a platforem. Proto musí být schopen bezproblémového nasazení v heterogenních prostředích, z čehoţ plyne, ţe minimálně klientská část by měla být zcela platformě nezávislá. Sebepropracovanější systém totiţ, dle názoru autora, postrádá účelnost, je-li přístup k němu omezen. Requestor proto budeme vyvíjet jako webovou aplikaci základní architektura systému tedy bude typu klient-server. Webové aplikace mají proti klasickým tlustým klientům řadu nesporných výhod, především v oblastech instalace, správy, mobility pouţití, nezávislosti na platformě či distribuce nových verzí. Tato univerzalita je však vykoupena větší náročností a obtíţemi při vývoji, markantními zejména v případě tvorby uţivatelského rozhraní, jehoţ moţnosti jsou limitovány schopnostmi webových prohlíţečů. Přestoţe jsou dnes tyto 19

28 schopnosti značné, v oblastech ergonomie a ovládání stále dominují klasické tlusté klienty. Protoţe jsme dříve definovali poţadavek na integraci s Active Directory, budeme vyvíjet na platformě Microsoft Windows. Integraci s Active Directory lze sice zajistit i na jiných platformách, vývoj v nativním prostředí nám však zjednoduší práci. K vývoji webových aplikací lze dnes na platformě MS Windows a Internet Information Services vyuţít širokou škálu technologií, od poněkud historických ASP, přes technologie PHP, Java, aţ k ASP.NET, které vývojářům nabízí prozatím největší moţnosti integrace s prostředím a sluţbami Windows. Pro vývoj Requestoru zvolíme ASP.NET ve verzi 3.5, coţ je v podstatě ASP.NET 2.0 obohacené o AJAX knihovny a specifická vylepšení v oblasti návrhu uţivatelského rozhraní, datovou vrstvu zprostředkuje databáze MS SQL Server. Vývojovým prostředím bude Microsoft Visual Studio Tato práce se nezabývá detailním popisem ţivotního cyklu vývoje systému, ani pouţitím nějaké konkrétní vývojové metodiky. Stejně tak je nad rámec práce i detailní rozbor analýzy poţadavků a návrhu systému. Práce je zaměřena na konkrétní aplikaci technologií ASP.NET a MS SQL Server vedoucí k řešení tohoto typu úlohy řada dílčích procesů návrhu a vývoje proto nebude v textu dokumentována. 3.3 Analýza a návrh systému Jak bylo uvedeno výše, cílem práce není detailní popis postupů pouţitých při návrhu systému. Nebudeme se zde tedy zabývat detailním rozborem procesů návrhu, modelováním případů uţití, návrhových tříd či stavových grafů. Zmíníme pouze důleţité principy a modely, na nichţ bude vývoj Requestoru postaven, případně ty, které nejsou na první pohled zřejmé nebo jednoznačné Volba architektury, vrstvy a moduly Vrstvy Je zřejmé, ţe při vývoji systému pro správu poţadavků budeme potřebovat nějaké úloţiště dat databázi. Spolupráci business logiky s datovým úloţištěm lze zajistit různými způsoby. Můţeme vyvinout vlastní sadu tříd zajišťujících manipulaci s daty v datovém úloţišti (Data Access Layer), nebo vyuţít vestavěných moţností frameworku ASP.NET. 20

29 ASP.NET nabízí velmi propracovanou technologii vázání dat (data binding) tedy spojení poskytovatele dat (typicky databáze či XML souboru) s jejich konzumentem (ovládacím prvkem), tak, ţe konzument je schopen automaticky generovat svůj obsah na základě přiřazeného datového zdroje a sady určitých pravidel. Při pouţití data binding není programátor nucen vytvářet téměř ţádný kód, který by zajišťoval načtení dat a naplnění ovládacích prvků tuto funkcionalitu obstará ASP.NET na základě zvolených parametrů, které lze často nastavit přímo pomocí grafického rozhraní (odtud spojení deklarativní vázání dat declarative data binding). Microsoft Visual Studio 2008 dokonce umoţňuje vytvořit stránky, jeţ se dotazují do databáze a zobrazují i aktualizují data, pouze pomocí grafického vývojového prostředí aniţ by bylo nutno napsat byť jediný řádek kódu. Tento přístup, přestoţe působí na první pohled velmi přitaţlivě, při tvorbě Requestoru pouţívat nebudeme. Dle názoru autora je řešení zaloţené výhradně na declarative data binding vhodnější spíše pro projekty menšího rozsahu. Přestoţe se jedná o velmi silný nástroj, stále pomocí Visual Studia 2008 a ASP.NET 3.5 nelze (nebo není vhodné) řešit všechny běţné situace pouze deklarativně. 5 Komunikaci aplikační logiky s datovým úloţištěm proto zajistíme pomocí vlastní sady tříd, která bude v systému tvořit samostatnou mezivrstvu. Zde je vhodné poznamenat, ţe zmiňovaný declarative data binding se můţe stát vysoce efektivním nástrojem právě ve spojení s vrstvou DAL. ASP.NET od verze 2.0 obsahuje prvek ObjectDataSource, který umoţňuje vytvořit deklarativní spojení mezi jednotlivými ovládacími prvky webové stránky (např. prvky ListBox, TextBox) a uţivatelskou komponentou pro přístup k datům. Změny ovládacích prvků stránky jsou pak automaticky přenášeny prostřednictvím deklarativně vytvořeného spoje do datové komponenty (objektu vrstvy DAL) ObjectDataSource při kaţdé změně vytvoří nový objekt datové vrstvy a předá příslušné metodě obsah ovládacích prvků. Pro detailní popis ObjectDataSource není v této práci dostatek prostoru (lze nalézt v [3]), patří však ke třídám, které si pozornost webového vývojáře rozhodně zaslouţí. Requestor navrhneme jako klient-server aplikaci, jejíţ jednotlivé vrstvy budou členěny dle schématu na O2. 5 Více o Data Binding viz. MSDN: 21

30 O2: VRSTVY Datová vrstva (Data Layer) představuje datové úloţiště, bude reprezentována databázovým serverem. Aplikační vrstva bude tvořena mezivrstvou pro přístup k datům (Data Access Layer DAL), vrstvou business logiky (BL), z níţ bude do samostatného modulu vyčleněn subsystém pro předávání poţadavků do externích systémů, a validační částí, která bude realizována jak pomocí klientského skriptu v prohlíţeči, tak i metodami tříd BL. Samostatnou sloţkou aplikační vrstvy bude sluţba RequestorScheduler, jejímţ úkolem bude zajistit automatické provádění některých opakujících se činností (aktualizace dat z Active Directory, synchronizace s ovými schránkami pomocí protokolu POP3, apod.). Prezentační vrstvu (Presentation Layer PL) představuje uţivatelské rozhraní (GUI), které je XHTML výstupem ASP.NET formulářů zobrazovaným webovými prohlíţeči. Mezivstva DAL má za úkol odstínit vrstvu BL od vlastní práce s datovým úloţištěm. Potřebuje-li nějaký z objektů BL vrstvy načíst či zapsat data do úloţiště, zavolá k tomu určený objekt vrstvy DAL a data mu předá nebo je od něj získá. Kupříkladu příkaz Person person = new PersonManager().CurrentUser 22

31 načte do proměnné person údaje o aktuálně přihlášeném uţivateli. Objekt, který v business vrstvě příkaz vyvolal, však neví, odkud data o uţivateli ve skutečnosti pocházejí (a ani ho to nemusí příliš zajímat). Změní-li se datové úloţiště osob z SQL databáze na databázi Oracle, XML soubor či ActiveDirectory, bude nutno upravit příslušnou třídu vrstvy DAL tak, aby dokázala pracovat s novým úloţištěm. Třídy vrstvy BL, které pracují s osobami, však změnu nezaznamenají, jelikoţ jimi pouţívaná funkcionalita třídy PersonManager se nezměnila vlastnost CurrentUser třídy PersonManager nadále vrací data aktuálního uţivatele, tak jako před změnou úloţiště. Zdánlivou nevýhodou začlenění mezivrstvy DAL je jiţ zmiňovaná počáteční vyšší pracnost oproti některému z postupů declarative data binding. Z předcházejícího příkladu je však patrné, jak pracné by bylo provedení jakýchkoli změn, pokud by byly jednotlivé business objekty vázány přímo na databázi k vloţeným procedurám. Pokud by byly místo vloţených procedur pouţity SQL dotazy (ať uţ vytvářené programově či deklarativně), byla by pracnost změny ještě vyšší. Vzhledem k tomu, ţe funkcionalita většiny aplikací vyţaduje v průběhu jejich ţivotnosti nějaké úpravy, lze začlenění vrstvy DAL doporučit i pro menší aplikace. Pro systémy většího rozsahu je tato architektura samozřejmostí. Uvedené členění vrstev však není zcela jednoznačné. Část aplikační logiky bude například realizována pomocí uloţených procedur na SQL serveru, čímţ v podstatě dojde k nesouladu mezi fyzickým a logickým pojetím datových vrstev (business logika je fyzicky uloţena v datové vrstvě). Tento jev je u vícevrstvých aplikací poměrně častý a má své zastánce i odpůrce. Odpůrci preferují jasné členění a striktní soulad fyzického a logického pojetí business logika je dle tohoto přístupu umístěna výhradně v business vrstvě, datová vrstva v extrémním případě nereflektuje ţádné business objekty a SQL databáze tak obsahuje velmi omezené mnoţství univerzálních tabulek, do nichţ lze uloţit téměř cokoliv, obvykle v nějaké serializované formě. Na opačném konci spektra stojí názor (zastávaný např. Papadimoulisem), ţe členění jednotlivých vrstev kromě fyzického rozměru ještě rozměr logický, a tyto dva se 23

32 mnohdy nepřekrývají. Tento přístup je, dle názoru autora, efektivnější. 6 Vrstva je chápána jako soubor veškeré příslušné logiky bez ohledu na to, kde je fyzicky tato logika umístěna. Část aplikační logiky tak můţeme najít v tabulkách či uloţených procedurách na SQL serveru, část například v prezentační vrstvě uţ jen názvy sloupců a členění tabulek mají blízko k business logice a například validace jednotlivých polí HTML formulářů pomocí klientského JavaScriptu není nic jiného, neţ opět aplikační logika uloţená ovšem v prezentační vrstvě. Rozdíly v přístupech a polemikou o správném návrhu vícevrstvých aplikací se dopodrobna zabývat nebudeme. Spokojíme se s konstatováním, ţe při návrhu Requestoru zvolíme druhý přístup Moduly a knihovny Třídy Requestoru lze rozdělit do několika skupin podle příslušnosti k některé z vrstev či funkce, jakou budou v systému vykonávat na základě tohoto rozdělení sdruţíme třídy do několika knihoven. Základní rozdělení kopíruje jednotlivé operační vrstvy. Jak bylo uvedeno, skupina tříd vrstvy DAL zajišťuje přístup k datům uloţeným v SQL databázi. Pomocí Data Access Objects (DAO) budou data načítaná z tabulek SQL databáze převáděna na jednotlivé objekty (Business Objects BO) vrstvy BL. Ukládaná data budou naopak z BO převáděna do parametrů pro vloţené procedury, které manipulují s daty v databázi SQL serveru. Další skupinou jsou třídy a typy BL. Mezi těmito třídami nalezneme čistě typové třídy (RequestStateChange), čistě funkční třídy (RqMailNotifier) a třídy typu BO (RequestSearchParameters), které v sobě zapouzdřují kromě typových atributů i funkční metody. Mezi BL třídy lze zařadit i ovladače HTTP (.ashx), které jsou sice, stejně jako stránky aspx, přímo volány uţivatelem pomocí webového prohlíţeče, ale neobsahují ţádné uţivatelské rozhraní. Třídy vrstvy BL zajišťují vlastní funkcionalitu systému. Lze je rozdělit do několika skupin podle oblastí, jejichţ činnost ovlivňují nebo zajišťují toto rozdělení vychází ze základních poţadavků uvedených v předchozích částech. Ústředními třídami jsou 6 Papadimoulis, Alex. The Mythical Business Layer. The Daily WTF [online] [cit ]. Dostupný z WWW: By implying that a system s architecture should include a layer dedicated to business logic, many developers employ all sorts of horribly clever techniques to achieve that goal. And it always ends up in a disaster. 24

33 Request (poţadavek), Section (oddíl) a Person (uţivatel). Kaţdá z těchto hlavních tříd je středem skupiny dalších na ní navázaných tříd. Vytvoříme skupinu tříd spojených s poţadavky (Request*), nástěnkou (DashBoard*), konfiguračními nastaveními (*Config), předávači poţadavků do jiných systémů (*HandOver*), uţivateli (Person), či oddíly (Section*). V systému se objeví i třídy s předvolbami (*Preferences*), třídy na pomezí mezi BL a PL vrstvou (LabelEllipsis) i třídy s jedinou funkcí (RqMailNotifier). Poslední skupinu tvoří třídy prezentační vrstvy, které poskytují uţivatelské rozhraní a zobrazují výstupy systému. Do PL vrstvy patří webové (*.aspx) stránky, které jsou (na rozdíl od klasického ASP) také třídy, uţivatelské ovládací prvky (*.ascx) a reporty (*.rpt) Crystal Reports. K prezentační vrstvě lze zařadit i pouţité Control Adapters, které upravují generovaný HTML kód. Při vývoji systému budeme dodrţovat následující rozvrţení: třídy DAL a BL s výjimkou předávačů sdruţíme do samostatného projektu, jehoţ výstupem bude knihovna RequestorObjects.dll. Pro předávače dat vytvoříme samostatný projekt s výstupem knihovny HandOvers.dll. RequestorScheduler bude opět samostatným projektem, vyuţívajícím knihovnu RequestorObjects. Výstupem projektu Requestor- Scheduler bude instalátor sluţby (service) Windows. Třídy prezentační vrstvy, ovladače (stránky *.ashx) a soubory klientských skriptů budou součástí dalšího projektu, jehoţ výstupem bude webová aplikace. Rozvrţení knihoven a databáze ilustruje O3. O3: KNIHOVNY A MODULY 25

34 3.3.2 Významné třídy Některé z výchozích poţadavků na první pohled implikují vznik konkrétních tříd, některé nikoli. V následujícím textu popíšeme, jak se některé ze základních poţadavků promítnou do návrhu klíčových tříd Requestoru. Jelikoţ se v této práci detailně nezabýváme jednotlivými vývojovými fázemi tvorby systému, nebudeme zde postupovat od analytických tříd k návrhovým, ale pouze popíšeme smysl a určení některých důleţitých návrhových tříd, které budeme implementovat později při vývoji Request Poţadavek č. 1 (Podpora řešení poţadavků v celém ţivotním cyklu, od jejich vzniku do vyřešení) přímo vybízí k definici třídy Poţadavek, která by se stala nositelem veškerých informací spojených s poţadavkem. V Requestoru tomu skutečně tak bude, a třída poţadavků Request se stane jednou ze stěţejních tříd. Budeme definovat i řadu dalších podpůrných tříd, jejichţ vzájemné vztahy ilustruje O4. O4: REQUEST A NAVÁZANÉ TŘÍDY 26

35 Budou definovány uţivatelské a systémové příznaky poţadavku (RequestFlag), priority řešení (RequestPriority), stavy řešení poţadavku (RequestState), oblasti (typy) poţadavků (RequestSphere) a další typy a třídy, jejichţ účel byl popsán v části Stavy řešení, kterých můţe poţadavek během svého ţivotního cyklu v Requestoru nabývat, a povolené přechody mezi nimi jsou zachyceny na O5. Po vyřešení poţadavku správcem je vhodné, jak je patrno z obrázku, vyţadovat akceptaci provedeného řešení klientem či zadavatelem poţadavku. Tato pro menší firmy zdánlivě nadbytečná podmínka zajišťuje potřebnou zpětnou vazbu je-li uţivatel spokojen s řešením svého poţadavku, explicitně vyjádří svou spokojenost akceptováním řešení, přičemţ tím zároveň potvrzuje, ţe k vyřešení skutečně došlo a kdy se tak stalo. Naopak pokud spokojen není, je správce poţadavku ihned informován poţadavek je mu vrácen k dopracování (reklamován). stm Sta... Odmítnutý znovu přijato k řešení Reklamov aný Řešený řešení odmítnuto řešení odmítnuto Řešený interně Vložený/Nepřijatý požadavek přijat k řešení [Ext. správci = 0] [Ext. správci > 0] řešení reklamováno požadavek zrušen požadavek zrušen Řešený externě Zrušený požadavek obnoven vráceno správcem Je v sekci vyžadována akceptace? [Ano] K akceptaci [Ne] řešení akceptováno Vyřešený Hotovo O5: STAVY POŢADAVKU RequestEvent Z poţadavku 4 (Archivace provedených datových změn, sledování stavu poţadavku v čase) vyplývá potřeba archivace veškerých změn provedených s poţadavkem v průběhu jeho ţivotního cyklu. Tato funkcionalita je obvykle vyţadována auditory IT procesů, kteří poţadují, aby bylo moţno dohledat, v jakém stavu se konkrétní poţadavek 27

36 nacházel v určitém čase přičemţ stavem není míněn pouze stav řešení, ale i hodnoty (obsah) jednotlivých atributů poţadavku. Součástí návrhu systému tedy bude i návrh archivačního mechanizmu. Návrh tříd archivačního mechanizmu vychází z úvahy, ţe kaţdou změnu poţadavku, ať uţ se jedná o připojení souboru, vloţení zápisu, předání externímu správci či změnu priority nebo jiného údaje, lze vţdy povaţovat za jedinečnou událost v systému. Události lze rozdělit na tři základní typy lišící se v údajích, které je při změně třeba uloţit: 1) změna stavu poţadavku vloţení, přidělení správci, změna údajů 2) připojení či smazání souboru 3) připojení zápisu o řešení/zprávy Celý princip řešení ilustruje O6. Událost (změnu) reprezentuje třída RequestEvent, jejímiţ specializacemi jsou RequestRecord (připojení zápisu), RequestFile (připojení souboru) a RequestStateChange (změna stavu). Při kaţdé změně poţadavku bude v systému vytvořena jednoznačně identifikovatelná událost (RequestEvent), s níţ budou svázána modifikovaná data, ať uţ se bude jednat o úpravu atributů nebo připojených souborů či zpráv. U kaţdé události (změny) bude evidován její pachatel (uţivatel, který změnu provedl) pomocí třídy Person (bude popsána v části ). Tyto události budou v systému zaznamenávány tak, aby jejich obsah bylo moţno kdykoli v budoucnu zobrazit a získat tak přehled o tom, v jakém stavu se poţadavek nacházel v konkrétním čase. class RequestEv... Request událost 1..* RequestEv ent 1 pachatel Person 1 1 RequestRecord RequestFile RequestStateChange O6: REQUESTEVENT 28

37 Section Section reprezentuje oddíl (v SSP často nazývaný pool), jehoţ účelem je sdruţení vkládaných poţadavků do logických celků na základě nějakého společného znaku (například skupiny řešitelů, oddělení apod.), přičemţ kaţdý z poţadavků zadaných do systému musí být členem právě jednoho oddílu. Jak je patrno z diagramu na O7, bude třída Section obsahovat také řadu konfiguračních nastavení, která reflektují poţadavky na funkcionalitu zmíněné výše. class Section Section SectionUserRoles RequestSphere * * AcceptationNeeded: bool + AlternateCSS: string + AutoAccept: bool + AutoAcceptDays: int + AutoNotify: bool + Domains: string[] + HOAdmin: string + HOUser: string + IsPublic: bool + UseHOForAdminNotification: bool + UseHOForUserNotification: bool + UserIsAdmin() : bool + UserIsAllowed() : bool + UserIsExAdmin() : bool + UserIsSuperUser() : bool 1 1 * * RequestFlag RequestExtraFlag RequestyPriority O7: SECTION Atributy AcceptationNeeded, AutoAccept a AutoAcceptDays určují, zda je v rámci oddílu vyţadována akceptace řešení poţadavku uţivatelem a pokud ano, po uplynutí jak dlouhého časového intervalu bude při nečinnosti uţivatele po vyřešení poţadavku tento automaticky systémem označen za akceptovaný (pokud vůbec). Nebude-li v sekci vyţadována akceptace, bude poţadavek označený správcem jako vyřešený automaticky přesunut do stavu hotovo. V opačném případě bude poţadavek po vyřešení předán uţivateli k posouzení, zda ho lze skutečně povaţovat za vyřešený (stav k akceptaci ). Teprve poté, kdy bude řešení uţivatelem akceptováno, přepne se poţadavek do stavu hotovo. Tak bude zajištěna zpětná vazba a faktické odsouhlasení provedeného řešení uţivatelem. AutoNotify slouţí k rozlišení, zda dojde po změně poţadavku k automatickému upozornění dotčených uţivatelů či zda budou informování aţ na základě akce provedené správcem. 29

38 AlternateCSS je určen k vizuálnímu rozlišení jednotlivých sekcí v případě potřeby bude moţno nastavit k oddílu vlastní CSS styl, kterým bude formátován výstup prezentační vrstvy. Tato vlastnost umoţní grafické odlišení oddílů a tím snadnější orientaci uţivatelů. UseHOForAdminNotification, UseHOForUserNotification, HOAdmin a HOUser podporují model zmíněný v v rámci oddílu definují pouţití předávačů pro správce a uţivatele. Třída Section bude odpovědná i za validaci rolí uţivatelů v rámci daného oddílu (viz ). Uvedenou funkcionalitu zajistí metody UserIsAllowed, UserIsAdmin, UserIsExAdmin a UserIsSuperUser. IsPublic označuje, zda je oddíl veřejný (přístupný všem uţivatelům) nebo zda je přístup k němu omezen na uţivatele z vybraných domén (uloţených v poli Domains). Třídy SectionUserRoles, RequestSphere a RequestPriority reflektují poţadavek č. 8 (Podpora vytváření vzájemně nezávislých oddílů s nezávisle definovanými rolemi, prioritami a klasifikátory). RequestSphere a RequestPriority reprezentují typy poţadavků a priority popsané v 3.1.2, které budou definovatelné nezávisle pro kaţdou zaloţenou sekci Person a SectionUserRoles Poţadavky uvedené v bodech 5 (Integrace s prostředím Windows a ActiveDirectory), 6 (Rozlišení rolí a oprávnění zadavatelů, klientů, interních a externích správců) a 7 (Omezení přístupu v závislosti na uţivatelských rolích) vyţadují kromě implementace mechanizmu pro rozlišení rolí uţivatelů v rámci jednotlivých sekcí i vytvoření funkcionality umoţňující kombinovat v systému uţivatele získané z Active Directory s uţivateli z interní databáze Requestoru. Tento zdánlivě jednoduchý poţadavek naráţí na poměrně značná omezení, která má ASP.NET v ověřovacím mechanizmu (podrobně v části 4.1.2) a v API pro členství. API pro členství se v ASP.NET pouţívá pouze pro správu a ověřování uţivatelů, neimplementuje ţádnou funkcionalitu pro autorizaci a správu rolí (pro tu je nutno poţít API pro role). Pro ukládání dodatečných uţivatelských informací, jakými jsou v pojetí ASP.NET (pro mnohé, včetně autora, poněkud překvapivě) i jméno a příjmení uţivatele, je navíc nutno pouţít další API technologie.net Profily. 30

39 Situaci lze sice úspěšně řešit vytvořením vlastního poskytovatele členství a jeho následným navázáním na vlastní profily vynaloţené úsilí však, dle názoru autora, není úměrné výsledku. Pouţití vestavěných poskytovatelů navíc naráţí na jistá bezpečnostní rizika přihlašovací informace jsou totiţ odesílány ve formě čistého textu. Všichni poskytovatelé členství ASP.NET, tedy i ti, kteří jsou určeni pro Active Directory, nativně vyuţívají formulářovou autentifikaci a pro zabezpečení dat při přenosu je tedy nutno pouţívat nějakou z dalších technologií, například SSL. V Requestoru se, vzhledem k výše uvedenému, vydáme vlastní cestou. Budeme ignorovat API pro členství, role i profily a navrhneme sadu vlastních tříd, které potřebnou funkcionalitu zajistí. Princip znázorňuje O8. O8: ČLENSTVÍ A ROLE V REQUESTORU Základní třídou nesoucí informace o uţivatelích (osobách pracujících se systémem nebo v něm vedených) bude třída Person. Pomocí objektů třídy Person budou uchovávány jak informace převzaté z uţivatelských účtů Active Directory, tak i data pořízená přímo v Requestoru. Tímto přístupem zajistíme konzistentní přístup k uţivatelským datům veškeré dotazy na uţivatelská data budou ve všech vrstvách aplikace důsledně směřovány na objekty třídy Person. Objekty pracující s uţivatelskými daty tak nebudou nuceny zjišťovat, zda se mají dotazovat do AD či jinam. 31