S KOMIXem do Evropy. Petr Sobotka, Petr Kučera, ředitel,

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

Vážení čtenáři, dovolte, abychom Vám opět po roce nabídli výběr z informací o našich projektech, technologiích a novinkách, které jsme v uplynulém období uvedli na trh nebo je pro uvedení připravujeme.

Když jsme bilancovali rok 2004, mohli jsme konstatovat, že se nám podařilo meziročně zvýšit obrat o cca 25% a dosáhli jsme nejvyššího obratu za celou historii společnosti. Naším cílem je samozřejmě růst i v roce 2005. Základem našich služeb je stále vývoj informačních systémů „na míru“; v současnosti hlavně centralizovaných systémů s tenkým klientem. Daří se nám získávat nové klienty ve finančním sektoru, hlavně v segmentu pojišťoven, pro které máme připraveno řešení postavené na specializovaném jádru tvořeném e-IMS (e-Insurance Management System) engine. Toto jádro pracuje s business objekty na úrovni pojistných rizik, pojistné smlouvy, pojistníka, pojistitele atd. Implementace nových pojistných produktů je pak velice rychlá, v řadě případů ji může provést uživatel bez programování. Vyvinuli jsme i novou verzi systému WOIS (Workflow Oriented Information System), která je založena na XML, podporuje širší sortiment formátů generovaných dokumentů a má výrazně zlepšené uživatelské rozhraní. WOIS je základem systémů pro hromadné zpracování dokumentů nebo automatizaci obchodních případů. Dnes se používá jako součást faktoringového systému, podporuje komunikaci při hromadných úpravách smluv mezi zdravotní pojišťovnou a zdravotnickými zařízeními nebo slouží právnímu odboru při vymáhání pohledávek. V uplynulém období se nám podařilo vybudovat komplexní systém správy webového obsahu pro klienta ve finančním sektoru. I naše vlastní webové stránky jsou nyní postaveny na nástroji firmy Sitecore pro WCM (Web Content Management). Velice dobrou pověst si buduje odbor testování, který je dnes schopen zákazníkovi nabídnout komplexní služby počínaje vytvořením nebo přizpůsobením metodiky testování pro specifické podmínky zákazníka (vlastní vývoj, outsourcing, kombinovaný přístup, různé typy projektů atd.) a konče např. dodávkou akceptačních testů aplikace včetně simulace zátěže několika tisíci uživateli „na klíč“. Nově rozbíháme služby zaměřené do oblasti company governance nebo IT governance. Budujeme tým, jehož cílem je nejen implementovat systémy pro podporu procesního řízení společnosti, ale chceme zákazníka podpořit již ve fázi definice požadavků na cílové řešení a výběru vhodného postupu pro jeho zavedení do života. Věřím, že každý z vás najde v tomto čísle našich novin něco zajímavého nebo inspirujícího.

Petr Kučera, ředitel, [email protected]

S KOMIXem do Evropy Petr Sobotka, [email protected] Vstup České republiky do Evropské unie, ke kterému došlo 1. května 2004, se v životě běžného občana projevil – a stále projevuje – především drobnými, na první pohled snadno přehlédnutelnými změnami. Ti z nás, kteří si v uplynulém roce zažádali o nový řidičský průkaz, však určitý rozdíl zaznamenali: ne-li při podání žádosti (řidičský průkaz se již nevystavuje na počkání přímo na obecním úřadě či magistrátu), pak zcela určitě v okamžiku převzetí dokladu. Plastový průkaz růžovomodré barvy svými rozměry připomíná platební karty, do které jsou „vypáleny“ fotografie i podpis držitele. Forma i obsah dokladu odpovídá současným evropským standardům a lze ho použít jako řidičský průkaz pro cestování po celé EU. Svým provedením zaručuje jednak delší životnost, ale také lepší zabezpečení proti padělání nebo jinému zneužití. Společnost KOMIX byla jedním ze subjektů, které byly vybrány Ministerstvem dopravy, aby se podílely na tvorbě systému pro výrobu řidičských průkazů vzoru Evropských společenství (jak je doklad oficiálně nazýván). Smyslem tohoto článku je nastínit základní rysy řešení a zhodnotit vytvořený systém po jednom roce ostrého provozu. Celá infrastruktura pro pořizování a zpracování dat pro výrobu řidičských průkazů je rozdělena do tří základních oblastí: 1. pořizování údajů o žadateli, které tvoří žádost o vydání řidičského průkazu, a vydání vyrobeného dokladu žadateli – probíhá na obecních úřadech s rozšířenou působností, 2. shromažďování údajů z jednotlivých obecních úřadů, příprava dat pro výrobu, následné převzetí údajů od výrobce dokladů a distribuce výsledků procesu výroby obecním úřadům – zajišťuje centrální systém pro řízení výroby řidičských průkazů, který je provozován na Ministerstvu vnitra, 3. vlastní výroba řidičských průkazů – provádí Státní tiskárna cenin. Úkolem společnosti KOMIX byla realizace centrální části řešení. Mohli jsme zde využít jak konkrétních zkušeností z oblasti obdobných agend provozovaných ve státní správě, jakož i dalších znalostí z oblasti vývoje

podobného druhu aplikací. Byla vytvořena softwarová aplikace skládající se ze dvou částí: modulu pro autonomní dávkové provádění jednotlivých činností, které souvisí se shromažďováním a dalším zpracováním dat, a modulu pro monitorování a správu prováděných činností. Obě části využívají společnou provozní databázi, kde jsou uloženy veškeré údaje žádostí o výrobu řidičských průkazů a rovněž informace o aktuálním stavu a historii prováděných činností. Aplikace je založena na standardu J2EE. Provozním aplikačním serverem je Sun Java System Application Server verze 7, jako provozní databáze je použit IBM Informix Dynamic Server verze 9.4. Z dílčích technologií, které se uplatnily při řešení, lze zmínit následující: • XML – pro výměnu dat v rámci celého systému výroby řidičských průkazů, • Web Services, Java Message Services (JMS), message-driven Enterprise Java Beans (EJBs) – pro spouštění jednotlivých autonomních činností v dávkové části aplikace, • Java Transaction API (JTA) – pro řízení transakcí uvnitř dávkových činností, • Struts, JSP – pro tvorbu uživatelského rozhraní v monitorovací části aplikace, • Stored Procedure Language (SPL) – pro efektivní implementaci dílčích operací nad daty v provozní databázi. V době, kdy vznikl tento článek, byl systém pro výrobu nových řidičských průkazů přes jeden rok v rutinním provozu. Během tohoto období jsme obdrželi několik drobných připomínek ze strany obsluhy – především k uživatelskému vzhledu a ovládání monitorovací aplikace. Objevila se jediná situace, kdy byla blokována činnost systému a bylo třeba provést úpravu aplikačního algoritmu. Důvodem bylo nasazení nové verze aplikačního software na straně výrobce dokladů, který začal produkovat data v nepatrně odlišném tvaru. Je nám ctí, že jsme svou účastí na tvorbě systému pro výrobu řidičských průkazů přispěli nejen ke splnění jedné z podmínek, které byly na Českou republiku kladeny pro vstup do EU, ale především k poskytnutí kvalitní služby našim spoluobčanům.

1

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

To je práce s portfoliem! Portfolia a zas portfolia… Své portfolio má dnes už snad úplně každý. Tu se s ním po městě prochází grafik a hledá uplatnění, tam nad ním ostřížím zrakem bdí investor a onde zase působí jedno portfolio projektů vrásky nejednomu manažerovi v nejedné firmě. Vlastně základní vlastností každého portfolia je, že nám působí problémy. Otázka tedy zní: „Proč je tedy máme?“. Odpověď je jednoduchá: “Musíme!“ A právě proto nad nimi trávíme tolik času a přesně proto v nás budí každá pochybovačná zmínka o našem portfoliu takovou nelibost. Tak co s nimi?

mají portfolia za náplň práce (v tuhle chvíli mluvím o projektových manažerech a ředitelích IT), vznikají jako houby po dešti nástroje pro správu portfolií a jejich částí.

A jak z toho ven? Jednoduše. Nejde to. Tuhle situaci nelze než přijmout. A právě proto a právě pro lidi, kteří

Takový software je pak především příběhem o tom, co všechno to moje/vaše portfolio obsahuje, v jakém je právě teď stavu ta která částička portfolia, a když už jsou všechny ty kousky tak

Správa portfolia užitím SW nástroje Nástroj jako takový nás nikdy nezbaví těch drobných radostí spojených s obhospodařováním portfolia. Může nám pomoci ve dvou základních směrech: – Mít přehled o tom, co se v našem portfoliu právě teď děje… – … a tím nám pomáhat při strategických rozhodnutích. Zkrátka a dobře, takové nástroje nám umožňují být efektivní.

Ě

I

T

Prostě plánuji, co se stane když… Protože ono se většinou/někdy (každopádně bohužel) v praxi stává, že dojde i na ty nejméně očekávané a nejméně příjemné situace. V tomhle umí být život pěkný prevít. A když situace nastane, jsme právě díky takovémuto nástroji schopni reagovat rychle, přesně a s rozvahou – efektivně.

krásně na jednom místě, jaké jsou mezi nimi vazby. Pro tohle je software ideální. Neumím si představit, jak by kdo tvořil tuhle strukturu síní, místností, chodbiček, ventilací – tohle mraveniště – jen s tužkou a papírem. A když už všechny tyhle informace máme pohromadě, měli bychom být také schopni s portfoliem pracovat. A plánovat. A dělat si scénáře. A být připravení, co se stane, když zastavím tenhle projekt, vyřadím tenhle server, můj jediný specialista pro tuhle aplikaci dostane angínu.

Software může v tom nejlepším případě jenom pomáhat a dodávat informace ke kvalifikovanému rozhodování. Co však jeho povinností je, že nám má prezentovat informace aktuální a hlavně detailní. Jenom tak se můžeme dopracovat k tomu, proč to naše zatr… portfolio zase není tam, kam jsme mu naplánovali trasu a kterýže lodivod mi tu moji flotilu zbrzdil o dvacet uzlů. Právě proto, že do našich ideálních portfolií vstupuje příroda a spolu s ní nezaměnitelný, ale vždy překvapivě tvořivý lidský faktor, potřebujeme software na správu portfolií. Pokud totiž dojde ke kolizní nebo ke kolizi směřující situaci, potřebujeme to naše portfolio přeskládat, přetaktovat a přiohnout velmi rychle. Jakmile nám tato akce bude trvat několik dní (neřku-li týdnů), můžeme být precizně připraveni leda na jeden ohníček uprostřed hořícího náměstí. A v tom je asi ta největší výhoda systémů pro správu portfolií. Za jejich pomoci lze jednat rychle a pokud v nich udržujeme kvalitní data pak také přesně a jak jinak než efektivně.

Závěr V tomhle článku slovo portfolio tvoří 3,97 % všech slov a slovo efektivně 0,99 %. Takový je dnešní svět.

Norbert Knobloch, [email protected]

V legislativním okolí firmy existují různé právní normy, předpisy a zákony, které musí příslušná společnost dodržovat či splňovat. Tyto normy mohou být buď národní nebo účelové. Mezi účelové patří například Sarbanes-Oxley Act (SOX). Ten pro firmy, jejichž akcie jsou obchodované podle pravidel SEC (Securities and Exchange Commission), definuje přesnou strukturu finančních výkazů a vyžaduje vytvoření prostředí, kde lze zaručit věrohodnost publikovaných údajů. Podle tohoto zákona je management osobně zodpovědný za správnost informací ve výkazech pro SEC. IT útvar splňuje SOX, pokud existuje takové IT prostředí, v němž je zaručena kvalita informací a toto prostředí je udržováno pod stálou a přísnou kontro-

Obrázek 1

Legislativní prostředí

Corporate Governance

Národní

ISO

IT Governance

a předpisy

CMM

CobiT

SOX

Ostatní (BSC, TQM apod.)

ITIL

zákony

2

T

Software je software, ale lidi jsou lidi

IT Governance Tlak konkurence na společnosti stále roste a tím rostou i požadavky na IT útvary jednotlivých organizací. Vedení IT útvarů musí s omezeným rozpočtem a snižujícím se počtem pracovníků neustále zlepšovat návratnost investic do IT technologií, zvyšovat bezpečnost informačních systémů a současně zlepšovat služby a udržovat spokojenost uživatelů na vysoké úrovni. Jak však mohou současní vedoucí IT útvarů splnit zadané cíle za současných omezení? Odpovědí je zavedení řízení pomocí přístupu IT Governance. Co však tento, dnes již poměrně často zmiňovaný pojem, znamená? Rád bych to vysvětlil zasazením IT Governance do širšího okolí (viz obr. 1).

Ě

Jiří Prokeš, [email protected]

Pojďme k sobě být upřímní V dnešním světě existuje přehršel prostředků a nástrojů, které mají za úkol nám všem zpříjemnit a maximálně zjednodušit život. Pokud budeme tímhle způsobem pokračovat, za chvíli už nebudeme ani muset sedět u televize, abychom byli štíhlí, svalnatí, spokojení a bohatí nekuřáci. Asi všichni tušíme, že tahle vize má někde svou slabinu. Portfolia nám budou dělat starosti pořád. Nejde na ně nemyslet, neexistuje portfolio, které by čas od času (většinou vlastně pořád) nepotřebovalo nějaký zásah, drobnou úpravu, která ve finále bude znamenat týdny tvrdé dřiny. Portfolia jsou základním stavebním kamenem naší efektivity (další módní slovo). Je třeba být efektivní. Dnes musí být každý z nás Superman, aby mohl obhájit svoje konání, svoji práci – vlastně to, že vůbec dýchá. A portfolia máme k tomu, aby bylo možno naši efektivitu měřit. A věřte nevěřte, už jsme v situaci, kdy portfolia vládnou lidem, a kdy portfolia vytváří nová portfolia. Profesor Parkinson by z nás měl radost.

V

lou. Kontroly se dělí na kontroly aplikací (kontrola obchodních procesů a aplikačních systémů, zda nemůže dojít k neautorizovaným transakcím) a všeobecným kontrolám (týká se všech informačních systémů, kontroluje se bezpečnost systémů, řízení konfigurací, řízení dat a vlastní provoz). V rámci legislativního prostředí si společnost stanovuje svoji „Corporate Governance“. Corporate Governance je množina zodpovědností a praktik vydaných top managementem pro nastavení řízení společnosti. Zároveň musí také zajistit, že definované cíle jsou dosažitelné, rizika správně řízena a minimalizována za optimálního využívání podnikových zdrojů. Pro Corporate Governance lze použít buď metodiku CMM (Capability Maturity Model), tzv. model zralostí a znalostí, Balanced Scorecard (BSC) nebo přístupy orientující se především na zlepšování kvality řízení (například normy ISO 9000, oborové normy VDA, QS 9000, TQM, Model EFQM, Six Sigma a další). IT Governance je integrální část Corporate Governance a jejím cílem je nastavení takových organizačních struktur a procesů, aby IT útvar podporoval rozšíření a zlepšení služeb či produktů celé společnosti. IT Governance zaručuje měření procesů a jejich kontinuální zlepšování, a proto i zlepšování celého IT útvaru. Podle IT Governance Institute IT Governance pomáhá také firmě zajistit zodpovědné užití IT zdrojů. Cílem zavedení IT Governance je změna chování IT útvarů - z řešení incidentů (například kolaps internetové aplikace) na řešení problémů (například zvýšení kvality aplikací v provozu a minimalizace času, kdy jsou mimo provoz). Pro implementaci řízení pomocí principů IT Governance je výhodné využít několika dobře zavedených sbírek doporučení. Jedna z nich je

ITIL (IT Infrastructure Library). ITIL byl formulován Central Computing and Telecommunications Agency (CCTA) pro britskou vládu a nyní je vlastněn Office of Government Commerce (OGC). ITIL je rozšířen v Evropě a začíná i v USA získávat větší popularitu. Slouží především pro každodenní řízení IT útvarů jeho liniovými manažery. Jedná se tedy o řízení IT útvaru „uvnitř“. Další rozšířenou sbírkou doporučení je CobiT (Control Objectives for Information and Related Technology). Cílem CobiTu je strategické řízení IT útvaru a jeho audit. Jedná se vlastně o řízení IT útvaru „zvenku“.

ITIL (IT Infrastructure Library) ITIL se používá pro taktické a operativní řízení IT útvaru (viz obr. 2). Proto je určen liniovým manažerům IT útvaru. ITIL obsahuje souhrn nejlepších praktik pro klíčové provozní procesy uvnitř IT útvaru (například řízení změn, správa verzí či konfigurací, řízení incidentů a problémů, řízení kapacit a dostupnosti, řízení financí pro IT apod.). Tyto šablony osvědčených postupů lze použít v jakémkoliv IT prostředí (od poskytování podpory a služeb až po správu firemních počítačů). ITIL pomáhá především ve standardizaci procesního jazyka, popisu procesů a workflow základních operací. ITIL nemá obsaženy metriky. To znamená, že pomocí ITIL nelze určit, jak dobrý je IT útvar dané společnosti. IT útvar lze však měřit metrikami obsaženými v CobiTu (například doba a náklady realizace informatické služby; četnost výpadků, oprav a chyb; doba vyřešení problému a náklady s tím spojené; spokojenost uživatelů s IS, celkový počet hodin při poruše apod.). ITIL také jako takový neumožňuje certifikaci. Certifikaci však

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 2

umožňuje „nadřízená“ norma BS 15000, která podléhá dozoru British Standards Institutu. Silné stránky ITIL: – Rozšířená, vyspělá a detailní sbírka doporučení orientovaná na IT provozní záležitosti – Jednoznačná terminologie – Definované procesy – Může být kombinovaný s CMMI, aby se dosáhlo pokrytí celého IT (včetně provozu a vývoje aplikací) – Vyvíjí se (v roce 2006 se očekává nová metodika založená na ITIL a BS 15000) Neobsahuje: – Metriky – Řízení vztahů a životního cyklu služeb, propojení s obchodní strategií, analýzu nákladů na služby, řízení vztahů s dodavateli

CobiT (Control Objectives for Information and Related Technology) CobiT se používá pro strategické řízení IT útvaru a pro jeho audit. Proto je určen auditorům a business manažerům, ne liniovým manažerům jako ITIL. Je zaměřen na snížení rizik, integritu, spolehlivost a bezpečnost. Popisuje čtyři oblasti – plánování a organizaci, akvizici a implementaci, dodání a podporu, monitoring. CobiT pracuje s následujícími zdroji – lidé, aplikace, technologie, vybavení a data. Podobně jako CMM má 6 úrovní vyspělosti. Silné stránky CobiT: – Uvádí metriky (Key Goal Indicators, Key Performance Indicators a Critical Success factors) – Pokrývá všechny oblasti řízení a auditu IT útvaru – Velmi dobře navazuje na další rámce (zvláště na ITIL)

Slabé stránky: – Nedefinuje terminologii – Říká, co se má udělat, ne jak (procesy nejsou definovány, pouze načrtnuty) – Nepopisuje přímo vývoj software či IT služby – Nepopisuje postup neustálého zlepšování procesů

IT Customer Relationship Management

Change Management Configuration Management Incident Management

Service Level Management

Capacity Management

Financial Management for IT Services

IT Service Continuity Management

Service Delivery

Vnímáme již jako samozřejmost, že proces obvykle probíhá napříč organizační strukturou (čili více než jedním oddělením) a očekáváme, že SW bude tuto realitu respektovat. Nemusíme se ale spokojit s tím, že si ve firmě pomocí workflow zefektivníme oběh dokumentů a jejich schvalování, eventuálně se vzepneme k tomu, že si trochu zpřehledníme vyřizování obchodních případů a budeme jásat nad tím, že se pracovníkovi při spuštění aplikace zobrazí úkolovník upozorňující na časovou naléhavost řešení, popřípadě ho animovaný vztyčený prst pokárá za zmeškané termíny, přičemž proces běžící na pozadí pošle upozornění jeho vedoucímu. Nechci snižovat význam výše zmíněného, ale nezaškodí pomyslet na komplexní integraci a zavést opravdu automatizované řízení i velmi složitých a rozsáhlých procesů.

Service Desk

Availability Management Security Management

Obrázek 2

Některé zajímavé internetové adresy: Na závěr bych chtěl podotknout, že všechny uvedené přístupy jsou výhodné pro formalizaci řízení společnosti, pro popis stavu procesů a vyhodnocování jejich neustálého zlepšování a pro vzájemné porovnávání mezi firmami. Nejsou však samospasitelné a může se stát, že společnost nepoužívající tyto přístupy může být lépe řízená a konkurenceschopnější než společnost, která je používá. Základem úspěchu je především podpora a angažovanost vrcholného managementu a schopnost rychle reagovat na změny v obchodním prostředí.

WOIS – aneb jak na procesy Sotva se dnes podaří při čtení IT časopisu nenarazit na článek o BPM (Business Proces Management) a workflow, jakožto prostředku na jeho podporu. Módním hitem stalo se slovo proces - procesní řízení, procesní analýza, narovnávání podnikových procesů, procesně orientovaný SW. Pamatuji dobu, kdy hovoříc o produktu WOIS jako o procesně orientovaném systému, neboť ničím jiným není, jako bych se dopouštěla něčeho neslušného. Obléknout si mini v době, kdy je předepsána lady délka, nemusí se setkat s pochopením, i když odhaluje perfektní nohy. Avšak současnost procesům přeje. Chápeme, že fakturace je proces, vyřizování obchodního případu je proces, schvalování dokumentu a jeho oběh po firmě je proces, který jako takový má někde začátek a konec a stanovenou posloupnost kroků a pravidel, jak se od startu dostat k cíli.

Service Support

Problem Management

CMM/CMMI (Capability Maturity Model / Integration) CMM je model vyvinutý SEI (Software Engineering Institute) a je založen na kontinuálním zlepšování procesů od základních až po vyspělé. CMMI rozšiřuje zkušenosti a best practices z CMM, Capability Maturity Model for Software (SW-CMM), Systems Engineering Capability Model (SECM) a Integrated Product Development Capability Maturity Model (IPD-CMM). CMMI je souhrn „best practises“ pro vývoj softwaru a jeho udržování. Umožňuje společnostem ohodnotit jejich procesy a porovnat je s procesy v ostatních firmách. SW-CMM měří vyspělost procesů od úrovně 0 (počáteční) po úroveň 5 (procesy ve společnosti jsou optimalizované). CMM je použitelný pro Corporate Governance, CMMI pro IT Governance, protože je orientován na vývoj software. Silné stránky CMMI: – Velmi detailní popis – Použitelný především ve firmách vyvíjejících software – Zaměřen na neustálé zlepšování procesů, nejen na certifikaci – Může být použit pro ohodnocení firmy vlastními pracovníky (bez využití konzultantů) Slabé stránky CMMI: – Definuje cíle, ale neříká, jak je docílit

Release Management

K tomu je třeba SW, který umožní nejen – snadno navrhovat a popisovat procesy a pravidla rozhodování, nejlépe v grafickém prostředí – detailně sledovat postup vyřízení jakéhokoli případu (včetně historie) – automaticky spouštět akce na základě uplynutí času či jiných událostí – rozdělovat automaticky i manuálně práce mezi účastníky procesu, ale zároveň zvládne svým výkonem zpracovat i zátěž desítkami tisíc položek, které denně sviští napříč firmou. Další mnohdy opomíjenou nezbytností je účast metodika, který provede kvalitní procesní analýzu a navrhne optimální propojení jednotlivých činností tak, aby bylo možno maximum zautomatizovat, a uživatel nemusel v celé řadě standardních situací aplikaci explicitně spouštět, natož něco osobně řešit. Právě s tím má společnost KOMIX a autoři produktu WOIS bohaté zkušenosti. První verze produktu WOIS řešila „jednoduchý“ úkol: v rámci provozního systému, jenž byl obsluhován znakovými aplikacemi, řídit proces generování a tisku dopisů v grafickém textovém editoru přímo na tiskárně člověka spravujícího příslušnou agendu, aniž by bylo nutno nahrazovat znakové aplikace, nahrazovat terminály nebo instalovat další software na lokální počítače. Po úspěšném zvládnutí tohoto úkolu následovala aplikace řídící rozsáhlé procesy kontroly plateb, v jejímž rámci WOIS řídí generování a tisk desítek typů právně relevantních dokumentů (zahájení správního řízení, platební výměry) a po jejich odeslání sleduje odezvy adresátů na zaslané dokumenty. V případě neuhrazení systém automaticky zakládá právní případy vymáhání pohledávek a předává je k vyřízení právnímu oddělení. Právní oddělení má ihned k dispozici související informace o dlužníkovi, přehled o postupu vyřizování případu v oddělení plateb a náhled všech dokumentů generovaných v rámci procesu kontroly. Oddělení plateb, má-li k tomu nastavena práva, může sledovat, v jakém stadiu je proces vymáhání.

http://www.sarbanes-oxley.com/ http://www.ogc.gov.uk/ http://www.itil.co.uk/ http://www.itilcommunity.com/ http://www.itilpeople.com/ http://www.itil-itsm-world.com/ http://www.itgi.org/ http://www.itil.cz/ http://www.isaca.org/ http://www.ezcobit.com/ http://www.sei.cmu.edu/cmm/ http://www.sei.cmu.edu/cmmi/

Blanka Hrušková, [email protected] Produktem WOIS lze řídit procesy libovolné složitosti a věcné náplně. V praxi je nasazen především pro účely robustního zautomatizování mnohačetných a různorodých administrativních procesů. Jednotlivé procesy jsou navrženy a popsány a následně řízeny prostřednictvím struktur uložených v databázi metadat. Toto řešení umožňuje respektovat vysokou frekvenci změn v organizaci práce a různorodost způsobu práce v jednotlivých agendách. Změny lze provádět přímo v produkčním prostředí a je zajištěno zachování běžících procesů. Popisy procesů může metodik snadno upravovat pomocí návrhu v grafickém prostředí. Rozhraním pro přenos dat i metadat je XML, takže grafický návrh procesu lze importovat do produktu WOIS i z jiného prostředí (např. z produktu ARIS či dalších CASE nástrojů). Od svého vzniku prodělal WOIS řadu inovací, takže např. původní generování dokumentů do grafického editoru je nyní nahrazeno použitím XSL šablon a generováním do formátu PDF. V situaci, kdy se v systému nastartují desetitisíce kontrolních procesů, s klasickým úkolovníkem, v němž pracovník řeší případy ručně a jednotlivě, sotva vystačíme. Toto velké množství položek v procesech řízených produktem WOIS vyžaduje možnost dávkového (jak ručního tak automatizovaného) zpracování případů ve vytipovaných stavech a dávkové generování a tisk typových dokumentů. Proto WOIS disponuje jak standardním (Web) klientem využívaným pro klasické řešení jednotlivých úkolů, tak desktop klientem poskytujícím rozhraní pro práci s dávkami a samozřejmě kvalitním workflow enginem, který zpracování řídí. Produktů, které nabízejí řešení na bázi workflow, je mnoho, a vybrat si není lehké. Ale nejtěžší asi je, ujasnit si, k čemu nám má produkt sloužit a nebát se popustit uzdu fantazii. Mysleme na to, co skutečně potřebujeme vyřešit, nikoli jen na to, jaká připravená řešení nám produkty nabízejí.

3

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

Metadatová podpora informačních procesů v podnicích Jan Vrána, [email protected]

Úvod Většina velkých podniků má vybudovány a provozuje různé specializované informační systémy pro podporu a řízení svých dílčích činností a agend, např.: personalistiky, účetnictví, skladového hospodářství, logistiky, atd. S rostoucím počtem provozovaných aplikací velmi prudce narůstá počet jejich datových elementů a vzájemných přímých a nepřímých datových a funkčních vazeb. Implementace změn stávajících nebo vývoj nových aplikací v takovémto prostředí s sebou nese nutnost nejprve detailně prozkoumat všechny okolní systémy a jejich vzájemné vazby a teprve na základě zmapování a analýzy všech souvislostí provést návrh a implementaci zamýšlené změny nebo přírůstku. Mapování a analýza vzájemných vazeb jednotlivých aplikací spotřebovává veliké množství úsilí a prostředků. Ve velikých organizacích s opravdu velkým počtem dílčích aplikací rostou náklady spojené s jejich údržbou a rozvojem do astronomických výšek. Podstatná část činností, vyžadujících analýzu existujících vazeb, je navíc prováděna opakovaně. Jedním ze způsobů redukce činností, spojených s popsanou opakovanou analýzou závislostí jednotlivých existujících aplikací, je jejich dokonalé zmapování a uložení zjištěných informací v podobě metadat popisujících dané aplikace do společného metadatového úložiště. Úspěšné vybudování společného úložiště metadat jednotlivých provozovaných aplikací může organizaci přinést velikou konkurenční výhodu v podobě významné redukce nákladů na údržbu a rozvoj jejího IT portfolia a výrazně vyšší pružnosti ve vývoji a zavádění nových aplikací a v přizpůsobování se změnám prostředí, např. legislativy. Proces budování globálního úložiště metadat je však velmi komplikovaný a v mnohém směru i riskantní. Následující kapitoly stručně popisují výhody, které může společné úložiště metadat poskytnout, ale také úskalí a problémy, které nutně provází jeho budování.

• • • •

Redukce chybovosti IT aplikací Snížení výdajů na IT Společná správa znalostí Snazší přizpůsobení vnějším pravidlům a omezením, legislativě Jednotná správa IT portfolia je formální proces zajišťující řízení IT zdrojů, softwaru, hardwaru, IT projektů, vlastních a externích lidských zdrojů, atd. Řízené metadatové prostředí umožní formalizovat parametry jednotlivých elementů IT portfolia, tyto formalizované parametry uložit v podobě metadat do společného metadatového úložiště, svázat tato metadata s ostatními metadaty systému a nad všemi metadaty vytvořit jednotné manažerské rozhraní, které k nim poskytne rychlý a efektivní přístup. Velmi důležitým faktorem, který způsobuje prudký nárůst nákladů na údržbu a rozvoj IT portfolia, je redundance. Určitý typ redundance je žádoucí, např. redundance HW a SW sloužící pro zvýšení dostupnosti kritických aplikací, atd. Avšak neřízená redundance, hlavně aplikací, procesů a datových struktur a toků dat je nežádoucí a její odstranění nebo redukce má okamžitý efekt v podobě snížení nákladů na údržbu a rozvoj IT portfolia. Většina významných celosvětových studií uvádí, že pravděpodobnost selhání nového rozsáhlého IT projektu (např. budování datového skladu, CRM nebo ERP systému, atd.) v rozsáhlé organizaci se pohybuje v rozmezí 65 – 80%. Rozpočty takových projektů přitom dosahují mnoha desítek až stovek milionů dolarů. Mezi hlavní příčiny selhání projektů standardně patří: • Absence jasně definovaných a měřitelných aplikačních potřeb. • Nezohlednění existujících technických a aplikačních pravidel a zákonitostí. Řízené metadatové prostředí poskytuje prostředky, kterými lze podstatně usnadnit a zlepšit fázi specifikace a definice skutečných potřeb organizace a provést podrobnou analýzu dopadu zamýšleného projektu na ostatní součásti IT port-

ÊâãØÛ

bmèÚáãmà

ÄÀʗ¨

OdÜë¥

Ëé•à‡ëg Üâæåæä¥

èéçêàéêç ëÖï×î

ÇÜéêæå¥

ÊÜêëØíؗ¨

åçäØÚèî

Ëé•à‡ëg ãæÞàêëàâØ ÃæÞàêëàâØ

ÀëÖáÞéÖ ÄÀʗ©

éçÖãèÛäçâÖØÚ

ÄñÛð

Obrázek 1 – Extrakce metadat ze systémů a využití metadat

2 Řízené metadatové prostředí Úvodní kapitola stručně zmiňovala možnost vytvoření centrálního úložiště metadat, které obsahuje všechna podstatná získaná metadata ze všech aplikací provozovaných danou společností. Pouhé jednorázové získání a shromáždění metadat na jednom místě do jedné databáze však k vytvoření a trvalému udržení skutečné přidané hodnoty nestačí. Pro maximální využití všech možností, které centrální uložení metadat může poskytnout, je potřeba v organizaci vytvořit a trvale udržovat procesy, které shromážděná metadata využívají a ošetřují. Soubor technických komponent, organizačních opatření, procesů a lidí, zajišťující systematický sběr, využití a šíření metadat v organizaci je možno nazývat řízeným metadatovým prostředím. Hlavními přínosy, které správně navržené a implementované řízené metadatové prostředí může organizaci přinést jsou: • Jednotná správa IT portfolia • Omezení redundance IT

4

folia a tím podstatně snížit pravděpodobnost selhání nového projektu. Globálním trendem v IT je posun od zpracování dat ke zpracování znalostí. Jednou formou znalostí, které jsou ukryty ve zpracovávaných datech jsou jejich metadata. Znalosti jsou v každé organizaci tím nejcennějším a řízené metadatové prostředí poskytuje technologickou základnu pro jejich shromažďování, správu a doručování všem, kteří je potřebují. Každá aplikační doména je definována a svázána celou řadou nařízení a omezení, např. příslušnou legislativou. Tato omezení bývají vtělena do příslušných, především primárních, informačních systémů, které podporují základní činnosti a pracovní postupy každé velké organizace. Legislativa a omezení se však v čase mění a úměrně tomu se musí měnit i podpůrné aplikace. Jednotlivá omezení a aplikační pravidla jsou však většinou ukryta uvnitř aplikací a jejich zmapování a změna bývá náročným a dlouho trvajícím procesem, který při nedodržení termínů může vést

k citelným finančním sankcím. Správné centrální uložení a správa metadat může proces přizpůsobování IT aplikací změnám legislativy velmi usnadnit a urychlit především tím, že umožní mnohonásobně rychleji provést analýzu potřebných změn.

2.1 Architektura řízeného metadatového prostředí Popisované řízené metadatové prostředí zahrnuje úložiště metadat, katalogy, datové slovníky a další pojmy a znalosti, které musí z nějakého důvodu podléhat společné, jednotné a systematické správě. Nejedná se tedy pouze o datový sklad pro metadata. Jedná se o komplexní provozní systém, jehož je datový sklad pouze relativně malou součástí. Řízené metadatové prostředí sestává z následujících komponent: • Vrstva získávání metadat • Vrstva integrace metadat • Úložiště metadat • Vrstva správy metadat • Metadatová tržiště • Vrstva distribuce metadat

ÏmèàYëYãm âÚéÖÙÖé

né výhody především v podobě úspor výdajů na údržbu a rozvoj IT. Cesta ke správně vybudované správě metadat je však dlouhá a náročná. U standardních IT projektů uvádějí statistiky pravděpodobnost neúspěchu mezi 65 a 80 %. Seriózní statistiky úspěšnosti resp. selhání projektů budování a zavádění jednotné správy metadat zatím nejsou k dispozici, ale lze předpokládat, že procento selhání bude v tomto případě ještě vyšší, než v případě standardních IT projektů. Mezi hlavní aspekty, jimiž se proces budování jednotné správy metadat liší od většiny „standardních“ IT projektů a které způsobují jeho vyšší náročnost a následně pravděpodobnost selhání, patří: • Nedostatek zkušeností • Nepochopení problematiky a nepřijetí • Veliká zátěž celé organizace • Málo čitelný ekonomický přínos Začátky reálného budování a nasazování provozních informačních systémů se datují hluboko do osmdesátých let minulého století a za tu dobu byly po teoretické i praktické stránce dopracovány k dokonalosti. Budování datových skladů a mana-

¾ãéÚÜçÖØÚ âÚéÖÙÖé

ÂÚéÖÙÖéäëY éç“Þ…ée

¹ÞèéçÞ×êØÚ âÚéÖÙÖé

Máä“Þ…ée âÚéÖÙÖé

ÈåçYëÖ âÚéÖÙÖé

Obrázek 2 – Schéma Řízeného metadatového prostředí

Hlavním úkolem vrstvy získávání metadat je extrahovat metadata z primárních zdrojů (softwarové nástroje, uživatelé, dokumenty, transakční systémy, aplikace, …) a dopravit je přímo nebo prostřednictvím vrstvy integrace metadat do úložiště metadat. Hlavním úkolem vrstvy integrace metadat je transformovat získaná metadata do jednotné, cílové HW a SW platformy a tím umožnit snazší změny a přidávání zdrojů metadat. Úložiště metadat je standardní databáze, která uchovává metadata v obecné, konsolidované, integrované a aktuální formě, navíc s veškerou historií. Ukládání všech historických stavů metadat je nezbytné zejména tehdy, když řízené metadatové prostředí podporuje aplikace, které pracují s historickými daty, jako např. datový sklad nebo CRM aplikace. Úkolem vrstvy správy metadat je zajišťovat standardní operace správy dat (archivace, zálohování, ladění výkonu, plánování procesů, sbírání statistik využití, generování sestav, správa prostředí a konfigurací, mapování zdrojů, zajištění bezpečnosti, verzování a správa uživatelských rozhraní, atd.) Hlavní motivace metadatových tržišť jsou stejné jako u standardních datových tržišť v datovém skladu, tj. tématické seskupení metadat, přizpůsobení metadat specializovaným požadavkům, off-line předzpracování a odlehčení on-line zátěže. Poslední komponentou řízeného metadatového prostředí je vrstva distribuce metadat. Prostřednictvím této vrstvy jsou metadata ze společného úložiště definovaným způsobem dopravována všem potenciálním konzumentům, např. koncovým uživatelům, softwarovým nástrojům, aplikacím, datovým skladům, transakčním systémům, atd.

2.2 Proces budování řízeného metadatového prostředí Centralizovaná správa metadat, např. řízené metadatové prostředí může, když je správně vybudována, nesporně poskytnout velmi význam-

žerských nadstaveb nad provozními informačními systémy představuje ve srovnání s budováním provozních systémů mnohem kratší časovou etapu, avšak i v této oblasti již vesměs existuje velmi dobrá teoretická podpora a praktické zkušenosti. V obou případech se vývoj většinou týká aplikační domény, která je dané organizaci velmi blízká, tudíž nebývá problém obsadit vývojový tým lidmi s dostatkem věcných znalostí. Budování systému pro jednotnou správu metadat je z čistě manažerského pohledu IT projekt jako každý jiný s tím rozdílem, že se jedná o projekt zasahující a prostupující celou organizací. Jedná se o problematiku relativně zcela novou a tudíž teoreticky ani prakticky neprobádanou. Nelze tedy příliš počítat s dostupností pracovníků s bohatými zkušenostmi v této oblasti. Kvalifikačním předpokladem pro pracovníka vývojového týmu pro tvorbu a zavádění řízeného metadatového prostředí totiž ani tak nejsou hluboké znalosti určité aplikační domény, jako především schopnost systematického a abstraktního uvažování, schopnost „za vším vidět metadata“ a schopnost rozpoznat, která metadata jsou kandidáty na uložení ve společném úložišti a která naopak nikoliv. Řízené metadatové prostředí totiž není určeno pro ukládání naprosto všech myslitelných metadat, ale jenom těch, které má smysl propojovat s dalšími systémy. Velikým úskalím, které čeká na řešitelský tým, je nepochopení významu problematiky a následné nepřijetí nebo sabotování spolupráce ze strany pracovníků především na středních a nižších úrovních, tedy těch, kteří se reálně pohybují v jednotlivých aplikačních doménách a jsou nositeli znalostí o nich. Při budování řízeného metadatového prostředí je totiž členové řešitelského týmu ve většině případů „obtěžují“ tím, že po nich chtějí, aby to či ono své dílo, tu či onu specializovanou aplikaci, na kterou jsou uznávanými odborníky a mají ji celou „v hlavě“, z hlavy vydolovali a v přehledné,

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 4

strukturované a ucelené formě ji přenesli na papír. Tito lidé jsou často „staří praktici“, kteří mají zažitý způsob vytváření aplikací „na tvrdo“, tj. všechny vlastnosti mít zapsané v programovém kódu a bývá problém je přesvědčit o užitečnosti a významu metadat. Člověk jednající s takovými lidmi musí každopádně být profesionálně silně respektován a mít za sebou silnou podporu nadřízených pro případ, že profesionální respekt přestane fungovat. Kromě nepochopení významu a užitečnosti sběru metadat bývají také častými důvody nespolupráce obava ze ztráty výsadního postavení odborníka, nutnost metadata nejen jednou pořídit, ale i nadále průběžně aktualizovat a přizpůsobovat existující aplikace novým podmínkám (např. sdílené číselníky) nebo prostě jenom fakt, že jim je přidělávána práce.

Úspěch procesu budování řízeného metadatového prostředí je v každém případě jednoznačně podmíněn „osvíceným“ nejvyšším managementem společnosti, který je schopen a ochoten tomuto projektu zajistit a poměrně dlouhou dobu udržovat velmi vysokou prioritu a podporu na všech úrovních managementu. Přesvědčit a doslova nadchnout vrcholový management pro takovýto projekt je většinou velmi těžké. Mimo jiné i proto, že na těchto úrovních rozhodují především ekonomická hlediska, argumenty a budování řízeného metadatového prostředí má ten charakter aktivity, která velmi dlouho spotřebovává obrovské množství prostředků a zdrojů „navíc“, aniž by byl vidět nějaký hmatatelný přínos. Důležité je však vydržet alespoň do doby, než budování řízeného metadatového prostředí a jeho prostoupení společností přesáhne určitou

kritickou úroveň. Nad touto úrovní se role budovaného řízeného metadatového prostředí změní z „nechtěné přítěže“ na nezbytný a samozřejmý zdroj informací, čímž se další postup lavinově výrazně usnadní. Do té doby však budování řízeného metadatového prostředí vyžaduje velmi vysoké úsilí a prostředky.

3 Závěr Společná a jednotná správa metadat je zvláště pro velké organizace určitě jednou z cest, jak výrazně zefektivnit IT platformu a velmi podstatně tak snížit náklady na její údržbu a rozvoj, které u velkých společností často dosahují závratných výšek. Budování jednotné správy metadat není jednoduchá záležitost. Naopak je to komplexní proces, jehož je vlastní technické řešení úložiště metadat pouze malou částí. Velká většina činností

je spojena s transformací významné části společnosti, vybudování, zavedení a dodržování různých standardních postupů a procesů, které umožní vybudování jednotné správy metadat, ale i její další udržení a rozvoj. Řízené metadatové prostředí je jednou z možných metodologií, a je ji možno s výhodou použít jako osvědčenou kostru právě pro vytváření standardů, transformaci procesů, atd. V každém případě je potřeba dopředu počítat s tím, že tento proces je po všech stránkách náročný a dlouhodobý a jeho pozitivní účinky se začnou projevovat až za poměrně dlouhou dobu do dosažení tzv. kritické míry rozšíření ve společnosti. Do té doby bude většině společnosti pravděpodobně trnem v oku a bude potřeba ho prosazovat všemi dostupnými prostředky. Je však potřeba vytrvat, protože výsledek skutečně stojí za to.

Nástroje pro správu webového obsahu Východiska Web Content Managementu (WCM) Důvodů, proč uvažovat o efektivnější správě webového obsahu, je velmi mnoho. Uveďme si alespoň nejdůležitější z nich. Jednou z hlavních příčin, díky nimž se začaly rozvíjet nástroje WCM, je potřeba umožnit autorům textů publikovat jejich práci bez asistence webových specialistů. Ti totiž musí každý publikovaný dokument nejdříve upravit tak, aby zapadl do celkové struktury a designu stránek. Často je třeba rovněž provést řadu dalších souvisejících činností, jako zejména přidání odkazů do jednotlivých menu nebo mapy stránek. Kvalitní systém WCM by měl dokázat všechny výše uvedené činnosti automatizovat, popřípadě zajistit takovým způsobem, aby je snadno zvládli i autoři textů. Samozřejmě to nesmí znamenat, že se autoři začnou učit nové technologie, se kterými při stávající filozofii publikování pracují správci webů, ale naopak, nástroj jim musí poskytnout intuitivní prostředí, ze kterého mohou provádět všechny potřebné úkony související se vznikem a publikováním dokumentu. V ideálním případě je žádoucí zajistit přímé propojení nástroje WCM s některými běžně používanými kancelářskými aplikacemi takovým způsobem, aby si uživatel vůbec neuvědomil skutečnost, že jím vytvořený obsah není ukládán na pevný disk počítače, ale přímo do databáze systému WCM. Dalším důvodem je neustále rostoucí počet dokumentů, ať už se jedná o externí internetové prezentace nebo firemní intranety. Nejde však pouze o rostoucí počet dokumentů, ale také narůstající množství opakujících se informací. Z této skutečnosti pak vyplývá požadavek, aby opakující se informace byly ukládány pouze jednou a případná změna v „centrálním“ dokumentu pak může být snadno promítnuta na všechna místa, kde se dokument použil. Často je také potřeba zohlednit rozmanitost dokumentů a různý způsob jejich vzniku, kdy se

na jeho tvorbě podílí více lidí. Systémy WCM by tudíž měly podporovat workflow nejlépe takovým způsobem, kdy ke každému typu dokumentu lze připojit odpovídající posloupnost souvisejících činností. S tím pak souvisí také správné nastavení uživatelských oprávnění, kdy za každou činnost v rámci procesu zodpovídá určitá osoba.

stojí krabicová řešení. Tyto nástroje jsou levné a mohou být rychle implementovány. Na druhou stranu nabízejí jen minimální flexibilitu z hlediska designu (systémy obvykle mají možnost volby z několika předdefinovaných vzhledů) a také z hlediska obsahu (obsah je vztažen přímo ke konkrétní stránce, což znesnadňuje jeho opětovmanuální správa webu

provozní náklady (hodiny)

téměř naprostou volnost v oblasti tvorby a údržby stránek. Na rozdíl od krabicových řešení lze nástroje z této kategorie díky jejich aplikačnímu programovému rozhraní (API) mnohem lépe integrovat s ostatními podnikovými aplikacemi, které tak mohou přistupovat k obsahu uloženému v nástroji WCM a v případě, že obdobným rozhraním disponují i ostatní aplikace, lze ho využít pro získání informací uložených v jiných systémech.

Systémy all-in-one Nástroje tohoto typu jsou určeny pro správu nejen webového obsahu, ale také mnohých dalších druhů dokumentů včetně popisu procesů, které s těmito dokumenty souvisí (workflow). Tyto nástroje jsou schopné automatizovat veškeré činnosti související s podnikovým obsahem, u kterých je to možné. Pro potřebu nástroje usnadňujícího práci zaměstnanců s webovou prezentací je systém tohoto typu možná příliš rozsáhlý a bylo by možné místo něj použít menší nástroj, ale v případě, kdy firma uvažuje o větší reorganizaci svého obsahu, která by šla za hranice webu, je takovýto nástroj velmi atraktivní variantou. komplexnost nabídky informací (počet stránek)

použití WCM Vztah komplexnosti webu a jeho provozních nákladů

Kategorie nástrojů a jejich vlastnosti Nástrojů, které řeší oblast správy webového obsahu, je dnes již velmi mnoho. Dle jejich komplexnosti je lze rozdělit do určitých kategorií, a to od menších na bázi Open Source, až po vysoce sofistikované nástroje, jimiž lze kromě webového obsahu řídit veškerý podnikový obsah (tzv. Enterprise Content Management).

Krabicové systémy Necháme-li stranou systémy typu Open Source, pak v pomyslné hierarchii o stupeň nad nimi

né použití). Krabicové systémy se pak rozhodně nehodí pro rozsáhlejší a náročnější prezentace. Pokročilé funkce jako například rozhraní k propojení s jinými aplikacemi nebo workflow nejsou zpravidla vůbec implementovány nebo jen okrajově.

Vývojové platformy Nástroje spadající do této kategorie svým uživatelům obvykle nabízí dvě prostředí – jednak pro práci s obsahem, které je určeno zejména pro netechnicky zaměřené uživatele pracující s texty, jednak pro vývojáře, kterým systém umožňuje

Monitoring a optimalizace J2EE aplikací pomocí nástroje Wily Introscope Nabídka služeb naší společnosti pro zákazníka zahrnuje i monitoring a optimalizaci J2EE aplikací. S využitím nástroje Wily Introscope lze efektivně udržovat optimální stav kritických J2EE aplikací v provozu a stejně tak velmi rychle předcházet a lokalizovat problémy v jednotlivých částech aplikace. Společnost KOMIX s.r.o. má dlouholeté zkušenosti ve vývoji i testování aplikací technologie J2EE a nabízí služby optimalizace a monitoringu po celou dobu životního cyklu těchto aplikací: při vývoji, v průběhu zátěžových testů i při běhu v produkčním prostředí. Wily Introscope americké společnosti Wily Technology představuje pokročilý systém pro aktivní monitorování a identifikaci problémů jednotlivých vrstev aplikace J2EE . Kompletní řešení systému monitorování (viz obrázek 1.1) poskytuje efektivně informace o monitorovaných aplikacích pro všech-

Petr Pšeničný, [email protected]

ny zúčastněné role v jednotlivých společnostech (vývojáři, administrátoři, správci aplikací, testeři, manažeři atd.). Introscope Agent je spouštěn společně s monitorovanou aplikací a sbírá měřená data definovaných komponent. Pomocí patentované Byte Code Instrumentation technologie dosahuje agent minimálního zatížení monitorované aplikace, a to maximálně 5%. Ve standardní konfiguraci agent umožňuje monitorovat standardní komponenty a rozhraní architektury J2EE, například JSP, Servlet, WebServices, EJB, JNDI, JTA, JMS a JDBC, a s použitím technologie Blame usnadňuje identifikaci závislostí mezi nimi. Introscope Agent přímo podporuje monitorování komerčních aplikačních serverů (WebLogic, WebSphere, Sun Java AS, Oracle Application Server, SAP NetWeaver) i ostatních Open Source řešení (JBoss, Tomcat, Struts atd.)

Závěr Společnosti, které provozují webové stránky, kde je relativně mnoho dokumentů a kam přispívá větší počet uživatelů, se bez nástroje WCM s největší pravděpodobností neobejdou. Pokud taková organizace existuje, tak její weboví administrátoři budou trávit příliš mnoho času publikováním dokumentů, které dostanou v nejrůznějších podobách od jejich autorů. Kvalitní a správně implementovaný nástroj WCM však umožňuje všem zúčastněným pracovníkům zaměřit se na jejich hlavní pracovní činnost a znatelně tak zvýšit celkovou efektivitu práce.

Martin Ptáček, [email protected]

Obr. 1.1.: Introscope Architecture

5

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 5

Introscope Enterprise Manager přijímá a zpracovává data od agentů a umožňuje jejich prezentaci v Introscope Workstation nebo pomocí webového rozhraní aplikace Introscope WebView. Enterprise Manager historicky uchovává všechny naměřené metriky v databázi SmartStor a umožňuje jejich prohlížení a analýzu až několik dní či roků zpětně. Introscope Workstation slouží k vizualizaci naměřených dat a konfiguraci parametrů monitorování. V základní podobě je každá měřená veličina zobrazována ve formě periodicky aktualizovaného grafu. Nedílnou součástí Introscope Workstation je i možnost vytvářet uživatelsky definované kontrolní panely (Dashboards) sdružující několik měřených veličin v přehledném grafickém rozhraní (viz obrázek 1.2).

analýza jednotlivých transakcí v podobě detailních statistik volání jednotlivých komponent (viz obrázek 1.3). Introscope poskytuje velmi jednoduchý systém generování uživatelských reportů ve formátu HTML. Pro podrobnější reportování byla vytvořena naší společností speciální aplikace umožňující automaticky generovat hodinové i denní reporty podle uživatelských XML šablon do formátu PDF (viz obrázek 1.4). V případě, že při monitoringu vznikne potřeba získání platformě závislých dat, která nelze standardními postupy pořídit z JVM, je zde k dispozici speciální EPA agent (Environment Performance Agent), který spouští libovolný skript nebo nativní program generující do standardního výstupu jednoduchý definovaný formát dat (viz obrázek 1.5).

Nástroj Wily Introscope je vhodný a relativně cenově dostupný nástroj pro monitorování J2EE aplikací. Zvláště je oceňován pro svoji vysokou míru přizpůsobivosti individuálním

požadavkům zákazníků a velmi snadnou implementaci v řádech několika málo hodin. Ve své kategorii se jedná o jeden z nejlepších softwarových produktů pro monitorování na trhu.

Obr. 1.3.: Introscope Trace Viewer

Obr. 1.2.: Introscope Dashboards

Pro účely dlouhodobého monitorování bez nutnosti interakce s uživatelem je k dispozici systém událostí a akcí (Alerts and Actions) podmíněných překročením prahových hodnot sledovaných veličin. V případě výskytu události je provedena akce v podobě zaslání zprávy elektronickou poštou nebo spuštění libovolného příkazu hostitelského systému. Jednotlivé události mohou být zasílány do SNMP System Manageru (HP OpenView, Tivoli TEC, BMC Patrol atd.) Další důležitou součástí je i Introscope Transaction Tracer, který je určen pro zachycování a ukládání transakcí přesahujících definovaný časový interval. Jednotlivé transakce jsou zobrazovány jako posloupnost zúčastněných komponent i s jejich časovými odezvami, kterými se podílejí na celkové době transakce. Pomocí nástroje Introscope Trace Viewer je usnadněna

Pomocí mnoha rozšiřujících modulů je možno monitorovat i další specifické komponenty, rozhraní a parametry: • Introscope SQL Agent – sledování interakcí s databází až na úroveň jednotlivých SQL příkazů • Introscope Leak Hunter – identifikace úniků paměti • Introscope PowerPacks Weblogic, WebSphere – specifické parametry aplikačních serverů (HTTP Sessions, EJB Pools, Security, Threads atd.) • Introscope Portal Extension – IBM WebSphere Portal v5.1, BEA WebLogic Portal 8.1 SP2 (Portlets, Personalization, UserProfile, ContentManagement atd.) • Browser Response Time Adapter – měření end-to-end komunikace koncových klientů web aplikací

Obr. 1.4.: Wily Reporter

Obr. 1.5.: Introscope Environment Performance Data

Novinky na poli J2EE Od minulého vydání KOMIXových novin uběhl rok a za tu dobu se na poli J2EE událo mnohé. Letos jsme se s kolegou rozhodli zaměřit na dvě, doufám zajímavé, oblasti: 1. JSF (JavaServer Faces) – framework pro efektivní tvorbu webových aplikací 2. EJB 3.0 – nová specifikace jádra J2EE – Enterprise Java Beans

JavaServer Faces Framework JavaServer Faces vyvinutý firmou Sun se snaží zaplnit zřejmou mezeru v technologiích sloužících k vytváření aplikací pro web. Platforma J2EE k jejich tvorbě poskytuje technologie Servletů a JSP stránek. Problém je, že se jedná pouze o stavební kameny, které se dají používat a vzájemně provázat mnoha různými způsoby, avšak nejsou postačujícím prostředkem při vývoji složitějších aplikací. Vývoj takových aplikací s velkým počtem formulářů vyžaduje totiž něco navíc – snadný a systematický způsob jak vytvářet obrazovky a konzistentně je začleňovat do struktury aplikace. Opakovaná rutinní práce nikoho netěší, a proto určitě přijde vhod systém flexibilních opětovně použitelných komponent. Krátce řečeno, je

6

prakticky nezbytné mít framework umožňující toto všechno, aniž by nějak výrazně omezoval v rozletu tvůrce aplikace. Průmyslovým standardem na poli takovýchto frameworků se v minulých letech stal open source projekt Jakarta Struts, který se dočkal podpory snad všech velkých hráčů oblasti J2EE i výrobců vývojových prostředí. Ovšem sám autor Struts Craig McClanahan, nyní zaměstnaný firmou Sun a vedoucí tvůrce specifikace JavaServer Faces říká, že Struts jsou svým přístupem a architekturou poplatné době, kdy vznikly, což je více než pět let. Takto dlouhá doba umožnila, aby se především v řadách open source komunity objevily nové postupy usnadňující programátorovu práci. Ačkoliv popularita a rozšířenost Struts je obdivuhodná a pro speciální typy projektů díky svému nízkoúrovňovému přístupu může být jejich použití výhodnější, pozvolný nástup JSF jako standardizovaného nástroje pro tvorbu webových aplikací je těžko zadržitelný. Nyní už přistupme k tomu, co vlastně JSF tak průkopnického nabízejí.

Automatická správa Java Bean Ve web aplikacích se používají objekty s jednou ze tří životností: jediného požadavku, ses-

Jan Peremský, Martin Vaněk [email protected]; [email protected] sion uživatele a celé aplikace, přičemž servlet API poskytuje funkce k jejich ruční správě. JSF od této nutnosti odstiňuje programátora tak, že objektům je konfiguračně určeno symbolické jméno a rozsah platnosti. Při požadavku na práci s objektem zadaného jména je automaticky nalezen a vrácen ten správný. Tyto objekty bývají označovány jako backing beans nebo managed beans a principiálně jde o rozšíření code-behind systému ASP.NET.

Komponenty uživatelského rozhraní Tak jako JSP disponuje knihovnami tagů, tak JSF obsahuje obdobný balík komponent; ovšem s rozsáhlejší funkcionalitou a sofistikovanějším životním cyklem. Syntaxe použití je identická, ale velký rozdíl je v možnostech, které nabízí Expression Language. Ten u JSF pracuje se symbolickými jmény backing bean, které jsou rozhodovány až za běhu aplikace. Filozofie JSF je navíc taková, že komponenta samotná nic neví o své vizuální podobě, kterou řeší až tzv. RenderKit. Takovýto přístup umožňuje použít komponenty a pomocí nich vybudovaná uživa-

telská rozhraní beze změny i pro jiné než HTML klienty.

Zpracování událostí Na první pohled se může zdát nesmyslné mluvit o událostech v souvislosti s web aplikací, kde uživatelské rozhraní je tvořeno HTML, komunikace klient-server je vzdálená a probíhá nad HTTP protokolem. Ale JSF opravdu obsahuje mechanismus, který systém událostí typický pro tlusté (např. Swing) klienty zdárně emuluje. Skutečně existuje přímá korespondence mezi tlačítkem a metodou některé z backing bean, která se při jeho stisknutí vykoná.

Kontrola uživatelských vstupů Zatímco klasickým způsobem je nutné příchozí požadavek analyzovat a programově zjišťovat, co a jak uživatel ve formuláři vyplnil, v JSF se toto typicky řeší deklarativně. Na nejčastější případy povinných položek ve formátu text nebo číslo je pamatováno a přímo v balíku jsou pro tyto případy přítomny takzvané validátory. Jsou to třídy s jednoduchým rozhraním, takže pro složitější případy kontrol vstupů je triviální vytvořit vlastní.

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 6

Navigace mezi stránkami Kompletní balík by se neobešel bez navigačního nástroje, pomocí kterého se snadno nadefinují přechody mezi jednotlivými stránkami. JSF jeden takový jednoduchý, ale účinný, obsahuje. Deklarace jeho pravidel má formu: „výchozí stránka + výstupní hodnota akce = cílová stránka“ a je uložena v konfiguračním souboru, takže změny nevyžadují zásahy do programu a jeho následnou rekompilaci.

Internacionalizace a lokalizace Snazší než u JSF už to snad ani být nemůže. Stačí všechny texty nahradit symbolickými jmény a ty pak jsou automaticky dotahovány podle jazykových preferencí uživatele z tzv. ResourceBundles. Chybová hlášení deklarativní kontroly uživatelských vstupů nejsou výjimkou.

Výše popsanou funkcionalitu předvedu na triviální aplikaci, ve které uživatel hádá náhodné číslo. Ačkoliv v JSF je zřejmá snaha řešit co nejvíce úkolů konfiguračně a deklarativně bez nutnosti programovat, pro zvídavé jedince je určitě zajímavá možnost dostat se pomocí JSF API až na jeho vnitřní struktury a ty programově modifikovat anebo dokonce až na podložní Servlet a JSP API. Modulární architektura JSF s přesně vymezenými kompetencemi navíc umožňuje nahradit standardní implementaci celých částí frameworku jinými, které mohou být například vybaveny přídavnou funkcionalitou. V současnosti největší vadou na kráse JavaServer Faces je jejich nekompatibilita s aktuální verzí knihoven tagů a Expresion Language, což znamená, že je nelze použít na JSP stránkách obsahujících JSF komponenty. Tato nepěkná situace vznikla tím,

Obrázek 3 – Konfigurační soubor JSF

Obrázek 1 – Guess.jsp stránka s JSF komponentami

že v době vytváření specifikace JSF nebylo možné zasahovat do existující specifikace JSP, používající méně dynamické vyhodnocování Expresion Language a jednodušší životní cyklus tagů než mají jejich protějšky v JSF. Dobrá zpráva je, že nové verze specifikací jak JSF 1.2 tak JSP 2.1 řešící tento neblahý stav jsou již ve fázi Public Review. Nástup JSF i přes všechny jeho výhody není právě bleskový především díky existenci jiných zažitých a kvalitních web frameworků, ale také díky nemalé složitosti pro začátečníka. Nicméně jsem přesvědčený, že JSF posouvají efektivitu vývoje standardních webových uživatelských rozhraní na řádově vyšší úroveň. Dvě konkurující si implementace specifikace JSF, stále vzrůstající počet nových komponent a silná podpora velkých J2EE firem i výrobců vizuálních vývojových prostředí signalizuje pro JavaServer Faces příznivou budoucnost.

EJB 3.0 Zatímco JSF jsou v současné době již standardizovány a vznikají či již existují IDE pro jejich komfortní používání, EJB 3.0 (JSR 220) specifikace je ve fázi „Early Draft Review 2“- tzn., že není ještě dokončena, a neustále se vyvíjí. Nicméně již existují částečné implementace, reflektující poslední verzi dokumentu JSR220, které dávají možnost „otestovat“ nejočekávanější novinky a změny oproti verzi – EJB 2.x. V současné době lze nalézt minimálně dvě takové implementace resp. aplikační servery: 1. JBoss application server s podporou EJB 3.0 2. Oracle application server s podporou EJB 3.0

Co je EJB2.x vytýkáno?

Obrázek 2 – Backing (Managed) Bean

EJB 2.x je široce využívaná specifikace resp. technologie. Je však často považována za rozporuplnou a má tudíž množství přívrženců, ale i odpůrců. Zde uvádím nejčastější výtky vývojářů: Především se jedná o značnou komplexnost specifikace. Kvůli jednomu ejb je nutno kromě vlastní implementace vytvořit či vygenerovat několik interfaces a editovat minimálně jeden xml soubor. Takto vytvořená implementace ejb musí dále implementovat předepsané rozhraní a N tzv. callback metod, z nichž velká většina často neobsahuje žádnou funkčnost. EJB 2.x jsou dále vytýkány: nedostatečné oddělení operací týkajících se jediné instance ejb a operací se skupinami instancí a také zbytečné vytváření vazeb mezi komponentami.

Dle mého názoru je vývoj EJB aplikací ve verzi 2.x prakticky možný jen následujícími dvěma způsoby, z nichž však ani jeden není z toho či onoho důvodu ideální: 1. Pomocí specializovaného IDE (např. SunOne Studio či Websphere Application Developper), které umožňuje komfortní tvorbu ejb s tím, že na pozadí generuje potřebné interfaces, home třídy a především generuje a umožňuje lépe editovat xml descriptory. Zjevnou nevýhodou tohoto přístupu je většinou provázání IDE s konkrétním aplikačním serverem a tím pádem komplikovaná, pokud vůbec možná, migrace na aplikační server jiného výrobce. 2. Využití některého existujícího pseudo-metadatového přístupu: například XDoclet. Programátorovi se tak značně usnadní práce, avšak v tomto případě na úkor nutnosti znát XDoclet tagy a nutnosti extra kompilačního kroku – generování tříd a deskriptorů z metatagů. Výhoda této cesty oproti variantě se specializovaným IDE je v možnosti relativně snadného přechodu na jiný aplikační server.

Nejzásadnější změny a nové vlastnosti EJB3.0 Specifikace EJB 3.0 reflektuje mnohé výtky adresované svým předchůdcům. V obecné rovině se jedná především o následující: • Nahrazení či alespoň částečné nahrazení konfiguračních XML souborů (deployment descriptors) anotacemi (metadata annotations – definované v J2SE 5.0) • Zavedení defaultních hodnot tam, kde je to rozumné – sníží se tak nutnost jejich zbytečného opakovaného specifikování • Zmenšení velikosti a zjednodušení kódu. Snížení počtu potřebných tříd a rozhraní a jejich vzájemných vazeb a závislostí • Zjednodušený klientský model • Možnost testování mimo kontejner aplikačního serveru K velkým změnám došlo v oblasti entit (entity beans). Zde byl navržen úplně nový O/R model. Z důvodu komplexnosti a relativní autonomity problematiky byla pro její popis vytvořena vlastní specifikace (Persistence API). Entity se v EJB 3.0 „pyšní“, mimo jiné, následujícími vlastnostmi: • Entity jsou definovány jako tzv. POJO (Plain Old Java Object) – tedy v podstatě standardní java beans doplněné o případné anotace

7

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 7

• Vylepšená bezpečnost a robustnost založená

Ukázky kódu

na přesunu bezpečnostních a transakčních aktivit z roviny entit do roviny session beans • Mocnější a flexibilnější, ale přitom zjednodušený, mechanismus tzv. callbacks (např. precreate, postcreate u entit) • Snazší přenositelnost (portabilita) díky standardizovanému O/R modelu s manažerem entit • QL je komplexnější a flexibilnější, jednotlivé dotazy lze pojmenovávat (NamedQuery) a lze přímo využívat i nativních SQL příkazů (otázkou je, zda je to ta nejlepší cesta?)

Na prostoru tohoto článku lze jen stěží ukázat více kódu než jen to nejpodstatnější. Následují ukázky entity beanu a obslužného session beanu včetně remote rozhraní. Povšimněte si využití anotací, neexistence home rozhraní a ejbXXX metod. Jednotlivé beany neimplementují žádné povinné rozhraní (např. EJBObject). U stateless session beanu „FacadeBean“ si všimněte využití EntityManageru pro práci s entitami a mechanismu „code injection“ pomocí anotace @Inject.

Obrázek 5 – SessionBean’s remote interface

Obrázek 6 – Stateless SessionBean‘s implementation

Zhodnocení a budoucí výhled Specifikace EJB 3.0 představuje významný krok směrem k lepší a jednodušší tvorbě enterprise aplikací. Před tvůrci specifikace je stále ještě mnoho co řešit. Za sebe doufám, že výsledek bude dostatečně komplexní a konzistentní, a že prvotní cíl – zjednodušení života vývojářů – bude zachován. Do doby ukončení definice specifikace si lze novinky EJB 3.0 nezávazně zkoušet. Migrace stávajících aplikací je však zatím „hudbou budoucnosti“.

Obrázek 4 – EntityBean

Obě výše popisované technologie – JSF i EJB 3.0 jsou důkazem překotného vývoje v oblasti enterprise aplikací založených na platformě Java. Jedním z cílů, který si obě technologie kladou, je zjednodušení a zefektivnění vývoje aplikací, tudíž usnadnění práce vývojářů. S touto nastoupenou cestou se nedá než souhlasit. JSF 1.2 by se společně s EJB 3.0 měly objevit v příští verzi balíku standardů J2EE 5.0. Ten však bude obsahovat ještě značné množství jiných komplementárních technologií, z nichž některé jsou stále ještě ve fázi návrhu specifikace. Zůstává tak otázkou, kdy se J2EE 5.0 dočkáme?

Monitorování aplikací z pohledu uživatele a použití nástroje Business Availability Center

David Šorf, [email protected]

V dnešní době je kladen stále větší důraz na kvalitu a nepřerušený běh kritických podnikových aplikací. Je třeba aplikace nejen odladit a otestovat před vlastním nasazením do provozu, ale také je za provozu sledovat a mít tak přehled nad celým systémem, protože IT oddělení se již stalo nepostradatelnou součástí podniku a podnikových procesů. Dřívější pojetí monitorování ICT systémů nebylo monitorováním aplikací, ale pouze monitorováním infrastruktury (hardwaru a některých základních parametrů operačních systémů). Pro reálný a vypovídající obraz celého systému bychom museli tímto způsobem sledovat úplně všechny prvky, které mohou ovlivnit provozovaný systém. Ani tak bychom však neměli zaručeno, že odhalíme všechny problémy sledovaného systému, které mohou nastat. Např. malé vytížení procesorů, pamětí i sítě se může jevit jako projev „dobrého zdraví“ systému, ale ve skutečnosti třeba klíčová aplikace vůbec neběží, a proto nezatěžuje infrastrukturu. Současným trendem je sledovat aplikace (nejen infrastrukturu) z pohledu uživatele – tedy nejen interní parametry aplikace, ale především její použitelnost z uživatelského hlediska. Informace o stavu celého systému tak, jak ho vnímají koncoví uživatelé (zákazníci či zaměstnanci), umožňuje i bez podpůrného monitorování infrastruktury posoudit, jak se systém chová a zda funguje. Pro efektivní a rychlou identifikaci a odstranění příčin problému je ale stále nutné mít přehled o vzájemných vazbách mezi aplikacemi

8

a infrastrukturou. Rozhodně nezavrhujeme monitorování infrastruktury, ale vhodně ho kombinujeme s monitorováním aplikací, jak pasivním tak aktivním. KOMIXem preferované řešení je Mercury Business Availability Center (BAC) od společnosti Mercury Interactive, na kterém budeme ilustrovat funkce a schopnosti monitorovacích nástrojů, přínosy a praktické využití tohoto řešení.

Sběr dat Data je možno získávat několika různými způsoby. Sběrem dat z infrastruktury se nebudeme v tomto článku zabývat podrobně. BAC je modulární systém, který umožňuje získávat data o infrastruktuře pomocí modulu System Availability Management (SAM) z různých zdrojů. Je to buď monitorovací bezagentový nástroj

ļɺÌÉЗ¹ÌÊÀżÊʗ¸Í¸Àø¹ÀÃÀËЗº¼Å˼É

¼åۗÌêÜé ÄØåØÞÜäÜåë

ÊÜéíàÚܗÃÜíÜã ÄØåØÞÜäÜåë

¸åØãðëàÚê

ÊðêëÜ䗸íØàãØÙàãàëð ÄØåØÞÜäÜåë ÈÞéÚÈØäåڞ

¸ççãàÚØëàæå—ÄØççàåÞ

»àØÞåæêëàÚê ¿§ºº¡•£ÃÚ顕ÈÞÚ×Úáž

¶ÙâÞãÞèéçÖéÞäã ¶áÚçé蕕•¸äãÛÞÜêçÖéÞäã

¶êéäâÖéÞؕ¹ÞèØäëÚçî ¶ååáÞØÖéÞäã蕕•¾ãÛçÖèéçêØéêçÚ

ºãٕÊèÚç•ÂäãÞéäçÞãÜ ·êèÞãÚèè•ÅçäØÚè蕕•¸áÞÚãé•ÇÚÖá•ÊèÚç

¾ãÛçÖèéçêØéêçڕÂäãÞéäçÞãÜ ÈÞéÚÈØäåڕ•••¶ÙÖåéÚçè•é䕨ãٕÅÖçéÞÚè

»¼ÃÀͼÉЗÆÇËÀÆÅÊ ÄØåØÞÜۗÊÜéíàÚÜ

ºæäÙàåØëàæå

Obrázek 1 – Struktura modulárního řešení systému BAC

Àå¤ßæìêܗ»ÜçãæðäÜåë

Mercury SiteScope od společnosti Mercury nebo jeden z mnoha různých EMS systémů (Enterprise Management Systems) s využitím standardních konektorů, které jsou již vytvořeny a dodávány. Díky otevřenému rozhraní je možno data získávat z jakéhokoliv nástroje za předpokladu vytvoření příslušného konektoru. Zde rozlišujeme sledování bezagentové a agentové, (tj. měření, která využívají standardních služeb operačního systému nebo standardních utilit běžně dodávaných) a dále měření, která využívají své vlastní služby ke sběru potřebných dat – tzv. agenty. Agent je náhrada standardních služeb operačního systému a používá se tam, kde je třeba data sbírat velmi často, nebo na základě splnění určitých podmínek sběru dat. Systém BAC dále umožňuje dynamické propojení informací o aplikacích a informací z infrastruktury pomocí modulu Application Mapping (MAM). Modul MAM pravidelně vyhodnocuje komunikaci jednotlivých částí systému na úrovni protokolu a podle rozpoznaných částí a komponent aktualizuje vazbu mezi aplikacemi a infrastrukturou. Díky tomuto modulu máme neustále přehled o všech prvcích infrastruktury a jejich vlivu na aplikace (ať jsou vazby jakkoliv složité a nebo pokud se v čase mění). Pro sledování aplikací z pohledu uživatele jsou důležitější informace o době odezvy a o dostupnosti sledovaných systémů. Tyto informace jsou získávány třemi možnými způsoby:

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 8

A. Měření uživatelské akce přímo na klientském počítači, který je opatřen agentem Client Monitor (CM) sledujícím jednotlivé akce uživatele. Tento agent poslouchá na pozadí adresy, které uživatel prochází a podle nastavené adresy se aktivuje a začne měřit čas jednotlivých transakcí až do doby ukončení transakce. Jedna transakce má tedy pomocí parametrizace označen začátek a konec akce v aplikaci. Agent po dokončení každé transakce spočítá čas mezi začátkem a koncem akce a takto získaná data postupně zpracovává a v nastavených intervalech odesílá do Core Serveru BAC. Výhoda tohoto způsobu je opravdu reálný obraz o stavu aplikace z pohledu koncového uživatele. Nevýhodou může být nutnost instalace potřebného agenta na každý takovýto počítač. B. Druhý způsob sběru dat je měření doby odezvy na základě simulace uživatelských akcí generovaných agentem Business Process Monitor (BPM) pomocí parametrizovaných skriptů. Tento agent využívá stejné skripty jako Mercury LoadRunner pro generování zátěže aplikace. Pro vytváření a modifikace těchto skriptů je k dispozici sofistikovaný nástroj Virtual User Generator (VUgen). Po vytvoření potřebných skriptů a nahrání do datového profilu BAC serveru si tento skript jednotliví agenti BPM načtou a pak jsou příslušné skripty podle nastavení spouštěny. Jak často a z jakých lokalit (agentů) jsou vybrané skripty spouštěny je nastavitelné centrálně z hlavní konzoly BAC. Výhodou tohoto měření je možnost sledovat a vyhodnocovat měřené parametry i v době nečinnosti skutečných uživatelů, např. mimo pracovní dobu, a tak detekovat případné potíže dříve než je běžný uživatel zaregistruje. Nevýhodou je nutnost zvolit takové simulované akce, které dostatečně reprezentují určitou část práce uživatelů a zároveň nezpůsobí nežádoucí změny dat v produkčním systému. Je-li možné měřený systém nastavit tak, aby akce prováděné pomocí agentů BPM byly prováděny odděleným uživatelem a aby šlo tato data separovat od reálných provozních dat, pak můžeme mít simulovány i operace vytvářející nebo modifikující data. C. Třetí způsob sběru uživatelských odezev je použít analyzátor síťového provozu Real User Monitor (RUM), který dekóduje pakety a umožňuje sledovat doby odezev aplikace všech uživatelů pracujících v sledovaném systému, ale pouze na rozhraní síťového prvku před serverem a nikoliv přímo u jednotlivých koncových uživatelů. Modul RUM hlavně umožňuje sledovat všechny uživatele a zobrazovat tak celkový počet současně pracujících uživatelů a s těmito daty dále korelovat ostatní naměřená data. Díky tomu je pak možno vysledovat výkonnostní špičky a ty porovnat s počtem pracujících uživatelů nebo zjistit jiné podstatné souvislosti.

Měření doby odezev a zpracování dat Naměřené doby odezvy se odesílají do Core Services Serveru. Všechna naměřená data jsou zpracována a ukládána do datových profilů. Každý profil má své vlastní nastavení pro určení doby, jak dlouho se mají naměřená data uchovávat a s jakou periodicitou jsou v databázi uložena. V jednom profilu může být nastaveno podrobné ukládání dat s velkou periodicitou, ale krátkou dobou platnosti. Naopak v jiném

profilu může být nastavena doba uložení v řádu několika let, ale s menší periodicitou uložených dat – např. měsíční přehledy za poslední 3 roky. V takovémto profilu se vypočítají průměrné hodnoty potřebné k zobrazení měsíčního přehledu (jedna hodnota v grafu je průměr za několik hodin) a ty se uchovají v profilu. Ostatní podrobná data se odstraní. Tím je zajištěna jednoduchá správa nad naměřenými daty a jejich snadné zobrazení pomocí stejného pohledu jako zobrazení aktuálních podrobných dat. Nejen že jsou všechna data tímto způsobem spravována a ukládána, ale podle nastavení jednotlivých úrovní odezev jsou vyhodnoceny stavy pro jednotlivé transakce. Je tedy možno některým transakcím zadat „normální“ dobu odezvy v řádu jednotek sekund a časově náročnějším transakcím tuto dobu odezvy nastavit vyšší. Stejným způsobem jsou také nastavovány doby pro upozornění o zvýšené době odezvy a doby, při kterých je již hlášena chyba (špatná doba odezvy) nebo úplná nedostupnost měřené transakce. Informace o stavech těchto transakcí mohou být zobrazovány pomocí grafu ve formě histogramu a nebo jako stavová tabulka pomocí barevných semaforů. Každá transakce může zobrazovat doby odezvy a dostupnost jako okamžité stavy nebo agregované hodnoty za poslední čtvrthodinu (nebo jinou nastavenou dobu). Je pak velmi jednoduché pouhým jedním pohledem zjistit aktuální stav měřeného systému. Např. při dočasném zhoršení doby odezvy nebo krátkém výpadku může být aktuální doba odezvy ve stavu chyby (červená), agregovaná hodnota za poslední čtvrthodinu ve stavu upozornění (žlutá), hodnota dostupnosti je v normálním stavu (zelená) a agregovaná dostupnost je ve stavu upozornění (žlutá). Z tohoto příkladu je patrné, že daná aplikace (měřená transakce) má problémy s dobou odezvy, ale dostupnost je v tento okamžik v pořádku. Z agregovaných hodnot lze vyčíst špatnou dobu odezvy, která zatím netrvá déle než čtvrt hodiny, tudíž problém je právě aktuální (je potřeba ho řešit!). Situace s dostupností nám naopak napovídá, že dostupnost je v tento okamžik v pořádku, ale v poslední čtvrthodině bylo hlášeno varování k úrovni dostupnosti této transakce. Ke každé změně stavu je možno pro jednotlivé transakce nastavit možnost upozornění podle nastavených kritérií. Pomocí tohoto nastavení pak může být příslušná osoba informována emailem nebo SMS zprávou např. o každém varování a nebo pouze o vzniklé chybě, pokud tato chyba byla detekována např. více něž třikrát – možnosti konfigurace jsou velmi rozsáhlé. Na základě získaných dat je možno zobrazovat a rozesílat informace komukoliv podle jeho potřeb a odpovídajícího nastavení jednotlivých modulů BAC – jednotné zpracování dat pro všechny uživatele.

Modularita a vysoká dostupnost Do systému se přihlašují všichni uživatelé vzdáleně odkudkoliv pomocí webového prohlížeče. K přístupu do systému BAC není potřeba na klienty nic instalovat a proto je správa a používání systému BAC velmi snadná. Základ systému tvoří Core Services Server, který sbírá a ukládá získaná data, a Centers Server pro zpracování a zobrazování uložených dat. Všechna data se ukládají do databáze Oracle nebo MS SQL. Dále pak systém obsahuje samostatné části jako je Diagnostika (pro sledování J2EE nebo .NET aplikací) a tzv. Collectors – sběrače dat, tj. CM, BPM a RUM.

Systém BAC je modulární a skládá se ze základních částí systému a jednotlivých modulů (viz obrázek 1). Některé části vyžadují samostatný server, jiné mohou běžet jako služba na jednom ze společných serverů. Každý z datových sběračů doporučujeme instalovat na samostatný počítač. Základní princip je rozdělení celého systému na jeho elementární funkce, které se dají nainstalovat a provozovat odděleně. Core Services Server a Centers Server mohou být duplikovány pro zvýšení bezpečnosti a výkonnosti systému BAC – tzv. High Availability (HA) deployment. Pokud budeme zvětšovat rozsah monitorovaného systému a tím i zvyšovat množství měřených dat a počet datových sběračů, je vhodné do HA uspořádat Core Services server, který zajišťuje sběr a zpracování dat. Má-li tento systém být rychlý a stále dostupný pro větší počet uživatelů, je možno nasadit do HA uspořádání Centers Server, který je odpovědný za prezentování a obsluhu dat v systému BAC. S rostoucími požadavky a nároky na systém je možné ho stále rozšiřovat dle nových požadavků a potřeb.

Analýzy a reporty BAC zobrazuje on-line informace i dlouhodobé trendy. Podle nastavení lze generovat podrobné reporty a ty dle potřeby rozesílat – např. pravidelně jako součást týdenních nebo měsíčních výkazů. Reporty jsou vyhovující pro zpětné hodnocení určitého období. Jakým způsobem ale postupovat při vzniklém provozním problému, kdy nejsou z přednastavených pohledů a grafů jasně patrné souvislosti a vztahy mezi problematickými částmi? Modul Analytics nám dává možnost definovat vlastní grafy a zobrazovat jakékoliv závislosti různých metrik, které nás mohou zajímat. Bez tohoto nástroje můžeme mít v databázi spoustu důležitých dat, ale nedokážeme z nich jednoduše získat maximum informací. Pomocí tohoto nástroje pak můžeme snadno a rychle vysledovat potřebné vztahy mezi veličinami – s touto informací je pak následně jednodušší vyřešit vzniklé potíže a odstranit provozní problém. Využijeme-li maximální množství dostupných informací, můžeme značně zkrátit dobu potřebnou k vyřešení a odstranění vzniklých problémů.

Obrázek 2 – Ukázka modulu Service Level Management

Sledování dodržování kvality služeb (Service Level Agreement, SLA) Specifikovat podmínky „dohody o úrovni poskytované služby“ je vždy velmi obtížné. Máme-li již k dispozici naměřená data, můžeme definovat kvalitu jednotlivých služeb (SLA) a na jejich základě tuto kvalitu sledovat a vyhodnocovat. V systému BAC je správa SLA řešena modulem Service Level Management (SLM), který umožňuje definovat jakoukoliv službu v IT a nastavit jí požadované mezní parametry, které požadujeme aby dodavatel garantoval odběrateli. Dodavatelské SLA slouží k ověření kvality služby a dodržení smluvních garancí ze strany dodavatele. SLM lze s úspěchem využít ke sledování kvality IT služby dodávané vnitřnímu zákazníkovi. Dává nám kontrolní aparát pro přehled o námi dodávané službě a také pro řízení a vylepšování kvality vlastní služby. Každá služba v SLM může zahrnovat jak metriky systémových parametrů (např. dostupnost databáze nebo webového serveru), tak i uživatelské metriky jako dostupnost konkrétní aplikace nebo doby její odezvy. Tímto nastavením je možno jednoduše definovat potřebné cíle sledovaných služeb a snadno evidovat, kdy byly tyto cíle naplněny a kdy nebyly dodrženy. Systém umožňuje rozlišovat, jaký finanční dopad by mělo (má) nedodržení konkrétních služeb SLA, a podle toho přiřadit jednotlivým problémům různé priority dle závažnosti.

Výhody a přínosy Z hlediska jednoduchosti správy monitorování a dostupnosti všech potřebných dat v jednotném prostředí je použití tohoto nástroje velmi snadné a efektivní. Díky definovaným rolím a webovému přístupu jsou komukoliv (s příslušnými právy) a odkudkoliv přístupná všechna potřebná data relevantní pro konkrétního uživatele. V porovnání s jinými nástroji umožňuje plně integrované řešení Mercury Business Availability Center snadno a efektivně pracovat jednotným způsobem se všemi získanými daty. Tím usnadní a zrychlí práci pracovníků zabývajících se monitorováním, místo aby jim složitost a nepřehlednost několika různých nástrojů ztěžovaly a znepříjemňovaly každodenní práci. Volba monitorovacího nástroje pro efektivní monitorování produkčních systémů je závislá na vašem očekávání a požadavcích, ale i když jsme zde ukázali možnosti monitorování pomocí řešení Mercury Business Availability Center, doporučujeme vybrat takové řešení a nástroje, které Vám zjednoduší práci v oblasti monitorování, splní Vaše očekávání a přinesou požadované výsledky.

9

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

Virtuální stroje a jejich možnosti Pryč jsou doby, kdy důkladné otestování určité konfigurace a spolupráce operačních systémů či aplikací vyžadovalo zapůjčení či koupi hardwaru ve větším rozsahu. Technologie pro simulování počítačů třídy PC výrazně pokročila vpřed a dozrála do podoby, jež uspokojí i velmi náročné uživatele či nekompromisní znalce. Myšlenka virtualizace hardwaru vychází z principu vytvoření oddělených virtuálních prostorů tzv. virtuálních strojů (VS), které simulují virtuální hardware sdílející fyzický hardware serveru. Pomocí této technologie lze vytvořit více VS na jednom fyzickém počítači. V případě nekorektní aplikace (a např. jejím pádu, který by měl za následek zatuhnutí celého serveru) je zasažen pouze odpovídající virtuální server, ostatní pracují bez ovlivnění dál. Virtuálnímu počítači je možné přidělit i hardware, který fyzicky není přítomen, jako je např. SCSI řadič disku nebo síťová karta. Přidělit lze také několik optických mechanik, a to jak fyzicky přítomných, tak virtuálních v podobě připojení obrazu CD uloženého na pevném disku hostitelského počítače. Nastavení sítě je dalším krokem, který umožní komunikaci virtuálního stroje s hostitelským operačním systémem a samozřejmě také okolním světem. Mezi základní vlastnosti VS patří: • Možnost instalace několika nezávislých a autonomních virtuálních strojů (chová se jako fyzický počítač připojený v síti) na jeden HW a možnost jejich současného běhu. • Sdílení VS v síti: UNIX běžnými prostředky (terminál, xwin), Windows přes prostředky typu VNC nebo remote desktop. • Jednoduchá instalace (klonování) v podstatě pouhým překopírováním souborů virtuálního disku; zálohování je také možné řešit pouhou archivací souborů VS. • Možnost návratu k předchozímu definovanému funkčnímu stavu, ať už prostřednictvím tzv. snapshots (VSW), funkcí UNDO nebo prostou zálohou souborů VS; velmi výhodné např. při bádání nad opakovaně neúspěšnými instalacemi některých produktů, testování časově omezených instalací (demo verze) apod.

V úvahu v podstatě připadají dva dodavatelé produktů pro VS – Microsoft a VMware. VMware má v této oblasti několikaleté zkušenosti, Microsoft to vyřešil nákupem technologie od Connectixu. Microsoft Microsoft Virtual PC 2004 – jedná se spíše o desktopovou aplikaci, která obsahuje výkonnostní a funkční omezení, např. není k dispozici rozhraní SCSI, je omezen počet IDE disků na tři, atd. Microsoft Virtual Server 2005 – je k dispozici ve verzi Standard a Enterprise Edition, je schopen využít až 32 procesorů na hostitelském serveru. Pro ilustraci uvádíme některé jeho vlastnosti: • Podporuje přidělování prostředků CPU pomocí metod různých vah a omezení procesů. • Umožňuje nezávislé přidělování paměti jednotlivým virtuálním počítačům. • Poskytuje komplexní rozhraní COM API, které umožňuje kompletní řízení prostředí virtuálních počítačů pomocí skriptů. • Zapouzdřuje virtuální počítače do snadno přenositelných virtuálních pevných disků (Virtual Hard Disk, VHD), které umožňují pružné konfigurace, správu verzí a zavádění. • Umožňuje provozování virtuálních sítí pro zabezpečenější a pružnější možnosti síťových služeb typu host-host, host-hostitel a host-síť. • Obsahuje webovou konzolu pro zabezpečenější správu, ověřování a vzdálený klientský přístup. • Integruje adresářovou službu Active Directory, a umožňuje tak delegování správy a ověřování přístupu hostů. • Podporuje stávající nástroje pro správu serverů, které je tak možné používat i pro správu virtuálních počítačů (Microsoft Operations Manager 2005, Systems Management Server 2003). Microsoft nabízí nástroj Virtual Server Migration Tool pro převod stávajícího (běžícího) stroje na virtuální. VMware disponuje podobným nástrojem už dávno. VMware VMware Workstation – desktopový produkt pro VS, platforma Windows a Linux, několikaletá

5 let – čas k ohlédnutí Je to právě skoro na měsíc přesně 5 let, co jedna z největších a nejvýznamnějších bank na Slovensku Tatra banka, a.s. (člen RZB Group) začala používat řešení Mercury Interactive pro testování software dodané společností KOMIX s.r.o. Zeptali jsme dvou dam: Lenky Šalfalviové, vedoucí oddělení systémového testování a referátu řízení testů (LŠ) a Zuzany Ondrušové, vedoucí referátu technologického testování (ZO), jak uplynulou pětiletku hodnotí. ZO: Dovolím si zhodnotiť posledné 4 roky. J Máme za sebou dlhú a dúfam, že aj úspešnú cestu. Vydali sme sa na ňu s výbornými nástrojmi a takmer nulovými skúsenosťami. Momentálne máme výborné nástroje aj skúsenosti, vlastnú metodiku a dobré vzťahy s firmou KOMIX. Dodávame kvalitné otestované aplikácie a naši testeri sú skutoční odborníci a nielen v oblasti testovania. Můžete nám prozradit, jak „tehdy“ a proč právě tehdy vzniklo rozhodnutí nasadit softwarovou podporu testování v Tatra bance? S Y2k to asi nesouviselo, to bychom měli nejméně rok zpoždění... LŠ: Testovanie bolo v tom čase robené iba s minimálnou SW podporou. Interne sme testy

10

tradice, bohaté konfigurační možnosti. Aktuální verze 5 (3Q2005), podrobnosti na http://www. vmware.com/. Serverové produkty: VMware GSX Server, VMware ESX Server ESX server operuje přímo na fyzickém HW, čímž odpadá režie klasického OS, VS provozované pod ESX srv. se blíží výkonu fyzických serverů s identickou konfigurací (úbytek výkonu oproti fyzickému HW je cca 5 %).

Další (podpůrné) produkty: VMware Virtual SMP – rozšíření pro VMware ESX Server 2, které umožňuje, aby jeden virtuální stroj mohl využívat více fyzických procesorů (symetrický multiprocessing pro Intel-based VS) VMware ACE – Assured Computing Environment for the Enterprise – konfigurace zabezpečení a přístupových práv desktopů prostřednictvím Virtual Rights Management VMware podporuje na rozdíl od MS VS&VPC i non Windows OS. Firmy jako např. IBM, HP, Unisys atd. jsou partnerem VMware a certifikují své servery pro použití s VMware. Velká řada klientů konsolidovala své servery na bázi VMware u nás i ve světě, VMware používají např. SAP, Symantec, Lockheed Martin, Merril Lynch apod. Výhody Nasazení VS Lepší využití HW – většina aplikací (databáze, web server, aplikační server, různé služby) nevyužívá HW zdroje po celý čas na 100%, spíše naopak, nárazově. Umístění více VS na jeden fyzický server vede k jeho intenzivnějšímu využití a rozložení zátěže v čase. Při plánované extrémní zátěži je ovšem nutná domluva mezi vývojovými týmy, které používají jednotlivé VS. Za zmínku stojí také jednoduché přidělování systémových zdrojů: lze libovolně přidávat/odebírat volnou fyzickou paměť podle aktuální potřeby nebo dokonce pozastavit/vypnout momentálně nepotřebný virtuální server, aby uvolnil prostředky ostatním. Flexibilita použití hostovaných OS – v podstatě odpadá nutnost instalace, stačí překopírování čistých image souborů daného OS, který

T

Ě

I

T

je tak rychle připraven k použití. Doba restartu virtuálního stroje bývá o hodně kratší než u fyzického HW a hlavně restartuji pouze svůj vlastní VS. Oproti např. dual-bootu, kdy mám na harddisku několik diskových oddílů s různými OS, VS mohou běžet současně, síťově spolu komunikovat a restart jednoho neovlivňuje ostatní VS. Havárie dual-bootu mívá často kritické následky pro instalované operační systémy. Při technické podpoře programů na různé platformy OS u zákazníka (Win95, Win98, Win95SE, WinME, WinNT4.0 atd.) není třeba udržovat tyto OS fyzicky nainstalované na zvláštních počítačích (případně v dual-bootech), ale stačí mít archivován příslušný virtuální stroj a v případě potřeby ho uvést v činnost. Široké možnosti konfigurace síťových a záznamových zařízení – práce až se čtyřmi síťovými kartami v různých režimech (HOST, Bridge, native), což může být výhodné při testování různých firewalových řešení, demilitarizovaných zón, návrhu zabezpečené síťové infrastruktury apod. Samozřejmostí je podpora kromě sběrnice IDE i SCSI, což nabízí značnou volnost při konfiguraci a testování různých druhů diskových polí. Prezentace vícevrstvých řešení zákazníkům – s využitím VS si při prezentaci (často na půdě zákazníka) vystačíme s jedním nebo dvěma silnějšími notebooky s dostatkem paměti, kde se dají virtualizovat další počítače a přesvědčivě tak demonstrovat nabízené řešení; virtuální disky s prezentovaným řešením se pak dají snadno zazálohovat pro opakované použití.

Závěr Záměrem článku bylo seznámit čtenáře s možnostmi a výhodami virtualizace hardware PC. Díky dlouholetému vývoji má tato technologie odborné IT veřejnosti rozhodně co nabídnout. Samozřejmě je třeba mít na paměti, že v některých oblastech je nasazení VS nevhodné, např. při zátěžovém testování aplikací nebo při snaze o minimalizaci licenčních poplatků za provozované OS. V ostatních případech však mohou být VS velkým přínosem.

Dan Petřivalský, [email protected] ponúkaná technická podpora, zaškolenie pracovníkov, podiel na trhu a referencie.

ZO: Bankový sektor zažíval svoju renesanciu. Tatra banka bola vždy priekopníkom pri zavádzaní nových technológií a patria jej mnohé prvenstvá v bankovom biznise. Dynamický vývoj nových produktov, priblíženie sa ku klientom prostredníctvom elektronického bankovníctva a množstvo aktivít IT odboru, si vyžiadal prirodzenú potrebu automatizácie procesu testovania. Veď pozitívnu image banky určuje nielen množstvo pobočiek a produktov, ale aj ich kvalita a dostupnosť.

ZO: Evidencia testovania bola reprezentovaná v rámci internej databázy: ako dátum začiatku a konca testov, zoznamu zúčastnených testerov a richtextového poľa pre poznámky na/z testovania. Testovanie bolo intuitívne a scenár často udával programátor. Automatizované testovanie takmer neexistovalo. Automatizéri písali krátke skripty v ľubovolnom skriptovacom jazyku v závislosti od testovanej platformy. Skripty si uchovávali na lokálnych PC... Začínali sme s kratučkými skriptami s minimálnou logikou, postupne sme nabaľovali komplexnú funkcionalitu, pokrývajúcu kompletný workflow, a možné kontroly. Dnes sa vraciame k „batchovkám“, máme vlastné knižnice najčastejšie využívaných funkcií a implementujeme štandardy.

LŠ: Mali ste lepšiu prezentáciu a ponúkli ste nižšiu cenu. J Vami ponúkané riešenie lepšie spĺňalo naše požiadavky: Kritériami hodnotenia boli – pokrytie/automatizácia procesu testovania, práca a integrácia nástrojov, hardvérové nároky, licenčná politika, skúsenosti z realizovaných projektov,

Ě

Jan Krejčí, [email protected]

evidovali vo formulároch, ktoré prioritne slúžili na zber business požiadaviek a nie na evidenciu testovania. Vtedy to bolo jediné riešenie, ktoré sme poznali. Rozsiahly vývoj v tom čase však vyvolal tlak na výber testovacieho nástroja.

Proč jste tehdy vybrali právě naše řešení (TestDirector a WinRunner od Mercury Interactive)?

V

Jak vlastně vypadalo testování softwaru v Tatra bance do té doby?

Jaká byla vaše očekávání přínosů nasazení testovacích nástrojů? ZO: Z pohľadu riadenia procesu testovania sme požadovali on-line informácie o stave testovania formou (štatistických) prehľadov

vytvorených z jednotlivých modulov TD, možnosť generovať kvalitnú dokumentáciu. Táto funkcionalita bola požadovaná od projekt manažérov a vedúcich testerov. Pre testerov bola dôležitá jednoduchá a prehľadná evidencia vytvorených a vykonávaných testov z cieľom budovať znalostnú bázu testov, testovacích prípadov či vytvoriť testovacie sady regresných testov. Neoceniteľnou pomocou je implementovaný manažment chýb od zistenia chyby až po jej odstránenie. Automatizáciou opakujúcich sa postupov testov sme sa snažili pokryť veľké množstvá testovacích prípadov, odbremeniť testerov od rutinnej práce a zvýšiť kvalitu vykonávaných testov. Do jaké míry se vaše očekávání naplnila? ZO: Systém prináša výsledky, keď sa používa a navyše keď sa používa podľa dohodnutých pravidiel. Myslím si, že v tomto ohľade boli automatizéri vždy o krok vpred oproti manuálnemu testu, čo vyplýva aj z prirodzenej náklonnosti k novým technológiam a nutnosti evidencie vytvorených skriptov. Dnes však s istotou viem povedať, že rozhodnutie pre TestDirector, sa stalo jednou z množstva konkurenčných výhod Tatra banky.

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 10

Jak bylo obtížné a co obnášelo vytvořit metodiku pro řízení testování a automatizované testy? ZO: Vytvoriť metodiku je jedna vec, zaviesť ju medzi ľudí druhá. Aktivita obnášala hodiny práce, presviedčania a trpezlivosti. V TB sme mali vytvorenú metodiku SW vývoja, ktorá však nebola plne zimplementovaná do praktického života. Naše oddelenie si uvedomilo potrebu nájsť spoločnú cestu od vzdelávania nových pracovníkov až po reálne vykonávanie práce – ňou bola najprv teoretická časť Metodika testovania, neskôr sme ju rozšírili o praktické časti Metodika zaznamenávania procesu testovania do TestDirectora a Štandardy automatizovaného testovania. Vyžiadalo si to vyčlenenie metodického tímu, štúdium literatúry, konečne využitie existujúceho know-how. TD sám o sebe má už v sebe zimplementovaný proces testovania, ktorý sme rozšírili o vlastné špecifiká. Myslíte, že vaše metodika testování je snadno přenositelná kamkoliv jinam, nebo alespoň do jiné banky, resp. je možné vytvořit dostatečně univerzální metodiku testování vhodnou pro jakoukoliv organizaci?

ZO: Dovolím si tvrdiť, že naša metodika je dostatočne univerzálna. Ide o otvorený dokument, ktorý vychádza z teórie testovania, z riadenia projektov a z metodológie UML. Nevymýšľame koleso – poučili sme sa z histórie a pozeráme sa dopredu. Jak jsou s TestDirectorem a WinRunnerem spokojeni vlastní uživatelé, jaké jsou jejich názory? Do jaké míry by jim vadilo vrátit se do stavu před nasazením nástrojů? ZO: Nestrašte! TestDirector sa stal neoceniteľnou a nutnou súčasťou našej práce! Základňa používateľov TD sa v našej banke rozširuje, pomer nadšených užívateľov narastá aj vďaka novým metodickým postupom založeným na best practices. Doba, kedy sa dokumentácia zdala byť zbytočnou administratívou, je už našťastie za nami. Najlepším liekom na reptajúcich členov je zverenie riadenia testovania projektu práve do ich rúk. Práve vtedy sami veľmi radi siahnu a trvajú na používaní TD. Pri dynamike dnešného vývoja, rastu náročnosti aplikácií, skracovaní času od zadania po implementáciu aplikácie, nie je v ľudských silách fungovať s Outlookom, Wordom či Excelom.

Jaké je vaše hodnocení obou nástrojů z pohledu „šéfek testování“? Myslím hodnocení jejich manažerských přínosů. LŠ: TD poskytuje jednoduché ale zároveň jasné a prehľadné reporty a grafy o vykonávaných testoch, detekovaných chybách, chybovosti programátorov ale aj výkonnosti testerov a kvality testovacích prípadov. Tieto informácie slúžia ako podklad pre hodnotenie jednotlivých členov nášho tímu, ale aj ako výstupy z fázy testovania ako súčasť projektovej dokumentácie. ZO: Ako vedúca referátu oceňujem rast kvality testovania, TD mi poskytuje informácie o stave a pokrytí požiadaviek na test, informácie o výkonnosti jednotlivých členov tímu a evidenciu chybovosti dodávaných aplikácií. Máte představu kolik celkem testů máte uloženo v TestDirectoru a kolik skriptů pro WinRunner udržujete? ZO: Predstavu?! Vieme to presne v akomkoľvek momente pre každý projekt – chcete to vo forme tabuľkového alebo grafického reportu z TD? Napr. pre projekt elektronického bankovníctva ide o 808 testov v pomere 494:314 pre manuálne a automatizované skripty. Polovica

automatizovaných skriptov je v tomto momente v stave Ready. Jaké jsou vaše plány do budoucna v rozvoji testování v Tatra bance? LŠ: Najbližší plán je upgrade na TestDirector 8.2 for Quality Center. Následne môžeme uskutočniť dlho plánované „upratovanie“ vytvorených projektov v TD a revíziu testovacích prípadov. Počas piatich rokov aktívneho používania TD bez zavedenej metodiky sme dospeli do štádia, kedy sa pôvodne navrhnutá štruktúra projektov a adresárov stáva neprehľadnou a komplikovanou. Upgrade a zavedenie metodiky zaznamenávania procesu testovania do TD považujeme za ten správny impulz na revíziu. ZO: Rozšírením tímu automatizérov chceme zvýšiť podiel automatizovaných funkčných testov, zaviesť unit testy a rozbehnúť záťažové testovanie. Děkuji za rozhovor a těším se na další spolupráci.

Plug-in pro správu požadavků a sledování postupu vývoje Každý, kdo musí spravovat požadavky na vývoj informačního systému, řešil problém, jaký nástroj k tomu použít. V KOMIXu jsme zvolili cestu vývoje vlastního pluginu do UML nástroje MagicDraw. V tomto článku se seznámíte s UML extension mechanismem (tj. s možnostmi rozšíření UML modelu) a s pluginem ExtendIX, který těchto možností využívá. Plugin najde uplatnění nejen při správě požadavků, ale i při plánování a sledování postupu vývoje, odhadování pracnosti a při přípravě testů. V závěru najdete informace o tom, jak plugin získat.

l›—ˆ‘‡p ‰’•êyˆ”˜Œ•ˆˆ‘—–

• Spreadsheet (Excel) Požadavky je možné třídit a filtrovat. Můžete si zobrazit např. všechny požadavky plánované pro etapu 2 setříděné podle priority s uvedením autora a stupně složitosti. Spreadsheet je také možné kombinovat s word procesorem (např. pomocí html odkazů). Nehodí se pro větší projekty, vyžaduje poměrně komplikovanou ruční práci.

• Vlastní nástroj Tato kategorie bývá někdy označována jako „homegrown tool“. Jedná se o vlastní aplikaci založenou zpravidla na databázi. Umožňuje třídit, filtrovat, provazovat požadavky. Nevýhodou může být obtížná adaptovatelnost na nový projekt, protože podobné aplikace bývají vytvořeny často na míru konkrétnímu projektu a rychle zastarávají. Problémem zůstává provázanost s UML nástrojem, pokud integrace není přímo součást řešení takovéhoto nástroje.

• Specializovaný komerční nástroj

Problém

L

V KOMIXu jsme hledali náhradu specializovaného nástroje pro správu požadavků DOORS firmy Telelogic. Hlavním důvodem byly licenční poplatky. Druhým důvodem byla možnost přímé integrace s UML nástrojem (v našem případě MagicDraw od firmy NoMagic), ve kterém jsou vytvářeny modely používané v průběhu vývoje softwaru již od fáze specifikace požadavků. Naší snahou je vždy dělat věci jen jednou a co nejjednodušeji, bez nutnosti ručního kopírování a propojování. Obecně se při správě požadavků nabízí tyto možnosti: • Word processor (Word) Snadné formátování, výsledek je přímo součást dokumentace projednávané se zákazníkem, možnost zaznamenávat změny pomocí revizí. Nevýhodou je nemožnost požadavky třídit, filtrovat, obtížné je zajistit trasovatelnost do dalších fázích vývoje.

Nástroj kategorie RM tool (Requirements management tool). Hlavním problémem bývá vyšší cena a licenční poplatky. Specializovaný nástroj se určitě uplatní na skutečně velkých projektech, u menších projektů ale zbytečně zvyšuje náklady. Dalším problémem může být integrace s konkrétním UML nástrojem, který používáte pro vývoj. Možná jste řešili podobný problém a dokázali by jste popsat i další varianty.

ní komponent, možnost „undo“ atd. a můžeme se soustředit na požadovanou funkcionalitu. Další velkou výhodou je integrace správy požadavků přímo do UML nástroje používaného při vývoji. Díky tomu není nutné řešit synchronizaci s jinými specializovanými nástroji. Snadno můžeme uplatnit use case driven přístup při vývoji softwaru, kdy funkční požadavky jsou zaznamenány formou use case modelu a use case jsou potom sjednocujícím pohledem na vyvíjený systém pro všechny zúčastněné strany a profese tj. pro zákazníka, analytika, designera, testera i vedoucího projektu. Nevýhodou se může zdát závislost na konkrétním UML nástroji. MagicDraw jako svůj formát uložení modelu používá standardní XMI. Ani plugin nezavádí žádný vlastní formát uložení dat. Veškeré informace se kterými pracuje plugin jsou popisovány standardně v UML (nemusí se však vždy jednat o grafické zobrazení, zvláště u požadavků je primární text) a jsou ukládány ve standardním formátu XMI v rámci projektu, takže s těmito daty je možné pracovat i v jiných UML nástrojích podporujících XMI (což jsou snad všechny). Jedná se o plugin, nikoli o samostatnou aplikaci ukládající data ve formátu XMI, MagicDraw je proto nutná součást tohoto řešení. Nevýhodu závislosti na MagicDraw lze proměnit ve výhodu: plugin nabízíme i ostatním uživatelům MagicDraw. Plugin dostal jméno ExtendIX podle UML extension mechanism. Na vysvětlení tohoto pojmu se blíže podíváme v následující kapitole.

Řešení: plug-in Zvažovali jsme různé možnosti, především vývoj vlastního nástroje s parametry blízkými komerčním specializovaným nástrojům. Nakonec jsme se rozhodli využít možností UML nástroje MagicDraw a s pomocí jeho Open API vytvořit plug-in splňující naše požadavky (přesněji naše metapožadavky = požadavky na správu požadavků). Výhodou tohoto řešení z hlediska pracnosti vlastního vývoje je především využití infrastruktury poskytované UML nástrojem: nemusíme řešit autentizaci a autorizaci, bezpečné ukládání dat ve standardním formátu XMI, práci v týmu a zamyká-

Teorie: UML extension mechanism UML (Unified Modeling Language) je nejvíce rozšířený standard pro modelování informačních systémů. Je poměrně obecný, umožňuje však taková rozšíření a přizpůsobení, že dokáže popsat i specifickou problémovou oblast, kde s obecnými elementy UML nevystačíme. OMG (Object Managament Group) definuje dvě možnosti jak definovat jazyk specifický pro určitou problémovou oblast: 1. Definovat nový jazyk jako alternativu k UML a to za použití MOF (Meta Object Facility) což

Tomáš Vahalík, [email protected]

je meta jazyk pro definici objektově orientovaných modelovacích jazyků. Pomocí MOF je definován například UML, CWM (Common Warehouse Model), ale i MOF sám. 2. Poněkud šetrnější možností je specializace elementů a doplnění různých omezení při zachování původního významu UML elementů. Pro tyto případy poskytuje UML extension mechanismus: stereotypy, tagged values, constraints. Všechna tato přizpůsobení jsou seskupena do UML Profilů. Obě varianty mají své výhody a nevýhody. Velkou výhodou druhé varianty, tedy použití Profilů, je ale skutečnost, že narozdíl od první varianty, lze využít komerční UML nástroje pro modelování. Profily je možno využít nejen pro specifické problémové oblasti, ale i pro přizpůsobení UML modelu různým implementačním platformám (J2EE, .NET) tedy podle přístupu MDA (Model Driven Architecture) při transformacích mezi modely a při transformaci modelu do kódu. Profily byly definovány již ve verzi UML 1.1. Ve verzi UML 2.0 je několik vylepšení a vyjasnění. Dále uvedené specifikace se týkají UML 2.0.

Profile Profil obsahuje sadu extension mechanismů (stereotypes, tagged values, constraints), které jsou seskupeny do package se stereotypem <<profile>>. Existuje několik profilů standardizovaných OMG, další byly definovány organizacemi a softwarovými firmami (např. UML/EJB Mapping Specification). Další profily jsou součástí UML nástrojů (RUP Extensions Profile, UseCase Description Profile).

K

Stereotype

Stereotyp je druh meta-třídy, která rozšiřuje jiné metatřídy (definuje se tedy nikoli rozšíření např. pro modelovanou třídu Osoba, ale definuje možná rozšíření například pro Class, UseCase, Association, ...). Na diagramech se zobrazuje ve dvojitých lomených závorkách nad názvem elementu. Stereotyp může změnit grafické znázornění modelovaných elementů. Například v robustness diagramech třídy stereotypu <> mají

11

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

pokračování ze strany 11

jiné znázornění než třídy stereotypu <<entity>>. Můžete například definovat stereotyp <<externí systém>> pro meta-třídu Actor, instance s tímto stereotypem budou zobrazovány nikoli jako panáček, ale např. jako počítač.

Pří vývoji softwaru je však vhodné mít celkový přehled. Například při plánování a sledování postupu vývoje chceme zobrazit tabulku, kde je název use case, jejich autora, prioritu a stupeň složitosti, stav realizace, setřídit podle priority a filtrovat jen use case plánované do druhé etapy projektu. Následující obrázek ukazuje náš dříve použitý jednoduchý příklad tak, jak je zobrazen v ExtendIXu. Výhodou je nejen přehledné zobrazení, ale i možnost při tomto tabulkovém zobrazení nastavovat hodnoty sloupců odpovídající tagged values. V příkladu není uveden textový popis use case, který odpovídá formulaci funkčního požadavku. Můžete si však nechat zobrazit další sloupec Documentation, potom text požadavku uvidíte.

<>

Send Credit {Status=Approved, Author=Novák Priority=2 Above normal}

Constraint Constraints neboli Omezení mohou být asociovány se stereotypy a tím přesněji definovat pravidla pro modelované elementy rozšířené stereotypem. Constraint může být vyjádřen v přirozeném jazyce nebo v OCL (Object Constraint Language), což je součást UML. Pojmenování „Constraint“ v názvu jazyka pochází z jeho první verze, OCL 2.0 se vyvinul do bohatého jazyka, jehož vyjadřovací možnosti jsou srovnávány s SQL. Constraint se znázorňuje ve složených závorkách.

<>

Pay Refund Credit manager

{Status=New, Priority=4 Below normal, Author=Polák}

Obrázek 2

Tagged value Tagged value (někdy překládané jako Označené hodnoty nebo Příznaky) jsou přidané meta-atributy k meta-třídě. Tagged value je vždy dvojice jméno a typ a jsou přidruženy k určitému stereotypu. Typem může být i Enumeration, což je druh datového typu, který definuje výčet přípustných hodnot nazvaný Enumeration literals. Graficky jsou tagged values znázorněny jako atributy třídy, která definuje stereotyp, u modelovaného elementu jsou zobrazeny ve složených závorkách.

Obrázek 4

ExtendIX plugin umožňuje práci s extension elementy (stereotypy, tagged values, constraints) v tabulkové formě. Klíčové místo zde mají především tagged values, které fungují jako uživatelsky definované atributy. Tyto atributy nemusíte vždy definovat znovu – můžete využít tagged values definované v profilech, které jsou součástí MagicDraw (např. UseCase Description Profile) nebo využít Requirements Profile, který je součástí instalace pluginu. Nebo můžete vyrobit profil sobě na míru. ExtendIX najde uplatnění nejen při správě požadavků, ale i při plánování a sledování postupu vývoje, odhadování pracnosti, přípravě testů – vždy když potřebujete filtrovat a třídit informace spojené s modelovanými elementy, vytvářet různé pohledy, definovat vlastní atributy. A to vše bez nutnosti exportování a importování do jiného nástroje. Obrázek 5 ukazuje okno pluginu a naznačuje hlavní funkcionalitu. Náhled na data (view) lze ukládat a vytvářet reporty v různých formátech včetně možnosti exportu do Excelu. Tímto způsobem je možné exportovat data například do Mercury TestDirector – pokud přece jen dáte přednost specializovaným nástrojům.

Ve verzi UML 1.3 mohly tagged values rozšířit element modelu bez toho, aby byly součástí stereotypu. V UML 1.4 byla tato možnost podporována pouze kvůli zpětné kompatibilitě. Ve verzi UML 2.0 může být tagged value reprezentována pouze jako atribut definovaný na stereotypu. V těchto případech ale může UML nástroj automaticky definovat stereotyp pro samostatné tagged values, aby byla zachována zpětná kompatibilita.

Příklad Následující obrázek ukazuje definici profilu. Use case může být označen stereotypem <>, v tom případě je možné k takovému use case definovat hodnoty k tagged values Author, Priority, Status. Jsou předdefinovány přípustné hodnoty pro Prioritu a Status. Tento profil může být použit v libovolném projektu.

Download Obrázek 3

<<profile>>

Requirements Profile <<stereotype>>

Functional Requirement [UseCase]

Tags Author : String[1] Priority : PriorityEnumeration [1] Status : StatusEnumeration [1]

Constraints {Functional Requirement can be associated (extend, include) with other Functional Requirement use case only. }

V projektu, který používá takovýto profil, mohou být potom konkrétní use case označeny stereotypem <> a mohou být definovány jejich Tagged Values. Obrázek 2 ukazuje příklad dvou use case. Zobrazení stereotypu i zobrazení tagged values lze potlačit, aby diagram zůstal přehledným.

Define filter

Select columns

Produkt: ExtendIX UML nástroje včetně MagicDraw umožňují definovat a upravovat profily – to nebylo cílem pluginu ExtendIX. Nevýhodou UML nástrojů je omezený pohled na tagged values pouze přes jeden vybraný element – viz příklad pro use case Send Credit na obrázku 3.

Switch filter on/off

Define sorting

Switch sorting on/off

Reference: Jim Heumann: Writing good requirements is a lot like writing good code http://www-106.ibm.com/developerworks/ratio nal/library/5170.html Lidia Fuentes and Antonio Vallecillo : An Introduction to UML Profiles se2c.uni.lu/tiki/se2c-bib_download.php?id=1421

Display details switch on/off

Display level

Save view

Collapse rows

<<enumeration>>

PriorityEnumeration 1 High 2 Above normal 3 Normal 4 Below normal 5 Low

<<enumeration>>

J

Plugin je k dispozici ke stažení na našich internetových stránkách www.komix.cz.

Select view

StatusEnumeration Expand rows

Approved New Under construction

Display tree switch on/off

Obrázek 1

Poznámka: Zde v příkladu výše uvedený Requirements Profile není totožný s profilem, který využívá ExtendIX, to by bylo moc jednoduché. Tree

12

Table view

Change value

Obrázek 5

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

Nové vlastnosti analytických reportovacích nástrojů Microstrategy 8 a MS SQL 2000 Reporting services Jan Krejčí, [email protected] Cílem tohoto článku je seznámit čtenáře s reportovacími možnostmi dvou nástrojů pro Business Intelligence (BI), které jsou ve firemním portfoliu, a to Microsoft Reporting Services a MicroStrategy 8. Hovoříme-li obecně o BI, máme na mysli ucelený a efektivní přístup k práci s podnikovými daty, který má vliv na správnost strategických rozhodnutí, a tím i na obchodní úspěch společnosti. V současném vysoce konkurenčním prostředí představuje informovanost jednu z hlavních konkurenčních výhod. Tato výhoda spočívá ve schopnosti efektivně využít data nashromážděná ve firmách k tvorbě informací a znalostí, na základě kterých můžeme reagovat na rychle se měnící požadavky trhu a našich zákazníků. Základem Business Intelligence je přetváření zdrojových (zpravidla transakčních) dat na znalosti, s pomocí nichž jsou následně přijímána správná rozhodnutí. V rámci tohoto procesu jsou data čištěna, integrována, transformována (tzv. ETL proces – extract, transform and load) do využitelné podoby a následně analyzována, případně dále zpracovávána. Business intelligence poskytuje mechanizmus zajišťující doručení správné informace správné osobě ve správný čas a jako takový je základním kamenem procesu vytváření a distribuce komplexních informací. Analytické možnosti pak představují určitou nadstavbu, která umožňuje prostřednictvím predikce, modelování nebo simulace odhalit skryté souvislosti. Složitou problematiku procesů ETL a „inteligentního“ skladování dat přenecháme jiným článkům, které se tímto tématem i zde na stránkách KOMIXových novin již zabývaly a podívejme se spíše na analýzu a prezentaci dat. Vytvořit report není v dnešní době žádný problém. Existuje řada reportovacích nástrojů, obecných či integrovaných v různých aplikacích. Report si často může vytvořit i koncový uživatel. Mít na starosti reportovací systém ve firmě (jakkoli velké) se však může stát noční můrou. Reporty se vytvářejí různými nástroji či aplikacemi, které mají různé vyjadřovací prostředky. Reporty je nutné upravovat podle požadavků různých uživatelů a zabezpečit je před neoprávněným použitím. Je potřeba sledovat výkonnost systémů, „citlivě“ spouštět náročné reporty, sledovat, které reporty se používají. Někdy je nutné i reporty automatizovaně vytvářet a odesílat některým uživatelům a při té příležitosti je převádět do patřičných formátů apod. Report během svého životního cyklu prochází následujícími fázemi: vytvoření, správa (administrace) a doručení uživatelům. Dobrý reportovací nástroj by měl všechny tyto fáze pokrývat. Produkty Microsoft Reporting Services a MicroStrategy 8 tyto potřeby bezezbytku splňují. Nyní se na každý z nich podívejme podrobněji.

Microsoft Reporting Services Microsoft SQL Server Reporting Services je otevřená serverová platforma pro vytváření, správu a doručování reportů (ať už tradičních papírově orientovaných sestav či interaktivních webově orientovaných). Produkt zaplňuje poslední mezeru v rodině produktů Microsoftu pro oblast Business Intelligence a Datawarehousing, do které patří MS SQL server, Data transformation services a Analysis services. Reporting Services poskytují výkonné reportovací prostředí, které umožňuje doručování informací v reálném čase z různých datových zdrojů do známého prostředí webového prohlížeče, Microsoft Office nebo existujících aplikací (viz obr. 1). Autoři reportů mohou vytvářet reporty publikované na serveru Report Server pomocí nástroje Report Designer (využívá MS Visual Studio .NET a rozhraní MS .NET Framework) nebo nástrojů jiných výrobců, které podporují jazyk Report Definition Language (RDL).

Závěr

obr. 1 – Architektura RS, Reporting Services – způsoby využití

Definice, složky a prostředky reportů jsou publikovány a spravovány jako webová služba. Spravované reporty je možné generovat na požádání či podle časového plánu a volitelně je ukládat do mezipaměti (např. z důvodů zachování konzistence nebo zvýšení výkonu). Reporting Services podporují vyžádané (pull) i na základě událostí nabízené (push) doručování reportů. Uživatelé mohou reporty zobrazovat ve webovém formátu nebo v e-mailu.

implementaci a údržbu vysoce zabezpečeného systému, který je nasazován i na nejchoulostivější místa v bankovnictví. Možnost vytvářet serverové clustery dovoluje MicroStrategy Intelligence Serveru podporovat jakýkoliv počet uživatelů rozložením požadavků mezi více serverů. Serverové clustery umožňují také budovat systémy s vysokou dostupností aplikací.

Reportovací nástroje už dávno vyrostly z dětských nemocí a nabízejí široké možnosti nasazení a použití. Na jedné straně se snaží uživateli poskytnout co nejjednodušší a intuitivní ovládání, na straně druhé obsahují stále více analytických nástrojů a funkcí, což jejich použití zesložiťuje. Ideálem je zřejmě produkt, který umožní uživateli dostat se jednoduchým způsobem k údajům, které ho zajímají a vývojáři poskytne dostatečné prostředky a komfort pro vývoj a úpravy reportů podle neustále se měnících požadavků uživatelů. Microstrategy 8 je produkt s dlouhou tradicí a širokou uživatelskou základnou, zejména v zahraničí. Díky vysoké míře komplexnosti a propracovanosti lze při jeho využití v relativně krátké době požadované výstupy realizovat s vysokou kvalitou grafického provedení. Tato vlastnost bývá, pochopitelně ruku v ruce se správností zobrazených dat, důvodem k tomu, aby uživatelé nový nástroj dobře přijali. Je vidět, že Microsoft se ve svých Reporting Services poučil z chyb svých předchůdců a nabízí velmi konkurenceschopný produkt. Jeho zaměření, ale hlavně způsob nasazení, je pro produkty tohoto výrobce typický a tak poněkud odlišný od Microstrategy. Reporting Services nenabízí takové množství předpřipravených typových analytických funkcí nebo záplavu šablon pro grafické zpracování výstupu jako Microstrategy. Vývojář má v Reporting Services, díky „nízko-

MicroStrategy 8 Společnost Microstrategy Inc. je jednou z vedoucích společností na poli Business Intelligence nástrojů. Produkt MicroStrategy 8 využívá vícevrstvou architekturu a umožňuje přistupovat k relačnímu datovému skladu nebo sadě relačních datamartů z různých uživatelských rozhraní, jako jsou MicroStrategy Desktop, MicroStrategy Web, Narrowcaster, ze zákaznických aplikací (API pro JAVA a DCOM s využitím protokolů založených na technologii XML) a také pomocí klientských nástrojů třetích stran, prostřednictvím MicroStrategy OLAP Provider, který poskytuje rozhraní Microsoft OLE DB pro OLAP API). Celá infrastruktura systému MicroStrategy je založena na produktu MicroStrategy Intelligence Server (MSIS). MSIS poskytuje pokročilé analytické schopnosti s širokou knihovnou statistických, finančních, OLAP (On-Line Analytical Processing) a matematických funkcí. Tyto funkce je možné uživatelsky parametrizovat a kombinovat s klasickými postupy ROLAP (Relational On-Line Analytical Processing) analýzy relačních datových skladů. Důsledná a propracovaná implementace konceptu ROLAP umožňuje efektivně zpracovávat jak agregované údaje, tak i vysoce granulární data (např. jednotlivé zákaznické transakce). Výsledkem pak je efektivní návrh a zpracování komplexních víceprůchodových dotazů, jinými technologiemi nedosažitelné. Reporty mohou představovat jednoduché indikátory výkonu jako např. čtvrtletní prodeje po produktech, ale také sofistikované testování hypotéz s použitím statistických testů, včetně možnosti parametrizace reportů a matematického modelování (what-if analýzy). Výsledky jsou distribuovány uživatelům pomocí široké škály rozhraní a komunikačních kanálů s možností dalšího zpracování (drillování, pivotování, zpětný zápis do datového tržiště). Server poskytuje robustní vícevrstvý bezpečnostní model pro řízení přístupových práv uživatelů a to jednak pomocí prostředků SŘBD datového skladu, jednak na úrovni jednotlivých analytických objektů pomocí systému uživatelských účtů, uživatelských rolí a ACL (access control list). Tento bezpečnostní model umožňuje

obr. 2 – Architektura MSTR8

Mezi největší technologické novinky v MicroStrategy 8 patří kromě vylepšeného uživatelského rozhraní také nová technologie pro rychlý návrh a provedení reportů, díky které mohou reporty bez problémů vytvářet a zdokonalovat i netechničtí uživatelé, ve zjednodušujícím WYSIWYG režimu ve web rozhraní typu „zero-footprint“. Mezi další zásadní novinky patří také možnost přímého přístupu k datům systému SAP Business Warehouse prostřednictvím nového nástroje MicroStrategy MDX, který generuje MDX syntaxi, certifikovanou pro práci s BAPI rozhraním systému SAP Business Warehouse. MicroStrategy MDX využívá multidimenzionální datové modely, které jsou standardní v SAP Infocubes, QueryCubes a ODS - proto lze automaticky drillovat zpět do SAP Business Warehouse bez nutnosti programování a navrhování cest pro drillování. MicroStrategy 8 také propojuje data SAP Business Warehouse Infocubes, QueryCubes i různých instancí SAP Business Warehouse.

úrovňovému“ návrhu reportů prostřednictvím zásuvných modulů do MS Visual Studia, otevřenou možnost kontroly a úprav vzhledu výsledného reportu nebo dokumentu až na programátorské úrovni. Úzká a bezbolestná návaznost na Office se dá u Microsoftu považovat za samozřejmost. Tento koncept klade větší nároky na analytické a vývojářské kapacity a samozřejmě odpovídajícím způsobem prodlužuje dobu potřebnou k realizaci reportu, ale zase lze takto uživatelům „ušít“ reporty přímo na míru. Vhodnost nasazení jednoho či druhého řešení u zákazníka se liší případ od případu. Za základní kritérium lze ovšem považovat hledisko TCO (Total Cost of Ownership - celkové náklady na vlastnictví), kdy se na počátku levnější řešení od Microsoftu může postupem času prodražit vývojem nových reportů, které jsou si analyticky zaměření uživatelé Microstrategy schopni generovat a vytvářet sami. Naopak, jestliže zákazník již vlastní databázi MS SQL server, jehož jsou Analysis a Reporting Services součástí, může finanční prostředky investovat právě do analýzy a vývoje reportů.

13

V

Á

Š

S

P

O

L

E

H

L

I

V

Ý

P

A

R

T

N

E

R

V

E

S

V

Ě

T

Ě

I

T

Test:

Jste závislí na ICT? Odpovězte na následující otázky: Probudíte se ve 3 ráno a rozhodnete se a) Jít na záchod. b) Vyplenit ledničku. c) Zkontrolovat, zda vám nepřišel e-mail. Co jsou podle vás vhodná jména pro děti? a) Albína a Kristián b) Maruška a Jakub c) Mozilla a Dotcom Co je to telefon? a) Přístroj s kulatým číselníkem umístěný v budce, za pětadvacetník umožní povídat si s jinými lidmi. b) Mobilní telekomunikační zařízení. c) Jedna z funkcí kamery. Aby jste se vyhnuli virům a) Držíte se dále od lidí, kteří smrkají a pokašlávají. b) Nestrkáte do své mechaniky cizí 5 a 1/4 palcové diskety. c) Používáte rezidentní antivirový štít. Pokud si nejste jisti, zda se za smajlíkem píše čárka a) Sáhnete do knihovničky pro Pravidla českého pravopisu. b) Navštívíte FAQ na webu Ústavu pro jazyk český. c) Takový problém nemáte, protože váš kancelářský software kontroluje gramatiku automaticky. Pokud chcete podat daňové přiznání a) Vypravíte se na finanční úřad pro papírový formulář. b) Elektronicky vyplněný formulář opatřený elektronickým podpisem zašlete finančnímu úřadu. c) Po zavedení 100% rovné daně takový problém nemáte.

Hodnocení Za každou odpověď a) si připočtěte 0 bodů, za odpověď b) 1 bod, za odpověď c) 3 body. 0 až 4

Pravděpodobně jste nedočetli až na toto místo.

5 až 10

Informační a komunikační technologie občas používáte. Vzpamatujte se, nebo vám ujede vlak!

11 až 14

ICT rozumíte ale nejste na nich závislí, neztrácíte kontakt s realitou.

15 a více Vaše doba teprve přijde!

KOMIX s.r.o. je systémový integrátor zaměřený na dodávky vlastních řešení informačních systémů s využitím moderních a ověřených technologií. Svým klientům poskytuje služby ve všech fázích životního cyklu informačního systému od definice požadavků na jeho funkčnost, až po provedení akceptačních testů a podporu jeho provozu. KOMIX se přitom spoléhá především na vlastní vývoj, know-how a tým odborníků, kteří se dokonale orientují v informačních technologiích, znají potřeby svých zákazníků a mají praktické zkušenosti z realizace rozsáhlých systémů. Hlavními kritérii úspěšnosti našich projektů jsou míra spokojenosti zákazníka a trvale dobré vztahy. Předáním systému spolupráce nekončí, ale pokračuje ve formě technické podpory, školení a dalších navazujících služeb. Společnost KOMIX byla založena v září 1992 v Praze. V současné době má 105 zaměstnanců.

KOMIX – ověřená kvalita produktů a služeb

KOMIX s.r.o. Holubova 1, 150 00 Praha 5, tel.: +420 225 989 811, fax: +420 225 989 803, [email protected], www.komix.cz Redakční zpracování: kolektiv pracovníků KOMIX s.r.o., DTP a produkce: ARDEA grafické studio, s.r.o. KOMIX s.r.o. 2005

14