S KOMIXem do Evropy

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 <<boundary>> 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.
<<Functional Requirement>>
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.
<<Functional Requirement>>
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 <<Functional
Requirement>>, 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 <<Functional Requirement>> 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