komixí noviny 2007 / 2008

Transkript

1 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. 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. 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, Komerč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 kucera@komix.cz 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

2 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 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 N E 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 tak, že do vstupního pole portálu zadáte loc: Měl by se Vám zobrazit Pražský hrad. Některé typy geocache Pokud je skrýš s pokladem uložena přímo na uvedených souřadnicích, pak je to tradiční geocache. 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. 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ě: N E 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ě. Určíme A = počet sloupů můstek podpírající, včetně těch u zdí budov. Určíme B a C = číslo popisné (červené) vlevo na zdi budovy je 2BC0. 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) E (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). 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) E (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) E (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) E (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 u - 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. 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 do potíží s určováním souřadnic či dohledáváním finální cache, obraťte se na výše uvedený . Nápověda/Hint cyrpu Decryption Key A B C D E F G H I J K L M N O P Q R S T U V W X 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 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 Martin Lipš lips@komix.cz Softwarové řešení pro e-pasy 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. Hlavním dodavatelem rozsáhlého technického řešení, zajištujícího funkce potřebné pro vydávání 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. Architektura řešení 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 zbarvené), 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ě. Samoobslužné kiosky na kontaktních místech umožňují držiteli e-pasu ověřit funkčnost čipu. 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. 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: 2

3 fotografický přístroj a příslušný softwarový modul, 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živatelský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. Klientské aplikace jsou vytvořeny v technologii.net, která nejsnáze umožňuje integrovat uvedené množství různorodých komponent, jejichž ob- Kontaktní místa Aplikace Aplikace pro Aplikace kontaktní pro kontaktní promísta kontaktní místa místa Kiosek Kiosek Kiosek Evidence cestovních doklad Národní certifika ní autorita 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ž žá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. Ministerstvo vnitra Evidence obyvatel Aplikace centrálního systému Dohledov systém Cizineck IS Správa u ivatel Aplikace pro v m nu dat s STC off-line off-line Systém MZV Státní tiskárna cenin Certifika ní 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ě, který je rovněž uložen na čipové kartě; šifrování biometrických údajů žádosti pomocí 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 Petr Sobotka sobotka@komix.cz 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). 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í. 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 ve své příjmové části zajišťuje tyto automatizované procesy: přiřazení externě pořízených PPPZ zaměstnavatelů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í 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 Systém zároveň plní funkci analytické evidence účetnictví. Obr. 2 Architektura systému 3

4 Obr. 3 Procesy kontrolní činnosti 5.Výdajová část Základem je evidence smluvních partnerů a pojištěnců (Registry). Vstup dokladů probíhá ze souborů v rozhraní VZP. 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. 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. Ruční revize (RL) Revizní lékař má při ruční revizi v rychlém dosahu všechny dostupné informace potřebné k rozhodnutí. Historii pacienta, smluvní podmínky zařízení, vazby mezi zdravotními doklady. Obr. 4 Automatizované procesy ve výdajové části 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í. Zúčtovací zpráva (ZZ) Zúčtovací zpráva obsahuje informaci o tom, v jaké částce jsou zdravotnímu subjektu proplaceny vykázané doklady a pokud došlo ke korekcím, tak vysvětlení, proč k nim došlo. Vazba IZOP/NIS do účetnictví RIS Důležitou nadstavbou (jenž byla zmíněna již v bodě 2.3 Rozhraní) IS je rozhraní IN- VRIS (OZP)/XIS (VoZP) mezi IS Pojišťovna (IZOP/NIS) a účetnictvím RIS. V rámci zajištění funkcionalit vazeb do účetnictví, je možné realizovat tyto následující kroky: prohlížení jednotlivých položek účetních dokladů nastavení účetního období Obr. 5 Výdajový okruh zpracování dávky příprava podkladů na základě platebních povinností osob, vyúčtování Přehledů OSVČ a předpisů pohledávek z kontrolní činnosti (penále, pokuty) tvorba účetních dokladů inventury účtů Jednotlivé účetní záznamy z IS Pojišťovna (IZOP/ NIS) jsou seskupovány do účetních dokladů. Prohlížení těchto účetních dokladů je možné právě v rozhraní INVRIS/XIS. Pomocí této aplikace lze prohlížet i prvotní záznamy zahrnuté do účetních dokladů (předpis PPPZ, předpis penále apod.). Jiří Tománek, Pavel Körner tomanek@komix.cz; korner@komix.cz 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 ( 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š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 portá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 produkovaná vlastním IS pojišťovny, zpracovává xml soubory obsahující data shromážděná portálem umožňuje přenos dat v komprimované podobě (inovace k ) 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 byl zahájen také provoz portálu Vojenské zdravotní pojišťovny ČR. 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 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účtová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í fdavka a kdavka) Podání sestavy hlášení úrazu Žádost o výpis Přehled kapitovaných pacientů 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ěstnavatele Žá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ěstnavatele 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. 4

5 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á em 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řednictví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 registrů 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 korner@komix.cz 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. 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. Výkonnostní limity pro ZT aplikace JOK/ISP 3.1 Typ uživatelské odezvy aplikace 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í 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 / VU: 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 Výkonnostní limit pro uživatelskou odezvu aplikace (s) Výkonnostní limit pro uživatelskou odezvu aplikace (s) ZT v roce 2005 ZT v roce 2006 odezva na jednoduchý dotaz 5 5 složitější dotaz nebo přehled čas přihlášení 5 s z 80 %, 10 s z 20 % 5 s z 80 %, 10 s z 20 % zobrazení jednoduchého seznamu 5 5 či detailu zobrazení odměn - jednoduché zobrazení odměn - složité zobrazení souhrnného přehledu 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: 1. Monitorování paměti Byl sledován parametr velikost volné operační paměti pro DB servery, aplikační a webové servery. 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. 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. Odezvy transakce Elektronická distribuce souborů 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. 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. 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 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ý vrsecky@komix.cz Výsledky ZT v sec - průměrné hodnoty Kroky Limit (134 VU+ navýšení na 268 VU) VU VU 1000VU Plná zátěž 400 Plná zátěž 400 Plná zátěž v sec. login 5 z 80%, 10 z 20%* 1,5 57,763 0,497 0,483 GUI ,155 99,674 0,085 0,087 zadani 1 pozadavku 15 1,349 93,02 0,07 0,096 prehled_stah_souboru 10 0, prehled_pozadavku_ , ,487 0,156 0,18 stazeni_souboru 0,962 57,858 0,249 0,247 logout 5-44,977 0,281 0,348 * limit pro transakci login 5 sec. v 80% měření a 10 sec. ve 20% měření 5

6 Virtualizace testovacího prostředí 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. 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. 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 Test- Director 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 kovanic@komix.cz Čí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 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. 6

7 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! Ř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í velmi úč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. Obr. 2 - Srovnání jednotlivých variant modelů podle výkonnosti a finanční náročnosti 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í 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ý dan.petrivalsky@komixbrn.cz 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 sobotka@komix.cz 7

8 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. 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 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. 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 inkrementů 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 vahalik@komix.cz 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. 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,...) 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ří: čí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 pomocí 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. Č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). 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). 8

9 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. 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 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) Obr. 2 Rozšíření KUP 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. 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) 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. 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 ciha@komix.cz 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 ové 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) 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í) Maily mohou být filtrovány dle záhlaví přímo 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 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) 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 Přidání vlastní poznámky do požadavku, pozná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 ovou 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 Systém Programovací jazyk Perl Databáze MySQL Podpora ASP (Activ Service Providing) Rozhraní databáze XML Databázové vrstvy, podpora jiných SQL databází (MySQL, PostgreSQL, MaxDB/SAPDB, Oracle a DB2) Domovská stránka: Petr Ebr, Jaroslav Kahoun ebr@komix.cz; kahoun@komix.cz 9

10 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). Vysokokapacitní rozhraní USB 2.0 Zdařilá konstrukce, pevné pouzdro, kompaktní, nosí se na kroužku s klíči Kapacita paměti pro vaše vlastní aplikace 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. Na midentity lze provozovat certifikovanou zabezpečenou diplomatickou poštu, používají je američtí vojáci i síly NATO a také řada komerčních organizací nebo banky. Více detailů lze najít na Nenechte si nikdy vzít svou identitu, chraňte si ji! Petr Kučera kucera@komix.cz Kontrola vstupu a registrace času Zabudovaná bezinstalační mobilní aplikace Vysoce výkonná čtečka karet Smart Card Reader ve formátu SIM karty, včetně E4-high-evaluated smart karty 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. 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. 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. 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. 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é. 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 nazývaný Portfolio Manager) v portfoliích je nyní možné pracovat i s Návrhy (Ideas), portfolia mohou oproti verzi 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 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 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 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- 10

11 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 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 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 gabriel@komix.cz Podpora mobility v CAS genesisworld 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. 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é. Častým požadavkem uživatelů CRM je také možnost synchronizace mobilního zařízení s daty umístěnými v CRM. V takovém případě jsou data ukládána přímo do mobilního zařízení. Využívá se vestavěná PIM (Personal Information Manager) databáze, kterou je mobilní zařízení vybaveno již od jeho výrobce. Uživatel má k dispozici informace z CRM i v tzv. off line režimu a pracuje v důvěrně známém prostředí svého mobilního Obr. 2 - Možnosti synchronizace genesisworld s mobilními zařízeními 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 nainstalovanou plnohodnotnou CRM aplikaci včetně databáze a aplikačního serveru. Při příchodu do podnikové centrály synchronizuje požadovaná data včetně rozsáhlé databáze dokumentů do svého notebooku. Varianta využití replikačních stanic je vhodná všude tam, kde je potřeba mít s sebou rozsáhlý objem dat, jejichž synchronizace vyžaduje rychlou konektivitu. Skutečnost, že vybraná 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 notebooku. 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ů. 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. 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 zebrak@komix.cz 11

12 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 definici 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. Obr. 3 - Richtextový editor Obr. 2 - Struktura dokumentu (šablona) 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 obvykle 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ý systé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. 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 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ý psenicny@komix.cz 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í definice 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 informačních systémech; jednoznačnou identifikaci a autentizaci uživatele, 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í informace; zaznamenávání událostí, které ohrozily nebo narušily bezpečnost informačních systémů, do bezpečnostních auditních záznamů, ochranu 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. 12

13 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 obrazovce 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 řízení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 - vzhledem 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čí krejci@komix.cz Centrální správa uživatelských účtů a přístupů 13

14 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. č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ó :-( 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). 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! Vaši komixaci komičti P.S.: no a ta konference byla taky moc dobra 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

15 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 vahalik@komix.cz A b c 15

16 Děkujeme všem našim klientům za důvěru KOMIX s.r.o. Anděl City, Radlická 3185/1c, Praha 5, Tel.: , Redakční zpracování: kolektiv pracovníků KOMIX s.r.o. DTP a produkce: BC Graphics, s.r.o., Komix s.r.o