komixí noviny 2007 / 2008

komixí noviny 2007 / 2008
Vážení čtenáři,
tento rok uběhlo již
patnáct let od chvíle,
kdy se 7 lidí rozhodlo založit softwarovou
společnost KOMIX. Začínali jsme v době, kdy
se všechno měnilo a firmy vznikaly jako na běžícím pásu. Svůj pokus jsme nebrali až tak
moc vážně. Prostě jsme
to zkusili s tím, že když pokus nevyjde, necháme se
opět zaměstnat.
V té době kdekdo psal programy ve Foxce a každá
třetí softwarová firma měla v nabídce vlastní účetní program.
Více než polovina zakladatelů KOMIXu, však měla
zkušenosti s vývojem real-time systémů a všichni se
shodli na tom, že vyvíjet další účetní program není
to, co by je naplňovalo. Nakonec jsme si vybrali vývoj zakázkových programů v prostředí databázového systému Informix a preferovali operační systém
Unix. Tato volba se ukázala jako šťastná. Informix se
v té době na českém trhu výrazně prosadil a to jak
ve státní správě, tak v soukromém sektoru. Společnost jsme založili v září a ještě v témže roce se naše
společnost umístila mezi prvními třemi prodejci Informixu i SCO Unixu.
K úspěchu nám jistě pomohlo i to, že první knížka
o Informixu v českém jazyce byla napsána Martinem Lipšem, Martinem Slámou a Yvonou Parmovou – zakladateli společnosti. Pavel Krutina, další
z těch, co společnost zakládali, v té době vyvinul svou vlastní úpravu serveru Informixu, která
zajišťovala správné třídění podle české abecedy,
což v té době Informix jaksi neuměl. Vyvinuli jsme
také vlastní generátor programů 4GL, který nám
umožnil konkurovat jak produktivitou práce, tak
i krátkými dodacími lhůtami.
Jelikož naším záměrem bylo dodávat kompletní projekty, doplnili jsme softwarová řešení i o hardwarovou infrastrukturu, zejména unixové servery. Celkem
přirozeně jsme nabídli našim zákazníkům i podporu
jak našich aplikací a dodané infrastruktury, tak podporu dalších provozovaných aplikací. V době Klausových „balíčků“ jsme diverzifikovali zákaznické
portfolio a získali zákazníky také z oboru financí a telekomunikací.
V té době jsme rozšířili své služby o nabídku služeb
testování a testovacích nástrojů. Otevřeli jsme trh
České republiky pro testovací nástroje Mercury Interactive a byli jsme první, kdo začal nabízet službu zátěžových testů. Později jsme zkompletovali pokrytí
celého životní cyklu projektu podporou jeho přípravných fází – konzultacemi při vytváření zadání projektů a tvorbou katalogů uživatelských požadavků.
Naše společnost za dobu svého trvání vytvořila řadu
zajímavých aplikací, které slouží dodnes. Za zmínku
stojí např. důchodová statistika, faktoringový systém
pro ŠkoFIN, informační systémy pro zdravotní pojišťovny, část logistického systému pro Ministerstvo
obrany nebo systém pro řízení a optimalizaci sítě mobilního operátora pro Eurotel. Z čerstvých projektů
mohu zmínit dodávky programového vybavení pro
projekt biometrických pasů, naši účast na rekonstrukci informačního systému České správy sociálního zabezpečení nebo účast na projektech v bankovním
sektoru pro naše velké banky Českou spořitelnu, Ko-
merční banku, ČSOB a mezi naše současné zákazníky
patří i Česká pojišťovna nebo ČEZ. Jedná se jak o vývojové projekty, tak projekty testovací.
Naši konzultanti se prosadili v evropském měřítku
a implementovali systém Clarity pro multiprojektové
řízení v nadnárodních společnostech jako jsou Vodafone, ING nebo Orange.
Společnost KOMIX je po patnácti letech své činnosti připravena dodávat rozsáhlé informační systémy
včetně infrastruktury i unikátní technicky vyspělá
specializovaná řešení. Má certifikovaný systém jakosti a systém environmentálního managementu a také
prověrku pro práci s utajovanými informacemi.
Naši specialisté pomohou zákazníkům formulovat
zadání projektů, vybrat technologie pro realizaci
a pro řadu z nich projekty i realizují. Na jiných projektech vystupují na straně zadavatele a podporují
jej při převzetí softwarových projektů a dohledu nad
jeho kvalitou.
Stoupající nároky klientů a především snaha o maximální spokojenost našich zákazníků jsou stále tím
hlavním důvodem k rozšiřování nabídky našich produktů a zlepšování úrovně poskytovaných služeb.
Petr Kučera
[email protected]
Protože jsme se od samého začátku snažili o to, abychom měli vývoj organizovaný a postupovali při
tvorbě programů systematicky, začali jsme používat a také školit metodiku vývoje software a používat i prodávat CASE systémy. Tehdy zejména značky
Westmount a později také SELECT.
Již v prvních letech existence společnosti jsme získali významné zákazníky - Ministerstvo obrany, Českou správu sociálního zabezpečení, Generální ředitelství cel, Zdravotní pojišťovnu zaměstnanců bank
a pojišťoven, pojišťovnu Kooperativa a další. Se všemi uvedenými se nám podařilo vybudovat dobré
vztahy a spolupracujeme s nimi dodnes.
1
Geocachingová hra k 15. výročí KOMIXu
Co je to geocaching?
Každý programátor je zvídavý a hravý a má rád
dobrodružství.
Je
tedy
potenciálně
předurčen stát se
účastníkem celosvětové hry zvané geocaching. V rámci této
hry její účastník, tzv.
geocacher, pomocí přístroje GPS, anebo i bez něj, hledá (loví) skrýš
s „pokladem“ (geocache). Pokladem je obvykle
dobře ukrytá plastová krabička s notýskem (logbook) a tužkou a několika drobnostmi na výměnu.
Informace o pokladech jsou předávány na Internetu na geocachingových serverech – třeba na jednoznačně nejznámějším www.geocaching.com.
Tato hra je určena pro všechny, kdo rádi přemýšlí,
či jinak zatěžují mozek, nevadí jim pohyb v přírodě nebo ve městě a mají v oblibě mapy, hádanky
a záhady. A právě těmito vlastnostmi oplývá (téměř a nejen) každý programátor.
Souřadnice
Souřadnice skrýše s pokladem jsou uváděny
ve formátu N50° 05.446‘ E014° 24.045‘ tj. ve stupních a minutách až do jejich tisícin. V takovém tvaru je zadáte do GPSky a umí s nimi pracovat i mapové portály, například maps.google.com a www.
mapy.cz, které jsou geocachery hojně využívány. Pomocí mapových portálů lze „ulovit“ poklad
i bez GPS.
Vyzkoušejte si třeba výše uvedené souřadnice
na portálu www.mapy.cz tak, že do vstupního
pole portálu zadáte loc:50° 05.446‘ 014° 24.045‘.
Měl by se Vám zobrazit Pražský hrad.
Vážné varování: geocaching je velmi návyková
hra, takže pokud nechcete přijít o svůj zbylý volný
čas, nečtěte tento článek dále ...
Pokud musíte souřadnice skrýše určit z více či
méně složité úlohy nejrůznějšího druhu, jedná se
o tzv. mystery nebo také unknown cache.
Multicache k 15. výročí KOMIXu
Nyní již o multicachingu máte dost informací
k tomu, abyste se mohli zúčastnit následující geocachingové hry. K 15. výročí založení KOMIXu
jsme pro Vás totiž připravili privátní multicache,
která Vás provede po místech, která jsou nějakým
způsobem spjata s působením firmy KOMIX. Při
lovu se také dozvíte některá zajímavá fakta z historie KOMIXu.
Postupujte po jednotlivých stage (etapách), postupně určujte neznámé cifry A, B, C, X, Y a Z. Cílový bod s finální skrýší Vás zavede k areálu, kde
v současné době sídlí vedení firmy KOMIX.
Odvozované souřadnice se skládají po cifrách, závorky se nenásobí.
Kontrolní ciferný součet A+B+C+X+Y+Z (ciferný
součet opakujte tak dlouho, až dostanete jednociferné číslo) je 8.
Stage 1: První setkání zakladatelů KOMIXu
Začneme na následujícím místě:
N50° 4.038‘ E014° 25.428‘
Stojíte před budovami VŠ, které jsou spojeny spojovacím můstkem. V kancelářích horního patra tohoto můstku zakladatelé firmy KOMIX společně
pracovali v roce 1992 – zatím ještě v jiné firmě.
Některé typy geocache
Určíme A = počet sloupů můstek podpírající, včetně těch u zdí budov.
Pokud je skrýš s pokladem uložena přímo
na uvedených souřadnicích, pak je to tradiční geocache.
Určíme B a C = číslo popisné (červené) vlevo na zdi
budovy je 2BC0.
Pokud Vás uvedené souřadnice zavedou na začátek několikaetapového lovu, kdy postupně dopočítáváte souřadnice postupných cílů až k závěrečné finální skrýši, pak se jedná o multicache.
Stage 2: První provizorní sídlo KOMIXu
První, i když pouze provizorní, sídlo KOMIXu v srpnu až říjnu 1992 bylo v budově jiné VŠ. Tam Vás zavedou souřadnice:
N50° 05.(B)(C+2)(C)‘ E014° 26.(A-4)(C+3)(A)‘
Určíme X = počet sloupků na protějším chodníku
(směrem k soše státníka).
do potíží s určováním souřadnic či dohledáváním
finální cache, obraťte se na výše uvedený e-mail.
Nápověda/Hint
Stage 3: První stálé sídlo KOMIXu
První skutečně stálé sídlo KOMIXu od konce roku
1992 až do začátku roku 1997 bylo na souřadnicích:
N50° 06.(X+1)(C)(A)‘ E014° 23.(C+2)(B+1)(X)‘
Určíme Y = počet oken z ulice do suterénních
místností.
Stage 4: Stěhování KOMIXu do svého
V dubnu 1997 se pak KOMIX nastěhoval do svého vlastního objektu a začal se rozrůstat po okolních budovách, kde sídlí výkonné odbory firmy
dodnes. Toto místo najdete na souřadnicích:
N50° 03.(Y+3)(X)(B)‘ E014° 23.(A+1)(B)(X)‘
Určíme Z = počet cihlových sloupků plotu (pouze
ze strany ulice včetně krajních).
Stage 5: Současnost KOMIXu
A v současnosti sídlí velitelství KOMIXu v obchodním centru na souřadnicích:
N50° 04.(X)(Z)(B)‘ E014° 24.(C-3)(A-3)(Y)‘
Finální cache je uložena v plechové krabičce o rozměrech 6x10x2cm. Pod jejím víčkem najdete heslo, které odešlete na adresu geocaching@komix.
cz, a tím prokážete svůj úspěch. Prvních 5 cacherů - seřazeno podle data a času e-mailu - bude odměněno.
A nakonec dobré rady, než vyrazíte lovit nejen tuto cache – důkladně prostudujte zadání
a všechny indicie, připravte se na „suchu“ (Internetu), vezměte si s sebou plány a mapy, tento výtisk
se zadáním, pro jistotu něco na psaní a do GPS náhradní baterie. Pro případ, že se Vám nebude dařit
na finální cache, vezměte si s sebou zakódovanou
nápovědu (hint). Klíč je přiložen.
cyrpu
Decryption Key
A B
C D E
N O P Q R
F G H
S
I
J
K
T U V W X
L M
Y
Z
(letter above equals below,
and vice versa)
Závěrem
Pokud se Vám tato geocahingová hra zalíbila, bližší informace najdete na následujících webových
stránkách:
wiki.geocaching.cz
www.geocaching.cz
www.geocaching.com
Slovníček protřelého cachera
keš, keška - z angl. (geo)cache: skrýš s pokladem
kačer, kešer - z angl. (geo)cacher: zasvěcený
účastník hry, hledač pokladů
mudla, mudlopes - osoba do geocachingu nezasvěcená a jeho pes
mysterka - z angl. mystery: keš, jejíž souřadnice
musí kačer vyluštit
multina, multikeš - z angl. multi-cache, keš skládající se z několika etap (stage)
hint - nápověda k úkrytu pokladu
geožena/muž, geopes - osoba nebo pes doprovázející kačera
A nezapomeňte, že před mudly (viz slovníček) nesmíte prozradit umístění skrýše – vyzvedávejte
tedy krabičku opatrně. V případě, že se dostanete
Martin Lipš
[email protected]
Centrální systém (CS) zajišťuje sběr a uložení dat
žádostí vytvářených na kontaktních místech,
zprostředkovává výměnu dat s externími systémy
(evidence obyvatel, evidence cestovních dokladů,
cizinecký IS, systém e-pasů Ministerstva zahraničních věcí), provádí autonomní dávkové úlohy
(příprava dávek pro STC, likvidace biometrických
údajů v zákonem stanovené lhůtě), obsahuje subsystém pro správu uživatelů a výměnu dat s certifikační autoritou a umožňuje monitorování systému a dat v něm uložených.
Systémy MV a STC komunikují v off-line režimu
z důvodu splnění požadavků na vysoký stupeň
zabezpečení personalizačního centra.
Softwarové řešení pro e-pasy
e-pasů pro Ministerstvo vnitra (MV), byla STÁTNÍ
TISKÁRNA CENIN, státní podnik (STC). Společnost
KOMIX s.r.o. se podílela na realizaci významné
části systému – byl jí svěřen vývoj softwaru pro
zpracování žádostí a další procesy spojené s vydáváním těchto dokladů. V dalším textu představíme základní architekturu a důležité aspekty
především této části systému. Není zde hovořeno o vlastních elektronických pasech a technologiích v nich použitých. Rovněž nejsou popisovány
další oblasti řešení, které spadaly pod jiné dodavatele (Siemens, IBM, Monet+, aj.) – např. detaily
hardwarové architektury, vlastní výroba dokladů
v STC či Národní certifikační autorita, která vydává certifikáty pro elektronické podepisování údajů v e-pasu.
Počínaje zářím 2006 jsou občanům České republiky vydávány nové cestovní pasy, které se významně liší od svých předchůdců: obsahují elektronický čip, na němž jsou uloženy základní údaje
o držiteli pasu včetně jeho fotografie. O zavedení těchto tzv. cestovních dokladů s biometrickými prvky, zkráceně označovaných jako „e-pasy“,
bylo rozhodnuto Radou EU v prosinci 2004 v souladu s celosvětovým trendem v oblasti cestovních dokladů, který s mandátem OSN koordinuje
ICAO – mezinárodní organizace civilního letectví. Jedná se mj. o nutnou podmínku pro zachování, resp. zavedení bezvízového styku se Spojenými státy. Hlavním důvodem pro tuto inovaci je
zvýšení bezpečnosti cestovních dokladů a dále se
do budoucna počítá s automatizovaným ověřováním totožnosti držitele pasu na hraničních přechodech, letištích apod.
Architektura řešení
vené), obsahuje: klientské aplikace pro kontaktní
místa, samoobslužné kiosky, aplikace centrálního
systému a aplikace pro výměnu dat s STC.
Kontaktními místy jsou obecní úřady, které zajišťují vydávání běžných e-pasů pro občany ČR, a pracoviště Oblastních ředitelství Policie ČR vydávající
doklady pro cizince a uprchlíky. Klientské aplikace zde poskytují funkce pro pořízení nové žádosti o cestovní doklad, předání vyrobeného dokladu držiteli, reklamaci dokladu, zpracování žádostí
přicházejících ze zastupitelských úřadů, obnovu
uživatelských certifikátů uložených na čipové kartě a další doplňkové funkce. Kromě „ostrých“ klientských aplikací jsou na všech kontaktních místech instalovány ještě tzv. „školicí“ aplikace, které
slouží pro zaškolení nových úředníků a liší se tím,
že nedochází k výměně dat s centrálním systémem – „školicí“ data jsou uložena lokálně.
Hlavním dodavatelem rozsáhlého technického
řešení, zajištujícího funkce potřebné pro vydávání
Architektura vytvořeného systému včetně vazeb
na okolní systémy je patrná z obrázku. Řešení,
které spadalo do naší kompetence (modře zbar-
Samoobslužné kiosky na kontaktních místech
umožňují držiteli e-pasu ověřit funkčnost čipu.
2
Klientské aplikace
Z technického hlediska jsou velmi zajímavou částí řešení klientské aplikace pro kontaktní místa.
Integrují totiž velké množství komponent, které jsou nutné pro zpracování žádostí o e-pasy.
Jedná se o:
 fotografický přístroj a příslušný softwarový mo-
který je rovněž uložen na čipové kartě;
dul, který zajistí nejen vlastní pořízení podoby
obličeje žadatele, ale rovněž implementuje funkce pro automatické ověření kvality fotografie,
aby vyhovovala mezinárodním standardům; jako příklad automatických kontrol uveďme: čelní
pohled žadatele, otevřená ústa, zavřené oči, stíny a přesvětlená místa, odlesky na brýlích, aj.;
 tablet a software pro digitalizaci podpisu žadatele; za zmínku stojí, že bylo nutno vyvinout algoritmus, který zajistí normalizaci velikosti podpisu (žadatelé různým způsobem využívají plochu
pole pro podpis na žádosti), aby se dosáhlo vysoké kvality při tisku podpisu do e-pasu;
 čtečku e-pasů, která je využita nejen pro načítání údajů z čipu nově vyrobených e-pasů (kvůli
kontrole), ale rovněž se používá pro automatické získání rodného čísla žadatele z dokladu obsahujícího strojově čitelnou zónu;
čtečku
čipových karet; čipové karty s uživatel
skými certifikáty a privátními klíči se využívají
jak pro autentizaci uživatele, tak pro elektronické podepisování vytvořených žádostí;
2
 monitory připojené ke klientské stanici,
z nichž jeden je určen pro úředníka a druhý je
obrácen směrem k žadateli a slouží pro kontrolu pořízené fotografie, resp. údajů v novém
e-pase;
 tiskárnu pro tisk žádostí; pro občana odpadla
nutnost ručního vyplňování údajů do žádostí,
naopak veškerá data jsou pořízena elektronicky
a jediným manuálním úkonem žadatele je vytvoření dvou podpisů na vytištěné žádosti.
 šifrování biometrických údajů žádosti pomocí
Klientské aplikace jsou vytvořeny v technologii
.NET, která nejsnáze umožňuje integrovat uvedené množství různorodých komponent, jejichž ob-
Ministerstvo vnitra
Evidence
cestovních
doklad
Evidence
obyvatel
Cizineck
IS
Systém
MZV
Kontaktní místa
Aplikace
Aplikace
pro
Aplikace
pro
kontaktní
pro
kontaktní
místa
kontaktní
místa
místa
Kiosek
Kiosek
Kiosek
Aplikace
centrálního
systému
Národní
certifikaní
autorita
Dohledov
systém
služný software je obvykle realizován v téže či příbuzných technologiích.
Centrální systém
Na straně centrálního systému se zmíníme krátce
o použité architektuře, která má zajistit především
dostatečnou výkonnost, spolehlivost a vysokou
dostupnost. Systém je dimenzován na zpracování až 20.000 žádostí denně.
Kvůli spolehlivosti a rozložení zátěže zpracovává
CS klientské požadavky ve dvou paralelních větvích propojených do clusteru, z nichž každá obsahuje hardwarově oddělený web server, aplikační server (oba typy serverů z rodiny Sun Java
System) a databázový server (Informix). Data jsou
pak uložena v externím diskovém poli. V případě havárie centrálního výpočetního střediska lze
provoz přepnout na záložní středisko, kde je udržována replika provozní databáze.
Aplikace
pro vmnu
dat s STC
Správa
uivatel
off-line
off-line
Státní
tiskárna
cenin
Certifikaní
autorita
Aplikace CS jsou postaveny nad technologií J2EE.
Pro komunikaci s okolními systémy včetně výměny dat s klientskými aplikacemi se používají webové služby. Vzhledem k tomu, že žádosti v XML
formátu jsou poměrně velké (řádově stovky KB)
a propustnost datových přípojek obecních úřadů není vždy optimální, bylo nutno použít komprimaci dat žádostí.
Zabezpečení dat
Systém pracuje s osobními údaji občanů a proto
je ochraně dat po celou dobu zpracování věnována mimořádná pozornost. Ke slovu přichází masivní využití PKI technologií, a sice v oblastech:
 autentizace uživatele do systému a ustanovení
HTTPS spojení s CS pomocí komerčního certifikátu uloženého na čipové kartě;
 podepsání vytvořené žádosti kvalifikovaným
certifikátem úředníka na kontaktním místě,
veřejného klíče STC;
 podepsání dávek připravených pro odeslání
do STC soukromým klíčem CS, uloženým v HSM
modulu;
 šifrování dat na datových nosičích přenášených
mezi MV a STC;
 podepsání obsahu nosiče pro STC úředníkem
MV, resp. návratového nosiče zaměstnancem
STC;
podepsání
údajů v čipu e-pasu pomocí klíče

tzv. Document Signeru (DS).
Pro ustavení bezpečné komunikace mezi CS a externími systémy je využito HTTPS se základní autentizací pomocí jména a hesla, což je dostatečný způsob ochrany vzhledem ke skutečnosti, že
se jedná o komunikaci po privátní síti.
Očekávaný vývoj
Systém nasazený do produkčního prostředí průběžně doznává drobných úprav a vylepšení. Podstatná úprava chování systému bude probíhat
v následující etapě, kdy přibudou mezi údaje uložené v čipu e-pasu rovněž otisky prstů držitele a nový způsob ochrany údajů v čipu. Uvedené změny si vyžádají úpravu klientských aplikací
i centrálního systému a některých datových rozhraní. Zavedení otisků prstů do čipu cestovního dokladu je pro členské státy EU stanoveno do
28. 6. 2009.
Petr Sobotka
[email protected]
„IS Pojišťovna“ - IZOP/NIS
Informační systém zdravotních
pojišťoven
Informační systém „IS Pojišťovna“ je implementován ve dvou modifikacích a zajišťuje komplexní funkcionalitu pro zdravotní pojišťovny (IZOP
pro Oborovou zdravotní pojišťovnu zaměstnanců bank, pojišťoven a stavebnictví a NIS pro Vojenskou zdravotní pojišťovnu ČR). Má jednotné
a centralizované uložení dat, která jsou tak dostupná ze všech komponent systému a rovněž je
tím zajištěna jejich dostatečná integrita. Systém
je schopný zpracovávat vstupní data z externích
zdrojů v definovaném formátu a recipročně taková data poskytovat. Součástí systému jsou automatizované i interaktivní procesy v příjmové
a výdajové části (načítání, validace, kontroly) nad
registry pojištěnců, poskytovatelů péče a plátců
pojistného. O prováděných úkonech se vede záznam (protokol).
Architektura informačního systému
IS Pojišťovna (IZOP/NIS) je tvořený aplikačním serverem, který pracuje nad databází Informix. Integrovaným uložením je zajištěna okamžitá dostupnost aktuálních dat a umožněna automatizace úloh.
Terminálová aplikace, kde se k aplikačnímu serveru přistupuje prostřednictvím klientského rozhraní v rámci firemní sítě, umožňuje rovnocennou
práci všem uživatelům.
1. Oblasti zpracování
Informační systém zahrnuje nástroje pro správu
těchto oblastí:
Registry a číselníky – údržba a aktualizace – základna pro všechny procesy,
Příjmová oblast – zpracování příjmů (plateb pojistného) – požadovaných, skutečných, kontroly,
vymáhání,
Obr. 1 – Architektura jádra IS
Výdajová oblast – zpracování zakázek – kontroly
správnosti a oprávněnosti,
Rozhraní systému – vstup a výstup dat, zavedení plateb, zavedení zakázek, hlášení, komunikace
s CRP, VZP, subjekty, portálem
Správa systému – správa uživatelských účtů, přístupových práv, konfigurace parametrů,
Pomocné aplikace – vytváření a tisk sestav, práce
s datovými soubory, protokolování.
2. Součásti systému
Data jsou uložena v transakčních databázích
Informix. Jádro aplikační vrstvy systému IS Pojišťovna (IZOP/NIS) se ovládá přes znakový terminál
(protokol telnet). K funkcím systému se přistupuje
prostřednictvím jednotného interaktivního menu. Hromadné úlohy jsou prováděny automatizovaným dávkovým zpracováním.
Nadstavbové součásti systému – workflow systém
WOIS (Workflow Oriented Information System) komunikují a spolupracují s touto aplikační vrstvou
IS a s databázovou vrstvou.
Systém WOIS je nedílnou
součástí instalace systému
IS Pojišťovna (IZOP/NIS).
Zajišťuje řízení procesů
a kompletní oběh a tisk dokumentů. Komunikace se
systémem WOIS probíhá
prostřednictvím webového
klienta (protokol http).
Systém ve své příjmové části zajišťuje tyto automatizované procesy:
přiřazení externě pořízených PPPZ zaměstnava
telům
přiřazení úhrad plátcům

vyúčtování Přehledů

kontrolní činnost v oblasti plateb pojistného


kontrola předložení PPPZ

kontrola plateb osob i zaměstnavatelů
průběh
správního řízení

3. Rozhraní
IS komunikuje prostřednictvím svých datových rozhraní s dalšími systémy, jako jsou Účetnictví, Portál ZP,
podatelna. Dávky, podání
nebo třeba aktualizace číselníků lze tak zpracovávat jak automaticky, tak v interaktivě.
Procesy
Za klíčové procesy, které systém zajišťuje, jsou:
sled kroků v příjmové části – zpracování plateb
pojistného, kontrola platební kázně subjektů, vymáhání dlužného pojistného, a ve výdajové části – příjem dávek, kontrola správnosti, rozhodnutí
o uhrazení a vyúčtování.
V automatických kontrolách se uplatňuje subsystém WOIS v oblasti řízení procesu:
 Kontrola PPPZ
Kontrola plateb zaměstnavatelů

Kontrola osob

zvláštním typem kontrol jsou:


kontroly z důvodu konkurzu či likvidace

vyžádání vratky přeplatku pojistného

vydání dokladu o neexistenci závazků
- bezdlužnost
4. Příjmová část
Základem pro procesy příjmové části jsou správné
a aktualizované údaje v registrech osob, a v registrech zaměstnavatelů (výše
předpisu OBZP, výše zálohy OSVČ, typ plátce, údaje o zaměstnavateli, adresy,
bank. spojení).
Systém zároveň plní funkci analytické evidence
účetnictví.
Obr. 2 – Architektura systému
3
 Automatické kontroly
(KO)
Automatická revize vyhodnocuje již zkontrolované
zdravotní doklady. Podle
nastavení parametrů je automaticky zreviduje nebo
předá k ruční revizi reviznímu lékaři. Po vyhodnocení
většího objemu dat lze parametry významně ovlivňovat množství dokladů předložených k ruční revizi.
Obr. 3 – Procesy kontrolní činnosti
 Ruční revize (RL)
Revizní lékař má při ruční revizi v rychlém dosa5.Výdajová část
hu všechny dostupné informace potřebné k rozZákladem je evidence smluvních partnerů a pojišhodnutí.
těnců (Registry).
Historii pacienta, smluvní podmínky zařízení,
Vstup dokladů probíhá ze souborů v rozhraní VZP.
vazby mezi zdravotními doklady.
Soubory s doklady pořízené externě lze načíst
v nočním dávkovém zpracování. Je možné i interaktivní zavedení papírového dokladu.
Doklady s vykázanou zdravotní péčí jsou zavedeny do systému, a probíhá jejich zpracování.
Záznamy jsou trvale dostupné. S ohledem
na množství dat se cca po pěti letech mohou odsouvat do archivu.
 Automatické/interaktivní zpracování dokladu (CD)
Doklady ze souboru, z dávky souborů nebo z tištěné podoby jsou zaváděny do systému. V nočním zpracování se prověřuje formát, platnost vůči registrům a obsah se načítá do databáze.
 Vyúčtování (PL)
Vyúčtování definitivně
ohodnotí schválené zdravotní doklady. Uplatní se
i individuálně nastavené
platové podmínky smluvních subjektů. Částky jsou
převedeny na příslušné
účty v účetnictví. Možnost
proplácení záloh. IS má otevřené datové rozhraní pro
externí účetnictví.
Obr. 5 – Výdajový okruh zpracování dávky
 Zúčtovací zpráva (ZZ)
Zúčtovací zpráva obsahuje informaci o tom,
 příprava podkladů na základě platebních povinností osob, vyúčtování Přehledů OSVČ a předv jaké částce jsou zdravotnímu subjektu proplapisů pohledávek z kontrolní činnosti
ceny vykázané doklady a pokud došlo ke korek
(penále, pokuty)
cím, tak vysvětlení, proč k nim došlo.
 tvorba účetních dokladů
Vazba IZOP/NIS do účetnictví RIS
 inventury účtů
Důležitou nadstavbou (jenž
Jednotlivé účetní záznamy z IS Pojišťovna (IZOP/
byla zmíněna již v bodě 2.3
NIS) jsou seskupovány do účetních dokladů. ProRozhraní) IS je rozhraní INhlížení těchto účetních dokladů je možné právě
VRIS (OZP)/XIS (VoZP) mev rozhraní INVRIS/XIS. Pomocí této aplikace lze
zi IS Pojišťovna (IZOP/NIS)
prohlížet i prvotní záznamy zahrnuté do účetních
a účetnictvím RIS.
dokladů (předpis PPPZ, předpis penále apod.).
V rámci zajištění funkcioJiří Tománek, Pavel Körner
nalit vazeb do účetnictví, je
[email protected]; [email protected]
možné realizovat tyto následující kroky:
 prohlížení jednotlivých
položek účetních dokladů
Obr. 4 – Automatizované procesy ve výdajové části
 nastavení účetního
období
portál zdravotní pojišťovny jako další služba klientům
Podíl společnosti KOMIX na provozu informačního systému pojišťovny v OZP a VoZP spočívá nejen ve vývoji a v následné technické podpoře, ale
také v dalším rozvoji rozhraní, kterými se zajišťuje
komunikace systému s klienty ZP. Jedním z nich je
právě Portál zdravotní pojišťovny.
Portál ZP – webové rozhraní
Klientům šesti zdravotních pojišťoven (Česká národní zdravotní pojišťovna, Oborová zdravotní
pojišťovna zaměstnanců bank, pojišťoven a stavebnictví, Revírní bratrská pokladna, zdravotní pojišťovna, Zaměstnanecká pojišťovna Škoda, Zdravotní pojišťovna Metal-Aliance, Vojenská
zdravotní pojišťovna ČR), se nabízí možnost jednat se „svou“ pojišťovnou prostřednictvím elektronického kanálu – webového portálu ZP. Nicméně žádná z výše uvedených pojišťoven si takovou
službu nezajišťuje sama, všechny využívají služeb
Portálu ZP, který provozuje Asseco Czech Republic, a.s., dříve Podnik výpočetní techniky. O službách portálu se dozvíte mnohé na webu (http://
www.portalzp.cz), takže jen ve stručnosti:
Uspořádání Portálu ZP
V celém uspořádání je nutné respektovat dvě zásady: zajistit širokou dostupnost služby a zajistit
ochranu informací (dat) předávaných mezi klientem (portálu) a zdravotní pojišťovnou. Proto je komunikace rozdělená do dvou sfér.

V první klienti komunikují s Portálem prostřednictvím zabezpečeného spojení (https), klient
se portálu identifikuje svým certifikátem vydaným I.CA, Českou poštou (Postsignum), eIdentity a certifikáty pro elektronické bankovnictví
(ČSOB, KB, ČS).
Logika věci je následující: existují subjekty, které
mají zájem využívat pro styk se zdravotní pojišťovnou elektronickou cestu. Mohou jimi být pojiš-
4
těnci, plátci pojistného (zaměstnavatelé) a poskytovatelé péče (zdravotnická zařízení). Předmětem
komunikace jsou vstupy dat do IS (podání přehledu plateb OSVČ, PPPZ, fakturace za poskytnutou
péči, požadavky na různé výpisy, elektronická podání) a výstupy IS (výpisy z účtu pacienta, zúčtovací zprávy, reakce na podání).
V rámci služeb portálu jsou vytvořeny účty pro registrované klienty. Klient portálu a subjekt IS pojišťovny nemusí být totéž. Významná je role, s jakou klient do IS pojišťovny přistupuje. Lékař může
být zároveň poskytovatel péče (logicky), ale také
zaměstnavatelem (sestra je u ZP pojištěná) a koneckonců i pojištěncem ZP. Jsou tu i role zákonného zástupce, zplnomocněné osoby, atp. Tudíž,
významná je informace, k jakým subjektům a v jakém rozsahu mohou klienti portálu přistupovat.
Portál zajišťuje správné přiřazování předaných
dat od klienta k subjektu a recipročně od ZP klientovi.
V druhé sféře probíhá spojení zdravotní pojiš
ťovny s portálem prostřednictvím zabezpečeného kanálu v rámci VPN.
Na straně pojišťovny pracuje server, v schématu
komunikace označovaný jako „brána“. Při přenosu
dat mezi portálem a bránou se oba servery vzájemně identifikují svými certifikáty. Výměna dat
mezi portálem a bránou probíhá dávkově a iniciuje ji brána (spouští se automaticky z cronu anebo ručně).
Tuto část systému ve spolupráci s pojišťovnami
navrhli a vyvinuli v Assecco ČR.
Uspořádání Brány
KOMIX s.r.o. se soustředil na vývoj komunikačního software brány a následné zpracování dat. Veškerá výměna dat mezi portálem a bránou probíhá
ve formátu XML. Šablony pro jednotlivé typy komunikace vypracoval a dodal provozovatel por-
tálu. Úkolem KOMIXu bylo tedy vyvinout aplikaci, která:
obsluhuje komunikaci mezi portálem a bránou

(naváže spojení, ověří pravost serveru, stáhne
data, nahraje data, obslouží logování),
vytváří a zpracovává xml věty řídící komunikaci

mezi portálem a bránou,
vytváří xml soubory obsahující data produko
vaná vlastním IS pojišťovny,
zpracovává xml soubory obsahující data shro
mážděná portálem
umožňuje přenos dat v komprimované podobě

(inovace k 1.4.2007)
Aplikace byla vyvinutá ve skriptovacím jazyce
PHP. KOMIX s.r.o. dodal software nejprve na bránu Oborové zdravotní pojišťovny zaměstnanců
bank, pojišťoven a stavebnictví a k 1.4.2007 byl
zahájen také provoz portálu Vojenské zdravotní
pojišťovny ČR.
Sestava „Výpis z individuálního účtu pojiš-
těnce“
Sestava „Přehled dob pojištění“
Sestava „OSVČ – potvrzení ročního vyúčto-
vání“
Obecné oznámení do schránky pojištěnce
 Zdravotnické zařízení – směr do ZP
Podání vyúčtování zdrav. péče (podání fdav-
ka a kdavka)
Podání sestavy hlášení úrazu
Žádost o výpis „Přehled kapitovaných paci-
entů“
 Zdravotnické zařízení – směr na portál
Zúčtovací zpráva
Sestava „Přehled kapitovaných pacientů“
Obecné oznámení do schránky zdrav. zaří-
zení
 Zaměstnavatel – směr do ZP
Podání přehledu HOZ
Podání přehledu plateb pojistného zaměst-
Požadavky na funkcionalitu
Informační systémy ZP IZOP (pro OZP) a NIS (pro
VoZP) v obou případech dodává KOMIX s.r.o.
V případě IZOP si OZP přenos dat mezi bránou
a IS primárně řeší vlastními silami. Jenže v rámci projektu NIS bylo rovněž třeba vytvořit rozhraní IS pro portál. Předmětem obousměrného přenosu a zpracování jsou soubory (podání), žádosti
a odpovědi ZP:
Pojištěnec – směr do ZP

Podání přehledu OSVČ
Žádost o výpis z individuálního účtu pojištěnce
Žádost o výpis z individuálního účtu pojištěnce – zastupované osoby
Žádost o výpis „Přehled dob pojištění“
Žádost o výpis „OSVČ – potvrzení ročního
vyúčtování“
Pojištěnec
– směr na portál

navatele
Žádost o výpis „Pojištěnců zaměstnavatele“
 Zaměstnavatel – směr na portál
Sestava „Přehled pojištěnců zaměstnavatele“
Obecné oznámení do schránky zaměstnava-
tele
Obecné
podání

Elektronická podatelna
 Ostatní
Externí instituce (žádost o součinnost)
Policie (hlášení dopravních nehod)
Řešení podle KOMIXu
Podání (HOZ, PPPZ, FDAVKA, KDAVKA) jsou z portálu přenášeny jako součást XML souboru. Aplikace brány je extrahuje do formátu dle specifikace
VZP a poskytne nově vyvinutému softwarovému
rozšíření IS, které si je stáhne na aplikační server.
Tam jsou prostřednictvím rozhraní systému zpracovány jako soubory, které se do systému dostaly
„běžnou cestou.“
Požadavky na vytvoření sestav (XML soubor dle
příslušné šablony) po stažení z portálu čekají
na bráně. Pokud softwarové rozšíření IS (NIS) zaregistruje nový požadavek, zahájí se tvorba a export
příslušné sestavy. Podání prostřednictvím elektronické podatelny portálu se po přenosu a zpracování bránou předává e-mailem na podatelnu ZP.
Odpověď systému na podání a požadavky (zúčtovací zprávy, sestavy) se vytvářejí jako text, uploadují na bránu, kde se z nich vytváří XML odpověď,
která putuje do příslušné schránky portálu.
Provádění výše uvedených úloh se děje prostřed-
nictvím shellového skriptu, který se spouští periodicky z cronu a postupně volá dílčí kroky. Přenos
dat mezi bránou a portálem zajišťuje aplikace tvořená skripty PHP, přenos dat mezi bránou a aplikačním serverem probíhá zabezpečeným kanálem (ssh), import/export dat do IS NIS a jejich
zpracování řídí WOIS (Workflow Oriented Information System).
Registry ZP na portálu
Pro to, aby správně pracovalo přiřazování vstupů
od klienta k subjektu v IS (a naopak), musí portál
obsahovat příslušné registry osob, zaměstnavatelů a zdravotnických zařízení.
Součástí vyvinuté aplikace je proto i export regist-
rů do xml souborů a jejich upload na portál, vzhledem k velikosti registrů v komprimované formě.
Závěrem
Klient pojišťovny, který využívá služeb portálu,
by mohl být spokojen. Pokud zvolí elektronickou
cestu komunikace se svou zdravotní pojišťovnou,
ušetří si spoustu papírování. Tedy, musí vyplnit
elektronické formuláře na portálu, ale pokud jeho
účetní software dokáže generovat např. kdavku,
může ji přímo odeslat prostřednictvím portálu
do ZP. Mimo to, jak na portálu, tak v IS pojišťovny probíhají validace a jen s velmi malou pravděpodobností se v podaných dávkách vyskytne syntaktická chyba.
Bohužel i cestou portálu musí klient počítat s určitou prodlevou mezi podáním a odpovědí. Minimálně je nutné zohlednit to, že výměna dat s portálem probíhá dvakrát denně. Soubory dávek jsou
zpracovávány standardně v nočním zpracování.
Generované sestavy čekají na bráně na další výměnu dat. Zadaná kdavka může procházet ruční
revizí.
Možnosti portálu jsou navrženy v mnohem širším
rozsahu, než v jakém je stávající aplikace využívají. V rámci informačního systému ZP se můžeme
proto těšit na další vlastnosti a funkce komunikace s portálem.
Pavel Körner
[email protected]
Zátěžový test JOK/ISP 3.1 v České pojišťovně
Česká pojišťovna a.s. (dále jen ČP) věnuje zvýšenou pozornost výkonnostnímu ladění aplikací,
před jejich uvedením do provozu. Výkonnostní ladění probíhá při zátěžových testech (dále jen ZT)
s využitím software HP LoadRunner, který do České pojišťovny dodala a implementovala společnost KOMIX s.r.o. Tento software se používá pro
generování zátěže testované aplikace a pro vyhodnocení zátěžového testu.
Jednou z aplikací, která byla pomocí HP LoadRunner testována v roce 2006 byla i aplikace JOK/ISP,
která zajišťuje zobrazování informací o výpočtu
odměn pro obchodníky a slouží pro komunikaci mezi nimi a Českou pojišťovnou. S aplikací pracují kromě obchodníků i pracovníci ČP. Aplikace
prošla v roce 2006 celou řadou úprav, proto bylo
vhodné věnovat pozornost i výkonnostnímu testování. Nejvýznamnější programovou úpravou
bylo spojení původní aplikace JOK ISP R2.1 s další
aplikací ISP PRU do jednoho celku.
Projektový tým
Vývoj nové verze aplikace JOK/ISP prováděla firma
SOFTEC. Přípravu zátěžového testu a jeho provedení zajišťoval smíšený tým složený z pracovníků ČP
a KOMIXu. Vyhodnocení zátěžového testu a návrh
úprav aplikace JOK/ISP dle výsledků ZT prováděl
tým složený z pracovníků ČP, SOFTECu a KOMIXu.
Výsledky každého běhu zátěžového testu byly pravidelně prezentovány určeným manažerům a specialistům ČP, kteří se k němu měli možnost vyjádřit. Tímto způsobem byla zajištěna široká diskuse
o dosažených výsledcích a korigován další postup
výkonnostního ladění aplikace JOK/ISP.
Prostředí pro zátěžový test
Pro ZT bylo v ČP vytvořeno testovací prostředí,
které se se svými HW a SW parametry blížilo produkčnímu prostředí včetně připojení diskového
pole o kapacitě 900 GB. Do tohoto prostředí byla
zkopírována produkční databáze aplikace JOK/ISP,
jejíž údaje byly pro tento zátěžový test anonymizovány, tj. osobní údaje osob v této databázi byly
upraveny tak, aby vyhovovaly zák. 101/2000 Sb.
o ochraně osobních údajů.
Výběr business transakcí
Business transakce pro zátěžový test byly vybrány pracovníky ČP v průběhu analýzy. Do výběru
byly zařazeny 4 transakce, které byly pro ZT použity v roce 2005, 2 nové transakce, které representují rozšíření aplikace o ISP PRU a 1 transakce, která byla navržena do ZT v r. 2005, ale nebyla při ZT
provedena kvůli problémům s daty pro tuto transakci. V analýze byl také navržen počet virtuálních
uživatelů (dále jen VU), kteří vybrané transakce
v průběhu ZT prováděli.
Pro zátěžový test byly stanoveny 2 postupové
cíle:
1. ověření výkonnosti aplikace při zatížení 400 VU
– základní referenční běh pro nasazení systému
do provozu
2. ověření výkonnosti aplikace při zatížení 1 000 VU
– maximální zatížení, které bude v rámci testu simulováno.
Rozložení počtu VU v jednotlivých transakcí
při zátěži 400 / 1 000 VU:
Tyto úpravy prováděl vývojový tým firmy Softec
s administrátory infrastruktury prostředí „JOK SystemTest“. Zásahy byly prováděny postupně na základě údajů získaných při jednotlivých bězích ZT.
1. Monitorování paměti
Byl sledován parametr „velikost volné operační
paměti“ pro DB servery, aplikační a webové servery.
Společným úsilím všech členů týmu se v posledních bězích zátěžového testu aplikace JOK/ISP již
podařilo splnit limity uživatelských odezev. V tabulce níže jsou pro srovnání uvedeny výsledky ZT
pro uživatelské odezvy jedné transakce při vybraných bězích ZT, na kterých je vidět k jak drastickému snížení uživatelských odezev došlo.
2. Monitorování CPU
Byl sledován parametr vytížení CPU pro DB servery, aplikační a webové servery.
3. Monitorování databáze
Vzhledem k požadavku na detailní monitorování
databází bylo pro sledování jejich výkonnostních
parametrů využito, vedle LoadRunneru, širokozáběrového nástroje Statspack, který je k dispozici na všech DB serverech. Pomocí Oracle monitoru LoadRunneru byly sledovány pouze základní
metriky databází. Detailní přehled o jejich výkonnostních parametrech byl získáván ze snímků pořízených nástrojem Statspack, který byl vyhodnocován specialistou na databáze Oracle.
Příprava a provedení zátěžového testu
V přípravné fázi zátěžového testu byla v analýze
definována struktura dat pro zátěžový test a stanoveno jejich množství v závislosti na počtu zpracovaných transakcí. Přípravu dat pro zátěžový test
provedl specialista ČP. Přípravu a odladění skriptů
pro vybrané transakce provedli pracovníci společnosti KOMIX a ČP.
V období čtyř týdnů bylo postupně realizováno celkem 8 běhů zátěžového testu. Po každém
běhu byly výsledky zátěžového testu vyhodnoceny a navrženy úpravy aplikace JOK/ISP.
Jelikož byla aplikace zátěžově testována již v roce
2005 a projektový tým měl k dispozici výsledky
těchto testů, mohl být realizován tzv. benchmarkový zátěžový test. Výstupem tohoto typu testu je
porovnání výsledků hodnot měření z roku 2005
s nově naměřenými hodnotami.
Prioritou a akceptačním kritériem ČP bylo, že naměřené hodnoty nesmí být horší než v roce 2005
a pro vybrané typy transakcí byly limitní hodnoty ještě sníženy. Konkrétní limity pro jednotlivé
typy uživatelských odezev jsou uvedeny v následující tabulce.
sledována celá řada HW a SW parametrů. Naměřené hodnoty těchto parametrů byly podkladem pro
rozhodnutí o úpravách aplikace. Kromě uživatelských odezev byly sledovány tyto parametry:
Monitoring v průběhu zátěžového testu
V průběhu zátěžového testu nebyly sledovány jen
uživatelské odezvy vybraných transakcí, pro něž
byla definována akceptační kritéria. Aby bylo možné aplikaci po výkonnostní stránce doladit, byla
Provedené ladící zásahy
V prvních bězích zátěžového testu byly zjištěny
závažné výkonnostní problémy, proto byly prováděny úpravy testované aplikace a nastavení infrastruktury prostředí za účelem dosažení požadované výkonnosti testované aplikace.
odezva na jednoduchý dotaz
složitější dotaz nebo přehled
čas přihlášení
zobrazení jednoduchého seznamu
či detailu
zobrazení odměn - jednoduché
zobrazení odměn - složité
zobrazení souhrnného přehledu
Kroky
Výkonnostní limit pro uživa- Výkonnostní limit pro uživatelskou odezvu aplikace (s)
telskou odezvu aplikace (s)
ZT v roce 2005
ZT v roce 2006
5
10 - 20
5 s z 80 %, 10 s z 20 %
5
5
10 - 20
5 s z 80 %, 10 s z 20 %
5
10
20
20
10
15
15
Celkové vyhodnocení zátěžového testu
JOK/ISP
Realizované běhy zátěžového testu aplikace
JOK/ISP v roce 2006 umožnily odhalení výkonnostních problémů této aplikace a infrastruktury
testovacího prostředí. Na základě těchto zjištění
byly učiněny úpravy aplikace a nastavení testovacího prostředí. Účinek úprav byl ověřen při referenčním běhu ZT, který prokázal schopnost aplikace obsloužit předpokládaný počet uživatelů při
zachování akceptovatelných odezev a zatížení infrastruktury testovacího prostředí. Následující běh
ZT potvrdil, že systém je schopen stanovené limity splnit i při 2,5 násobku předpokládaného špičkového zatížení.
Díky zátěžovému testu tak ČP získala výkonnou
a stabilní aplikaci.
Vlasta Vršecký
[email protected]
Odezvy transakce „Elektronická distribuce souborů“
Výkonnostní limity pro ZT aplikace JOK/ISP 3.1
Typ uživatelské odezvy aplikace
V tabulce jsou průměrné hodnoty odezev měřených kroků transakce „Elektronická distribuce
souborů“ během referenční zátěže, tj. plná zátěž
aplikace JOK/ISP bez náběhových a sestupných
vln uživatelů. Hodnoty a odchylky výkonnostních
limitů jsou barevně odlišeny. Hodnoty, které nepřekročily stanovené výkonnostní limity jsou zvýrazněny zelenou barvou a hodnoty, které překročily výkonnostní limity jsou v tabulce zvýrazněny
červenou barvou. Pro porovnání jsou v tabulce
uvedeny i hodnoty naměřené při zátěžovém testu této aplikace v roce 2005.
login
GUI 207
zadani 1 pozadavku
prehled_stah_souboru
prehled_pozadavku_2
stazeni_souboru
logout
Výsledky ZT v sec - průměrné hodnoty
2005
01.11. 2006
21.11. 2006
Limit
(134 VU+ navý- Plná zátěž 400 Plná zátěž 400
v sec.
šení na 268 VU)
VU
VU
5 z 80%,
1,5
57,763
0,497
10 z 20%*
5
1,155
99,674
0,085
15
1,349
93,02
0,07
22.11. 2006
Plná zátěž
1000VU
0,483
0,087
0,096
10
0,434
-
-
-
15
30,196
132,487
0,156
0,18
5
0,962
-
57,858
44,977
0,249
0,281
0,247
0,348
* limit pro transakci „login“ 5 sec. v 80% měření a 10 sec. ve 20% měření
5
Virtualizace testovacího prostředí
VMware Lab Manager (dříve Akimbi Slingshot)
Lab Manager řídí využití virtualizačních serverů používajících virtualizační software od VMware. Uživatelé si po přihlášení do portálu Lab Manageru vyžádají jakoukoli položku z konfigurační
knihovny. Může se jednat o nastavení jednoho
virtuálního serveru, typicky se ale používá nastavení celého souboru virtuálních serverů, nebo celého testovacího prostředí. Při objevení defektu
je možné vytvořit snímek celého prostředí a uložit ho do konfigurační knihovny pro pozdější zopakování chyby.
Asi každý už někdy slyšel výrok „běží to na véemvéru“. Není divu, virtualizace, tedy přístup ke zdrojům způsobem odlišným než jaký poskytuje jejich
fyzická existence, je používaná již od šedesátých
let minulého století - a to jak virtualizace zdrojů
(diskové pole tvářící se jako jeden logický disk,
cluster serverů vystupující jako jeden server), tak
virtualizace platformy (kompletní emulace HW
i SW, oddělená instance samostatného operačního systému).
V rámci tohoto článku se budeme zaobírat úvodem do virtualizace platforem, tedy vytvářením a správou virtuálních operačních systémů
se zvláštním přihlédnutím k nasazení virtualizace
v rámci testovacího prostředí. Nejprve si uvedeme základní virtualizační techniku – vytvoření obrazů (image). V zásadě jde o zaznamenání všech
dat v reálném systému. Z těchto dat je vytvořen
obraz, který je možné uložit, kopírovat a spouštět na virtuálním systému. Zaznamenaný a spouštěný obraz může být relativně jednoduchý a zachycovat pouze počáteční stav systému před
jeho spuštěním. Lze samozřejmě podobným způsobem zachytit stav systému v jakémkoli bodu
jeho činnosti, nebo dokonce zachytit nikoli pouze
daný stav v jednom okamžiku, ale celý kompletní
běh všech operací systému.
Udělejme nyní krok stranou a podívejme se na požadavky testovacího prostředí, tedy prostředí použitého pro provádění testů systému.
Základním předpokladem je oddělení testovacího prostředí od prostředí produkce. Tedy testování na něm by nemělo žádným způsobem ovlivnit funkčnost či data, které jsou použity na ostrém
provozu. Asi by zákazníka úplně nepotěšilo, pokud bychom na jeho reálném kontě testovali
funkčnost „zablokování účtu“, případně pokud by
se nám povedlo v průběhu testů celý systém položit na lopatky.
Dalším nutným předpokladem je, že testovací prostředí je co nejvíce podobné produkčnímu a to včetně dat. Pro otestování blokace účtu
prostě musíme mít účet, který můžeme zablokovat. Zároveň není vhodné, aby tato data byla zcela reálná. K datům na testovacím prostředí mívá
zpravidla přístup větší množství pracovníků, což
v kombinaci s nižším zabezpečením testovacího
prostředí může způsobit velmi nepříjemný únik
citlivých informací. O zákonu na ochranu osobních údajů nemluvě. Je tedy nutné naplnit testovací prostředí daty, která jsou buď čistě fiktivní nebo kopií produkčního prostředí, ale následně
znehodnocenou například zrušením vazeb mezi
konty, osobami, daty narození a rodnými čísly.
Je zřejmé, že příprava testovacího prostředí může
znamenat velké nároky na zdroje, zejména čas. Během samotných testů bude docházet ke změnám
v testovacím prostředí a to jak na datech (účty jsou
rušeny a zakládány), tak v konfiguraci (jsou generovány a zakládány certifikáty). Po prvním běhu testů jsou nalezeny chyby, nasazeny opravy a nastává
potřeba testy zopakovat. Abychom mohli provést
stejné testy a tudíž ověřit, že skutečně nastala změna k lepšímu oproti předchozímu stavu, musíme
uvést i testovací prostředí do původního stavu.
V jednodušším případě to znamená provést rollback databáze, v horším je nutné provést reinstalaci celého testovacího prostředí.
Pokud je použita virtualizace testovacího prostředí, jedná se o prosté nasazení prvotního obrazu
systému. Zároveň může virtualizace představovat
možnost jednoduchého provedení alternativního
scénáře - „Co když bude v tomto segmentu použit alternativní server/konfigurace?“ Na dané místo prostě nasadíme jiný obraz a můžeme provádět testy.
Virtualizace testovacího prostředí se tedy jeví jako
dobrý nápad. Je zde nicméně nutné počítat i s určitými nástrahami.
Hardware, který má být pro virtualizovaný systém
použit bude potřebovat vždy větší výkon, než HW
použitý na stejnou činnost bez virtualizace. Přece jen se zde jedná o jednu úroveň operací navíc.
Časté řešení je, že existuje menší množství výkonných serverů, z nichž každý simuluje více serverů
virtualizovaných.
Tím se dostáváme k dalšímu bodu a tím je alokace
zdrojů. Při virtualizaci prostředí je častou chybou,
že jsou jednotlivé virtualizované stroje rozděleny
po virtualizačních serverech podle svého umístění
v reálném prostředí. Lehce tak nastane případ, kdy
se na jednom virtualizačním serveru sejde většina
virtualizovaných systémů, zatímco výkon dalších
serverů je využit pouze z několika procent.
A samozřejmě jsou zde ještě požadavky testovacích týmů, z nichž každý mívá typicky jiné požadavky na zdroje, anebo (což je ten horší případ)
stejné požadavky na stejné zdroje v jeden čas. Situace, kdy máme pouze jedno testovací prostředí
pro více týmů není nikdy příjemná. Nicméně je to
situace velmi častá. Virtualizace nám úlohu ulehčuje - můžeme souběžně uspokojit rozdílné požadavky na testovací prostředí tím, že pro každý tým
nasadíme na virtualizační servery obrazy, které budou pro daný tým dedikovány. Na druhou stranu
se nám objevuje nová oblast k řešení – jakým způsobem zajistit, aby byla zátěž virtualizace rozumně
rozdělena v čase mezi reálné servery? Pokud se jeden tým zrovna věnuje týmbildingovým aktivitám
v blízkém restauračním zařízení, nemá smysl aby
byly blokovány zdroje, který by jiný tým rád využil.
Dostáváme se tedy k tomu, že nestačí pouze říci
„budeme virtualizovat“, ale musíme také určit
způsob správy virtualizovaného prostředí, stejně
(nebo možná ještě více) jako prostředí reálného.
Naštěstí nejsme odkázáni pouze na papír a tužku,
či jejich elektronické ekvivalenty. Na trhu je v současné době více řešení správy virtuálního prostředí. Z opravdu široké nabídky řešení jsem na závěr
pro alespoň stručné přiblížení vybral tři nejzajímavější. Místa se bohužel nedostalo na řešení IBM
Systems Director, Microsoft System Center Virtual
Machine Manager (zatím Beta 2), Opsware, Parallels, Virtual Iron a XenSource.
Surgient Virtual QA/Test Lab Management System (VQMS)
Základní funkce jsou obdobné jako u VMware
Lab Manageru, tedy nasazení, konfigurace a řízení většího počtu virtuálních systémů na základě
požadavků uživatelů. VQMS není omezen pouze
na virtualizačního software VMware, spolupracuje i s virtualizacemi GSX Server a Microsoft Virtual
Server 2005 (podpora Xen je ve vývoji). Navíc dodává rezervační systém, kdy si uživatel může zarezervovat pouze zdroje dostupné v daný budoucí
okamžik, administrátor VQMS může tuto rezervaci schválit, či v případě potřeby zrušit. Dalším rozdílem oproti VMware Lab Manageru je tvorba reportů, cílená hlavně na využití zdrojů. A to nejlepší
nakonec – VQMS je možné integrovat s HP TestDirector software (dříve Mercury TestDirector for
Quality Center), který řídí proces testování. Je tak
možné například svázat sadu testů spolu s požadavkem na konfiguraci prostředí, automaticky informovat o připravenosti prostředí pro testy atp.
Cassatt Cross Virtualization Manager (XVM)
Deklaruje „Vendor neutral solution“, tedy řešení
nezávislé na dodavateli. Zatím podporuje VMware (ESX, GSX a VMware Server), Xen (v následující
verzi) a Microsoft Virtual Server (ve vývoji). Zajímavostí XVM je monitoring serverů jak virtuálních,
tak reálných. Spolu s možností automatizovaného
managementu zdrojů se tak vytváří velmi flexibilní prostředí, kde v případě problémů na jednom
systému je přechod na jiný fyzický/logický systém
(případně jinou instanci/image) v rámci několika
minut a to v režimu 24/7.
Doufám, že jste nyní možnostmi, které virtualizace testovacího prostředí přináší, přímo nadšeni, ale že si zároveň uvědomujete možnou hloubku celé problematiky, a máte základní přehled
o možných řešeních, která jsou v současné době
na trhu.
Jan Kovanic
[email protected]
Čím nahradit křišťálovou kouli v IT praxi???
Společnost KOMIX se už hezkých pár let věnuje zátěžovému testování, tj. testujeme výkonnost aplikací před tím než jsou uvedeny do ostrého provozu. Za všechna léta praxe jsme realizovali
nebo pomohli realizovat desítky testů. Pokud bychom se pokusili spočítat, kolik z nich nebylo pouze v testovacím prostředí, ale přímo na cílovém
produkčním prostředí, nepotřebovali bychom ani
všechny prsty jedné ruky.
Těch pár výjimek se týkalo zcela nových implementací rozsáhlých informačních systémů, pro
které byla pořizována samostatná infrastruktura,
typicky nasazení SAP R/3. V ostatních případech
6
Obr. 1 - Model systému v HyPerformix IPS Performance Optimizer
jsme museli vystačit
s otestováním výkonnosti aplikace „v laboratorním“ prostředí. Notoričtí skeptici
/ škarohlídi / rýpalové, popřípadě dodavatelé aplikací*)považují testy na jiném
než produkčním prostředí za zbytečné,
nevypovídající, vyhazování peněz, ztrátu
času*).
Tak tomu samozřejmě není! Aplikace výkonnostně vyladěná na slabší konfiguraci prostředí se
bude nepochybně chovat v produkčním prostředí lépe než aplikace, o jejíž výkonnost se nikdo
nestaral.
Otázkou však zůstává, jak zjistit zda aplikace otestovaná na třetinovém počtu uživatelů bude potřebovat trojnásobný počet serverů, procesorů,
paměti atd., nebo se snad spokojí s dvojnásobkem? Nebo snad tak velký systém má tendence
sám sebe zahltit a budeme rádi pokud uspokojivých výsledků dosáhneme na čtyřnásobku? Někdy dokonce nemusí platit ani „kožené pravidlo“
o jistotě desetinásobku.
Odhady, porovnávání s podobnými projekty, sliby a přísahy dodavatelů systému, postupné nabíhání (je-li možné), záměrné předimenzování
(pro případ co kdyby?!) to jsou nejobvyklejší postupy zajištění dostatečné výkonnosti a stability
aplikace v provozu. Všechny z uvedených postupů se podobají věštění z křišťálové koule. Moderní IT manažer však nemůže spoléhat na kus skla,
musí opírat svá rozhodnutí o výpočty postavené
na solidních základech. Pokud takovým základem
je matematická teorie a praktická zkušenost promítnutá do modelovacího nástroje, který dokáže
s uspokojivou přesností „vypočítat“ budoucí výkonnost aplikace na základě modelu testovacího
prostředí, výsledku testu a modelu produkčního
prostředí, pak má IT manažer vyhráno!
mi účinné. HyPerformix vytváří a udržuje knihovnu „vlastností“ mnoha hardwarových zařízení
– serverů, síťových prvků apod., s jejímž využitím dokáže „přepočítat“ (správně namodelovat)
chování aplikace v cílovém prostředí z hodnot naměřených různými monitory v průběhu zátěžového testu.
Postup je ve stručnosti následující:
1. funkčně otestovaná aplikace je předána k zátěžovému testování
2. konzultant na HyPerformix vytvoří model testovacího prostředí, současně probíhají zátěžové testy a ladění výkonnosti
3. výstupy monitorů z průběhu testů společně
s modelem testovacího prostředí
jsou podkladem k určení výkonnosti různých konfiguračních variant produkčního prostředí
4. z modelů produkčního prostředí, které splnily výkonnostní parametry se k realizaci vybere některá
z variant, která splňuje i ekonomické zadání
Řešení společnosti HyPerformix dovolí navždy
zamknout křišťálovou kouli do skříně a začít pít
rozpustné kafe, protože už nebudeme potřebovat ani kávovou sedlinu.
Celá myšlenka je vlastně prostá, aplikační logika
je naopak velmi složitá, ale výsledné řešení vel-
Obr. 2 - Srovnání jednotlivých variant modelů podle výkonnosti a finanční náročnosti
Pro modelování mohou být využita i data z provozního monitorování, proto jsou možnosti modelování mnohem širší:
modelování konsolidace serverů
modelování dopadů migrace
na jinou HW platformu
modelování navýšení počtu uživatelů
plánování investic do HW i v horizontu let
Modelování je levné a poměrně rychlé. Výběr ekonomicky nejzajímavější varianty přináší významné úspory. Odložené nákupy serverů, jejichž ceny
stále klesají, mají pozitivní vliv na finanční toky
a na jejich výši.
Zkušenosti zákazníků HyPerformixu dokonce uvádí (pro nás až neuvěřitelnou) návratnost investice
již na prvním projektu!
Jestliže řešení HyPerformixu funguje v ABN
AMRO, AXA, Bank of America, eBay, France Telecom, T-Mobile, Toyota Motor Company a u mnoha dalších zákazníků po celém světě, proč by nemohlo fungovat i u nás?
--*) Nehodící se škrtněte
Dan Petřivalský
[email protected]
Agilní? Aha.
V hlubinách české IT kotliny to zatím tak nepůsobí, podívejte se však na webové stránky různých
softwarových magazínů, konferencí či sdružení a záhy můžete nabýt dojmu, že se naším vývojářským světem šíří trend, který lze s trochou nadsázky charakterizovat sloganem: „Be agile or die“.
Nejvýrazněji se tzv. agilní přístup ve vývoji softwaru prosazuje ve Spojených státech - odkud,
přiznejme si, pochází většina inovací v oblasti IT
- ovšem postupně se tato „infekce“ šíří do softwarových komunit v dalších zemích. Jako u všeho, co
je nové a hýbe světem, setkáte se jak s informacemi rozumnými (těch je většina), tak s názory zavánějící dogmaty a fanatismem (někteří potřebují ke svému životu absolutní pravdy). Následující
text si klade za cíl stručně vysvětlit základní myšlenky agilního přístupu a vyjmenovat metody,
které mají sloužit k jejich naplnění.
Jedno je jisté - agilní metody vznikly jako reakce
na často neúspěšné a po všech stránkách problematické obří softwarové projekty řízené klasickou
cestou (vodopádový životní cyklus, byrokratické
procesy projektového vedení, kvanta dokumentů a formálních postupů). Osobně si myslím, že
se jedná o (chvályhodnou) vzpouru dělnické třídy
(vývojářů) proti vrchnosti (management). Ti první mají dobré argumenty pro tvrzení, že ti druzí
vedou projekty špatně: z různých výzkumů totiž vyplývá, že 50% (některé zdroje
tvrdí 65%) softwarových projektů je neúspěšných či že pouze 20% implementovaných funkcí je intenzivně využíváno,
60% občas a 20% vůbec (některé studie
uvádějí dokonce ještě „horší“ výsledky).
Nejdůležitější myšlenky jsou shrnuty
do tzv. agilního manifestu, pod kterým
jsou podepsáni významní představitelé
a dlouhodobí propagátoři agilních metod. První z těchto idejí říká, že „lepší než
věnovat čas zavádění striktních metodických postupů a složitých nástrojů
pro vedení a realizaci projektu je zaměřit se na podporu práce jednotlivců a vzájemné interakce mezi nimi“. Jinými slovy: je navýsost důležité vytvořit
dobré, fungující a intenzivní vztahy mezi
členy týmu, mezi týmem a zákazníkem
i mezi týmem a managementem. Kvalitní lidé jsou
tím nejlepším prostředkem pro dosažení úspěchu
a proto jim musíme vytvořit pracovní podmínky,
které je budou motivovat, nikoliv mrhat jejich časem a schopnostmi pro naplnění samoúčelných
procesních postupů.
Podle druhého tvrzení „je lepší dodat funkční
software než stohy projektové dokumentace“.
V rámci projektu by tedy mělo vzniknout pouze
tolik dokumentace, kolik je nezbytně nutné pro
dosažení cíle – vytvoření provozuschopného systému, který uspokojuje potřeby uživatelů. Cílem
softwarového projektu má být totiž především
funkční software, nikoliv dokumentace.
Třetí myšlenka zní: „Lepší než strávit mnoho
času nad smluvním vyjednáváním je úzká spolupráce a dobré vztahy se zákazníkem v průběhu projektu“. Důvodem dlouhých a složitých
smluvních jednání je snaha obou stran mít dobrou pozici v situaci, kdy dojde k problémům a projekt se místo věcného řešení stane kořistí právníků. Není právě tím, jak se již od počátku obě strany
připravují na porážku druhého při případných obchodních sporech, položen základ vzniku skutečných problémů v průběhu projektu a neochota je
věcně vyřešit?
Poslední myšlenka, která má zároveň asi nejviditelnější dopad na průběh projektů, říká, že „lepší než se striktně držet dopředu stanoveného plánu je naučit se reagovat na změny“. Svět
kolem nás se rychle mění a co zákazník potřeboval před půl rokem mu dnes již k ničemu není.
A také je normální to, co rozčiluje vývojáře-juniory: teprve poté, co dáme uživateli vytvořený
software do ruky, je schopen říci, zda to opravdu chtěl, popř. zda vývojáři pochopili, co vlastně
chtěl. Z uvedených důvodů se nejeví být rozumné
„zakonzervování“ uživatelských požadavků v počáteční (analytické) fázi projektu, jak je zvykem
ve vodopádovém životním cyklu. Dokonce jsem
slyšel názor, že „na konci dobrého agilního projektu je vytvořeno něco jiného, než se plánovalo na začátku – a všichni zúčastnění jsou s výsledkem spokojeni“. A ještě jedna myšlenka: „Je mojí
konkurenční výhodou, když dokážu snadno zrealizovat nový uživatelský požadavek i v pozdní fázi
projektu.“
Jaké konkrétní postupy lze tedy označit jako agilní? Je to především iterativní vývoj neboli postupné vytváření drobných přírůstků systému,
které se průběžně dávají k dispozici uživatelům.
Dlouhodobý plán existuje pouze v podobě základních vizí, detailní plánování činností se provádí na dobu obvykle několika týdnů
– pro potřeby jedné iterace. Na začátku projektu se nevytvářejí všeobjímající analýzy a rozsáhlé návrhy veškerého
fungování systému. Průběžně se udržuje seznam hrubě definovaných požadavků, podrobně se však analyzuje
a navrhuje pouze to, co je potřeba pro
realizaci v rámci jedné iterace.
Výběr funkcí, které budou v daném přírůstku vytvořeny, je striktně dán podle
priorit, které definuje zákazník. Naopak
kolik se toho v rámci dané iterace udělá, rozhoduje primárně vývojářský tým.
Typická logická námitka zní, že přírůstkovou metodou bez detailního počátečního návrhu může jen stěží vzniknout robustní systém s kvalitní vnitřní
architekturou. Argumentem proti bývá,
že stejně dopředu nevím, co přesně budu potřebovat, a navrhovat na začátku příliš složité a komplexní řešení je plýtváním času. Nic není univerzálně platné – jistě jsou systémy, kde rozsáhlejší
počáteční návrh jádra řešení těžko můžeme vynechat (systémy založené na metadatech, s vysokým důrazem na bezpečnost apod.). S iterativním
přístupem úzce souvisí programátorské metody, které je třeba zavést, aby agilní projekt mohl
být úspěšný: automatizované testy (jak jednotlivých funkcí či komponent, tak integrační), refactoring (průběžné zdokonalování již vytvořeného
kódu) či průběžná integrace kódu.
Zmenšení objemu psané dokumentace (především programátorské) je kompenzováno jednak
přímou účastí zákazníka ve vývojářském týmu
a rovněž větším povědomím o vnitřním fungování systému všemi členy týmu. Toho se dosahuje pomocí společného vlastnictví kódu (žádný
kus kódu není výlučně přidělen jednomu vývojáři), párového programování (vývojáři programují
ve dvou), definování standardů psaní kódu nebo
použití metafor (samovysvětlující názvy metod,
tříd apod.). Z hlediska budování kvalitního týmu
je důležitá úzká vazba mezi jeho členy (a to i fyzicky např. sezením ve společných prostorách), pravidelné schůzky (nejlépe denní) hodnotící aktuální
postup prací, pravidelné retrospektivy (zhodnocení a hledání cest ke zlepšení práce týmu) na konci každé iterace – nikoliv až na konci projektu (!),
sblížení profesí (není striktně oddělena práce analytika, návrháře, vývojáře a testera).
Na závěr si dovolím ještě krátkou úvahu, na jaké
typy projektů se agilní přístup určitě hodí. Je to
především tehdy, když jsou vágně definované uživatelské požadavky, když vzniká pro daného zákazníka nový typ systému, se kterým nemá zkušenosti, když jsou součástí řešení nové, v praxi
dosud málo prověřené technologie. Popřípadě
když se jako dodavatel necítím příliš silný v použité a u konkurence dobře zvládnuté technologii.
Zákazníkovi však potom musím použití agilního
přístupu asi zdůvodnit nějak jinak :-).
Petr Sobotka
[email protected]
7
Jak se strefit do potřeb zákazníka
Jak zajistit aby zákazník dostal takový software,
který skutečně potřebuje – to je dlouhodobý problém softwarového inženýrství, který vyvolává
snahu o stálé zlepšování metod vývoje aplikací.
Snaha strefit se do potřeb zákazníka někdy připomíná střelbu na pohyblivý cíl, který se postupně
vynořuje z mlhy nejasností. Jaké jsou možnosti
řešení a jak se v posledních letech mění pohled
na tuto problematiku?
Důvody změn a upřesňování požadavků mohou
být různé:
 Potřeba a cíl se objektivně mění (změna legislativy, reakce na požadavky trhu).
 Stupeň porozumění požadavkům se v čase mění:
Dodavatel plně neporozuměl požadavkům,
není odborníkem v řešené problémové oblasti. Požadavky se nemění, mění se stupeň
jejich porozumění dodavatelem.
Zákazník postupně upřesňuje své požadavky tak, aby se kryly s jeho skutečnou potřebou (ani precizně specifikovaný požadavek
nemusí odpovídat skutečné potřebě zákazníka), zákazník si postupně uvědomuje, co
přesně chce.
Ve vnímání změny došlo k posunu. Dříve byla
změna vnímána především jako chyba nedostatečného předvídání ve fázi analýzy a návrhu. Nyní
je změna vnímána jako přirozená nebo až jako vítaná pro zákazníka, který má možnost dolaďovat
své požadavky.
Stará známá poučka říká, že čím později v životním cyklu vývoje SW se požadavek na změnu objeví, tím jsou náklady na provedení změny vyšší.
Je zde riziko, že když se nestrefíme do terče, tak
nové míření a výstřel budou dlouho trvat a budou
pracné a drahé.
Prvním způsobem střelby je tedy
Pečlivě zamířit
Cílem při určování požadavků zákazníka je co nejdříve získat zpětnou vazbu od zákazníka, že požadavky jsou úplné a dodavatelem správně pochopené a že specifikace navrhované aplikace míří
na správný cíl. Aby zákazník mohl takovouto zpětnou vazbu poskytnout dříve než vystřelíme (tj.
naprogramujeme a nainstalujeme do testovacího prostředí zákazníka), musí zákazník specifikaci navrhované aplikace rozumět a musí si ji umět
představit.
Oproti původní deklarativní formě specifikace požadavků (věty typu „Systém umožní …“) se v posledních letech preferuje forma popisu případů
použití (use case), které jsou postupně zpřesňovány od popisu cíle až po popis jednotlivých kroků prováděných uživatelem a podobají se tak uživatelské příručce včetně prototypu obrazovek.
Ve snaze vyprovokovat zákazníka ke zpětné vazbě se někdy doporučuje psát případy použití ve 2.
osobě, tedy místo „Uživatel zaeviduje adresu zákazníka“ napsat „Zaevidujete adresu zákazníka“.
Poněkud exotickým doporučením je místo uživatelských rolí používat role personifikované a při
popisu klást důraz na motivaci uživatelů – tím
přesvědčit zákazníka o důvodech a výhodnosti
navrhovaného řešení.
Toto se týká především popisu těch případů použití navrhovaného systému, kde uživatelem je zákazník zákazníka. Například v případě internetového obchodu: „Maruška se tak těšila na novou
ledničku, že ve spěchu při zadávání adresy nezadala číslo orientační, systém ji ale na chybu upozornil a červeným rámečkem označil nesprávně
vyplněné pole formuláře.“
Přesto ani od naprosto srozumitelné specifikace
ani od prototypu nelze očekávat, že zpětná vazba
zákazníka předejde nesprávnému zamíření, protože cíl se pohybuje.
„Systém umožní definovat atributy nového produktu a definovat transformaci těchto atributů“.
Pokud má dodavatel dostatek podkladů pro zobecnění, tj. má možnost porovnat způsoby řešení
problematiky v jiných projektech nebo v minulosti, může přístup parametrizovatelné řízené střely
významně ušetřit náklady na změnu. Na druhou
stranu v případě nutnosti úprav neprůhledného
systému řízeného metadaty mohou být náklady
větší než v případě evolučního přístupu doporučovaného agilními metodami.
Samonaváděcí střela
Je přístup, kdy navrhovaný software je vybaven
mohutným parametrizovatelným mechanismem,
který upraví chování aplikace podle okamžitých
potřeb zákazníka. Díky tomu neunikne ani pohybující se cíl. I tento přístup má svá rizika. Dodavatel
stojí před rozhodnutím, zda se pokusit navrhnout
mechanismus, který by možná mohl řešit i budoucí dosud neznámé požadavky bez zásahu do aplikace pouhým nastavením parametrů, nebo zda
řešit co nejjednodušeji pouze dobře známé požadavky. V tom případě si sice nové požadavky vyžádají zásah do aplikace, je ale na zvážení, co bude
větším rizikem: zásah do aplikace a doplnění nové
funkcionality do jednoduchého a přehledného
návrhu nebo riziko, že složitý univerzální mechanismus není dostatečně univerzální a jeho úprava bude nákladnější než evoluční přístup. Dříve
jednoznačně preferovaná snaha předcházet změnám aplikace vedla až do extrému, takže v „uživatelských“ požadavcích se mohlo objevit něco jako
Kulomet
Studie „Chaos Report“ zpracovaná Standish Group
na základě vyhodnocení mnoha projektů odhalila, že 45% funkcionality “úspěšně“ dokončených
projektů zákazník nikdy nepoužívá, dalších 19%
jen občas. Není to plýtvání? Není to střelba z kanónu na vrabce? Agilní metody proto považují
detailní specifikaci požadavků za zbytečnou. Dokonce takovouto činnost uvádí jako antipattern
(tedy odstrašující příklad slepé uličky) označovaný zkratkou BRUF (Big Requirements Up Front).
Dávají přednost postupu, kdy požadavek je popsán na kartičce formou User Story (tj. 1 – 2 věty
kterým uživatel rozumí. Je zde však omezení, že
realizace požadavku nesmí přesáhnout 10 dnů).
Skutečnou zpětnou vazbu od zákazníka lze očekávat až po dodání alespoň malé, ale funkční části softwaru. Místo zdlouhavého míření tedy začít
střílet co nejrychleji za sebou a na základě zpětné
vazby iterativně reagovat na upřesnění požadavků. Prioritu požadavků a tím obsah dalších inkre-
mentů určuje zákazník v průběhu vývoje, takže by
se nemělo stát, že bude dodána zbytečná funkcionalita. Ve výsledku může být cíl zasažen dávkou
z kulometu dříve než zdlouhavým mířením. Překážkou tohoto postupu je v praxi nejobvyklejší
sjednávání smluv s pevnou cenou, pevným termínem a pevným rozsahem, kdy na jedné straně
zákazník nechce kupovat zajíce v pytli a na druhé straně dodavatel, který nese riziko překročení
nákladů, potřebuje co nejpřesněji specifikované
požadavky jako podklad k odhadnutí pracnosti.
Přesto lze tento iterativní postup použít interně
v organizaci dodavatele pro získání zpětné vazby
z jednotlivých kroků vývoje.
Ani jeden z výše uvedených způsobů střelby není
univerzálně použitelný v libovolné situaci. V případě, kdy zákazník přesně ví co chce a dodavatel
má zkušenosti s řešenou problematikou, je možné dobře zamířit a strefit se. Stejně tak v případech, kdy aplikace komunikuje s mnoha okolními
aplikacemi, je nutné předem pevně stanovit aplikační rozhraní, na kterých je závislý vývoj ostatních aplikací a nelze střílet od pasu. Naopak v případě projektu s vyšší mírou neurčitosti nabývá
na významu iterativní přístup. Snahou dodavatele
je vždy zvážit výhody a nevýhody a vybrat nejlepší postup. Nutnou podmínkou je v každém případě kompetentní a motivovaný garant řešené problematiky na straně zákazníka.
Tomáš Vahalík
[email protected]
Tvorba a využití katalogu uživatelských požadavků
V průběhu vývojového cyklu SW dochází někdy
k postupnému odklonu od požadavků zákazníka některé požadavky jsou plněny jen částečně a některé nejsou plněny vůbec. Místo toho jsou dodavatelem často řešeny problémy automatizovaných
kontrol dat, o nichž zákazník vůbec nemluvil (dodavatelem uměle vytvořené požadavky).
Tyto případy končí implementací, ve které mohou
chybět klíčová data nebo jejich zpracování. Automatizované kontroly dat, doplněné dodavatelem,
často omezují využití systému.
Katalog uživatelských požadavků (dále jen KUP)
není universální všelék na popsané příznaky, ale
pomáhá odstranit ty nejhorší následky. V článku popsané rozšíření katalogu omezuje odklon
od původních uživatelských požadavků v průběhu vývojového cyklu SW.
8
Základní podoba katalogu uživatelských požadavků
Při tvorbě SW se KUP používá především pro popis chování systému (dynamický model) a datové
struktury (statický model). Typický katalog obsahuje především následující kapitoly:
 popis okolí systému (externí systémy, uživatelské role)
 požadavky na chování systému (dynamický
model)
 požadavky na data systému (statický model)
 ostatní požadavky (bezpečnost, výkon, spolehlivost, použité technologie, kvalifikace obsluhy, ...)
 číslo požadavku (jednoznačný identifikátor)
 název požadavku (stručný, ale výstižný)
 popis požadavku (volným textem nebo s pomo-
Každá z uvedených částí KUP je popsána strukturovaným textem ve formě tabulek. Každý požadavek je popsán sadou atributů. Mezi nejčastěji používané základní atributy požadavku patří:
Často je použita hierarchická struktura – požadavky
na chování bývají sdružovány do procesů, požadavky na data jsou sdružovány do jednotlivých skupin
dat (třídy a relační tabulky budoucí implementace).
cí odrážek)
 priorita požadavku (obvykle stačí tři stupně)
 stav řešení požadavku (v rámci vývojového
cyklu SW)
 datum poslední změny stavu požadavku
 jméno autora požadavku
Uvedené atributy tvoří sloupce tabulek (je možné sdružovat několik atributů do jediného sloupce), řádky tabulek pak představují jednotlivé požadavky.
Obr. 1 – Základní podoba KUP
KUP používá výhradně terminologii zákazníka –
používání termínů z oblasti IT technologií není
vhodné (výjimkou mohou být například požadavky na využití stávající technické infrastruktury).
Strukturu KUP je možné použít v nezměněné podobě po celou dobu života SW aplikace. Ve fázi prvotní tvorby SW KUP neslouží k detailnímu popisu
systému – nenahrazuje analytickou dokumentaci. Soustřeďuje se na klíčové požadavky na úrovni akceptačních kriterií. Priorita požadavku přitom
pomáhá oddělit zásadní požadavky od požadavků podružných a v případě potřeby rozdělit projekt na několik realizačních etap. Ve fázi údržby
SW jsou do KUP naopak zapisovány detailní požadavky zákazníka (požadavky na opravu chyb a požadavky na doplnění a změny). V tomto případě
umožňuje priorita třídit zásobník požadavků takovým způsobem, aby bylo vždy jasné, které požadavky mají v realizaci úprav přednost.
cyklu SW – analýzu a návrh. Dále popsané rozšíření však pomáhá zvýšit kvalitu i v dalších fázích
– například při testování a tvorbě uživatelské dokumentace.
Pro každou fázi vývojového cyklu je vhodné vytvořit v KUP nový atribut (sloupec tabulky) s odkazem do příslušné fáze:
 analýza (odkaz na kapitolu dokumentu s popisem rozhraní, procesu, třídy)
 návrh a implementace (odkaz na modul, třídu,
databázovou tabulku)
 testování (odkaz na testovací scénář)
 uživatelská dokumentace (odkaz na kapitolu
s popisem obsluhy požadavku)
Na KUP navazuje analytická dokumentace, která doplňuje detailní popis a diagramy (ARIS, IDEF,
UML, ...). KUP by se dal přirovnat k základům stavby budoucího systému – všechny ostatní fáze vývojového cyklu SW jsou „postaveny“ na KUP.
Rozšířená podoba katalogu uživatelských požadavků
Uvedená základní podoba KUP slouží především
pro bezprostředně navazující fáze vývojového
Automatizovaná podpora katalogu uživatelských požadavků
Často bývá KUP vytvořen na sdíleném disku s pomocí nástrojů MS-Office (Word, Excel, Access).
Existují však specializované nástroje, které mají
své nesporné výhody.
Závěr
KUP opravdu není všelék – neřeší nic za uživatele.
Je to však užitečná pomůcka – podobně jako diář
připomíná uživateli podstatné události v průběhu
všech fází vývojového cyklu SW.
V oblasti tzv. „RE Tools“ (Requirements Engineering Tools) existuje celá škála nástrojů od jednoduchých a levných až po nástroje drahé a složité (ty se používají například pro vývoj vesmírných
a vojenských technologií).
I ty nejjednodušší specializované nástroje umožňují:
 řízený přístup ke KUP (správu přístupových práv
uživatelů)
 sdílení dat s podporou zámků zpracovávaných
požadavků (současná práce několika uživatelů)
 tvorbu uživatelských atributů (rozšíření KUP)
 výběr sloupců pro zobrazení
 výběr řádků pro zobrazení (výběrová kritéria
na základě hodnot atributů)
 tvorbu hypertextových odkazů na externí dokumenty (rozšíření KUP)
Obr. 3 – Zvýšení kvality v průběhu vývojového cyklu SW
Při realizaci větších projektů je použití jednoduchého a levného specializovaného nástroje rozumným kompromisem.
Milan Číha
[email protected]
Obr. 2 – Rozšíření KUP
Service Desk ve společnosti KOMIX
Zavedení služby Service Desk znamená především
pomoc při řešení problémových nebo chybových
situací, které se vyskytují například u zákazníků
na dodaných produktech nebo službách. Service
Desk však může také sloužit pro interní podporu
a řešení požadavků vlastních zaměstnanců. V rámci Service Desk je tak možné řešit jednotlivé požadavky nejen v oblasti informačních technologií,
ale také v ostatních odvětvích, které vyžadují stálou a včasnou podporu zákazníků nebo interních
pracovníků - například v obchodě, výrobě, dopravě, telekomunikacích, bankovnictví.
Ve společnosti KOMIX s.r.o. jsme od března roku
2007 začali používat aplikaci OTRS (Open source Ticket Request System), která slouží pro správu požadavků v našem firemním prostředí, v rámci poskytování služeb Service Desk. Systém OTRS
používáme jak pro interní, tak i externí řešení problémů a požadavků. Tento Open Source systém
jsme lokalizovali do českého jazyka a provedli jeho nastavení a přizpůsobení identifikovaným
požadavkům. Pomocí tohoto systému řešíme jak
interní nákupy, tak i technické problémy a veškeré požadavky na IT v naší společnosti. Dále tento
systém využíváme pro externí zákazníky na technickou podporu projektů a produktů společnosti
KOMIX. Všechny požadavky, jejich přidělení k řešení, termíny a historie řešení je ukládána do databáze, takže není problém jakýkoliv požadavek zpětně
dohledat, zjistit jeho aktuální stav a průběh řešení.
Je to opravdu mocný nástroj, který ušetří spoustu
času při řešení požadavků od interních uživatelů
nebo zákazníků a zrychlí komunikaci mezi nimi a
zkrátí tak čas potřebný pro řešení jednotlivých požadavků.
Service Desk tak spojuje zákazníka a řešitele problému a je garancí jednotného rozhraní jak pro zákazníka, tak i pro řešitele, včetně podpory zvýšení
kvality poskytovaných služeb.
Popis systému OTRS
OTRS je Open Source webová aplikace, která
může být použita s jakýmkoliv HTML-kompatibilním prohlížečem. Pro komunikaci lze samozřejmě
využít i poštovního klienta. V systému OTRS je implementováno E-mailové rozhraní, které je konfigurovatelné (blíže viz vlastnosti OTRS). Vlastní
webové rozhraní OTRS nepoužívá aktivní webový obsah jako Flash nebo Java applety, takže lze
do něho přistupovat i přes PDA nebo mobilní telefony. Pro přístup do OTRS není potřeba instalovat
žádného speciálního klienta a uživateli stačí pouze HTML prohlížeč. Systém je vhodný pro všechna řešení, kde je potřeba vyřizovat rychle příchozí
požadavky od zákazníků jako je interní podpora IT
společnosti, technická podpora zákazníků aj. Systém je napsaný v jazyku Perl, takže běží na kterékoliv platformě, pro kterou existuje Perl. Systém
používá jako primární databázi MySQL, ale je možné použít též MS SQL, ORACLE nebo PostgreSQL.
Základní přehled vlastností systému OTRS je popsán níže.
Před implementací Service Desk je potřebné popsat a definovat především katalog služeb a na něj
navazující přesně popsané typy všech požadavků
s konkrétními parametry služby. Dále pak je potřebné stanovit řešitelské skupiny, jejich role, dostupnost řešitelů a eskalační procedury. Tyto informace pak slouží pro vlastní nastavení celého
systému dle požadavků zákazníka.
Vlastnosti systému OTRS
Webové rozhraní
 Jednoduché a přehledné ovládání přes web
rozhraní
 Není potřeba aktivní webový obsah jako Flash
nebo Java
 Systém je možné administrovat i přes web rozhraní
 Řešitel a zákazník (zadavatel požadavku) komunikuje přes web rozhraní
 Web rozhraní zákazníků zahrnuje napsání nového požadavku, sledování stavu požadavku,
připsání dalších požadavků do již odeslaného
požadavku a vyhledávání již vyřešených požadavků
 Podpora mnoha jazyků
K požadavkům lze připojit i přílohy (systém

podporuje jakékoliv typy příloh)
 Maily mohou být filtrovány dle záhlaví přímo
 Přidání vlastní poznámky do požadavku, po-
do vybrané fronty v systému
 Podpora šifrování PGP, vytvoření nového klíče
nebo vložení svého, podepsání a šifrování odchozích mailů
 Podpora zobrazení a šifrování S/MIME (Secure
Multipurpose Internet Mail Extensions) zpráv,
správa S/MIME certifikátů
 Automatické odpovědi pro zadavatele, konfigurovatelné pro veškeré fronty v systému
 E-mail notifikace pro řešitele o novém požadavku, o změně stavu, o nových poznámkách u požadavků
 Notifikace obsahují odkaz přímo na požadavek
(požadavek lze jedním klikem zobrazit)
známka může být interní nebo externí (u externí ji vidí i zadavatel požadavku), lze připojit
i další přílohy
 Detailní zobrazení požadavku
 Přesun požadavku do jiné fronty
 Zaslání požadavku na jinou E-mailovou adresu
 Změna priority u požadavku
 Provedení hromadné akce u více požadavků
(např. změna fronty nebo stavu)
 Požadavek lze odložit a nadefinovat dobu čekání na vyřízení
 Podrobné vyhledávání požadavků dle obsahu
 Sledování průběhu práce s požadavkem
Požadavky (Tikety)
 Rozšířené zobrazení front a jejich vlastností,
rychlý přehled o novém požadavku v jednotlivých frontách
 Požadavek může být zamknut, slouží pro řešení
jedním řešitelem
 Lze nastavit automatické odemknutí požadavku po uplynutí stanoveného času
 Eskalace požadavků
 Tvorba vlastních automatických odpovědí
 Detailní sledování historie požadavku (informace o čase, kdy se stala jaká akce, např.: změna
stavu, vlastníka, vložení nová poznámka atd.)
 Tisk požadavku
 Programovací jazyk Perl
 Databáze MySQL
 Podpora ASP (Activ Service Providing)
 Rozhraní databáze XML
 Databázové vrstvy, podpora jiných SQL databá-
Systém
zí (MySQL, PostgreSQL, MaxDB/SAPDB, Oracle a
DB2)
Domovská stránka: http://otrs.org/
http://www.komix.cz/Podpora/ServiceDesk.aspx
http://servicedesk.komix.cz/
Petr Ebr, Jaroslav Kahoun
[email protected]; [email protected]
E-mail rozhraní
 Podpora příloh (podpora MIME)
 Automatická konverze z HTML do prostého textu (lepší ochrana proti nebezpečnému obsahu
a umožňuje rychlejší vyhledávání)
9
Chraňte si svou identitu!
Dnešní svět neustále skloňuje mobilitu a bezpečnost. Lidé čím dál častěji provádějí finanční transakce pomocí elektronických zařízení, potřebují být ve styku se svou firmou bez ohledu na to,
kde se právě nalézají nebo třeba pracují z domova. Ve všech těchto případech nějakým způsobem
prokazují svou identitu a oprávnění tyto činnosti vykonávat. Je-li takové prokázání jednoduché
(např. login pomocí jména uživatele a hesla) nebývá často dostatečně zabezpečené a identitu
uživatele lze zcizit a zneužít.
Vyšší úroveň požadavků na zabezpečení vede
ke složitějším postupům; obvykle uživatelsky nepřívětivým.
V této situaci přichází společnost KOBIL se svým
přelomovým patentovaným řešením mIDentity. mIDentity je USB zařízení velikosti flash paměti, které kombinuje kryptovanou paměť, ROM paměť, která se chová jako bootovatelné CD, Smart
kartu velikosti SIM karty a může mít i RFID chip.
Jediné malé USB zařízení umožní, abyste se bezpečně identifikovali (PKI + PIN) a bezpečně přihlásili do vaší firemní sítě včetně zabezpečení šifrované komunikace nebo abyste zašifrovali disk svého
notebooku, adresáře nebo soubory. Po připojení
k počítači se automaticky spustí aplikace umístěná na zařízení (není třeba administrátorské oprávnění). Protože je umístěna na ROM paměti, nelze
ji zavirovat a díky patentované technologii ji lze
provozovat i na zavirovaném PC, aniž by viry měly
šanci vám „ukrást“ vaše přihlašovací jméno a heslo – vaši identitu.
Díky tomu, už s sebou nemusíte na cestách nosit
notebook, ale s tímto maličkým zařízením se do firemní sítě připojíte třeba z internetové kavárny.
Můžete spustit SAP klienta a podívat se, jak běží
obchod ve firmě nebo vzdáleně provést potřebné operace.
V některých konfiguracích je možno si transakce
(třeba bankovní) připravit off-line a po připojení k internetu je centrálnímu serveru jen předat
ke zpracování.
Výrobce nabízí kompletní řešení problematiky včetně zabezpečení distribuce koncovým uživatelům.
Můžete využít tři nezávislé kanály – jedním jde vlastní HW zařízení s nahranou aplikací, druhým SIM karta a třetím PIN. Technologie počítá i se ztrátou zařízení nebo s tím, že uživatel zapomene PIN nebo heslo.
Použil-li zařízení k šifrování dat, lze data odšifrovat
náhradním klíčem, uloženým na bezpečném místě
(třeba bankovním sejfu).
Kapacita paměti pro vaše
vlastní aplikace
Kontrola vstupu a registrace času
Vysokokapacitní
rozhraní USB 2.0
Zabudovaná bezinstalační mobilní
aplikace
Zdařilá konstrukce, pevné
pouzdro, kompaktní, nosí se
na kroužku s klíči
Vysoce výkonná čtečka karet Smart Card Reader ve formátu SIM
karty, včetně E4-high-evaluated smart karty
Obrovskou výhodou je snadnost užití. Uživatel
jen zasune zařízení do USB portu, vyplní PIN a vyčká, až se spustí aplikace. Ta se sama přihlásí k vybranému serveru nebo přímo na počítač uživatele
v jeho kanceláři a po případném klasickém loginu, může uživatel okamžitě pracovat. Po odpojení nezůstanou v paměti počítače žádná data, s nimiž uživatel pracoval.
američtí vojáci i síly NATO a také řada komerčních
organizací nebo banky.
Více detailů lze najít na www.komix.cz.
Nenechte si nikdy vzít svou identitu, chraňte si ji!
Petr Kučera
[email protected]
Na mIDentity lze provozovat certifikovanou zabezpečenou diplomatickou poštu, používají je
Co nového v Clarity?
Na začátek malé připomenutí. Co je to systém Clarity? Clarity je produkt firmy CA a jedná se o komplexní systém pro správu projektů a podnikových
portfolií. Prostřednictvím správy projektů, programů, zdrojů, finančních toků a procesů poskytuje pracovníkům a manažerům podklady pro
vytváření optimální strategie firmy. Na druhé straně pomocí zpětné vazby o realizovaných pracích
a nákladech informuje o skutečném průběhu probíhajících projektů a umožňuje tak porovnávat
plány firmy s realitou.
V současné době je nově distribuován systém Clarity ve verzi 8.0. Od předchozí verze (ta má označení 7.5.3) se neliší pouze kosmetickými úpravami.
Naopak. Systém přináší poměrně razantní změny.
Uživatel si tak bude muset zvyknout na novou
strukturu některých informací a naučit se využívat rozšířenou funkcionalitu nové verze. Nicméně
se jedná o změny, které jsou systému ku prospěchu a buď rozšiřují jeho možnosti, nebo umožňují
snazší práci s produktem. Clarity je modulární systém a změny jsou patrné napříč všemi moduly.
Systém CA Clarity se v posledních letech pravidelně umisťuje na špičce hodnocení průzkumů prováděných celosvětově uznávanými agenturami.
Vedoucí pozici si udržuje i v roce 2007, jak vyplývá
z průzkumu porovnání Magic Qaudrant for IT Project and Portfolio Management 2007 společnosti
Gartner Inc., uveřejněné v 6/2007.
Nejprve ve stručnosti projdeme nejdůležitější změny v jednotlivých modulech produktu
a poté se podrobněji zaměříme na správu portfolií. S trochou nadsázky můžeme říci, že portfolia
jsou v systému Clarity tou pověstnou „třešničkou
na dortu“. Modul portfolií je velmi lákavý pro top
management, obsahuje totiž důležité informace,
nutné pro další rozvoj a směrování firmy. Podává
nejen přehled o jednotlivých projektech, potřebných finančních, či lidských kapacitách, návratnosti investic, ale také přehledně umožňuje uživatelům v předstihu řešit situace typu „co když“
a takto vybírat optimální variantu rozvoje firmy
porovnáváním jednotlivých scénářů. Tyto scénáře mohou představovat různé směry rozvoje firmy, kde jsou zohledněny vazby na cíle firmy, rizika, časové rozložení finančních a lidských zdrojů,
návratnost investic a jiné.
Pro udržení této pozice společnost CA v minulých
12 měsících zdvojnásobila vývojový tým (z 55
na 110 vývojářů) a stejně tak i tým produktové
podpory (z 89 na 171 pracovníků).
Za uplynulý rok si Clarity koupilo celosvětově 243
nových zákazníků, celkem tak jejich počet překročil 700.
10
Novinky, změny a vylepšení ve verzi 8.0.
 Vylepšený Portfolio Management
 IT Portfolio Management
 IT Financial Management
 Business Relationship Manager
 Departments
 Vylepšený Resource Management
 Vylepšený Schedule in the Browser
 Audit Trail
 Vylepšený Business Process Manager
 Novinky v Clarity Studio
 Integrace s dalšími CA produkty
Nové vlastnosti
Project Portfolio Manager (ve verzi 7.5.3 nazývaný Portfolio Manager) – v portfoliích je nyní
možné pracovat i s Návrhy (Ideas), portfolia mohou oproti verzi 7.5.3 zohledňovat zdroje a jejich
kapacity. Novinkou je také přímé porovnávání
scénářů na jedné stránce, kde má uživatel možnost porovnat vedle sebe data a grafy jednotlivých variant. Nově koncipovaná nástrojová lišta umožňuje rychle měnit porovnávané varianty
portfolií (varianty typu „Co když“).
Protože IT oddělení ve firmě má svá specifika, Clarity ve verzi 8.0 toto zohledňuje třemi novými moduly: IT Portfolio Manager, IT Financial Manager
a Business Relationship Manager.
IT Portfolio Manager obsahuje nový objekt nazvaný „Service“ (Služby), který je používán ve spojitosti s investicemi v IT (nabídky IT služeb, potřebné investice, vytváření portfolií z těchto služeb).
IT Financial Manager je modul zohledňující finanční ocenění IT služeb (schvalování rozpočtu,
plánování nákladů a plánování výnosů). Podporuje rozpočtování a plánování IT služeb.
Business Relationship Manager obsahuje zákaznický a dodavatelský portál (vazby mezi zákaz-
níky a IT, SLA, náklady, výnosy, cíle, zdroje). Nabízí
přehled o využívaných IT službách a s nimi spojených nákladech.
Departments – do systému byl přidán nový objekt „Department“. Na tuto úroveň (odbor, oddělení) je možno vázat náklady, portfolia, plánování
kapacit, služby apod. Nahradil FOS (finanční organizační strukturu) známou z verze 7.5.3 se současným zachováním vztahu Entity – Department
– Location.
Resource Management (správa zdrojů) má různá
vylepšení, změny jsou patrné ve „Staff“
(personál), požadavcích na zdroje a plánování kapacit.
 Ve „Staff“ je možné přidávání znalostí
zdrojů, používání klíčových slov, příjemnou změnou je možnost vícenásobného
přidávání stejné role do projektu a dále
přidávání, nebo změna účastníků týmu
podle organizační struktury.
 V požadavcích na zdroje jsou vylepšeny přehledy, postupy a sdělení.
Plánování kapacit – tento modul byl ve verzi 8.0
kompletně přepracován, stránka „Capacity Planning“ z Clarity 7.5.3 byla změněna na sérii portletů. Kapacitní plánování je nyní komplexnější (stránky kapacitního plánování jsou přidány
do „Team“, „Department“ a „Dashboard“).
Týmy a zdroje mohou být nyní využity
i ve scénářích.
Audit Trail (auditní, prověřovací záznam) – pro zákazníky bude příjemným
zjištěním, že Clarity 8.0 umožňuje pořizování auditních záznamů ve všech objektech při ukládání, změnách a rušení.
Tímto může být vyřešen tradiční problém u zákazníka (Proboha, KDO to vymazal?!!, změnil apod.) Verze 7.5.3 umožňovala
také auditování, ale to bylo omezeno na vybrané
druhy objektů.
Business Process Manager – „workflow engine“
byl ve verzi 8.0 vylepšen a je více flexibilnější.
Podporuje více objektů, subprocesy, akce, více-
násobné kroky, joby a skripty. Dále je zde vylepšené zabezpečení a ověřování, vylepšené „flow“
diagramy.
Clarity Studio – vylepšený modul, podpora „Auto
– numbering“, možnost vypočítávaných atributů,
nově je zde možnost rušení uživatelských objektů
a atributů (ve verzi 7.5.3 je pouze možnost deaktivace atributů, nikoli jejich rušení.) Je zde „Filter
portlet“ pro globální filtrování, parametrizovatelné hodnoty číselníků (hodnoty jednoho mohou
být závislé na dalších), vylepšení akcí pro uživatelsky definované objekty, vylepšené konfigurovatelné zabezpečení a jiné.
Integrace s CA produkty – vylepšená integrace
s produktem CA Unicenter Service Desk a nově
přidaná integrace s produktem CA Unicenter Asset Portfolio Management (UAPM).
Portfolia ve verzi 8.0
O portfoliích jsme mluvili jakožto o „třešničce
na dortu“. Podívejme se nyní, čím nás tato „třešnička“ potěší a překvapí. Project Portfolio Manager je nástroj, obsahující informace, které využívá top management při klíčových rozhodnutích
v souvislosti s dalším rozvojem firmy. Project
Portfolio Manager pomůže odpovědět na otázky
typu: jaká jsou rizika projektů ve firmě, které projekty mají v daném období nejvyšší míru návratnosti investic, které projekty preferovat a jaké naopak utlumit.
Ve verzi 8.0 mohou být v portfoliu zohledněny
všechny standardní typy investic: aplikace, majetek, návrhy, ostatní práce, produkty, projekty
a služby (verze 7.5.3 nepodporovala návrhy ani
služby). Nově je také možné při tvorbě portfolií
počítat též s náklady kapacit rolí (pracovníků).
Tvorba scénářů (otázky typu „co když“)
zůstala zachována, ale Clarity ve verzi 8.0
umožňuje porovnávání těchto variant –
konkrétně jde o zobrazení dvou variant
vedle sebe na jedné obrazovce. Uživatel může tedy vizuálně porovnávat jednotlivá data nebo grafy. Jedná se možná
o drobnost, ale tato drobnost velmi zpříjemní a zrychlí práci. Pomocí nově upraveného panelu nástrojů si můžeme vybrat například námi vytvořené scénáře
„Optimalizace návratnosti investic“ a „Minimalizace rizik a optimalizace benefitu“. A na grafech můžeme třeba porovnat
rozložení investic v čase pro obě varianty
portfolií. Pokud vidíme, že se v určité variantě blížíme námi vysněnému optimu,
ale že to stále ještě není ono, stačí použít
optimalizační nástroj, který nám připraví
podle našich kritérií škálu podrobnějších
variant, ze kterých si můžeme vybrat.
Stejně jako žádný software neřídí fundovaně firmu „sám od sebe“, tak ani optimální portfolia
v systému Clarity ve verzi 8.0 nevznikají sama
o sobě. Na druhé straně nutno říci, že Clarity 8.0
disponuje takovými nástroji, které poskytnou
managementu velké množství podkladů nutných pro rozhodování o strategii ve firmě.
Tolik současnost a Clarity ve verzi 8.0. A co přinese budoucnost? Můžeme se těšit na další verzi 8.1, kde tvůrci produktu slibují další vylepšení.
Ale o tom až jindy.
Karel Gabriel
[email protected]
Podpora mobility v CAS genesisWorld
booku. S pomocí replikace dat je možné propojit
i několik poboček se sídlem firmy. Nevýhodou replikačních stanic můžou být zvýšené požadavky
na výkon hardwarové součásti podnikové infrastruktury, a to jak na úrovni serveru, tak na úrovni notebooků.
Rozhodování je v dnešní době čím dále více závislé na dostupnosti aktuálně platných informací.
CRM aplikace umožňují svým zaměstnancům přístup k relevantním datům, které jim umožňují náhled do historie i současnosti vztahu se zákazníky.
Doposud bylo poměrně běžné, že tyto byly aplikace dostupné pouze v sídle společnosti, respektive ve fyzické blízkosti datového a aplikačního
serveru. V současnosti častěji zaznívají požadavky na dostupnost aktuálních dat od managementu i mobilních pracovníků.
Pracovník pohybující se v terénu býval dříve často vybaven stohy papírů a dokumentů. V lepším případě mohl mobilní pracovník společnosti, který potřeboval nutně ověřit aktuální stav dat
zkontaktovat operátora, který mu poskytl požadovanou informaci. V horším případě se spolehl
na tištěné médium či vlastní paměť.
Taková situace s sebou, kromě nedostatku zajištění požadované informace, nese zvýšené nároky na alokaci pracovních zdrojů, náklady na častý
tisk a rostoucí informační šum, resp. konflikt informačních verzí.
Současná CRM řešení již nabízí několik způsobů
jak podpořit mobilitu pracovníků používající informace uložené v CRM. Nejčastěji se můžeme setkat s těmito produkty:
 www verze stránek CRM řešení,
 speciálně upravené stránky pro mobilní telefony (XHTML, případně WAP),
 synchronizace CRM dat s mobilními zařízeními
(Palm, Windows Mobile, Symbian, Blackberry),
 plná nebo částečná replikace CRM dat.
Téměř každé CRM řešení má zpravidla k dispozici
nějakou formu www rozhraní. Některé CRM řešení jsou dokonce založena pouze na HTML standardu. WWW rozhraní však vyžaduje kvalitní dostupnou internetovou konektivitu v terénu a zařízení,
které je schopno tyto stránky zobrazit. Trendem
je využívání technologií Web 2.0/AJAX. Podmínky
zobrazení www stránek není vždy možné zajistit.
Důvody mohou být různé: např. nedostatek konektivity, zvýšené náklady na pořízení notebooků
při větším počtu zaměstnanců, nemožnost nosit
notebook např. z důvodu jeho velikosti či nedostatku možnosti dobíjení, požadavek na bezpečnost dat (data jsou přístupná přes internet) apod.
Výše zmíněné možnosti podpory mobilních pracovníků nejsou součástí všech CRM řešení. Některá CRM řešení umožňují jen a pouze www stránky,
některá neumožňují synchronizaci s mobilními
zařízeními. Při vytváření poptávky po CRM řešení
je vhodné se informovat a nechat si předvést, jakým způsobem dané CRM řešení mobilitu pracovníků podporuje.
Obr. 1 – Architektura CAS genesisWorld CRM podporuje mobilní zařízení
Kvalitní CRM řešení je schopno poskytnout mobilnímu pracovníkovi možnost přístupu k vybraným
datům formou načtení HTML stránky na obrazovce mobilního telefonu. Speciální stránky pro mobilní telefony usnadňují orientaci na malé obrazovce mobilního telefonu a zkracují tak dobu pro
získání požadované informace. Tyto stránky vyžadují „chytrý“ telefon, tj. zařízení, které je schopno
relativně přehledně zobrazit XHTML stránky. Tyto
telefony jsou však dnes již běžně dostupné.
zařízení. Synchronizace CRM dat s mobilním zařízením může být jedno či obousměrná a je možné ji uskutečnit i v terénu prostřednictvím GPRS/
EDGE/UMTS připojení.
Všechna výše zmíněná řešení podpory mobility jsou vhodná pro menší objemy dat. Pro velký objem dat je vhodné použít metodu replikace
dat na úrovni databází či aplikačních serverů. Nejjednodušší případ zahrnuje podnikovou centrálu
a několik notebooků, nebo chcete-li replikačních
stanic. Pracovník má na notebooku nainstalovaČastým požadavkem uživatelů CRM je také možnou plnohodnotnou CRM aplikaci včetně datanost synchronizace mobilního zařízení s daty
báze a aplikačního serveru. Při příchodu do podumístěnými v CRM. V takovém případě jsou data
nikové centrály synchronizuje požadovaná data
ukládána přímo do mobilního zařízení. Využívá
včetně rozsáhlé databáze dokumentů do svého
se vestavěná PIM (Personal Information Mananotebooku. Varianta využití replikačních stanic
ger) databáze, kterou je mobilní zařízení vybaje vhodná všude tam, kde je potřeba mít s sebou
veno již od jeho výrobce. Uživatel má k dispozici
rozsáhlý objem dat, jejichž synchronizace vyžainformace z CRM i v tzv. off line režimu a pracuduje rychlou konektivitu. Skutečnost, že vybraná
je v důvěrně známém prostředí svého mobilního
nebo i celá podniková data se nacházejí na notebooku je potřeba
zohlednit v IT bezpečnostní politice podniku a poskytnout příslušná
opatření, která zamezí neoprávněnému úniku dat,
například v případě krádeže noteObr. 2 - Možnosti synchronizace genesisWorld s mobilními zařízeními
Výše popsané způsoby řešení podpory mobility
pracovníků jsou integrovanou součástí CRM řešení CAS genesisWorld CRM od společnosti CAS
Software AG. CAS genesisWorld se na trhu orientuje na střední a větší podniky, u nichž je možné
předpokládat využití u 20 až 50 počítačů. Na českém trhu se jedná o novinku, která oslovuje zákazníky především snadnou instalací, implementací
a vysokou přizpůsobitelností potřebám zákazníka. Když k tomu navíc přičteme i příjemné grafické rozhraní a dostupné doplňky pro spolupráci s aplikacemi třetích stran, je CAS genesisWorld
CRM řešením, o kterém je třeba v případě řešení
vztahů se zákazníky přinejmenším uvažovat. CAS
genesisWorld dospěl již do své aktuální verze čísla 9, která přináší další novinky a to nejen směrem
k mobilitě.
Mobilita pracovníků využívajících data v CRM
vyžaduje důkladné rozmyšlení nad odpověďmi
na otázky, Kdo? Kdy? Kde? a Jak? bude podniková data používat. Teprve vhodně provedená analýza, která zahrnuje odpovědi na tyto otázky, nám
umožní zvolit efektivní, bezpečnou a uživatelsky
přívětivou formu zpřístupnění CRM dat pro pracovníky, kteří se často pohybují mimo prostředí
podnikové centrály. Současnost ukazuje, že v budoucnosti bude práce s aktuálními informace
o zákaznících vnímána naprostou samozřejmostí.
Miroslav Žebrák
[email protected]
11
Obsah v systémech WCM
Tento článek se zaměří na nejdůležitější funkční oblast systémů pro správu webového obsahu
(Web Content Management, WCM), a to na samotný obsah. Podíváme se na životní cyklus základní obsahové jednotky - dokumentu - a jakým
způsobem je práce s ním ze strany systémů WCM
podporována.
Životní cyklus dokumentu a workflow
Životním cyklem dokumentu u systémů WCM rozumíme proces pokrývající jeho vznik, úpravy
(různě složité v závislosti na nastaveném publikačním procesu), publikování, stažení z webu a archivaci. Klíčové části životního cyklu dokumentu
v nástrojích WCM (tj. vznik, úpravy a publikování)
formálně popisuje workflow, které lze v kontextu WCM chápat jako množinu stavů, ve kterých se
Obr. 1 - Ukázka workflow
dokument může nacházet, a přechodů mezi těmito stavy. Pokročilé systémy složitost workflow nijak neomezují, a tak je možné publikační proces
namodelovat přesně dle požadavků zákazníka.
Jednoduchá implementace workflow může vypadat např. jako na obrázku 1, kde jsou znázorněny
tři stavy („Editing“, „Reviewing“ a „Published“) a tři
přechody. Každý přechod má svůj výchozí a cílový stav. K přechodům lze nadefinovat dodatečné
akce, které se mají provést. Obvykle se jedná o automatické vygenerování mailu uživateli nebo skupině uživatelů, kteří jsou spjati s daným typem dokumentu a příslušným cílovým stavem. Obecně
by WCM systém měl umožňovat připojit k přechodu provedení libovolného programového kódu.
Struktura dokumentu
Přestože webový dokument je ze své podstaty
z větší části nestrukturovaný, vyplatí se jeho návrhu věnovat dostatečnou pozornost. Na webu se
obvykle vyskytuje více druhů dokumentů – např.
standardní informativní stránka, tisková zpráva,
článek apod. – a každý druh dokumentu má trochu jinou podobu, kterou popisuje tzv. šablona
dokumentu. Šablonu lze částečně přirovnat k de-
finici tabulky v databázi, kde jsou popsány jednotlivé sloupce tabulky a jejich datové typy. Dokumentem by pak v tomto přirovnání byl záznam
v příslušné tabulce.
Typy polí u šablon v systémech WCM jsou však
do značné míry odlišné od těch databázových.
Nejdůležitějším typem je textová oblast, do které
může uživatel vkládat libovolné formátované texty, obrázky, odkazy, tabulky, v ideálním případě
vše, co umožňuje textový editor kancelářského balíku. Další typy polí jsou například prostý text, obrázek, odkaz, výběrové seznamy a mnoho dalších.
Kromě polí, které jsou navrženy administrátorem na základě analýzy, má dokument také svá
metadata (např. datum založení a poslední úpravy dokumentu, autor, připojené workflow podle
kterého bude s dokumentem nakládáno, návrhový vzor,
nastavení bezpečnosti pro skupiny
a uživatele, datum
publikování a „odpublikování“ dokumentu atd.). Některá metadata jsou
vždy spjata s konkrétním dokumentem (např. autor nebo datum poslední změny) a některá lze definovat pro určitou množinu dokumentů (obvykle
dokumenty stejného typu nebo dokumenty nacházející se ve stejné sekci).
Práce s dokumentem
Vlastní tvorba dokumentu je pro uživatele obvyk-
Obr. 3 - Richtextový editor
tém má verzování upraveno
trochu jinak, základní myšlenka
však zůstává stále stejná. Verze
dokumentů vznikají zpravidla
automaticky při zahájení procesu workflow, popřípadě uživatel
může mít možnost vytvořit verzi manuálně.
Verze mohou být zobrazeny
vedle sebe a odlišnosti v porovnávaných verzích bývají uživateli barevně zvýrazněny.
Obr. 2 - Struktura dokumentu (šablona)
Závěr
Práce s obsahem je klíčovou
činností s WCM nástrojem. Snaha výrobců systémů WCM je poskytnout autorům a editorům
veškerou podporu a komfort
le velmi jednoduchá a lze ji přirovnat k vyplňování formuláře. Důležitou předností je, že se uživatel může soustředit pouze
na práci s obsahem a nemusí vůbec znát
způsob a technologie související s tím, jak
bude obsah zobrazen na webu. Nástroje WCM obvykle nabízejí možnost náhledu nového dokumentu ve výsledném designu webu před vlastním publikováním
na živý web. Tuto možnost nejvíce ocení
uživatelé, kteří jsou na konci procesu workflow a kteří zodpovídají za správnost publikovaných informací.
Vícejazyčnost a verzování
Důležitou vlastností systémů WCM je možnost vytváření vícejazyčného obsahu. Nejjednodušší způsob, jak toho lze
docílit, je nabídnout uživateli
totožnou strukturu dokumentu
jako v primárním jazyce. Pro zajištění vyššího komfortu při překladu některé nástroje umožňují vedle dokumentu v novém
jazyce zobrazit dokument v jazyce, ze kterého překladatel při
své práci vychází.
WCM nástroje obsahují také
možnost verzování. Každý sys-
Obr. 4 – Dokument tiskové zprávy
při práci s texty, aby efektivita jejich práce byla
co nejvyšší. Klíčovým předpokladem pro snadné
zvládnutí systému běžného uživatele je důkladné
oddělení obsahu a formy, tj. zcela odstínit uživatele od technologií starajících se o to, jakým způsobem bude obsah vygenerován.
Petr Pšeničný
[email protected]
Správa identity
Mezi nejčastěji řešené problémy v IT dnes patří
snižování nákladů a investic, pravidelné získávání
informací nutných pro rozhodování a hlavně zlepšování služeb, které IT poskytuje. Po IT je požadováno, aby zrychlilo nasazování nových aplikací
pro přímou podporu obchodu a aby je pak dokázalo levně a efektivně provozovat. Nárůst počtu
aplikací však s sebou přináší větší bezpečnostní rizika. Jedním z nejdůležitějších, leč špatně řešitelných požadavků dnešní bezpečnosti je bezpečnost vlastních sítí. Ve většině organizací se jedná
o jedno z nejkritičtějších míst bezpečnosti. Důležitou roli zde hraje správa přístupu, což je schopnost přesně definovat, který uživatel má mít možnost přístupu k jakým informacím či datům, kdy
a jaká má mít konkrétní práva atd.
Odpovědní pracovníci si tato rizika uvědomují
a zvyšují důraz na zajištění bezpečnosti IT systémů a procesů. Jako konkrétní příklad kvalitní defi-
12
nice těchto požadavků si uvedeme opatření České národní banky z února 2004, které je závazné
i pro ostatní banky:
Požadavky na informační systémy v oblasti
bezpečnosti přístupu k informacím
Banka zabezpečí:
přidělení přístupových práv uživatelům v infor
mačních systémech;
jednoznačnou identifikaci a autentizaci uživa
tele, která musí předcházet aktivitám uživatelů
v informačních systémech;
přístup k informacím v informačních systémech

pouze uživateli, který byl pro tento přístup autorizován;
ochranu
důvěrnosti a integrity autentizační in
formace;
zaznamenávání událostí, které ohrozily ne
bo narušily bezpečnost informačních systémů,
do bezpečnostních auditních záznamů, ochra-
nu těchto záznamů před neautorizovaným přístupem, zejména modifikací nebo zničením,
a jejich archivaci;
vyhodnocování bezpečnostních auditních zá
znamů pracovníkem, který nemá možnost modifikovat v informačních systémech informace
související s činností, o níž je bezpečnostní auditní záznam pořízen.
Provozní požadavky na informační systémy
Při provozování informačních systémů musí být

pravidelně prověřována a vyhodnocována jejich bezpečnost.
S uvedeným opatřením jsou v rozporu běžně se
vyskytující jevy v mnoha bankách, ale i v dalších
společnostech. Pro ilustraci uvedeme pouze nejběžnější příklady.
Neplatné účty
To je asi nejčastější případ. Zatímco příchod nového zaměstnance do firmy bývá relativně dob-
ře nastaven a kontrolován, jeho odchod probíhá
podle nějakého procesu spíše výjimečně. Účty bývají často používány i po odchodu zaměstnance –
dál je používá některý z kolegů, na kterého přešla původní agenda. Většina podniků je schopná
toto kontrolovat na dvou až třech klíčových systémech, na další již nemá kapacitu. Ztrácí tak přehled o tom, kdo který účet používá.
Pravidla autorizovaného přístupu
Dalším častým problémem je vlastní definice „autorizovaného přístupu“. Málokdy má společnost
vytvořenou mapu pracovních pozic a k nim příslušných oprávnění v jednotlivých aplikacích. Většinou o příslušných oprávněních rozhoduje přímý
nadřízený. Ale lze si jen těžko představit, že manažer zná u dvaceti aplikací, které jeho útvar používá, přesně všechny možnosti přístupů a komu by
je měl přiřadit.
Kumulace přístupů
Běžný jev, kdy se zaměstnanec posouvá ze své
původní pozice na pozici novou a pro svou práci
vyžaduje další a další oprávnění. Málokdy se řeší
také odebírání přístupů u těch systémů, se kterými již nepracuje a tak se jeho oprávnění kumulují.
Nedostatečný audit
Vyhláška se však nezabývá pouze řízením přístupů k informačním systémům, ale také jejich auditem. V současnosti si většina aplikací řeší audit
svými vlastními prostředky. Problém však nastává, je-li třeba auditovat chování uživatele v celém
prostředí, ne pouze jeho účty v oddělených aplikacích.
Pravidelné vyhodnocování auditu přístupu k informacím bývá kvůli roztříštěnosti zdrojů a formátů tak náročné, že se provádí spíše výjimečně.
V lepším případě se přístup k informacím vyhodnocuje při nepravidelných auditech, v horším se
nedělá vůbec.
Jaká existují řešení?
Existuje několik možných řešení, která se liší přístupem. V následujících odstavcích si nejprve ukážeme typické přístupy nebo spíše stavební bloky
správy identity.
Aktualizace hesel
Cílem aktualizace hesel je snížení ceny a administrativy vynakládané na prosazování autentizační politiky založené na používání důvěryhodných
hesel. Uživatelům umožňuje inovovat svá hesla a případně odblokovávat své účty zablokované kontrolními mechanismy prosazované autentizační politiky pokud možno bez kontaktu nebo
s minimálně nutným kontaktem s help-deskem.
Uživateli umožňuje inovovat své heslo např. aplikací zpřístupněnou standardním www prohlížečem, klientem běžícím pod operačním systémem
jeho koncového počítače nebo interaktivně hlasovou službou poskytovanou vhodným call centrem. Autentizace uživatele se v takových případech řeší typicky principem „něco znám jen já
sám”, tj. odpověďmi na otázky, které může znát
pouze příslušný uživatel.
Synchronizace hesel
Cílem synchronizace hesel je umožnit uživatelům,
aby při interakci s více aplikacemi (systémy) mohli používat stále jediné heslo a usnadnilo se jim
dodržovat zásady stanovené autentizační politikou. Modul synchronizace hesel, na rozdíl od řešení pomocí dále popsaného funkčního modulu
single sign-on (SSO), požaduje zadávání ID uživatele a hesla pro každý přístup ke každé aplikaci (systému).
Zavedení modulu synchronizace hesel v rámci správy uživatelů nevyvolává drastické změny v existující
infrastruktuře IT organizace. Jeho zavedení si vyžádá vynaložení méně nákladů než zavedení principů typu SSO nebo inteligentního koncového řízení
přístupu na úrovni aplikací. Příslušný software pro
synchronizaci hesel typicky běží na některém serveru organizace a přes API je navázán na podporované databáze, na systémy zajišťující bezpečnost
aplikací, na help-desk a podobně.
Single sign-on
Funkční modul jednorázového přihlášení do systému – single sign-on (SSO) lze chápat jako další, propracovanější krok navazující na prostou
synchronizaci hesel ve vývojové linii směřující
k optimální správě uživatelů. Uživatel se přihlásí ke svému počítači nebo do sítě pouze jednou
a k aplikacím (systémům) spoléhajícím z hlediska prosazování autentizační politiky na zavedený princip SSO přistupuje bez nutnosti opakování autentizace. V prostředí podporovaném SSO se
uživatel autentizuje při přihlášení a na obrazov-
ce se mu prezentují dostupné aplikace. Jakmile
si uživatel vybere konkrétní aplikaci, agent SSO
dodá autentizační informace uživatele zvolené
aplikaci „na pozadí“, bez explicitně vyžádané interakce s uživatelem.
Zavedení technologie SSO požaduje implementovat speciální infrastrukturu, ve které se typicky nachází autentizační server, který dříve než
se uživateli umožní přístup k požadované aplikaci, identitu uživatele a jeho přístupová práva
ověří. Systémy SSO jsou při srovnání se systémy
provádějícími pouze synchronizaci hesel vesměs
finančně nákladnější, náročnější na zavedení
a implementaci a také náročnější na vlastní administrativní správu.
Identity & Access Management
Typickými reprezentanty centrální správy uživatelských přístupů a indentit – identity & access
management (v literatuře někdy označováno jako
inteligentní koncové řízení přístupu) jsou produkty, nejčastěji používající webové rozhraní, jako
Policy director z IBM Tivoli, Access/Identity Manager od Sun Microsystems, SiteMinder od Netegrity, ClearTrust od RSA Security, NetPoint od Oblix (nyní pod Oracle) nebo GetAccess od Entrust.
Jsou zabudovány do komplexu aplikací a umožňují řešit správu uživatelů on-line, souběžně s provozováním koncových byznys aplikací. Vesměs
umožňují používat více autentizačních metod, vč.
hesel, digitálních certifikátů, hardwarových nástrojů apod. Umožňují správcům prosazovat politiku přístupu uživatelů k aplikacím centrálně.
Jejich součástí bývá server prosazující politiku přístupu na bázi principu SSO. Integrální vlastností
těchto nástrojů je, že umožňují řízeně delegovat
správu přístupových práv uživatelů na byznys manažery a partnery. Administrátoři těchto nástrojů
mohou rovněž odvolávat individuální a skupinová
přístupová práva k různým zdrojům. Další součástí řešení na bázi těchto nástrojů bývá funkcionalita, která efektivně podporuje aktivaci prostředí
(zpřístupnění informačních zdrojů) a podpůrné
infrastruktury pro uživatele dynamicky požadované v jeho životním cyklu v systému.
Co z toho bude pro nás nejlepší?
Nyní se vraťme k problémům uvedeným na začátku tohoto článku. Protože tyto problémy jsou
způsobeny hlavně složitostí (mnoha aplikacemi
s mnoha účty), tak na prvním místě asi každého
napadne „to celé zjednodušit“. Zařídit to tak, aby
každý uživatel používal v celém prostředí pouze jeden účet a jedno heslo. Je to logická úvaha
– řízení a kontrola přístupů do jednoho systému,
který obsahuje efektivní účty a hesla, je mnohem
snazší než řízení a kontrola přístupů do mnoha
různých aplikací na různých platformách. Tomuto přístupu odpovídá výše zmíněná synchronizace hesel. Z tohoto pohledu také pouhá aktualizace hesel pro nás představuje sice vítaný přínos
v podobě úspory času a prostředků při správě uživatelských identit, není však pokryta oblast autorizace (přístupu) a proto se raději podívejme
na další možnosti.
Dalším krokem k optimální správě uživatelů je implementace SSO, tedy jednorázového přihlášení. Cílem není pouze pohodlí zákazníka, k tomuto
řešení vede snaha o zvýšení bezpečnosti − omezuje se počet případů, kdy zákazník musí při placení udávat číslo platební karty nebo jinou citlivou informaci. Dále na to jediné heslo, kterým se
uživatel přihlašuje do systému (v kombinaci s nějakým dalším HW prostředkem) lze klást nejpřísnější bezpečnostní požadavky, např. co se délky
a četnosti aktualizací týče.
Na druhou stranu je nutno uvést, že v některých
bankách platí bezpečnostní politika, která vylučuje toto řešení (uživatel musí mít jiný účet pro
základní přístup do Windows a jiný v každé obchodně-provozní aplikaci). Věc má ale ještě jeden
háček: implementace SSO je totiž dosti drahá záležitost. Problémem jsou již existující a dlouhodobě provozované aplikace. Existují různé scénáře pro nasazení SSO, ale většina z nich směřuje
k úpravám těchto aplikací. Tyto úpravy navíc často bývají dosti zásadní, takže je obvykle jednodušší celou aplikaci nahradit než ji jen předělat do nového konceptu.
Zkusme tedy změnit směr myšlení a místo snahy
o zjednodušení prostředí budeme řešit, jak zjednodušit činnosti související s řízením účtů a přístupů – jak je co nejvíce zautomatizovat, zprůhlednit a auditovat. V tom okamžiku se přesouváme
do oblasti produktů typu Identity & Access Management.
Identity and Access Management
Co vlastně Identity and Access Management (IAM)
znamená? Na jedné straně je IAM systém napojen na aplikace řízení lidských zdrojů (HR systém)
a na straně druhé jsou k němu připojeny aplikace, které on ovládá. Pro každého uživatele IAM
systém vytvoří jeho entitu (podle HR systému),
ke které přiřadí všechny uživatelem používané
účty v cílových aplikacích.
Oproti přístupu založeném na synchronizaci hesel
tedy na spravovaných systémech zůstávají různé
účty a hesla, IAM systém již o nich ví. Ví komu patří a ví i jaká oprávnění na tom kterém systému jednotliví uživatelé mají. V okamžiku změny (odchod
zaměstnance, postup na jinou pozici), je schopen
podle definovaných pravidel tuto změnu propagovat i do těchto systémů (zakázání účtu, přiřazení jiných oprávnění atd.). A protože je vše v databázi, dokáže z toho udělat i smysluplné reporty
pro auditní zprávy.
Nyní se pokusíme vyjmenovat některé základní
přínosy IAM, abychom se přesvědčili, že jeho nasazení opravdu za to stojí.
Bezpečnost založená na rolích
Toto je jeden z největších potencionálních přínosů IAM systémů.
Systém umožňuje nadefinovat uživatelské role
a k nim příslušné aplikační přístupy (takové role
mohou odpovídat např. pracovní pozici). Při změně pozice pracovníka pak IAM systém jednoduše
opraví (nebo zruší) všechny jeho přístupy a účty
automaticky.
Centralizace a automatizace správy účtů
Celý proces správy účtů je prováděn z jednoho
místa – IAM systému. Správce účtů pouze definuje role a jim odpovídající přístupová oprávnění v konkrétních aplikacích, ale již nemanipuluje
s konkrétními účty.
Rekonciliace
Rekonciliace nebo také „sladění, uvedení do souladu“ prakticky znamená, že IAM produkty dokáží
identifikovat manuálně vytvořené přístupy, které
neodpovídají žádné roli a upozornit na ně administrátora oprávnění, případně je automaticky
opravit.
Jednoduchý audit
Všechny operace (vytvoření/smazání uživatele,
změna role, změna hesla, atd.) jsou auditovány
na jednom místě. Pokud někomu nebudou stačit
reporty dodávané s produktem, tak u většiny produktů je otevřená databáze, ze které je možné si
dělat svoje vlastní výstupy.
Řešení problému odemykání účtů
IM systémy totiž umožňují delegovat některé operace (například smazání zapomenutého hesla)
na samotného uživatele. Pomocí “webové samoobsluhy“ tak může uživatel všechna svoje hesla
měnit/mazat v jednoduchém webovém formuláři
sám a ušetřit tak náklady na help–desk.
Další výhody Identity & Access Managementu
Mezi další výhody IAM, které jsou také velmi zajímavé, patří například:
snížení počtu pracovníků zabývajících se říze
ním přístupů (díky automatizaci operací);
zrychlení vyřizování žádostí, jejichž stav si může

sám uživatel kdykoliv zkontrolovat;
relativně krátká doba implementace - vzhle
dem k tomu, že IAM produkty jsou víceméně
krabicová řešení a existují konkrétní postupy,
jak je nasadit, je doba jejich implementace rozhodně kratší, než doba implementace jednotného front-endu;
efektivní plánování SW licencí (software assset

management) - role-based security (a tedy vytvoření mapy aplikací příslušných konkrétních
pracovních pozic) poskytuje přesný přehled
o potřebných licencích a může sloužit jako další zdroj dat pro asset management.
Shrnutí
IAM produkty přímo řeší část požadavků z výše
uvedeného opatření ČNB. Zavádějí přehled a pořádek do problematiky řízení přístupových oprávnění k informačním zdrojům bez nutnosti zásahu
do provozovaných systémů.
Díky větší efektivitě a automatizaci procesů v oblasti zabezpečení, auditu a správy účtů, lze ve většině případech spočítat i poměrně rychlou návratnost investice, která se může projevit dokonce již
po prvním roce (dokazují to analýzy renomovaných firem jako jsou např. META Group nebo Gartner group). Dlouhodobé analýzy společnosti Gartner consulting a dalších se zaměřením na ROI
(Return Of Investment) v oblasti IAM (Identity and
Access Management) systémů ukazují, že IAM řešení vede ke zřejmému a hlavně měřitelnému ROI.
Jan Krejčí
[email protected]
Centrální správa uživatelských účtů a přístupů
13
Dva vidláci ve Vegas
Tak nás uvrtali do služebky do té Ameryky. Praktycky to znamenalo napsat Amíkům
o to jejich visum. Asoška nám stáhla formy
z webu, do kterých sme naklofali naše údaje
a naplili vodpovědi na asi milión blbónskéch
otázech stylu, jestli tam pré povezu nejaké
rostlinky bo semena. Na ambošce se ukázalo,
že ten ofiser není úplně mimo, nebyl žadné
béčko, bo hned chytal, co je to džejtuyi archytekt. Řikal, že nějaké patek dělal pro ajbiem a tak, že sčastnó cestu. Aj název naši kompany se mu líbil, bo pry na tom je odkojeny
každy Ameryčan. Dostat se pomalu před rozedněnim na letiště bylo dost krušné, ale co
naděláš, když máš byt na tem aeroportě dřív
než mozol opusti diru. Nakonec sme se zorientovali podle mechu a mravenišťa a trefili ten správné terminátor. Pasovka nebyla pasova, ale celkem v ouklendu, jenže ta baba
na rentgeně chtěla vyhotit či vylabat obě butylylky co sme si šanovali na ten vylet do noveho světa. To by nebylo to jen tak vylét. Tož
sme to kósli hned u téch elektrickéch futer.
Air Dolomity nas trochu poděsilo, ale obě
italske letove pinglice s prořidlim obočim
byly tak fajne, že jsme přežili i v tom omezenem prostoru, kde místo snídaně servírovali
dětskó výživu.
Zato Luftka měla v Airbusu do Denver místa dost a hlavně měla vinisko, keré se dalo
pit. Těch cirka 128 litru bileno kyvča a 150 litru cabernetu mohlo stačit, akorat ten pikolik to měl daleko do sklepa. Tak náš závazek
stihnót každéch sto kilometru jednu decku
vzal nad Reykjavikem za svoje.
Film s Cameron Diaz byl blby, jak software
od jednorožců. Tož sme radši psali nabidku
na komplexni řešeni pro velkeho telefoniho
operatora.
V Denveru na pasovce byla ta malá Mexičanka tak rozhozená z našich novéch biometrickéch pasů, že sme jí museli třikrát vysvětlit odkud že jako sme a že to fakt dělá naše firma.
Tak pokec to byl dobrý, akorát to éro do Vegas
nám kvůli tomu nemuselo uletět. :-(
No co 10 hodin na letišti nam uteklo jak splašená želva do kopca.
Ve Vegas byla kosa, jak u nas loni o Vanocich.
Když druhé den dokonce pršelo, tak jsme
preventivně skočili do recepce položit dotaz
jestli není eště další Vegas nekde jinde, kde
je tepléš?!
Cele nám to tam připadalo postavené na hlavu, tak sme zašli na horskó dráhu, kde se jede
aji hlavó dolu, jestli se to jako spravi aspoň
na tu chvilu co pojedeme tém uvřeštěném
vláčkem.
Jak sme byli jen v kraťasech, zašli sme do
kasina než na vélet do póště. To taky nebyl
nélepší nápad. Ruleta se s nama nemazlila.
Tož Ameryka, nestačí jim jedna nula musijó
mět hned dvě a vobě zelený. Když ten borec
v motýlku a vestičce hodil třetí nulu za 6 her,
tak jsme se shodli, že tu mají nejenom jinó
ústavu, ale aji jinačí zákony pravděpodobnosti. Po 20 minutách se všecky naše love
přestěhovaly kamsi pod stul v kasinu. Nakonec jsme nedopadli tak zle. Jedneho Amery-
14
čana tam dost komplikovaně křisili ze mdlob,
jenom nevime, jestli jak všechno projel, nebo
to měl od radosti.
Už v letadle sme řešili jestli radši zajdeme
na muzikál o ABBĚ – Mama Mia, nebo o Menopause, ale nakonec zvytězili modři lebkouni,
bo ani na čipendejs nebyl nikdo z nás zvědavé.
To sme nechápali co všechno se da zabubnovat na normalni trubku vod záchoda (záchod
na jeviště nenosili; eště že tak!).
Chceli sme děckam přivezt nějaky ten suvenyr tak sme trochu zašopovali. Nakonec
to bylo stejně zbytečné, protože na zpáteč-
ní cestě se jeden kufr zdržel čertvi kde a už
vůbec nikdo nevi kdo se vněm hrabal. Bombony pro sviště aji další prkotiny z kufru jaksi
vyprchali, či co. Eště že vim, že je ten kufr teď
bezpečny, bo to ma na sobě nalepené „Security Checked“. Že ten tramin, co mě ho vybrali, je bezpečny se nás mohli zeptat, koštovali
sme ho předem, tak to musime vědět! Oni to
už taky vijó, když mě s tó flaškó čórli aji švýcarák s vývrtkó :-(
Náš děda byl 40 let haviř, ale takovó díru
za celé život neviděl (šak taky jak, když v havirni je tma?). Jeden by nevěřil, jak só ti Indoši fikani! Aby měli na vohnivó vodu a nemuseli dělat, tak přes kraj té vobrovské propastě
dali tabulu skla, aby trčela deset kroků nad
díru, na druhé konec hodili kvich a za 25 peněz tam každýho pustijó hodit čučku. Foťáky
nás tam nenechali vzít, tak nám holt musíte
věřit, že to tak je!
Poslední den už byl pařák tak sme eště vyrazili do Arizóny (bo je to pravéch chlapů zóna,
tak to bez nás nemohlo jít) podívat se na tu
Velkó díru (Amíci tomu říkají Grand Canyon).
Vaši komixaci komičti
P.S.: no a ta konference byla taky moc dobra
Na chvíli odložte své obvyklé pracovní nástroje notebook a mobil, najděte si ořezanou tužku (nejlépe HB) a používejte chvíli palec (SMS finger) a ukazováček (left
mouse click finger) společně a koordinovaně.
Úkoly
Řiďte se následujícími pokyny:
1) očíslované plochy obrázku A vyplňte
2 šedě 20%
5 šedě 50%
8 šedě 80%
2)očíslované body v bublině obrázku A spojte čarou
v daném pořadí (vzestupně)
počáteční bod úseku
bod zlomu lomené čáry
hladký bod, proložte křivku
koncový bod úseku - přejděte na další bod
se zvednutou tužkou bez kreslení spojovací čáry
3) najděte nejkratší cestu bludištěm B
4) přečtěte tajenku skrytou v nejkratší cestě
5) kroky 1 a 2 proveďte pro obrázek C
6) kolik rozdílů jste našli mezi obrázky A a C ?
Tomáš Vahalík
[email protected]
A
b
c
15
Děkujeme všem
našim klientům
za důvěru
KOMIX s.r.o.
Anděl City, Radlická 3185/1c, 150 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz, Redakční zpracování: kolektiv pracovníků KOMIX s.r.o.
DTP a produkce: BC Graphics, s.r.o.,
© Komix s.r.o. 2007
16