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

Rozměr: px
Začít zobrazení ze stránky:

Download "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

Sjednocení dohledových systémů a CMDB

Sjednocení dohledových systémů a CMDB Řízení dodávky IT služeb v enterprise společnosti Sjednocení dohledových systémů a CMDB Václav Souček, ČEZ ICT Services, a.s. Jaroslav Jičínský, AutoCont CZ, a.s. 26. Ledna 2012 Agenda Úvod Výchozí stav

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory Příloha č. 2 ke smlouvě Rozsah a podmínky provozní podpory Předmět smlouvy v části Provozní podpora zahrnuje zejména: A) Technickou, uživatelskou a administrativní správu a provozní podporu APV IS ROS

Více

Technická specifikace předmětu plnění:

Technická specifikace předmětu plnění: Technická specifikace předmětu plnění: Poskytnutí standardní služby Premier Support zahrnující konzultační a implementační podporu, řešení problémů u produktů v nepřetržitém režimu 24x7 v rámci aktuálního

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Přednáška č.2 Jan Valdman, Ph.D. jvaldman@dns.cz 8.3.2011 ITIL Information Technology Infrastructure Library ITIL v současnosti zahrnuje: Samotnou knihovnu Oblast vzdělávání a certifikace odborné

Více

icc Next Generation atlantis Copyright 2011, atlantis

icc Next Generation atlantis Copyright 2011, atlantis icc Next Generation atlantis Copyright 2011, atlantis Zaměření icc zdravotnická zařízení výrobní podniky instituce a samospráva jednotky až stovky agentů malé, střední a velké organizace kontextově zaměřený

Více

Mobilní aplikace ve světě ERP. Asseco Solutions, a.s. a Simac Technik ČR, a.s.

Mobilní aplikace ve světě ERP. Asseco Solutions, a.s. a Simac Technik ČR, a.s. Mobilní aplikace ve světě ERP Michal Hanko Petr Kolda Asseco Solutions, a.s. a Simac Technik ČR, a.s. Skupina Asseco Solutions Asseco Solutions je průkopníkem a vizionářem na poli informačních systémů

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM Č. 3. Zadavatel: Název veřejné zakázky: Česká republika Ministerstvo zemědělství

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM Č. 3. Zadavatel: Název veřejné zakázky: Česká republika Ministerstvo zemědělství Zadavatel: Česká republika Ministerstvo zemědělství Název veřejné zakázky: Vytvoření nového informačního systému MZe pro výzkum a vývoj - "VÝZKUM-AGRI" Sídlem: Těšnov 65/17, 110 00 Praha 1 Nové Město Evidenční

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

1.1. Správa a provozní podpora APV ROS, HW ROS a základního SW

1.1. Správa a provozní podpora APV ROS, HW ROS a základního SW Příloha č. 4 - Specifikace a informace o předmětu veřejné zakázky Předmětem veřejné zakázky je řízení projektu, správa a údržba programového vybavení pro informační systém Základní Registr osob (dále rovněž

Více

MODULÁRNÍ REDAKČNÍ SYSTÉM (CMS), SE ZAMĚŘENÍM PRO FIREMNÍ

MODULÁRNÍ REDAKČNÍ SYSTÉM (CMS), SE ZAMĚŘENÍM PRO FIREMNÍ MODULÁRNÍ REDAKČNÍ SYSTÉM (CMS), SE ZAMĚŘENÍM PRO FIREMNÍ PREZENTACI Petr Minařík 2.2.2010 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE ZADÁNÍ PRÁCE Seznámení se s současnými redakčními systémy vyuţívanými pro

Více

Projekt informačního systému pro Eklektik PRO S EK. Řešitel: Karolína Kučerová

Projekt informačního systému pro Eklektik PRO S EK. Řešitel: Karolína Kučerová Projekt informačního systému pro Eklektik PRO S EK Řešitel: ÚVODNÍ ZPRÁVA ZADÁNÍ PROJEKTU Zefektivnění komunikace ve firmě Eklektik, a to především v oblasti informací o klientech a o tištěných materiálech

Více

Zkouška ITIL Foundation

Zkouška ITIL Foundation Zkouška ITIL Foundation Sample Paper A, version 5.1 Výběr z více možností Pokyny 1. Měli byste se pokusit odpovědět na všech 40 otázek. 2. Všechny svoje odpovědi vyznačte na samostatný formulář, který

Více

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o. Bezpečnostní politika společnosti synlab czech s.r.o. Platnost dokumentu: 14. ledna 2015 Datum vypracování: 8. ledna 2015 Datum schválení: 13. ledna 2015 Vypracoval: Schválil: Bc. Adéla Wosková, Ing. Jaroslav

Více

Allegro účetnictví. Schéma účetního modulu. Podstatné vlastnosti. Allegro Business Solution Účetnictví

Allegro účetnictví. Schéma účetního modulu. Podstatné vlastnosti. Allegro Business Solution Účetnictví Allegro účetnictví Obsahuje zákonem vyžadované agendy podvojného účetnictví a tvoří jádro celého systému. Standardní bloky zahrnují účetní knihu, faktury přijaté a vydané, banky, pokladny a přiznání DPH.

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Technická dokumentace

Technická dokumentace Příloha č.1 výzvy Technická dokumentace k veřejné zakázce malého rozsahu Obsah Technická dokumentace... 1 Předmět zadání k podání cenové nabídky:... 3 Dodávka a služby budou zahrnovat:... 3 Specifikace

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

Wonderware Information Server 4.0 Co je nového

Wonderware Information Server 4.0 Co je nového Wonderware Information Server 4.0 Co je nového Pavel Průša Pantek (CS) s.r.o. Strana 2 Úvod Wonderware Information Server je výrobní analytický a reportní informační portál pro publikaci výrobních dat

Více

MIS. Manažerský informační systém. pro. Ekonomický informační systém EIS JASU CS. Dodavatel: MÚZO Praha s.r.o. Politických vězňů 15 110 00 Praha 1

MIS. Manažerský informační systém. pro. Ekonomický informační systém EIS JASU CS. Dodavatel: MÚZO Praha s.r.o. Politických vězňů 15 110 00 Praha 1 MIS Manažerský informační systém pro Ekonomický informační systém EIS JASU CS Dodavatel: MÚZO Praha s.r.o. Politických vězňů 15 110 00 Praha 1 Poslední aktualizace dne 5.8.2014 MÚZO Praha s.r.o. je certifikováno

Více

Představuje. Technický Informační Systém nové generace

Představuje. Technický Informační Systém nové generace Představuje Technický Informační Systém nové generace Nový náhled na položky Sjednocení typů položek - položky nejsou striktně dělené na vyráběné a nakupované. Do tohoto typu je zahrnuté i nakupované a

Více

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků Microsoft.NET AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků Přehled Země: Velká Británie Odvětví: Informační technologie Profil zákazníka Pantek Ltd.

Více

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009 1.Podniková informatika pojmy a komponenty (1) Objasněte pojmy: IS, ICT, ICT služba, ICT proces, ICT zdroj. Jakou dokumentaci k ICT službám,

Více

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Prezentace CRMplus Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Obsah prezentace Představení společnosti Technodat Develop, s.r.o. CRMplus základní charakteristika

Více

Indexace pro souborová uložiště a Vyhledávací centrum

Indexace pro souborová uložiště a Vyhledávací centrum Indexace pro souborová uložiště a Vyhledávací centrum Obsah I. Úvod... 2 II. Cíl dokumentu... 2 III. Fáze projektu... 2 IV. Popis jednotlivých fází projektu... 2 1. Fáze 1. - Analýza... 2 2. Fáze 2. -

Více

P@wouk nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing.

P@wouk nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing. P@wouk nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing. Tomáš Petránek tomas@petranek.eu Karviná, 21. 10. 2011 Obsah prezentace 1. Okolnosti

Více

RDF DSPS ROZVOJ PORTÁLU

RDF DSPS ROZVOJ PORTÁLU RDF DSPS ROZVOJ PORTÁLU ČEZ Distribuce, a.s. HSI, spol. s r.o. Zbyněk Businský Miroslav Kaňka ZÁKAZNÍK A DODAVATEL ČEZ DISTRIBUCE, A.S. ČEZ distribuční síť Od r. 2012 implementován GEOPORTÁL (1. ETAPA),

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Manažerský informační systém na MPSV Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Konference ISSS-2009 Hradec Králové Aldis 6. dubna 2009 MIS na MPSV časové údaje projektu Vytvoření MIS MPSV

Více

UDS for ELO. Univerzální datové rozhraní. >> UDS - Universal Data Source

UDS for ELO. Univerzální datové rozhraní. >> UDS - Universal Data Source Univerzální datové rozhraní UDS for ELO UDS pro ELO je univerzální datové rozhraní, schopné napojit systém pro archivaci a správu dokumentů ELO na libovolný datový zdroj a to bez nutnosti programování.

Více

Microsoft Day Dačice - Rok informatiky 10.-12.2015

Microsoft Day Dačice - Rok informatiky 10.-12.2015 Microsoft Day Dačice - Rok informatiky 10.-12.2015 Jaromír Látal 1 Portálové řešení v bezpečí Sentinelu Portál úředníka Portál občana Portál pro radu a zastupitelstvo Portál zřizovaných organizací Portál

Více

Výhody a rizika outsourcingu formou cloud computingu

Výhody a rizika outsourcingu formou cloud computingu Výhody a rizika outsourcingu formou cloud computingu Jiří Voříšek katedra informačních technologií Vysoká škola ekonomická v Praze vorisek@vse.cz 1 Výchozí model MMDIS pro identifikaci možností outsourcingu

Více

Požadavky na parametry SLA

Požadavky na parametry SLA Příloha č.3 Požadavky na parametry SLA 1.1 Základní údaje Režim SLA pro provoz bude začínat od akceptace hlavního díla (nový portál) a je určen pro režim provozu portálu. Předmětem SLA budou následující

Více

Co je doma, to se počítá, aneb Jak ušetřit na komunikaci. Petr SOLNAŘ / Liberecká IS, a.s. Michal NOVÁK / SOITRON CZ, s.r.o. 12.6.

Co je doma, to se počítá, aneb Jak ušetřit na komunikaci. Petr SOLNAŘ / Liberecká IS, a.s. Michal NOVÁK / SOITRON CZ, s.r.o. 12.6. Co je doma, to se počítá, aneb Jak ušetřit na komunikaci. Petr SOLNAŘ / Liberecká IS, a.s. Michal NOVÁK / SOITRON CZ, s.r.o. 12.6.2008 VoIP Liberec Proč by se o telefony mělo starat IT? Případová studie

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

Co je to COBIT? metodika

Co je to COBIT? metodika COBIT Houška, Kunc Co je to COBIT? COBIT (Control OBjectives for Information and related Technology) soubor těch nejlepších praktik pro řízení informatiky (IT Governance) metodika určena především pro

Více

ČD Telematika a.s. Efektivní správa infrastruktury. 11. května 2010. Konference FÓRUM e-time, Kongresové centrum Praha. Ing.

ČD Telematika a.s. Efektivní správa infrastruktury. 11. května 2010. Konference FÓRUM e-time, Kongresové centrum Praha. Ing. ČD Telematika a.s. Efektivní správa infrastruktury 11. května 2010 Konference FÓRUM e-time, Kongresové centrum Praha Ing. František Nedvěd Agenda O společnosti ČD Telematika a.s. Efektivní správa konfigurací

Více

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně vyhledávat informace,

Více

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D. Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační

Více

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B5 Program Téma obsahuje informace o programech a programovém řízení a klade si za cíl především vysvětlit

Více

IntraDoc. Řešení pro státní správu a samosprávu. http://www.inflex.cz

IntraDoc. Řešení pro státní správu a samosprávu. http://www.inflex.cz Motivace IntraDoc Řešení pro státní správu a samosprávu http://www.inflex.cz Naším cílem je nabídnout pracovníkům úřadu efektivní a do detailu propracovanou podporu procesů a správu dokumentů spojených

Více

Příloha č. 1 Servisní smlouvy. Katalog služeb. S2_P1_Katalog služeb

Příloha č. 1 Servisní smlouvy. Katalog služeb. S2_P1_Katalog služeb Příloha č. 1 Servisní smlouvy Katalog služeb S2_P1_Katalog služeb 1 Obsah 1 OBSAH... 2 2 DEFINICE SLUŽEB... 3 3 SPECIFIKACE SLUŽEB... 6 3.1 SLUŽBA PS01_PROVOZ A SPRÁVA... 6 3.2 SLUŽBA PS02_ZÁLOHA A OBNOVA...

Více

OZNAČENÍ SLUŽBY ITSM/HELPDESK-PROVOZ TYP KL: PAUŠÁLNÍ. Služba zajištění obsluhy HelpDesku Objednatele

OZNAČENÍ SLUŽBY ITSM/HELPDESK-PROVOZ TYP KL: PAUŠÁLNÍ. Služba zajištění obsluhy HelpDesku Objednatele : HD-002 OZNAČENÍ SLUŽBY ITSM/HELPDESK-PROVOZ TYP KL: PAUŠÁLNÍ Název služby Služba zajištění obsluhy HelpDesku Objednatele VYMEZENÍ SLUŽBY Prostředí Cílová skupina Zkrácený popis služby PRODUKČNÍ Pracovníci

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

Více

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13

1. Úvod do Ajaxu 11. Jak Ajax funguje? 13 Obsah Úvodem 9 1. Úvod do Ajaxu 11 Jak Ajax funguje? 13 Popis 13 Ukázky 13 Jaké jsou možnosti tvorby interaktivních webových aplikací? 15 Co je třeba znát? 16 Jak fungují technologie Ajaxu 16 Jak funguje

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Reportingová platforma v České spořitelně

Reportingová platforma v České spořitelně Reportingová platforma v České spořitelně Agenda Implementované prostředí Cognos 8 v ČS Marek Varga, Česká spořitelna, a.s. Využití platformy Cognos z pohledu businessu Petr Kozák, Česká spořitelna, a.s.

Více

Slovenská spořitelna:

Slovenská spořitelna: Případová studie Slovenská spořitelna: Microsoft Dynamics CRM pro správu klientů ze segmentu malých a středních podniků Jak jsme Slovenské spořitelně usnadnily a zefektivnily práci s klienty ze segmentu

Více

RD.CZ : EVIDENCE DIGITALIZOVANÝCH DOKUMENTŮ A SLEDOVÁNÍ PROCESU ZPRACOVÁNÍ

RD.CZ : EVIDENCE DIGITALIZOVANÝCH DOKUMENTŮ A SLEDOVÁNÍ PROCESU ZPRACOVÁNÍ RD.CZ : EVIDENCE DIGITALIZOVANÝCH DOKUMENTŮ A SLEDOVÁNÍ PROCESU ZPRACOVÁNÍ Pavel Kocourek, Incad Praha Přestože mnohé knihovny v České republice digitalizují své dokumenty a další se na to chystají, neprobíhá

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

Zákon o kybernetické bezpečnosti základní přehled. Luděk Novák ludekn@email.cz, 603 248 295

Zákon o kybernetické bezpečnosti základní přehled. Luděk Novák ludekn@email.cz, 603 248 295 Zákon o kybernetické bezpečnosti základní přehled Luděk Novák ludekn@email.cz, 603 248 295 Obsah Zákon č. 181/2014 Sb., o kybernetické bezpečnosti Vyhláška č. 316/2014 Sb., vyhláška o kybernetické bezpečnosti

Více

Řešení pro správu logů, shodu a bezpečnost ve státní správě a samosprávě. Ing. Martin Pavlica Corpus Solutions a.s. divize Security Expert

Řešení pro správu logů, shodu a bezpečnost ve státní správě a samosprávě. Ing. Martin Pavlica Corpus Solutions a.s. divize Security Expert Řešení pro správu logů, shodu a bezpečnost ve státní správě a samosprávě Ing. Martin Pavlica Corpus Solutions a.s. divize Security Expert Agenda Úvod do problematiky Seznam problémů Definice požadavků,

Více

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt Projektový management Lekce: 8 Projektový management Doc. Ing. Alois Kutscherauer, CSc. Projektový management je typ managementu uplatňovaného k zabezpečení realizace jedinečných, neopakovatelných, časově

Více

Státní pokladna. Centrum sdílených služeb

Státní pokladna. Centrum sdílených služeb Státní pokladna Centrum sdílených služeb Státní pokladna Centrum sdílených služeb Organizační dopady při řešení kybernetické bezpečnosti Ing. Zdeněk Seeman, CISA, CISM Obsah prezentace Podrobnější pohled

Více

Požadavky na připojení regionálních/metropolitních sítí do CMS

Požadavky na připojení regionálních/metropolitních sítí do CMS Požadavky na připojení regionálních/metropolitních sítí do CMS Verze 1.00 BDO IT a.s. Poradenství v informačních technologiích IČ: 25 05 66 46 DIČ: CZ 25 05 66 46 Městský soud v Praze, oddíl B, vložka

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM Č. 2. Název veřejné zakázky: Česká republika Ministerstvo zemědělství

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM Č. 2. Název veřejné zakázky: Česká republika Ministerstvo zemědělství Zadavatel: Česká republika Ministerstvo zemědělství Název veřejné zakázky: Zajištění provozu HelpDesku a Dohledu infrastruktury a informačních systémů MZe Sídlem: Těšnov 65/17, 110 00 Praha 1 Nové Město

Více

Sísyfos Systém evidence činností

Sísyfos Systém evidence činností Sísyfos Systém evidence Sísyfos : Evidence pracovních Systém Sísyfos je firemní aplikace zaměřená na sledování pracovních úkonů jednotlivých zaměstnanců firmy. Umožňuje sledovat pracovní činnosti na různých

Více

přes webový prohlížeč pomocí P@wouka Ing. Tomáš Petránek tomas@petranek.eu

přes webový prohlížeč pomocí P@wouka Ing. Tomáš Petránek tomas@petranek.eu Open Sourceřešení správy studentských počítačových sítí na kolejích SU OPF Karviná aneb cesta, jak efektivně administrovat síť a její uživatele přes webový prohlížeč pomocí P@wouka Ing. Tomáš Petránek

Více

Případová studie. O2 Slovakia: Aplikace O2 Univerzita. Aplikace O2 Univerzita. jako nástroj řízení vzdělávání zaměstnanců

Případová studie. O2 Slovakia: Aplikace O2 Univerzita. Aplikace O2 Univerzita. jako nástroj řízení vzdělávání zaměstnanců Případová studie O2 Slovakia: Aplikace O2 Univerzita Aplikace O2 Univerzita jako nástroj řízení vzdělávání zaměstnanců Aplikace O2 Univerzita Vzdělávání je pro naši firmu jedním ze základních pilířů, bez

Více

Novell Identity Management. Jaromír Látal Datron, a.s.

Novell Identity Management. Jaromír Látal Datron, a.s. Novell Identity Management Jaromír Látal Datron, a.s. 19.4.2012 1 Identity management základní vlastnosti Jednoduché a rychlé poskytování uživatelských účtů Samoobslužné funkce pro uživatele Snadný návrh

Více

Co je to E-Business Centrum

Co je to E-Business Centrum Co je to E-Business Centrum Jedná se o internetovou aplikaci, která je určena k oboustranné výměně informací mezi informačním systémem firmy Bartech, s.r.o. a zákazníkem. Přínosem jsou informace o novinkách,

Více

Vnitřní integrace úřadu Středočeského kraje

Vnitřní integrace úřadu Středočeského kraje VIÚ Středočeského kraje, Mgr. Jan Drnovský, Mgr. Václav Pávek 09/11/15 Vnitřní integrace úřadu Středočeského kraje Vnitřní integrace úřadu KUSK Krajský úřad Středočeského kraje 2 Obecné předpoklady řešení

Více

Procesní řízení. Hlavní zásady a praxe dodavatele Komix

Procesní řízení. Hlavní zásady a praxe dodavatele Komix Procesní řízení Hlavní zásady a praxe dodavatele Komix 1 Obsah prezentace Teoretická část (menšího objemu) orientace na zákazníka hodnocení procesu podmínky procesního řízení cyklus zlepšování procesu

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM

Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM Jaromír Jiroudek Lukáš Mikeska J + Consult Ernst & Young Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM Náplň setkání 1. Rychlý úvod do CCM/CPM 2. Představení

Více

SW pro správu a řízení bezpečnosti

SW pro správu a řízení bezpečnosti Integrační bezpečnostní SW pro správu a řízení bezpečnosti Systém je vlastním produktem společnosti Integoo. Trvalý vývoj produktu reflektuje požadavky trhu a zákazníků. Ať už je velikost vaší organizace

Více

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Definice, budování a život GIS Kapitola 1: Vztahy strana 2 Data, informace, IS, GIS Kapitola 1: Vztahy strana 3 Rozhodnutí Znalosti Znalostní systémy. Informace

Více

Zavádění projektového řízení ve společnosti

Zavádění projektového řízení ve společnosti Zavádění projektového řízení ve společnosti Monika Pidrmanová 26.10.2011 ZÁKLADNÍ POJMY Projekt = Jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný

Více

Zavedení e-learningu

Zavedení e-learningu Zavedení e-learningu Česká pojišťovna snižuje díky e-learningu náklady na školení svých pracovníků Přehled Země: Česká republika Odvětví: Bankovnictví a finance Profil zákazníka Česká pojišťovna a.s. je

Více

ENVIRONMENTÁLNÍ BEZPEČNOST

ENVIRONMENTÁLNÍ BEZPEČNOST ENVIRONMENTÁLNÍ BEZPEČNOST INTEGROVANÁ BEZPEČNOST ORGANIZACE Ing. ALENA BUMBOVÁ, Ph.D. Operační program Vzdělávání pro konkurenceschopnost Projekt: Vzdělávání pro bezpečnostní systém státu (reg. č.: CZ.1.01/2.2.00/15.0070)

Více

Aktuální otázky provozu datových skladů PAVEL HNÍK

Aktuální otázky provozu datových skladů PAVEL HNÍK Aktuální otázky provozu datových skladů PAVEL HNÍK K čemu slouží datové sklady IT podporuje business podniků S velikostí podniku se zvyšuje náročnost zpracování dat DWH = unifikovaná datová základna pro

Více

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM Petr Dolejší Senior Solution Consultant OCHRANA KLÍČŮ A ZOKB Hlavní termín kryptografické prostředky Vyhláška 316/2014Sb. o kybernetické bezpečnosti zmiňuje: v 17 nástroj

Více

Nápověda pro systém ehelpdesk.eu

Nápověda pro systém ehelpdesk.eu www.ehelpdesk.eu Nápověda pro systém ehelpdesk.eu Obsah 1. Základní informace o ehelpdesk.eu... 2 1.1 Rychlé použití aplikace ehelpdesk.eu... 2 1.2 Příklady nasazení... 2 2. Příručka pro uživatele ehelpdesk.eu...

Více

SIEM Mozek pro identifikaci kybernetických útoků. Jan Kolář 4.2.2014, Praha, Cyber Security konference 2014

SIEM Mozek pro identifikaci kybernetických útoků. Jan Kolář 4.2.2014, Praha, Cyber Security konference 2014 SIEM Mozek pro identifikaci kybernetických útoků Jan Kolář 4.2.2014, Praha, Cyber Security konference 2014 Agenda Prvky bezpečnosti IT Monitoring bezpečnosti IT (MBIT) Co je bezpečnostní incident? Jak

Více

pro komplexní řešení agendy neziskových organizací se zaměřením na sociální služby zdravotně postiženým NABÍDKOVÝ LIST

pro komplexní řešení agendy neziskových organizací se zaměřením na sociální služby zdravotně postiženým NABÍDKOVÝ LIST pro komplexní řešení agendy neziskových organizací se zaměřením na sociální služby zdravotně postiženým NABÍDKOVÝ LIST Nabídkový list informačního systému modularis Informační systém modularis je typickým

Více

Představení projektu Metodika

Představení projektu Metodika Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah

Více

Koncept řešení EOS EVIDENCE ORGANIZAČNÍ STRUKTURY

Koncept řešení EOS EVIDENCE ORGANIZAČNÍ STRUKTURY Koncept řešení EOS komplexní řešení informačních systémů EVIDENCE ORGANIZAČNÍ STRUKTURY Městský rok informatiky v Olomouci Datum: 12.6. 2009 MARBES CONSULTING s.r.o. Brojova 16, 326 00 Plzeň Jaroslav PEROUTKA

Více

Business Suite for Notes

Business Suite for Notes Business Suite for Notes Systém BSFN byl vytvořen na základě zkušeností s podporou a řízením procesů v obchodní firmě. Během několika let existence na trhu se osvědčil u mnoha zákazníků. Z nejvýznamnějších

Více

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

Více

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

Windows Server 2003 Active Directory

Windows Server 2003 Active Directory Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

Microsoft Windows Server System

Microsoft Windows Server System Microsoft Windows Server System Uživatelský autentikační systém od společnosti truconnexion komplexně řeší otázku bezpečnosti interních počítačových systémů ebanky, a.s. Přehled Země: Česká republika Odvětví:

Více

Připravte se na konjunkturu se systémem řízení údržby SGM. SGM moderní nástroj pro řízení údržby nejen výrobních zařízení

Připravte se na konjunkturu se systémem řízení údržby SGM. SGM moderní nástroj pro řízení údržby nejen výrobních zařízení Připravte se na konjunkturu se systémem řízení údržby SGM SGM moderní nástroj pro řízení údržby nejen výrobních zařízení 30.3.2010 konference EAM, Brno Boris Soukeník ředitel Synergit s.r.o. Agenda prezentace

Více

Řízení rizik s nástroji SAP BusinessObjects GRC AC Josef Piňos, CONSIT s.r.o.

Řízení rizik s nástroji SAP BusinessObjects GRC AC Josef Piňos, CONSIT s.r.o. Řízení rizik s nástroji SAP BusinessObjects GRC AC Josef Piňos, CONSIT s.r.o. Bezpečnost informačních systémů Využívání informačních technologií, zejména sofistikovaných ERP systémů jako je SAP, znamená

Více

QUO VADIS ICT. z pohledu ICZ. Roman Zemánek, obchodní ředitel ICZ a.s., Praha, 25. září 2014

QUO VADIS ICT. z pohledu ICZ. Roman Zemánek, obchodní ředitel ICZ a.s., Praha, 25. září 2014 QUO VADIS ICT. z pohledu ICZ Roman Zemánek, obchodní ředitel ICZ a.s., Praha, 25. září 2014 Dokument: Informační prezentace Důvěrnost: Veřejná www.i.cz 1 ZÁKLADNÍ ÚDAJE Společnost zaloţena 1997 Jediný

Více

Helios Orange. www.helios.eu

Helios Orange. www.helios.eu 45685696362545563221245896533661123695887878123456856963625455632212458965336611236958878781 23 568569636254556322124589653366112369588787812345685696362545563221245891236958878781234568 556322124589653366112369588787812345685696362545563221245891236958878781234568

Více

Úvod do problematiky vývoje Vývoj informačních systémů

Úvod do problematiky vývoje Vývoj informačních systémů Úvod do problematiky vývoje informačních systémů Vývoj informačních systémů Management Klasický management - slouží k udržování a rozvíjení zavedených systémů, které jsou prostředkem pro nepřetržitou,

Více

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY 29 HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY POKORNÝ Karel Abstrakt: Metoda Balanced Scorecard (BSC) její podstata, obsah a principy. Vztah BSC ke strategickému a operativnímu řízení

Více